Bugzilla – Bug 4842
Time remaining on Transporter panel is not right when repeating the same track.
Last modified: 2009-07-31 10:14:20 UTC
System Info: Gateway, P4, 2.00 GHz, XP SP2 ENU, SlimServer Version: 6.5.2 - 11645 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt Player: Transporter Note: This bug is most like related to bug # 4841. Steps to Reproduce: 1. On a clean ghost of XP SP2 ENU, install SlimServer 6.5.2 of build 2007-03-19. 2. Start the SlimServer web UI. Make sure the repeat "ALL" is selected. 3. Play this track repeatedly: flac_24_44100_2_440_10.flac. 4. Look at the front panel of Transport. The number (time remaining for the track) should go from 10 to 1, then 10 again when the track is repeated. 5. Notice the number goes 2 then jumps to 10 for the repeat. 6. Play flac_24_48000_2_440_10.flac. 7. Notice the number on Transporter goes from 10 to 1, then 10. No jump here. 8. The only difference between the two tracks is the sampling rate. The jumpy one is of 44100. The good one is 48000.
Created attachment 1855 [details] Jump, not jump thests.
Created attachment 1856 [details] Jumpy track.
Created attachment 1857 [details] No jump track.
Do you see the same symptom on the Squeezebox when playing the same tracks, Wallace?
Waiting on a response from Wallace, I'll assign this one to myself for now.
wallace, 20070321: I am working on this right now. I switched the Transporter to a SqueezeBox on the same PC, and promptly ran into another bug. I am investigating and logging that bug right now.
Indeed something strange is happening here. I'm not seeing the exact symptom you're seeing, however there is definitely a timing issue. Both files only display playing the first 8 seconds. Chris any ideas on what we should do next about this?
I've listened to this test tone long enough... The issue is the time display. The track is not being truncated, the time display just isn't accurate.
Putting this off to 7.0.
Alan: your player refactoring may improve this.
My guess is that the database may have an inaccurate idea of how long each track is, or maybe only the 44100-rate track. Perhaps frame-padding is throwing off the calculation and this gets made worse by the display update quantization. Wallace, what is the detailed track-info for each of these tracks (either from the player UI or the Web UI)? Change 14077 should not have made any difference in this specific case. In general, I do not think that the server has accurate track-length data; generally just guessing it by dividing length by bitrate, not taking into account inaccuracies caused by frame-padding or VBR. The result is that calculated durations can be wrong by several seconds and so end-of-track counters may be jumpy. More-accurate duration data would significantly increase the cost of the scanning process.
Dean, do you think that we should try to fix this or just accept that time-remaining near the end of a track may be inaccurate?
I cannot reproduce this with 7.2/ Perhaps something has changed there (with new-streaming) but nothing comes to mind.
Reduce number of active targets for SC