Support and General Use > Audio Playback, Database and Playlists

Automatically resume playback when new track or playlist is selected

(1/3) > >>

chris_s:
Just saw this thread on Reddit. This issue has bothered me quite a few times in the past already but I never thought to do anything about it: When playback is paused, Rockbox doesn't automatically resume after selecting something else to play.

I had a look at the code and have attached a simple one-line patch. Would this be a generally accepted solution? After testing it, I certainly much prefer this adjusted behavior.

Frankenpod:
I've noticed this but it never really bothered me.  Logically the play/pause state and the currently selected track are two different things.  So if it's in a paused state and you pick a different track it doesn't seem 'wrong' that it should remain paused.  (You might want to select a different track not to play it but in order to do a long-press and check its track details, for example.)


But it also wouldn't bother me if it worked the way you suggest.  Would it affect the 'pause on headphone unplug' situation?

Heh, I suppose to be really over-complicated there could be a user setting for 'start playing on track selection' yes/no.

chris_s:
So, yes. Some users may expect this behavior some of the time. A few may even expect it the majority of the time. What I doubt is that a majority of users expect it a majority of the time. That would mean that, for most users, the majority of the time, when the player is paused, their intent by choosing a new song is to have it stay paused and only check its track properties.

This also assumes that having previously paused the music communicates anything about the intent of the user when selecting a new song. You’re assuming the user previously paused the music in order to have the piece of music that is selected at a later point also paused. Which seems unlikely in the majority of cases. Tell me if you disagree.

The problem with the current behavior is that it forces the user take the current (play) mode into account which generally introduces complexity. I.e. a prediction about what happens after selecting a song is contingent upon which play mode is currently active. The result is also inconsistent across play modes: Stopped changes to Playing, but Paused stays at Paused (and Playing stays at Playing). This all gets way easier to explain/document and thus (arguably) to use when you can always successfully predict that a song is played back after choosing it. No need to even consider the current play mode. Currently you’d have to start your answer with “well, it depends…”

Lastly, I think it’s worth considering how other apps that users may be familiar with are doing it, both for consistency’s sake and since others may have already done the work of figuring out useful behavior. While I do think there is room for divergence if you have a good reason for it, I’m not aware of any other app that behaves the way Rockbox does.

ps: shouldn’t have any effect on the  'pause on headphone unplug' setting.

chris_s:
To add to that, the manual is actually incorrect about the current behavior. I'd strongly favor changing the code to make it consistent with the documentation though.


--- Quote ---By selecting (“playing”) a song from the File Browser

Whenever a song is selected from the File Browser with Select or Next, Rockbox will automatically create a playlist containing all of the songs in that directory and start playback with the selected song.
--- End quote ---

https://download.rockbox.org/daily/manual/rockbox-ipod4g/rockbox-buildch4.html#x6-660004.4.2

Frankenpod:
I might be misreading your 'tone', but you seem a mite over-defensive about it!  To be clear, I have no objection to the suggested change in behaviour.

  Am merely confirming that it does indeed behave as you say it does at the moment, while as an aside saying that I personally don't care either way (unlike the disappearing cover art, which always bugged me, so thanks for fixing that).

  As the manual apparently thinks it works the other way, presumably it wasn't intended to be like this in the first place - maybe some previous code change changed the behaviour by accident?  By all means change it back, you may well be right that others find this way to be unexpected behaviour.

Navigation

[0] Message Index

[#] Next page