Video Playback Behavior

Feature request
#1

This feels a bit like a bug, in that things that used to work for me no longer do, but I think it’s intended behavior so I’m posting it as a feature request instead.

App version: 2.6.1, from fdroid

Android version: 12

Device model: Pixel 4a (sunfish)

Previous behavior: Video podcasts continue playing in audio-only mode when the screen is locked or the back button is pressed (depending on the “upon exiting video” setting)

Current behavior: Video podcasts pause when the screen is locked or the back button is pressed. The “upon exiting video” setting no longer exists. The only way to switch to audio-only mode is to open the dropdown menu of the playing video and select the “Switch to audio only” option.

First occurred: Today

Steps to reproduce:

  1. Begin playing a video podcast
  2. Lock the screen or hit the back button
  3. Podcast pauses, with no setting for overriding this behavior

Related Discussions

Summary

Could we bring back the “upon exiting video” setting so we can choose whether or not we want the podcast to pause when we lock the screen?

Thanks, C

#2

Long time user, just created an account here to confirm this is super annoying, especially if it is indeed the intended function.

I do believe this is a bug, because it has done the same ‘auto-pause’ thing when already listening to an audio-only podcast and pressing the home button.

I can also confirm that the ‘Upon Exiting Video’ is missing.

2 Likes
#3

App version: 2.6.2, from store

Android version: 10

Device model: Samsung SM-G965U1

New user here, created an account on the forums just to reply to this functionality.

This is very unintuitive in current design, and as other state, super jarring in user experience.

I use the widget to play and pause podcasts, I also often use the widget to open AntennaPod to view the current Queue. When listening to an audio only podcast the flow for opening AntennaPod, seeing the current playing episode, clicking back, and getting to the main interface works as expected. However, once a video enabled podcast starts playing, things get very unintuitive.

Once a video podcast starts playing clicking the widget play/pause will work to start audio only, but clicking anywhere else on the widget opens the video. Hitting back takes you back to the home screen, pausing audio. Using the dropdown menu to ‘Switch to audio only’ also drops you back to the home screen but continues the audio. If you click on ‘Open Podcast’ you get picture-in-picture, same if you click the Android home button.

This appears to be the current reaction to video podcasts; if you simply keep using the back button or ‘Switch to audio only’, you will be unable to get to the main AntennaPod interface easily. You either have to Open Podcast, or use the app launcher to open AntennaPod.

If you use the ‘Open Podcast’ button however, it changes how this all works. Once you’ve clicked on ‘Open Podcast’ you get picture-in-picture and the main interface opens to the Podcast, as expected. Now if you go full screen video, and click back, you are taken to the AntennaPod interface, no PinP, and audio stops. When you hit play you go full screen video, and the back button takes you to AntennaPod. Furthermore, if you click ‘Switch to audio only’ you will now be dropped from the full screen video, taken back to AntennaPod, and you have audio playing. This appears to be working, until you hit pause and play, which then takes you back to full screen video, not audio only. While the main AntennaPod application now uses video playback, the widget can be used to play/pause audio only.

It’s all very unintuitive. Having not seen how AntennaPod worked previously, I thought maybe it was just my workflow coming from a different podcast app. Looking at this post however it seems this is a recent change to how video playback works in AntennaPod. AntennaPod has been great, I am glad I’ve switched, but I have stopped trying to interact with AntennaPod during any podcast which has video.

I never experienced the ‘Upon Exiting Video’ option, but there should be a more coherent way to go from a video podcast, to audio only, and then remain in audio only for the remainder of the session. Currently you get different reactions to play/pause, back, and opening the AntennaPod application, all based on the last action you took, and whether you used the widget, app tray, or AntennaPod itself.

200+ hours in AntennaPod, and I really hope to remain with AntennaPod to surpass the 2,300+ hours I had in the last app. This has been the only functionality which really makes it difficult to use.

Thanks for taking this issue in to consideration.

1 Like
#4

I finally managed to revert this behavior, so I’ve put my fork of AntennaPod in my own repos:

Be aware that I’ve no idea what ‘version’ this code base is since I very lazily worked with the latest ‘develop’ branch, so new/upcoming features AND BUGS will come with it. I’ll be importing/exporting my stuff over to this version soon and it’ll be my daily driver from now on. If I find this to be too unstable I’ll likely go back to the latest stable branch and re-apply this fix to that as well. For now I just wanted this irritation gone by any means.

The APK is available as well, look for it as “AntennaPod-WOTS.apk” if you’re interested.

Cheers!

#5

After having had a look at the fork, I can conclude that the difference appears to be a single boolean variable switching it’s value at two places. Not exactly a huge diff.

Would it not be in everyone’s interest to find a solution where no fork is required? To be fully honest, I have not understood the thread. I did read through it, but it’s not on a explain-it-like-i’m-five level which is likely what I would need.

I would object to Devs are loosing track of the entire point of this app being a factually correct statement. Can’t we be honest enough to state that the main point of AntennaPod is to play audio. There must be a very small minority who ever use it for video, right? That’s not to said the video experience shouldn’t be great, but a more likely reason for it being perceived as sub-optimal is because it is a seldom used corner case rather than the entire point of the app?

Did anyone but the author try running this fork? Does it make the functionality act as desired? Anyone of the opposite opinion? Why?

1 Like
#6

Yes, a small difference, basically changing one default behavior. This could easily be an option in the preferences but my Android coding skills have greatly weakened over the years. It’s also why I did not issue a pull request. I have much to learn before I can offer something worthy of that. I basically just made this fork for myself, but of course made it available to others who may be interested. To clarify, I do not recommend using my fork, but it is there.

You do make a fair point on the issue not being clear - it’s a bit tricky to describe but to those of us who’ve been fighting with this, it does make sense to us. I’ll attempt to clarify the problem.

I’ll go into the queue and select a video that I want to listen to while I mow the yard. Pressing the play button then opens the video and plays it - fair enough, it’s a video. I press the home screen and it pauses the video. I then press play again on the app, and it opens the video. So I press back and it pauses the video. I go to the widget and press play again, and it opens the video. Then I shut the screen off and it pauses the video.

It is this behavior that’s annoying.

We feel that it should default to the ‘switch to audio only’ mode and keep playing. Only pause if the user pauses it. It is from this position where I say ‘missing the point of the app’ - it keeps refusing to just play the thing.

There are four ways to close the video, but only one way (the menu->switch to audio only) to get the desired (expected?) behavior.

You make another great point - this app is designed for audio only, with handling video being a bonus. While I could do something on my end to grab the audio-only versions of these podcasts, on a rare occasion there is a need to see what they’re talking about, at which point I like being able to get out my phone and watch for a few seconds, then shut the screen back off and put the phone back into my pocket.

In short, the app defaults to pause videos rather than switch to audio only when closing the video. While videos are a rare use-case, it does happen. A simple option in the settings could allow for both preferences. My fork simply toggles the hard coded setting.

If I may, I’d like to also apologize if my tone came out a bit harsh. I was attempting blunt honesty, and did not intend for anything to be taken harshly or as any sort of attack. Mostly just venting as I reached out on the issue. I am so very grateful for AntennaPod, and would like to offer a huge thanks to the devs and team for making it available (and open source! yay!) for us. THANK YOU! I mean that sincerely

1 Like
#7

Thanks for summarizing the issue. I would say you make a strong case for a use case which seems very reasonable, and the fork shows how the problem is severe enough to result in action taken.

To try this out, I added the only video rss feed known to me: CGP Grey

I agree requiring to select switch to audio only for every video is highly annoying. My thought is that a more pragmatic way would be to make this a per feed setting. Was that what the upon exiting video used to do?

#8

Thank you so much for looking into this!

I believe the ‘upon exiting video’ option was this setting, but on a global scale affecting all feeds. I can see a per-feed method working, though it could end up requiring going through each feed and setting them all to act the same. Perhaps a global option, then a per-feed override?

I make heavy use of another fork of mine, https://github.com/amckee/PodTube to unofficially ‘subscribe’ to Youtube, Rumble and Bitchute channels within AntennaPod which is why most of what I use ends up being videos in the end, and probably why I was personally very interested in resolving this.

Thanks again.

#9

My argument would be that other video apps stop playback when closing them, and do not continue playing audio. Take YouTube, VLC, the Gallery, etc. All stop when pressing the back button. Simply continuing to play even if you “close” the app is pretty much unexpected if you are used to the behavior of other video apps.

#10

It’s not necessarily true.
I would say on Android you could expect the video to be show in picture on picture mode. You have that with AntennaPod but only if you go to home.

I tried a video and objectively user experience is not good :

  • in app no way to initiate playing without going to full screen (but you can from notification player or lock screen)
  • no way while in full screen to get back to app : I think you should switch to picture in picture on back button. It’s what happen when you tap home.
  • no way to switch screen off and continue listening, yet you can start audio from lock screen using notification player

For comparison in YouTube (Premium I believe) :

  • starting to play you don’t switch to full screen, you stay in portrait and have info below video
  • switching off screen don’t stop audio

It may never be implemented as video podcasts are niche but IMHO things could be a lot better if :

  • AntennaPod player would use cover space to display video in portrait and allowing access to notes the same you would for audio episodes. No Fullscreen if user do not tap on video or rotate his phone.
  • at minimal switch to picture in picture when pressing back button. Right now you are forbidden to do anything within AntennaPod while playing. Yet you can tap home and do what you want using your other apps
  • allow to continue audio to play when screen is off. I agree it could seems more logical for video to stop but in truth user is already used to manually stop for audio episodes which is the main usage. Here there is a discrepancy especially since audio only is allowed using notification player.
1 Like
#11

Well, it’s a video, so we should play it as a video. Before we changed the app to automatically launch the video player, people complained that AntennaPod does not play video.

VLC does exactly the same. Back button closes, and home button goes to PiP.

#12

Thanks Matt78 for summing this up so well.

I too would have to disagree that other video apps stop playback, or that AntennaPod currently acts like other video apps. Using just the AntennaPod application itself semi works as expected, but once you add in the notification player, lock screen, or the widget, you find there are inconsistencies in how it works with itself and how it compares to other apps.

Here is my limited experience with video playback.
PocketCasts

  • Home button goes to an audio only mode
  • Back button goes audio only and gets you back to the main app
  • When opening the app from a stopped video you are presented an interface showing the current video, at the current index, controls, and clicking back gets you to the main app
  • Videos are supported in landscape or portrait mode.

Plex

  • Home button goes to PnP
  • Back button stops playback
  • When opening the app from a stopped video, you are presented an interface showing that episode and an option to play
  • Videos are supported in landscape or portrait mode

YouTube

  • Home button goes to PnP
  • Back button takes you to various modes, all continue playing video, and you eventually end with PnP
  • When opening the app from a stopped video, you are presented an interface showing that episode and an option to play
  • Videos are supported in landscape or portrait mode

AntennaPod

  • Home button goes to PnP
  • Back button stops playback, leaves you in landscape
  • When opening the app from a stopped video, you are sometimes presented black screen, no way to easily get back to the main app, and back doesn’t take you to the main interface but exits the app
  • Videos are supported in landscape only
  • Once a video podcast completes playing, the video interface does not exit

I’m trying not to harp too much on this issue, but all it takes is one video podcast coming on while you are driving to realize this is a significant issue. I am now cautious to queue up only audio podcasts during any time I may be driving, as once video start my experience has never been great.

I’m really curious what the “upon exiting video” did specifically, why it was removed, and what impact it has specific to this topic. Was this a regression to user experience, or different topics?

Thanks

#13

Thanks for all the discussion about this!

My use cases are very similar to what Adam described: podcasts that are only available as videos, but where 90-95% of the visuals are unnecessary (think, the host’s face talking into a microphone) but the remaining 5-10% are extremely important for context (e.g. a schematic takes over the screen while the host’s face moves to the bottom corner). My previous podcast apps and the earlier builds of AntennaPod all handled these situations well, where I could start the video before locking the screen and continue listening to the audio. Once I needed a visual, I could quickly unlock my phone to glance at it for a few minutes before locking it again and putting it back in my pocket without ever interrupting the playback or having to take off gloves to tap around in the app menus.

I also appreciate Matth78 and dpremy’s research into how other apps handle this scenario. I would add that one of the main reasons I use NewPipe as my YouTube client (aside from preferring FOSS software) is that it allows you to configure this behavior so locking the screen seamlessly switches between audio-only mode and regular video playback.

While searching through the feature requests, bug reports, PRs, and GitHub Issues to see if anyone else had already raised this topic before I started a new thread, I definitely gained some sympathy for why the default would have been changed. As ByteHamster described, many users seemed to be confused and frustrated by the previous way videos were handled and I’m sure this new behavior will be very helpful for them. I only wish the previous behavior could still be available as a configurable option, even if it isn’t the default.

#14

Let’s trace back our steps. The current behaviour was introduced in response to this ticket:

(Which was actually mentioned already by @cburton in the first post.)

To quote my past self:

I think it would make sense to combine ByteHamster’s proposals with a new button to switch to ‘audio only’:

  • remove ‘upon exiting video’ option
  • like in other apps, pressing back closes and pressing home starts pip
  • make “continue to play audio” a setting on its own (to override default behaviour described above)
  • add a ‘video/audio’ toggle in both video and audio view (for quick one-off changes)

Now, it seems that the third point (a ‘continue to play audio’ setting) was not (yet) implemented. The last point (a video/audio toggle) was ‘replaced’ by a ‘Switch to audio only’ option in the overflow menu.

To enhance it, I would suggest the following:

  • add the ‘continue to play audio’ setting, and if active, continue playback as audio instead of stop
  • move the ‘Switch to audio only’ button from the overflow menu to the top bar (as icon, e.g. crossed-out-eye)

How does that sound?

2 Likes
#15

“add the ‘continue to play audio’ setting, and if active, continue playback as audio instead of stop” sounds like what we started with in this request. First line, in fact, “This feels a bit like a bug” and you’ve pointed out it’s a planned feature not yet implemented. I think that was our missing link. With that setting implemented, I have no preference on where the button gets placed. So long as I can kill the screen and not have to turn the screen back on to press play again.

Thanks

#16

I too think this may resolve my use case, or at least make a significant impact, making this thread mute. If I still have issues when a video podcast comes up while driving, I can open a separate thread dedicated to that after this is implemented.

Thanks for the discussion and looking back to how we got here.