Bugzilla – Bug 6737
Now-buffering not always cancelled for synced players
Last modified: 2008-01-23 12:12:33 UTC
Slim::Player::Squeezebox2::startAt() fails to cancel 'buffering message'. This is bacause of the way it overrides Slim::Player::Squeezebox::startAt(). When listening to radio stations it can be that the buffer is not canceled and then oscillates back and forth. I find it surprising that this has not been reported before.
Hmm, the buffering code checks if the track has already started and then it should stop: # If the track has started, stop displaying buffering status # trackStartTime is set to time() after a track start event if ( $client->masterOrSelf->trackStartTime() > $client->bufferStarted() ) { $client->update(); return; } How can I reproduce the bug?
Nothing ever seems to set trackStartTime. To reproduce: have two synced players, turn one off, then back on. The track restarts but the display never gets out of the buffering loop. With a plain track it will stop at Waiting to Sync, but with a radio station, which will generally cause the buffer fullness to drop below the threshold again, it will just cycle around.
Hmm, trackStartTime is set in trackStartEvent, but maybe the problem is on older players that don't call trackStartEvent? What are you testing with?
Ok, so I missed part of change 16452. I just had an inconsistent source tree. Sorry for the confusion.