Bugzilla – Bug 5996
FLAC track fails to stop at end of song
Last modified: 2008-04-16 23:51:27 UTC
In the default skin, I played a single song. I clicked near the end of the track in the track progress bar, so it reported -0:04 seconds remaining. The track never reached the end. In the WebUI, the track progress bar time remaining went down to -0:01, and then jumped back to -0:03. This continued forever. On the Player UI (SB2), the Now Playing screen reported "Now Playing" and -0:02 time remaining (not updating). I have managed to repeat this several times, but it doesn't happen every time. Sometimes at -0:01 it will skip back to -0:03 once, and then it will stop at the end of the track.
Was this with one specific track, or with more than one? What kind of track was it? Is it possible you could attach it to the bug?
I'm getting other effects now. If I click near the end of the track progress bar, and then click again in the same area, the second click will skip forward to that position on the *next* track, rather than set the position on the current track. Sometimes, the track will get very stuttery too for a while, before recovering. I tested this against SVN14561 using SoftSqueeze as a player.
Alan, can you take a look at this along with your other FFWD/REW work?
The bit about jumping to near the end of the next track is simply a timing race. You click but by the time the server gets the command to go to "95% of the current track", the current track has already advanced. The stuttering is just due to the difficulty of resyncing on a frame boundary. I have significantly improved this with one of the other changes. I have noticed that SQ is not very good in this respect. When it comes to actually not stopping, I suspect that that is a combination of the effects above. I have been unable to reproduce it but I suspect that there exists some bug along these lines with very short tracks (the very short bit at the end of a track is like a very short track to the player) - there is another bug for this which I cannot find just now. Peter, how easily can you reproduce the not-stopping phenomenon (actually not stopping, not simply odd display)?
Peter, ping. How easily can you reproduce the not-stopping phenomenon (actually not stopping, not simply odd display)?
Philip (sorry, not Peter), How easily can you reproduce the not-stopping phenomenon (actually not stopping, not simply odd display)?
Just to be clear, by "the track never reached the end" in the original bug report text meant that the web UI kept reporting different time remaining, never reaching 0. I just repeated it with a FLAC song, duration 02:59. It seems quite easy to repeat. The single song was playing in SoftSqueeze, no repeat. In the WebUI (default skin), I clicked on the progress bar near the end several times. It reported -0:04 seconds remaining, which then continued to decrement to -0:01 and then jumped back up to -0:04. No sound could be heard in SoftSqueeze at this time, although it reported "Now Playing" rather than paused or stopped (it reported -00:03 continuously).
Thanks, would up mind attaching the track? Can you reproduce this with a hardware player?
I don't think there's much point uploading a song - I seem to be able to repeat the problem for any song I chose the play. Definitely any FLAC song - I just repeated it with one that it over 6mins duration.
I could not recreate this with SoftSqueeze as I could not get SoftSqueeze to do gototime with flac at all. I could recreate this with an SB2. From the logs I gathered, I am pretty sure that this is a duplicate of bug 4019 and I am marking it as such. The following STMd frame is interesting. It shows that *both* the decode and output buffers are empty. The bytes_received value is correct (complete size of trailing track segment). Note that elapsed milliseconds is still 0 and no sound was heard. The STMd is not followed by any STMu. [08-04-17 08:20:53.5723] Slim::Networking::Slimproto::_stat_handler (722) 00:04:20:05:cb:14 Squeezebox stream status: event_code: STMd bytes_rec_H 0 bytes_rec_L 684227 fullness: 0 (0%) bufferSize 3145728 fullness 0 bytes_received 684227 signal_strength: 65535 jiffies: 248901594 [08-04-17 08:20:53.5727] Slim::Networking::Slimproto::_stat_handler (734) output size: 3528000 output fullness: 0 elapsed seconds: 0 [08-04-17 08:20:53.5730] Slim::Networking::Slimproto::_stat_handler (746) elapsed milliseconds: 0 server timestamp: 0 [08-04-17 08:20:53.5735] Slim::Player::Source::decoderUnderrun (599) 00:04:20:05:cb:14: Decoder underrun while this mode: playout-stop *** This bug has been marked as a duplicate of bug 4019 ***