Is this on an Intel mac?

No, primarily a 500mhz cube with 1.5 gig RAM. Duplicated on 1.67 gig Powerbook with 2 gig RAM.

Same OS, Perl versions on both

Perl version? (perl -v)

Got 10.4 running on a Cube? 

Sounds very strange, works fine here with 10.4 and Perl 5.8.6, but this is G5..

5.86... not a Perl version issue...

but, perhaps an IO::Socket version issue?
that is the module that provides the sockaddr_in function

(In reply to comment #6)
> but, perhaps an IO::Socket version issue?
> that is the module that provides the sockaddr_in function
> 

If it is, then its an issue with the version in the installer... I'm not using subversion... any other ideas?

can't replicate in latest version (01-28) as it doesn't get to the SlimP3 protocol... chokes on: "Can't locate object method "_new" via package "GD::Image" at /Library/PreferencePanes/SlimServer.prefPane/Contents/server/CPAN/GD/Image.pm line 83."

I'm seeing this on my G4 Powerbook still today.

FWIW, I'm hitting this too, with the 1/24/06 build.  This is on an old PMG4 (450 MHz uniprocessor) running 10.4.4 with all latest Apple patches (current as of noon today).  I haven't monkeyed with the Perl install or libs in any way, it's just plain vanilla whatever Apple supplies (perl -v says 5.8.6, IO::Socket is 1.28, IO::Socket::INET is 1.27).

I just checked in a fix for this - please give it a try. Change 5913.

I just patched in change 5913 to my 1/24/06 build by hand.  No joy -- slimserver still barfs in the same way.

Can you do a print "ip: [$ip] port: [$port]\n";  in that function?

ip: [192.168.43.2] port: [3483]

And what's the output from:

inet_aton(192.168.43.2)

and sockaddr_in($port, (inet_aton($ip))

if run from a test script? You'll need to "use Socket"

In answer to your question:

--
use Socket;
$myaddr = "192.168.43.2";
$myport = 1234;

$ip = inet_aton($myaddr);
print "ip is ", inet_ntoa($ip), "\n";
$sin = sockaddr_in($myport, $ip);
print "sin is $sin\n";
--

gives this output:

--
ip is 192.168.43.2
sin is ???+
--

Which is pretty much as expected.  HOWEVER, in refreshing my Perl memory I was browsing the Perl socket documentation which gave me a little hint.  The documentation says in part

--
sockaddr_in SOCKADDR_IN
In a list context, unpacks its SOCKADDR_IN argument and returns an array consisting of (PORT, ADDRESS). In a scalar context, packs its (PORT, ADDRESS) arguments as a SOCKADDR_IN and returns it. If this is confusing, use pack_sockaddr_in() and unpack_sockaddr_in() explicitly.
--

On a hunch, I replaced the return with a pack_sockaddr_in() to force the scalar context, so now I have

--
return pack_sockaddr_in($port, inet_aton($ip));
--

And lo and behold, it appears to be working!  This does indeed seem consistent with the error that's in the bug description -- the function seems to think it's being called in a list context and wants to see a SOCKADDR_IN as its argument.  I don't know why it thinks it's being called in a list context, but there you have it.  

It might be interesting to know if everyone seeing this bug has multiple active network interfaces on their computer.  I do.  One of the other people talks about a Powerbook, and they often have two interfaces (Ethernet and Airport).

It's called by

sayHello($udpsock, ipaddress2paddr($clientid));

in the SliMP3 protocol handler, and this is it.

Seems to me the above calls for list context, so ipaddress2paddr as well, and I guess the socket call likewise. Can we replace the call by the proposed value and close this? (annoying red line in my bug list :-))

just want to confirm that this error persists in last nights build.

Any use trying a newer build?

just caught this thread:

http://forums.slimdevices.com/showthread.php?t=21969

Someone blissing out over 6.5b1 on an IntelMac...

Has there been a change that has closed this bug?

Fixed in change 6965.

Sorry for the delay.