Bugzilla – Bug 4087
Slim::Player::Source::gototime seems to leave Player progress bar in wonky state
Last modified: 2008-09-15 14:39:24 UTC
I ran into this bug testing my GrabPlaylist plugin on the 6.5b1 (build from Sept 10, seems to actually be newer than the 6.5b2 RPM released today). I ran a playlist on one of Squeezebox 2's, and went to my Squeezebox 1, and used GrabPlaylist to bring the playlist over. Part of what GrabPlaylist attempts to do is use Slim::Player::Source::gototime() to advance the song to the point where it was before. At the point I did this, the song was about 1/2 way complete on the source player. Seemed to work fine. When I hit rewind to go back to the start of the song, the progress bar seemed to reset to the point where it was when I did the first gototime() call (something like 1:37 into the song). The song played all the way through, but the status bar ran until it showed 100% complete, and just stayed there. Then, when the next song came up, it immediately showed as being 1:37 into the song. The song played correctly from the start of the song all the way through, but the status bar seemed to start counting at 1:37. The same behavior occurred when I used the plugin to transfer the playlist back to the Squeezebox 2 from the Squeezebox 1, now occurring at whatever point the SB1 was at. As such, it would seem to be a server issue, rather than a player issue. The core functionality of GrabPlaylist is this: Slim::Control::Command::execute($dest, ['stop']); my $offset = Slim::Player::Source::songTime($source); Slim::Player::Playlist::copyPlaylist($dest, $source); Slim::Control::Command::execute($source, ['stop']); Slim::Control::Command::execute($dest, ['play']); Slim::Player::Source::gototime($dest, $offset, 1);
Dan do you feel it would be important to fix this for 6.5?
Setting this to 6.5 for now, then, just in case we end up having time to fix it AND the fix is not risky. Easy enough to set it to 7.0 if we don't.
Eric - there was a fix that went in last night which might affect this bug. Could you check with the latest nightly / svn and see if it's been fixed? Change 9691 Thanks.
Dan, the 6.5b3 release seems to solve this problem, at least at first glance. I'll give it a few more tries and make sure everything's all groovy, and let you know if it's not.
Eric: Is this bug ok to close as fixed? We're trying to shut down on 6.5 now...
I think so, haven't seen any issues on 6.5b3.