Bug 4087 - Slim::Player::Source::gototime seems to leave Player progress bar in wonky state
: Slim::Player::Source::gototime seems to leave Player progress bar in wonky state
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Player UI
: 6.5b1
: PC RedHat Linux
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-11 16:20 UTC by Eric Koldinger
Modified: 2008-09-15 14:39 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Koldinger 2006-09-11 16:20:13 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);
Comment 1 Chris Owens 2006-09-12 10:58:54 UTC
Dan do you feel it would be important to fix this for 6.5?
Comment 2 Chris Owens 2006-09-14 10:16:19 UTC
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.
Comment 3 Dan Sully 2006-09-14 10:19:55 UTC
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.
Comment 4 Eric Koldinger 2006-09-14 18:41:25 UTC
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.
Comment 5 Blackketter Dean 2006-09-16 19:31:20 UTC
Eric:  Is this bug ok to close as fixed?  We're trying to shut down on 6.5 now...
Comment 6 Eric Koldinger 2006-09-16 19:38:33 UTC
I think so, haven't seen any issues on 6.5b3.