PocketCasts - App issue with skip forward back

[penroseg]

Can I firstly say that I only discovered this project over the weekend after lots of frustration following buying a car with ID6 and discovering that if I am not on iOS, I'm a second class user as far as BMW is concerned. They really should just buy this project and release it, although actually, maybe not because then they'll potentially just ruin it too...

I do have one issue and am not 100% certain it's not something on my setup but I have been doing some testing and I think it may be related to how the app surfaces their notifications.

I use PocketCasts extensively as it is the only one that I have found that syncs my Up Next queue across all devices as I use the Android app in the car, Alexa skill at home, and either the iPad iOS app or the Browser client when in the office (back in the mists of time....)

PocketCasts works over Bluetooth in the car and forward/back skip works without any issue but when connecting to the app over AndroidAutoIdrive the buttons don't work. I tried this in the car but the same behaviour is also seen by opening the app on Android when a PocketCasts episode is playing and in that case, the Play/Pause button is operational but the Forward/Back are not. I've also tested Amazon Music, Plex Amp & Spotify, and all work with no issues. I tried using both Bluetooth and USB connection and same situation.

The only difference I can see is that the RWD/FWD icons on the PocketCasts notification are different so they may be using a different function, and the skip behaviour is not quite the same. If there was any way to capture this and make it behave in the same manner as the other apps it would be fantastic as PocketCasts doesn't actually skip back or forward to the next track, it skips a user-defined custom time in the current track (for me 15 sec back, 60 secs forward) which is very useful in a podcast as you may want to replay something without restarting the entire episode.

I've attached a screenshot of the notifications showing all four apps mentioned, along with a screen recording of the issue.

Many thanks for all your work on this project and really hopeful the behaviour in PocketCasts can be changed without much effort.

Screenshot

• https://user-images.githubusercontent.com/49922975/126150404-80057cf7-e489-426c-abd5-e5204d0943f4.jpg

Video of issue

• https://user-images.githubusercontent.com/49922975/126151315-c7de1ff6-a3ec-4d1b-aebd-9bf91fa4fbf7.mp4

[drm87]

Since I also use PocketCast, maybe I can share a bit more information:

AAI uses an Android API to get that information and controls for music/podcast apps. It seems that PocketCasts does not support the next command (at least so it seems when using Google's Media Controller tester app to debug). It supports the skip command (that also seems to be used when hardware button events are sent to the app). This skipping can also be found in AAI's Actions menu, together with the option for changing the playback speed (which is great!).

Unfortunately the "Up Next" queue works rather unreliable in my experience and currently it is not possible to browse your podcasts (I am hoping for a fix in the next update, if they follow my bug report 😉 ).

➡️ For AAI it might be possible to add a logic of mapping the next and previous menu options to other actions, if the PlaybackState.getActions of a MediaController (from the Media app like PocketCasts) shows that ACTION_SKIP_TO_PREVIOUS and ACTION_SKIP_TO_NEXT are not supported.

[hufman]

This is correct, thank you @masteralarm ! The Actions menu contains a set of Skip actions manually added by AAI, in addition to the app-provided skip actions, and long-pressing the dashboard's back/next buttons while holding audio context will also start seeking through the track.

While it does need Notification Access to control any running music app, this is merely coincidentally the same permission to get the underlying MediaController for the music app. However, AAI maps the Back/Next screen commands or buttons to the MediaController's Back/Next commands, and PocketCasts would need to be able to handle them. The same Back/Next command would be sent by the phone's lockscreen view and by Bluetooth inputs. My preference, of course, would be for it to behave like some audiobook players and natively handle the back/next as a skip command, which would also provide helpful support for Bluetooth headsets. The developers seem receptive, perhaps they might implement it on their side?

Adding special behavior might be possible, but I would have to consider how best to heuristically determine audiobook mode. Spotify at least sets a flag when it is playing an audiobook, but other apps would be trickier. Lack of back/next, but also has a valid maximum duration to ignore radio apps? And how much to skip by, should it be configurable? I'll most likely consider it for the next version, but hopefully the above workarounds will be helpful until then!

Thank you so much for the kind feedback!

[penroseg]

@masteralarm @hufman

Many thanks both. I did suspect it was something to do with it not being a Next-Previous track skip. It does work from the lock screen or when playing directly through Bluetooth to the car, or actually even from a Huawei band so it must be embedded in BT and know which context to use. I'm happy to open a bug with PocketCasts so will do that (they recently announced they have been sold through so might have other things to focus on...)

I actually couldn't get the 'hold to seek' working either so will play around a bit more with that. Not 100% sure what 'while holding audio context' means but will play around with it. I'm getting the iDrive software in the car updated later this week so will test again at that point. This actually is working after re-testing.

Browsing the Up Next queue is not a huge issue for me. I generally have enough 'stuff' in the queue to listen to and just take them in order, although it would be nice to be able to view what is coming next.

On the Action button, I found the Skip actions but for some reason when it is pressed iDrive then reverts back to an earlier menu so if you want to skip back multiples of the set time it gets a bit fiddly. I tried to store the skip backwards function onto one of the hardware radio buttons but it didn't take so will try that again too.

My fallback on this is to get a small BLE button with forward/back buttons to see if that works so there are plenty of workarounds. Once again, many thanks to you both and for all the hard work which has gone into the app.

BTW, I'm not a developer but I do have a Business Analyst/Product Owner background so if there is anything I can do to help with testing or defining logic I'm happy to help where I can.

Thanks again.

Additional comment: something I forgot to say last night and thought of afterwards is around the question of whether skip duration should be configurable. In the case of PocketCasts, this is configured in the app and connected BT devices to use this instead of next/previous track functionality so I don't think that configuration would need to be stored in AAI.

[penroseg]

I've sent an email to PocketCasts support with a request to replicate the Skip functionality onto the MediaController Back/Next functions. I also sent them a link to this issue so they have more context.

In terms of the audiobook mode and the flag which Spotify sets, is it reasonable to make an assumption that in the case of a Podcast app, all items should be treated as an audiobook rather than a media (song) track?

[hufman]

Thank you for the update! If I force the app to send the skipToNext() command, even if the music app doesn't claim to support it, then PocketCasts does in fact jump forward. Let me know if they seem receptive to adding these flags to the [PlaybackState's Actions](https://developer.android.com/reference/android/media/session/PlaybackState#getActions()), I'd rather not need to add special case logic to force enable it. I pushed a change to the Actions window to not close when certain app actions are clicked (such as this app's Jump commands and Change Speed). I do see that the list doesn't redraw, so the Change Speed doesn't update until you close and go back in, so I'll figure that out next.

[hufman]

I've pushed up the fix to enable the Actions menu to redraw itself, which is helpful for the Change Speed action. As another helpful tip, if you have the Actions toolbar button selected and then save a dashboard bookmark button, you can easily get back to the Actions menu at least, as a substitute for the inability to directly save a shortcut to an action. The Now Playing queue is subject to the music app, and would need to be provided by PocketCasts. This is separate from Browsing: Browse support is definitely impossible until the app allows AAI to start it (through the MediaBrowserService onGetRoot functionality, as the keyword to use in a feature request 🙂 )

I think your question proposes that, if an app (or Spotify mode) is known to be an Audiobook or Podcast app, then any music playing through it should be treated with this seeking behavior instead of changing tracks, which I agree with. However, it's hard to guess the Audiobook or Podcast app category as the starting point (see the Radio App heuristic, for example), so I was imagining how to determine this Audiobook mode from just the current playback state.

One possible workaround is to detect an app-provided jump back/next action, and use those to provide any missing back/next functionality, which would benefit PocketCasts and any other apps that assume that Android Auto is always showing these custom actions on screen. I suspect that's the main reason that they don't declare back/next support, to hide these superfluous icons in Android Auto and only show the skip action icons. Perhaps I could heuristically map other Custom Actions to regular Actions as well: I know of my favorite music apps has a specific Shuffle action instead of implementing the normal Shuffle API.

[penroseg]

@hufman Really appreciate all the effort you are putting into this one..!

I got to test the Actions menu staying in focus yesterday rather than reverting to the main menu and that worked perfectly. I was only doing a short drive so didn't get to see if it stayed like that indefinitely but it looked like it was going to. The only issue with remaining on that screen is you can't see time elapsed or remaining on the item being played but I definitely think that's worth dealing with to have the skip function easily to hand. I also thought about reducing the steps and saved the Actions menu to one of the hardware buttons so appreciate that as a suggestion too.

I see the issue on defining what is an Audiobook or Podcast type app as you'd end up maintaining an ever-expanding list of names as new apps are released, or even get renamed. I was having a look there as I thought that there must be a Category somewhere to figure out what an app is but even on the Play Store it doesn't seem to supply this, never mind on the device. Pocketcasts (and all of the other podcast apps I looked at are classified as 'News & Magazines', Audible/Libby/Borrowbox are all 'Books & Reference'. As an aside, my code reading skills are very basic but I see that one of the Radio App heuristic keywords is "cast" so is PocketCasts actually being categorised as a Radio app? I'm sure it makes no difference but was just interesting to see it.

Providing any custom back/next actions surfaced by the app mapped to Playbackstate.ACTION_SKIP_TO_PREVIOUS / Playbackstate.ACTION_SKIP_TO_NEXT sounds like a possible workaround but I don't want to be putting extra work on after you've made the flow a bit easier already..!! As an update, no response yet from PocketCast support to my email so I don't think that will be a quick change on their side to declare those items.

Thanks again..!!!

[hufman]

I'm happy to help! These changes have been minor but still helpful! If I do the substitute action workaround, I'll probably work on that after this next release. You read the code correctly, PocketCasts is classified as a Radio app. The only thing this changes is that it shows up on the Radio section of an ID5 car, which I think is a good place for an episodic news app. However, since it only shows up after you play the app on your phone, it probably doesn't matter too much :joy:

[hufman]

I just pushed up a new feature to heuristically map these skip CustomActions to provide the back/next option in the car, check it out!

[penroseg]

Hi and apologies for the delay in responding. I got a chance to try the new version briefly last night and it seems to be working perfectly. Skip fwd/back button on the car are now acting similar to a BT button or the on-screen buttons in the app. I'll give it a proper test over the weekend when I will be on a long drive but so far, all good news. Many thanks for getting this in there. The BT button in the car was workable but fiddly so fantastic to be able to get back to stock buttons...

Funny story though. I installed the new app version and nothing would play in PocketCasts. I uninstalled AAiDrive, cleared cache and settings in PocketCasts and nothing. Hitting play would show cover art in the car and then back out every time. Was recording a video clip to raise a bug with you and then noticed that even when not connected to BT it was the same issue so traced it back to the fact that I upgraded to Android 11 last weekend and PocketCasts had lost access to the device storage. Once I cleared all downloaded episodes and re-downloaded it was working as expected... Lesson learned (again!!) that the obvious reason for a fault is not always the correct one......

Thanks again for your help.

[hufman]

Excellent! I'm glad it's working well, it feels delightfully seamless now :) Please feel free to reach out to the app developer to allow AAIdrive to launch Pocket Casts through their MediaBrowserService! I'd love to add more supported apps to the list!