Yes, it's a bug. I see the same thing (running SbS 7.6 and 7.6 firmware). It's easy to test: just halt the server program on the server while a song is playing on the Touch. It plays out the buffered data, then goes silent while it continues to 'think' and act like audio is playing. When it gets to the end of the track it then just hangs there in the NP screen, never goes into the stopped state and never displays the stopped screensaver.
The reason that nobody else has noticed it? Probably few people shut down their server in that manner. Many people (like myself) never shut down their server at all. It's just another one of those things that nobody in QA and none of the developers thought to test. The reason that it only happens on the Touch (and most likely the Radio too)? I would say for two reasons: 1) The Touch and Radio are in their infancy compared to the maturity level of the older Squeezeboxes. 2) The Touch and Radio are less 'thin' that previous Squeezeboxes, with less dependence on the server. So when the server goes away, its less disruptive, but apparently the software isn't robust enough to realize it. Here's a bug that's essentially the inverse situation. It doesn't know that it's playing music, so the Now Playing screen goes away and it kicks into the idle screensaver. Marked with a low priority for some reason. http://bugs.slimdevices.com/show_bug.cgi?id=15431 Obviously there are problems with the device (or at least the display side of the code) actually knowing what state it's in. -- JJZolx ------------------------------------------------------------------------ JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10 View this thread: http://forums.slimdevices.com/showthread.php?t=83736 _______________________________________________ Touch mailing list Touch@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/touch
