mathieu.goessens at irisa.fr
Wed Feb 16 19:20:38 CET 2011
On 16/02/2011 18:52, Ignatios Souvatzis wrote:
> On Wed, Feb 16, 2011 at 09:08:12AM +0100, Ignatios Souvatzis wrote:
>> one "mplayer" binary as compiled (from pkgsrc) for Solaris 10/Sparc
>> (64bit) tries first to connect to such addresses, then, after timeout
>> to the correct one.
>> I've never had the time to find out where exactly this goes wrong.
> Ok, here's the short test:
> ignatios at einstein 24 % !!
> mplayer http://www.multicast.org.uk/absoluteradio/aruk-ar-ipv4.sdp
> MPlayer 1.0rc2-3.4.6 (C) 2000-2007 MPlayer Team
> CPU: Sun Sparc
> 115 audio& 237 video codecs
> Playing http://www.multicast.org.uk/absoluteradio/aruk-ar-ipv4.sdp.
> Resolving www.multicast.org.uk for AF_INET6...
> Connecting to server www.multicast.org.uk[984e:bd05::]: 80...
> connection timeout
> Resolving www.multicast.org.uk for AF_INET...
> Connecting to server www.multicast.org.uk[188.8.131.52]: 80...
> Cache size set to 320 KBytes
> Cache fill: 0.11% (364 bytes)
> Exiting... (End of file)
> Note that in my case it's not a wrong-endian ::184.108.40.206, but a
> 220.127.116.11:: , if you want to express it that way.
> snoop shows nothing surprising (see below). It's really only misguided
> name resolution, although I didn't look up the code yet.
It should be interesting to test if you have the same problem using for
In this case, the problem should not be on mplayer but may be on the
resolver itself (or in the implementation of getaddr() ?!)
I don't have anything particular when trying to use it (and NS looks to
geb at arkintoofle:~$ dig www.multicast.org.uk AAAA +short
geb at arkintoofle:~$ mplayer http://www.multicast.org.uk/absoluteradio
Resolving www.multicast.org.uk for AF_INET6...
Connecting to server www.multicast.org.uk[2001:630:d0:f104::de80]: 80...
IRISA, Campus de Beaulieu, 35042 Rennes cedex, France
Tel: +33 (0) 2 99 84 71 00, Fax: +33 (0) 2 99 84 71 71
More information about the ipv6-ops