Bugzilla – Bug 5103
Very short tracks: Player streams too many files to the player
Last modified: 2008-12-18 11:12:12 UTC
Steps to reproduce: 1. Get the 17 short WAV files from bug 4544. 2. Set repeat to none. 3. Play all tracks with WAV -> WAV using ethernet (just to rule out wireless issues). 4. Player will likely stop before playing all 17 tracks. May take several tries to duplicate. I think what's happening is that since the tracks are so small, 2 or 3 are getting queued up in the buffer at a time. When SlimServer is all done sending the last set of files (by around track 13, all 17 have been streamed to the player), it moves to playout-stop mode, but should continue to receive track start events for each of the tracks. However, the firmware often does not send these events but just sends a final underrun. This may also be related to the 'off by one' bug. After trying the above, add 1 more file to the playlist, an mp3 or something. It will start playing but the display will show "Track17". This is because we got 1 less track start event than we should have.
Richard says the firmware can't handle more than 2 tracks buffered at once, so I will work on fixing Source.pm to handle this.
Easily reproduced with the steps. I reproduced this twice in a row.
Fixed in change 12205.
Seems to me the firmware should be fixed instead.
Perhaps, but it's easier to fix SlimServer.
With this bug fix, should this happen to songqueue where there are 9 songs queued ? 2007-06-05 11:31:38.4320 Found command: [flac] -cs --totally-silent --compression-level-0 --skip=$START$ --until=$END$ -- $FILE$ 2007-06-05 11:31:38.4324 Matched Format: flc Type: wav Command: [flac] -cs --totally-silent --compression-level-0 --skip=$START$ --until=$END$ -- $FILE$ 2007-06-05 11:31:38.4328 opening next song (old format: flc, new: flc) current playmode: pause 2007-06-05 11:31:38.4330 Adding song index 13 to song queue 2007-06-05 11:31:38.4333 streamingSongIndex: Song queue is now 13,12,11,10,9,8,7,6,5 2007-06-05 11:31:38.4402 openSong on: file:///C:/Documents%20and%20Settings/Bryan/My%20Documents/My%20Music/GapTestWAVs/14%20Track14.wav I am trying to check a fix to socketwrapper so I am still doing the same tetsng -0 muultiple start/pause especially near end of track as the socketwrapper crash occurs when a pause occurs when it is finishing. While doing the testing this morning with the last night build - I think I am gettting silent plays/multiple track skips but much less frequently.
I don't know about the end of file pause issue, that should have been fixed the other day. In your log, song queue should never contain more than 2 tracks now. Can you post the full log?
Created attachment 2036 [details] Log file zipped. Log file attached. As usual 17 file queued and then lots of play/pauses.
OK I think I see the problem, if the player is paused when gotoNext is called, I think it will always add a new track to the queue. Should be a simple matter of checking prevPlaymode here.
OK can you try the fix in change 12211? This is very hard to test for all cases as most of these require pausing at just the right instant. Some thorough QA would be appreciated as well.
I will have a look.
Before change 12211 I was easily able to reproduce this, after the change I have not managed to reproduce this. OK to mark this as verified as fixed? I'm testing using Andy's reproduction steps in comment 1.
I think it is fixed as I had a number of related "pause" issues which were fixed at the same time and I never saw this problem subsequently.