Hi all, I'm still seeing this odd, but completely recreatable, problem after turning on the controller with current builds (SC 17533; SBC r1946). I haven't seen anybody else describing quite this behaviour, and I'm not sure whether Slim are looking at it or not. (I haven't opened a bug yet, if it's just me seeing this is there much point?)
Could somebody try these steps out and see if they get the same problem? 1. Start in a good state with controller and player working. 2. Power down/power up the controller. 3. The controller is now unusable - see below. 4. Find the IP address of the controller and ping it. I see it either not respond at all, or respond to every fourth packet. 5. Put the player into configuration mode, and use the controller to configure it (Settings->Advanced->Set Up Receiver). Let the configuration process go through. 6. The controller now works perfectly again, just like we started with. 7. Ping the IP address once more - you should now see 100% response. After step 2 the controller may not connect to the server at all; if it does it shows a number of symptoms all related to poor connectivity: not showing player status updates, and failing to retrieve artwork or album/artist lists. Controlling the player seems okay (though it doesn't always reflect the changed player status) Responding to every fourth ping packet is curious; for example (note the icmp_seq numbers): > $ ping 192.168.1.38 > PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data. > 64 bytes from 192.168.1.38: icmp_seq=4 ttl=64 time=3.85 ms > 64 bytes from 192.168.1.38: icmp_seq=8 ttl=64 time=9.71 ms > 64 bytes from 192.168.1.38: icmp_seq=12 ttl=64 time=6.84 ms > 64 bytes from 192.168.1.38: icmp_seq=16 ttl=64 time=9.28 ms > 64 bytes from 192.168.1.38: icmp_seq=35 ttl=64 time=9.44 ms > 64 bytes from 192.168.1.38: icmp_seq=39 ttl=64 time=7.99 ms > 64 bytes from 192.168.1.38: icmp_seq=43 ttl=64 time=6.53 ms > 64 bytes from 192.168.1.38: icmp_seq=47 ttl=64 time=6.98 ms > 64 bytes from 192.168.1.38: icmp_seq=51 ttl=64 time=5.02 ms > 64 bytes from 192.168.1.38: icmp_seq=55 ttl=64 time=5.90 ms > 64 bytes from 192.168.1.38: icmp_seq=59 ttl=64 time=6.40 ms > > --- 192.168.1.38 ping statistics --- > 61 packets transmitted, 11 received, 81% packet loss, time 60011ms > rtt min/avg/max/mdev = 3.859/7.090/9.714/1.784 ms > It's as if the wireless isn't starting up properly on power up; but when it switches to an ad-hoc network (for configuration) and back again it resets itself. I get this exact behaviour with both old and new beta controllers, so it's not likely to be a hardware issue... either SBC software or something strange with my network! Ian -- iwp http://www.last.fm/user/iwp/ ------------------------------------------------------------------------ iwp's Profile: http://forums.slimdevices.com/member.php?userid=409 View this thread: http://forums.slimdevices.com/showthread.php?t=43243 _______________________________________________ jive mailing list [email protected] http://lists.slimdevices.com/cgi-bin/mailman/listinfo/jive
