Bugzilla – Bug 10841
SC reverts to last stream played if ShoutCast server reached max. # listeners
Last modified: 2009-10-05 14:29:53 UTC
Created attachment 4713 [details] Screenshot WebUI (player pane) SC7.4-24751/Windows: When switching from one internet radio stream to another that has reached its maximum number of listeners, a player briefly shows the error message "Error: Playlist has no items" then reverts back to the last stream played and the WebUI looks messed up. Also the sound was *very* different (1st stream played: 96 kbps CBR mp3PRO, 2nd stream: 128 kbps CBR MP3). I think either the player should show a (correct) error message and stop, or *maybe* revert back but set playing params and display correctly. Streams played (both from Favorites): 1st stream: Das Wunschradio http://www.daswunschradio.de/listen.m3u 2nd stream: Radio Luxembourg http://s8.mediastreaming.it:7050/listen.pls The 2nd stream is from a ShoutCast server (1.9.8/Linux) and has a listener limit of 200 listeners which were reached at the time of my connection attempt. I can reproduce this behaviour here by using my own ShoutCast server, setting it to a small listener limit (like 2 listeners). I assume maybe the ICY-message isn't read correctly or the "revert to whatever else was played before"-logic is messed up. Also see attached screenshot.
Andy: care to address this
I've noticed this too, if you're playing something and try to play something else that fails, the previous item plays again. Maybe this is intended. Alan?
I think that I need more detailed instructions to reproduce this because when I try to play a bad URL, for example, when playing another track, I just get an error message followed by silence.
Easy: Set up a local shoutcast server (either Linux or Windows) with a maximum listener count of, say, 2. Stream something and have 2 listeners (players) listening to the stream, so the server is "full". Using SC and any player connected to it, tune to some OTHER internet radio stream, THEN tune in to your "full" shoutcast server, and it will happen. You may want to place both the "regular" radio and your "test radio" into Favorites, so it can be exactly reproduced. (If you don’t have the resources to set up your own shoutcast, AND we can agree on a time (I’m in Germany), I could probably help out setting up a "mini test server" running here and streaming *very* low bandwidth over my ADSL connection.)
Change 25406 should fix this. It would be good if you can verify this.
Ok, I’ll set up a testbed later and give it a try. May take one or two days, though.
Ok, managed to squeeze the time in: Confirm solved with SC 7.4-25416. Good job, thanks! "Shows briefly" on Controller "400 Server Full" (from the icy 400 message that comes from the server) and waits for further user interaction. The stream that played before is stopped, no "jumping back" (or forward) happens anymore. Just as it should be. Tried with two different SHOUTcast servers, v1.9.8/win32 and v1.9.8/Linux, seems to work reliable. The code change in StreamingController.pm looks good to me.
Also fine on SB3: Shows blank screen with "400 SERVER FULL" briefly, returns to previous position (i.e., Favorites).
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.