Automatically resume playback when new track or playlist is selected

[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.

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.

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.

[chris_s]

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.

Not at all. I just wanted to lay out my thinking on this as comprehensively as possible and possibly give you and others a chance to point out where I might be wrong or what other people's expectations are. While, at this point, I have a strong opinion towards changing the current behavior and would be lobbying for it (so to say), I'm interested in discussing the merits, pro/cons of either behavior and  wouldn't be opposed per se to have my opinion changed.

[Frankenpod]

I wonder if earlier versions of rockbox (e.g. 3.13 or earlier) behaved like this?  I am not 100% sure it worked this (current) way when I first used rockbox.

[chris_s]

Yeah, I don't know. Could be worth it to go back and check – maybe I'll do it later today.

[chris_s]

3.14, 3.13, 3.12 and 3.0 all behave the same way on my hardware. So it looks like it's been that way  going back to 2008 at least. Whether it was originally intended that way (and for what reason) or simply a long-standing bug is up for debate I guess (unless somebody knows and can tell us about it), although maybe it doesn't matter too much when deciding how it should work today.

[Frankenpod]

Hey, did this ever get "mainlined"?

Ironic in that it's not an issue I'm personally bothered about either way, but it seems as if a majority would prefer it to work chris_s's way, and as it's apparently a very small patch and there's talk of a new point release, maybe it could be included?

[Frankenpod]

Hey, I notice that this change was incorporated into the current version, and then reverted again.
Am curious why it was decided to go back to the original way.

[chris_s]

I had inadvertently described the change as applying to playlists only, which would have meant inconsistent behavior depending on the current context. I was a bit late in clearing that up but have resubmitted it as a new patch. It's possible that speachy or someone else with commit access will take another look at it.

[sarangpaul9]

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.  teatv apk  e sadhana

[chris_s]

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.

The patch has since been re-applied. So it should work as you would expect from other apps if you’re using the latest development version.