Bug 5094 - Pausing track after transcoding has finished causes rebuffering message
: Pausing track after transcoding has finished causes rebuffering message
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Transcoding
: 6.5.2
: Macintosh All
: P2 major (vote)
: ---
Assigned To: Andy Grundman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-30 11:27 UTC by Andy Grundman
Modified: 2008-12-18 11:12 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments
Log of session where files are "played" quickly and silently (28.45 KB, application/octet-stream)
2007-06-03 01:18 UTC, Bryan Alton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Grundman 2007-05-30 11:27:44 UTC
Pausing and then unpausing a transcoded track after the transcoding has finished results in the playmode being reset to 'play' instead of 'playout-play', so decoderUnderrun does not properly advance to the next track.
Comment 1 Andy Grundman 2007-05-30 11:36:40 UTC
Fixed in change 12155, please test.
Comment 2 Bryan Alton 2007-06-03 01:18:22 UTC
Created attachment 2032 [details]
Log of session where files are "played" quickly and silently

While testing this bug, the original symptoms have gone but another strange behaviour has appeared.  I don't know if it is as a result of the fix or just because of the fix it is now visible.

The bug appears on Windows and Linux. I was testing Start/Stop Pauses near the end of tracks.

As before
1. Using web i/f I queued up 17 short tracka from a directory. They are Ross' test gapless WAV files which are transcoded into Flac to play.
2. While the track are playing I used remote to start/stop in tracks - usually in track 07 I do frequent start/stop. 
3. Normally SS only has one song in the queue to play but when this bug happens - all the remaining tracks are transcoded and queued. This start around "2007-06-03 08:38:04.5236" in the log file - possibly a bit earlier.
4. Then SS "plays" all the queued tracks but fast and without sound but visualiser moves a bit and then stops moving. On Windows I thought SS was skipping the track but I think it was the display not being able to keep up to date.

A log is attached.  I can reproduce the problem but not every time as timing seems to be important and button presses with 1-2 secs near end of track.  IT is possibke that I have pressed pause twice but I don't think the silent playing is correct in any event.
Comment 3 Bryan Alton 2007-06-03 03:26:06 UTC
Bug 2910 description is very similar to this behaviour so maybe there is still some situation which has not been handled by latest fix which the 2169 fix somehow stopped it.
Comment 4 Andy Grundman 2007-06-03 04:50:31 UTC
Hmm, it looks like you paused it but it continued to load tracks and play them:

2007-06-03 08:38:04.2105 00:04:20:06:4a:9a: Switching to mode pause from play
2007-06-03 08:38:04.2113 00:04:20:06:4a:9a New play mode: pause
2007-06-03 08:38:04.2127 00:04:20:06:4a:9a: Current playmode: pause
2007-06-03 08:38:04.2996 Got a track starting event

It looks like it sent the pause command but got a track starting event before the SB had seen the pause command.  So there's a race condition here, you have to pause at just the right time to cause this.  Where can I get these short WAV files?
Comment 5 Bryan Alton 2007-06-03 06:44:12 UTC
(In reply to comment #4)
> Where can I get these short WAV
> files?
> 

They are in an attachment to bug 4544


Comment 6 Andy Grundman 2007-06-04 11:29:35 UTC
I've looked at this for a bit now and I can trigger a bug even without pausing tracks at all, or using WAV -> FLAC transcoding.  I think this is the same issue you saw in your log.  It will often stop playing too soon (after tracks 13, 14, 15, or 16) instead of track 17.  I think there may be a firmware bug here where the player is not sending the right amount of track start events, but I need to check with Richard to be sure.
Comment 7 Andy Grundman 2007-06-04 11:41:43 UTC
I've opened a new bug for this issue, bug 5103.