Bugzilla – Bug 10670
Empty MusicIP mixes on Windows systems with larger music libraries due to timeout issue
Last modified: 2009-10-05 14:35:06 UTC
I've seen 3 cases now where SC 7.3.2 Windows builds sometimes/often return "Empty" MusicIP mixes due to a timeout in Server/Slim/Plugin/MusicMagic/Plugin.pm's _syncHTTPRequest(). The standard timeout is 5s, changing it to 10s made it work on all 3 machines without seeing any other adverse effects. From a user's perspective, it still seems a "tolerable" delay. The situation seems to arise when -- users have a larger library (the test library was around 25,000 songs) -- the library is organised such that one (or more) Windows folders have a LOT of subfolders (test library has 3,573 "artist" subfolders) -- the Windows PC doesn't have too much RAM (test cases: 768 MB, 1GB, 2GB) -- Windows is configured to give preference to programs (instead of background processes and system cache) and/or configured with a lot of other gadgets (like display stuff) and/or it has many other processes running -- the MusicIP GUI HTTP API is used instead of the "real" headless version (it also happens when running headless as a service, but apparently less often) -- the user has a slow disc for the music library (i.e., an external disc connected via USB-1.1 instead of USB-2.0) All tests were done on machines which should still be "reasonable hardware" for SC: 1.8-2.2GHz P4, 768MB-2GB RAM, Windows/XP Home SP2/SP3. In all cases, MusicIP API actually returned valid mixes (verified by copying the request string from SC's log file and entering it manually into a browser), it just needed more time. If no other objections exist, I would suggest increasing the timeout from 5s to 10s since that was apparently enough for all 3 test setups: --- C:/Programme/SqueezeCenter/server/Slim/Plugin/MusicMagic/Plugin.pm.sav +++ C:/Programme/SqueezeCenter/server/Slim/Plugin/MusicMagic/Plugin.pm @@ -1280,7 +1280,7 @@ my $http = LWP::UserAgent->new; - $http->timeout(5); + $http->timeout(10); return $http->get("http://$MMSHost:$MMSport$url"); } I have been applying this fix to every version I used since SC 7.3.2-24282 now, and it always worked well on my tesing machine here.
One problem with this is that this is one of the remaining synchronous http requests. For users with multiple players, this added timeout creates a potential for a longer blocking request that may starve other players of streaming data.
As KDF states, we can't use this fix due to the lengthy blocking of other server activity. We'll consider hAs KDF states, we can't use this fix due to the lengthy blocking of other server activity. We'll consider how to fix this.ow to fix this. Andy suggests we could rewrite this function so that it's async, but that would be much more work than the suggested patch.
Yeah, I agree we can't break other users' streams when doing this. Unfortunately we *have* situations where MusicIP headless takes a LONG time (I've seen up to 3 minutes on some systems), depending on complexity, library size and server load. Making it asynchronous would surely be the best thing to do, eventually. Only I'd be quite unsure how this could be handled within SC (from a user perspective, i.e. reqesting something that would probably only come up a "long" time later). Would there be any way to NOT block SC/streaming BUT "block" the user at his menu selection on all devices until the result is there? And maybe show some "waiting" indicator? And abort the current request only if he aborts on his player? How would we see that HTML output from headless is finished? (I've seen cases where it spat out a few lines, paused, spat out another few and the like.) It must be easy and understandable for the end user, we wouldn't want to make anything that is comlicated or feels "too slow" for the end user. Then again, a user *might* understand "requesting a complicated sound-alike mix takes some time". I hope very much there is a good solution to be found. Let me know if I can help.
I see this about just under 50% of my Music Ip requests, fortunately ~80% of the time, a second request returns a valid list (not sure if I am capturing the answer to the first request or the second is just quicker). This is mildly anoying but enough for me to vote. Music Ip and SqueezeCenter both reside on an HP MediaSmart with 22,000+ FLAC tracks running WHS. This box has had no other software loaded. Operating system: Windows Server 2003 - EN - cp1252 Platform Architecture: 586
change 28422 - add 'timeout' preference to MusicIP, to be used in synchronous requests like the mix command. Please note: as mentioned before this can lead to hiccups if you set this value too high and other players starve waiting for MIP to return. This preference isn't exposed to any UI, as using it might negatively influence SC behaviour. It's for you poweruser's (and my ;-)) convenience only. To set the parameter either: - shut down SC - add "timeout: 10" (or whatever seconds you want) to prefs/plugin/musicip.prefs - restart SC or : - "telnet yourmachine 9090" - type "pref plugin.musicip:timeout 10" (or whatever), hit enter Up to you to find a value which fits you well. BTW: I'm running MIP against a collection of about 15k tracks. - main Linux server (1GHz Via C3) took more than a week(!) to analyze this. Mixing never was an issue with the default 5 seconds. - test Windows Home Server (1.6GHz Core2 solo - what a nice name for a good ol'Celeron!) finished the analysis in a few hours, but times out on many mixes...
Moonbase: Please re-test with 7.4 are you still able to reproduce this? http://downloads.slimdevices.com/nightly/?ver=7.4
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.