Bugzilla – Bug 9221
Pausing a stopped player or sync group begins play
Last modified: 2009-09-08 09:15:09 UTC
I set an alarm this morning for 8:25 AM on a Transporter synced with a Boom. The playlist was an album that I'd marked as a favorite and is 39:01 in length. For this alarm, I left 'Repeat Alarm' at 'Yes' and I have global settings of 9 minute snooze and a 60 minute timeout. The alarm went off at the correct time and I didn't touch a thing, just let it play through. It finished playing at about 9:05 AM. Then, at exactly 9:25 AM, the very last track in the album was played. I tested it again this evening using the same album as playlist and it did it again, playing the last track again, exactly 60 minutes after the alarm time. Then I created a playlist of 3 songs, 8:04 total length and saved it. I reset the global alarm settings to 3 minute snooze, 10 minute timeout. I set an alarm and allowed the playlist to play through. At exactly 10 minutes after the alarm was set, the 3rd track was played again. I just repeated the last test, but this time without the Transporter synced to any other players and the last track was not repeated again.
Max: Would this be yours?
Ah, yes there's a bug here. When the alarm times out, it always executes a pause, regardless of whether the music is still playing. Whilst I wouldn't have thought this would really be a problem, I should really only do the pause if needed. I imagine that the extraneous pause is interacting oddly with the synced player. Is this likely, Alan?
Hmm, I'm not sure why the extra pause would do anything off with synced players but I guess it is possible.
Ok, then, this is an easy one to duplicate. Doesn't really have anything to do with the alarm, although the alarm will easily trip it with synced players. Play _anything_ on a player in a sync group (one track or many) and allow the playlist to finish playing. Then using the IR remote on any player, press 'Pause'. It will begin playing the last track found in the current playlist. You can also duplicate this from the web interface by using the old Classic skin, since it has both Stop and Pause buttons. Load up some tracks. Begin play. Hit 'Stop'. Then hit 'Pause' and it will start playing the last track in the playlist. Behavior with an unsynced player is slightly different. When the playlist ends, the "current" track becomes track number 1. Pausing will then begin playing track number 1. For some reason, the alarm timeout behavior doesn't cause the player to begin playing again in this case. Seems to be two issues: 1. After a playlist for synced players completes, the current track remains pointing at the last track in the playlist rather than circling 'round to the first track, as it does with unsynced players. This is easily seen in the web interface, Default skin, by the location of the music notes icon after a playlist finishes playing. 2. There's some confusion over what pausing a stopped player or sync group should do. Should it begin playing as if the player(s) were paused, or should the Pause button/command have no effect?
Ok, this looks like the bug to me (Commands.pm): if ($cmd eq 'pause') { # pause 1, pause 0 and pause (toggle) are all supported, figure out which # one we want... if (defined $newvalue) { $wantmode = $newvalue ? 'pause' : 'play'; } else { $wantmode = ($curmode eq 'pause') ? 'play' : 'pause'; } # Start a player upon a pause command if player is currently in stop mode $wantmode = 'play' if ($curmode eq 'stop'); } The 'pause' command allows for an explicit parameter ($newvalue in this fragment) which, if defined, sets the desired state at the end of the command. If not defined, then the behaviour is to toggle. The trouble is that the code above effectively does toggle even if $newvalue is defined when in stop state. The following is probably what is really desired: if ($cmd eq 'pause') { # pause 1, pause 0 and pause (toggle) are all supported, figure out which # one we want... if (defined $newvalue) { $wantmode = $newvalue ? 'pause' : 'play'; } else { $wantmode = ($curmode eq 'pause' || $curmode eq 'stop') ? 'play' : 'pause'; } }
Further discussions have clarified why the behaviour is different between sync and non-sync cases. Sync players end up in state 'playout-stop', not 'stop' at the end of a (non-repeating) playlist, and track-advance logic is also different. These points will be dealt with in new-streaming. Actually, I'm not sure that this analysis is quite correct. The bug in Commands.pm should in any case be fixed.
Commands.pm fixed in change 22957. I'd be pleased if someone can verify that this fixes the original problem.
I don't think there's anything for me to do here.
Marking as fixed. Please reopen if you still trip over this.
Yes, it's fixed. I'd like to suggest that this could be a good one to merge into the 7.2 trunk. Might help with some of the random playing issues.
I find that I cannot use stop once the screen-saver has kicked in (even if the SS is what I was on already - just seems to be related to the SS timeout). Once the display is "awake" then I can use stop just fine. Would this concur with your experience?
That could be it. I have a real hard time knowing when I'm looking at the Now Playing screenserver vs. the Now Playing screen. I'm using the web ui to play tracks and it immediately kick into Now Playing when you play something.
I enabled a couple of screensavers that I never use and changed the now playing screensaver to something else. I can see for sure now that it's failing only when the screensaver kicks in. The key press is recognized, since the display immediately changes to the now playing information screen, but it keeps playing.