Play track in album: different behavior between app and Auto

Description

In the app, if you navigate to an album and tap a track, the playback of the whole album will be launched, starting with this track. This is not what is done on Android Auto (which launches the playback of this track alone).

Expected behavior

To me, the app's behavior is a bit off. This is the only place (that I know) in the app where taping a track will launch the playback for a list of media.

My first thought would be to make it launch the individual track and to add a context action "Play album from here".

This is opened for discussion though.

Smartphone

Auto

changed milestone to %3.4.x

added Android Auto Android Phone UX labels

From my point of view, I dislike the Play From Here (PFH) default behavior on Mobile, so I agree to have a context action. But I understand this default behavior on Auto, because we don't have overflow ans this option could be useful.

So I see 2 ways to handle this :

Standardize :
clic song = play song, and PFH from overflow. So no PFH on Auto

Revolution :
Mobile : clic song = play song and PFH from overflow
Auto : clic song = PFH

The comment on the forum was actually quite timely with regard to this issue. I have been digging into the library section lately, and I think I would prefer PFH behavior on Auto. I find playing one track to be somewhat limiting. I typically end up select play all and then use my steering wheel switches to navigate to the desired track.

One of the reasons it was done this way actually has to do with the structure of the media id and the onPlayFromMediaId function in MediaSessionCallback. At present, we only pass back a string prefix and album id, such as album_<album id> or a track as <media_id>, so we'd have to expand it to album_<album id>_<track number>, which is fine, I suppose. The underscore business, coupled with the mystery TODO (see below) really calls for a more comprehensive overhaul of the mediaId scheme. Of course, changing the media id probably has other impacts, since it's used in a few places, but may be insignificant (e.g. we're using it as a key a map or two, and if the key is generated by the same function, it'll just work.)

More Details:

After a lot of digging into the Bluetooth API in an attempt to get BT browser navigation to work correctly (which I never was able to resolve on my Toyota headunit), I came across this nugget:

// TODO (apanicke): Fix a potential media_id collision if two media players
// use the same media_id scheme or two devices browse the same content.

https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/jni/com_android_bluetooth_avrcp_target.cpp#766

The basic idea is that while Google says in their documentation you can build your media ids however you want and they'll simply treat it as a token**, the reality is that they are co-mingled with other media ids in the same data structure in at least one place (if not others?). Google Play Music actually set up their mediaIds as a scheme-less URI with their APP_ID as the authority, and the menu structure as the path. I was contemplating following that pattern in an attempt to resolve the BT issue (my headunit basically isn't going to work, but this might help someone else), and to simplify the parsing code. The built-in URI parser is always nice to use when strings get more complicated.

As an example for the menu:
ID_ROOT would become ${BuildConfig.APP_ID}/root
ID_ARTISTS would become ${ID_ROOT}/artists
etc.

On the callback side this fits a bit more nicely with the PFH behavior because that requires two pieces of information: the album id and the track number. This is elegantly encoded in URI form as org.videolan.vlc/play/album/album_id/track_number and it would certainly make the code easy to maintain.

Comment from OP:

Thanks for the link. I don't like "Play from here" as discussed in that issue. It's inconsistent with decades of experience using other media players, where you select a track and the player continues to play from there - one track after another without further intervention. For me, the larger usability issue isn't listening to tracks serially, but rather being able to navigate in either direction from the current track. For example, if I am listening to track 5 I want to be able to press forward to advance to the next track and back to go to the previous track in the same way that you would an a hardware CD player. Many CD players and software players are programmed so that if a track is playing one press of the back button returns to the beginning of the track and two quick presses in succession go to the previous track.

I agree with the OP's comment and I have a partially working solution. I think we agree on the the definition of "Play From Here" in the discussion. I understand it to be the position in a list of tracks. For example, if I have an album and select track 5, the queue will be loaded with all the tracks in the album; however, track 5 will play first. At that point it will continue playing until the last track in the queue. If the user chooses to press backwards, it will go to track 4, 3, 2, 1. If the user goes forward it will advance to the end.

This does resolve a usability issue I have encountered and is a desired change. The same behavior would apply to last added, history, tracks, and streams, too.

I'll put a MR up in the next week or so. This is a good opportunity to unify the paths (and constants) across ArtworkProvider, MediaSessionBrowser, and MediaSessionCallback.

think we agree on the the definition of "Play From Here" in the discussion. I understand it to be the position in a list of tracks. For example, if I have an album and select track 5, the queue will be loaded with all the tracks in the album; however, track 5 will play first. At that point it will continue playing until the last track in the queue. If the user chooses to press backwards, it will go to track 4, 3, 2, 1. If the user goes forward it will advance to the end.

We all agree on that indeed.

I'll put a MR up in the next week or so. This is a good opportunity to unify the paths (and constants) across ArtworkProvider, MediaSessionBrowser, and MediaSessionCallback.

Thanks a lot!

What's the status of this?

@rhstone could you please confirm that you work on this? Otherwise, I'll take care of it.

@Aza It's completely finished and I just need to open the MR. I have been testing the combined changes and have not seen any issues.

https://code.videolan.org/rhstone/vlc-android/-/tree/auto-sort-updates

Glad to read it! We just wanted to have a follow up as the beta will be built soon.

assigned to @Aza

mentioned in merge request !1020 (merged)

closed with commit c449dfff