Bugzilla – Bug 10818
Some types of transcoding degrade SC & GUI responsiveness
Last modified: 2009-06-17 09:36:33 UTC
I noticed that when Squeezeplay, running on the server PC, is playing audio that my Squeezebox V3 in another room is very difficult to control with the remote and the newsfeed that I have scrolling on its screen slows to a crawl and jitters badly. The Windows task manager does not show anything unusual. There is plenty of spare cpu cycles and the networking display does not show much activity. As soon as I pause the audio on Squeezeplay the Squeezebox in the other room returns to normal. Audio on the Squeezebox does not seem to be affected. It plays normally whether Squeezeplay is playing audio or not. Squeezecenter 7.3.2 - 24618, Jan 12
Dwayne: Can you please try SC 7.3.3 and the latest nightly build of SqueezePlay to verify if this is still an issue. please list the build date for SP that you tested
Squeezeplay was also from the Jan 12 nightly build. I'll try the latest and see if it's still doing this.
Ok, I installed the latest sc (7.3.3 24825) and sp (7.3 3992). I still see the problem, but discovered that it only happens when I am playing a Sirius Radio channel.
Dwayne: are they in the same sync group? (or synced at all) Can you turn on debug logging for plugin.sirius then attach the log to the bug
Sync doesn't seem to be involved. The problem is seen whether or not my single hardware player is sync'd with sp or not. It sometimes will go away without my intervention, but stopping audio on sp always cleans up the problem on the squeezebox. I have a log file for you. Let me know if you need anything else.
Created attachment 4740 [details] Sirius Radio debug info. Here is the log file. In the beginning the players are sync'd with squeezebox turned off. Then I turn on the squeezebox, later I unsync the two. Near the end I pause sirius and turn off sp. Finally, I shutdown the server.
Created attachment 4843 [details] --perfwarn=0.5 log Log file with --perfwarn enabled. When SP starts playing, IP3K device RSS feed gets very slow and choppy.
Alan: I think the problem here might be that reading from wmadec is blocking.
Andy, why would that be? Pipeline always sets its FDs to non-blocking. Unless Slim::Utils::Network::blocking() can fail without returning undef. Can QA please try to reproduce this with Vista.
QA has reproduced this, comment #7 contains the log file from when I repo'd this on Vista
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
I believe this happens because we don't set sockets non blocking or use a pipeline when playing remote streams in stream-mode R, i.e. when using an external convert command which connects to the remote stream itself - as is the case with Alien, and wmadec and some others. I think the operation we want is: If a local file then open directly in blocking more - we do this. If a remote url (stream-mode R) then for windows use a pipeline as we need socketwapper to make it non blocking. For non windows we should be able to set the file handle created from the file new to non blocking. If it is opened in stream-mode I then we need a pipeline. At present the middle one of these is missing?
Triode, Andy suggests this is something you could work on?
Created attachment 4970 [details] Possible patch
Adrian, I think we set non-blocking mode for local files too. Do we actually need socketwrapper to get non-blocking on windows? Otherwise I think that the attached patch may be sufficient.
Alan - your patch sets non blocking for local files too. I don't believe we did this before in 7.2 and before (or with the current 7.3/7.4) but I don't see why it should be a problem - perhaps means we spin a bit faster? The patch does fix the problem seen on linux. However on windows it doesn't fix - I think this is because of the comment in socketwrapper.cpp, that on windows we can't actually set pipes to be non blocking. I will continue to look at to see if we can use a pipeline in this case. Its easy to recreate this problem using softqueeze with a windows server to play wma remote streams (and no plugins).
(In reply to comment #16) > Alan - your patch sets non blocking for local files too. I don't believe we > did this before in 7.2 and before (or with the current 7.3/7.4) but I don't see > why it should be a problem - perhaps means we spin a bit faster? Not really. The code already sets non-blocking for local files, at around line 387. This patch only adds setting the non-blocking mode for a pipeline. > The patch does fix the problem seen on linux. > > However on windows it doesn't fix - I think this is because of the comment in > socketwrapper.cpp, that on windows we can't actually set pipes to be non > blocking. I will continue to look at to see if we can use a pipeline in this > case. > > Its easy to recreate this problem using softqueeze with a windows server to > play wma remote streams (and no plugins). Unfortunately (or something like that), I don't have a Windows system to test on. This is slightly ironic, because initially with 7.3.0, all pipelines used Slim::Player::Pipeline, not just those in 'I' mode. The fix for bug 10451 reverted the behaviour such that 'R' and 'F' modes would use perl's builtin pipeline capability - perhaps this was a mistake.
Created attachment 4994 [details] patch take 2
New patch above but I'm not sure that that is really the right solution (although probably the same as SC7.2). I am more inclined to revert the fix to bug 10451. Even with a pipeline reading from a local file, non-blocking input could cause SC to stutter, especially in the case of a slow, CPU-intensive transcoder.
Created attachment 4995 [details] another possible patch.. Patch tested on linux and windows - works for remote streams
Should be fixed by change 25723.
I tested Adrian Smith's fix on Vista. It works fine.
Verified fix in 7.3.3 r26187... I was not able to reproduce this issue with the build listed.
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.