Bugzilla – Bug 1854
Remote streaming RETRY_TIME could be adjusted to match bitrates and/or OS pipe buffer size
Last modified: 2009-09-08 09:26:21 UTC
On linux 2.4 remote streams which are decoded to wav/flac don't work correctly. This is due to RETRY_TIME in Slim/Web/HTTP.pm being too long for the size of the pipe buffer [4096 bytes] It works for linux 2.6 and windows as these support larger pipe buffers. See:http://forums.slimdevices.com/showthread.php?t=15194 (post 8) To support PCM streams RETRY_TIME needs to be reduced so that it sustains the data rate. However this increases cpu on slow servers and is unnecessary for low bit rate (mp3) streaming into the player. Bug as placeholder for a more elegant alorithm which adapts to rate and buffer size. [I will look at it, but will need some feedback from the author of this code]
vidur, this was your section of code, correct?
Created attachment 665 [details] Possible patch Michael - could you try this? I did look at more complex solutions to try to optimise how long to wait for, but didn't come up with anything which was always the same or lower cpu load! So this just attempts to quess when the problem occurs and switch to a lower retry time. I can' test so please try it out [test with --d_http to see which retry time is used] Vidur - this includes a possible typo fix for the line: - if ($chunkRef && length($chunkRef)) { + if ($chunkRef && length($$chunkRef)) { I'm assuming this is what was meant?
I'm feeling silly - but I can't reproduce the problem any more... I updated to the latest nightly build and am streaming Real->FLAC with no problem (DRS3 from the AlienBBC->Others) to my SB2. Normally the sound would become garbled after only a few seconds (<< 1 minute). But now... almost 10 minutes and still as clear as it could be. I'll try to get the garbling back today and test the patch asap.
It took only 35 minutes to get the expected result. I now applied your patch and am waiting to see whether it will work better. I'll give it a 2hrs test (before I have to leave).
I think the garbling is dependant on the order in which the OS is scheduling different tasks and hence can be complex to reproduce. Richard T noticed that simply turning on debugging stopped the garbling... Can you confirm that the fast retry time is used on your OS [0.02 rather than 0.05]
I'm a little late with the results of my test. But after applying the patch I listened to that stream for more than 2.5h before I had to leave. Seems to be working for _this_ case - I haven't tested whether it will introduce new problems.
kdf's patch maybe be a reasonable stopgap, but maybe the right fix is to compute a retry time based on the bitrate of the stream?
Vidur, [assume you meant my patch!] I tried something to compute the time more accurately, but to get it right requires computing an average of the previously transfered data as at least some transcoding apps [mplayer] can send large bursts to slimserver (which are all read as the retry time is only involked when nothing can be read). Hence to deal with such cases requires computing the average rate over the previous period and basing the retry on this. In the end I settled on a simple solution as it only appears a problem on OSs with a 4K pipe size [linux 2.4 + ?] My ideal would be to use select to trigger reading as well as writing into a buffer with thresholds to take the reader off select if it fills up too much etc. However this looks to be a more significant change...
Michael - any more feedback? Vidur - do we want to consider committing this? [+ is the typo fix correct?]
I'm sorry, can't give much more feedback than "it works for me"
Cc:ing Dean to get another pair of eyes on it.
I agree, the patch looks like a reasonable stopgap.
OK I'll commit to trunk - do we want to consider this for the 6.1 branch [as someone set the milestone to this (not me!)]
No, this hasn't yet come up as a big issue, so let's keep it out of the maintenance release.
original patch in trunk on change 3806. retitling to specify the suggested possible future fix. marking as enhancement since current problem is reported as fixed with stopgap.
Doesn't seem to have been a problem for 3 years - closing...
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.