Bugzilla – Bug 8861
Many (short) tracks are not playing in new-streaming (Work in 7.1)
Last modified: 2009-07-31 10:25:23 UTC
System Info: Dell Optiplex GX620, Vista, ENU, 1014 MB of RAM, P4 3.19 GHz Note: This bug was found by AutoTestsSystem, and has been confirmed manually. Steps to Reproduce: 1. Download SqueezeCenter-7.2-22048.exe from this particular web site: http://www.slimdevices.com/downloads/nightly/latest/boom/ (Please do not use builds from other places. Builds from other download sites may not have the same problem.) 2. Install it on Vista. 3. Play the attached flac track. It streams fine. 4. Play the attached mp3 track. Notice no sound comes out at all. 5. Play the same mp3 track on an XP with 7.1. It sounds fine. 6. It is not just mp3 tracks not playing. Oggs, flacs, as well as wavs tht are OK before are no longer playing on 7.2. Among the 146 tracks the AutoTestsSystem streams, only 15 are passing. It used to about 110 would pass, and only 30 or so failed.
Created attachment 3675 [details] One of the tracks that no longer works.
Created attachment 3676 [details] One of the very few tracks that still stream.
Created attachment 3677 [details] server log for this bug.
Created attachment 3678 [details] scanner.log for this bug.
Created attachment 3679 [details] sumamry report for the auto streamming tests As can be seen on this sumamry report for the auto streamming tests, besides a few flac files, all oggs, wavs, mp3s and some flacs are not streamming. The expected length of the sound should have been about 10 seconds. They are mostly 0, because no sound came of them.
Since the build was from http://www.slimdevices.com/downloads/nightly/latest/boom/, is it 7.2-new-streamming, or just 7.2? 7.2-new-streamming was selected. If that is not correct, please feel free to change.
This problem is found on XP also.
Created attachment 3680 [details] Comparison of 7.1 results vs new streaming results
With new streamming removed from 7.2, this bug is no longer seen on this release. Verified with SqueezeCenter-7.2-22118.exe. Among the 146 tracks, 101 passed. Only 45 failed. Please see the attached summary of streamming tests resutls. However, since new streamming is to be moved to 7.3, this bug is not to be closed until the fix is verified in 7.3.
Created attachment 3683 [details] Streamming Tests Summary for SqueezeCenter-7.2-22118.exe.
The problem was almost certainly a result of the test tracks being short. This should now be fixed for all but obscure cases where two short tracks follow each other (change 22690 and change 22081). A fix to bug 9125 should resolve those edge cases. Please retest with new-streaming when you get a chance.
Tested again with today's 7.2 exe build -- SqueezeCenter-7.2-22765.exe. None of the 10 seconds test tracks works now. Not just some or most. A new bug had to be logged because it is so serious -- bug #9207.
*** Bug 8802 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > The problem was almost certainly a result of the test tracks being short. This > should now be fixed for all but obscure cases where two short tracks follow > each other (change 22690 and change 22081). That's not really what I'm seeing with the most recent rev. Any transition into a track under 5 seconds in length still hangs.
Yes, transitions into a short track, while already playing, is the remaining problem case. It is not actually the real-time duration of the track that is relevant; rather, the size of the byte-stream. Code in Squeezebox.pm attempts to compensate for this (by reducing the buffering threshold), if it knows the byte-stream length, but this does not take into account the possibility of more than 1KBs worth of non-transmitted header data (ID3 tags, etc.), or when otherwise starting at some offset into the underlying file (after seeking, or using CUE sheets). The old streaming code used to force a resume when SC had finished sending the stream. No account was taken as to whether the player had actually received the data, which could still have been sitting in network buffers. Consequently, this sometimes lead to premature output-buffer-underrun events. I have just checked in change 22975. Would you like to this is this resolves the remaining cases for you?
Created attachment 3928 [details] log file I'm not sure if this is fixed and I'm seeing another problem or what. See the attached log. Short files generally seem to play now, but I can virtually lock up the server by trying to play something else _while_ a short track is playing. One major oddity - and I've actually seen this in the past under different circumstances - is that when the server goes into the weeds, it loads the **entire** library into the playlist in what looks to be trackid order.
Jim, I need the bit for that log running up to the problem. Maybe even player.source=debug. Alan.
Created attachment 3944 [details] bad flac file (In reply to comment #17) > Jim, I need the bit for that log running up to the problem. Maybe even > player.source=debug. Alan. I'm afraid I don't have it any longer, but I would have included any lines from the log with timestamps immediately preceding the errors. I've turned on player.source debugging, although haven't been able to recreate the big dump that SqueezeCenter was taking before, just the freezing. I think I may have narrowed down the remaining problem to a bad track in my library - looks like a last track on an album that wasn't ripped correctly. I've uploaded it here.
So far I have been unable to reproduce your latest problem.
Jim, can you still reproduce this with the latest build?
Seems to be cleared up, so long as transcoding isn't used. With transcoding it's a different story. That crazy failure mode is back - queueing up and playing all the tracks in the library. Is there actually some code somewhere that says "When all else fails, play EVERYTHING starting with track #1 in the tracks table"? Not very friendly, as it effectively locks up the server for a long period just to add everything to the playlist.
Jim, that seems a little different from the original problem. Please can you open a new bug for that, along with a log that illustrates the thing going wild? And thanks a lot for testing this so much. I'm going to close this bug.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC