Update the player to display current livestream info on pause and resume (for 24/7 and multi-show livestreams)

[DocDoo]

Describe the bug I have now on 2023-feb-17 and 2023-feb-24 experienced that when I start listening to a live episode of Podcasting 2.0 and I, after perhaps 3-5 minutes, pause playback of the live episode.. Then when I resume some time after the show has ended being live, I will listen to another 3-5 minutes of the show I paused, but then without any visual or audible cues the player will without pause (as I remember it) switch to playing back an audio stream from a podcast show which is unknown to me.

On the two occasions above I wasn't prepared for documenting the issue, so I don't have a recording of it happening live. But now that I know what to expect I will try to screen record the next time I have an opportunity to resume a live show which I paused until after it wasn't live any longer.

On 2023-feb-24 I did do a screen recording (added below) which demonstrates that when resuming the Podcasting 2.0 episode, which is already loaded in the player, the unknown audio stream plays. When I then go to the episode list for Podcasting 2.0 and then starts playback of the same episode (which is now no longer listed as Live) then I get the proper audio stream.

To Reproduce Steps to reproduce the behavior:

1. Start listening to a Live episode (most likely of any podcast) of 'Podcasting 2.0'.
2. Pause playback after 5-10 minutes.
3. Resume ~3 hours later when the episode is no longer live.
4. Expect to continue to listen to what you paused for 3-5 minutes.
5. After 3-5 minutes experience that the player, without any delay, changes to play back an audio stream from an unknown show (at least it's not a show/podcast I can recognize or have in my list of subscribed podcasts).

Expected behavior Pause and resume of a Live episode should happen seamlessly even if the pause and resume happen across an episode changing from Live to On demand.

Screenshots https://user-images.githubusercontent.com/46087270/221347549-62f57268-6241-40f6-8486-b9ea9adb27a5.mp4

Smartphone (please complete the following information):

• Device: Samsung Galaxy Note 10 Plus
• OS: Android 12
• App Version: 4.12.3

Additional context

[mitchdowney]

@DocDoo thank you for this excellent bug report!

Podverse doesn't have great caching support yet for livestreams. It may work ok for pausing then resuming after a short amount of time, but if there is a gap in the cache we have saved, then the app will jump ahead to the latest time from the livestream.

I think the reason you're hearing another podcast is because Podcasting 2.0 is broadcast on the 24/7 No Agenda Stream, and after Podcasting 2.0 ends, a different podcast plays on the stream.

The fix to allow reliable caching is unfortunately mostly out of our control at the moment. Basically we will need the podcaster's livestream server to allow us to request specific recorded times from the livestream. This can be done with some more modern media file formats like HLS, but I think No Agenda Stream uses an older media file format which may not support that feature.

While this issue is out of our control, we're going to try to work with livestream hosts to add feature support, because the ability to pause and rewind livestreams would be a huge improvement.

[DocDoo]

Thanks for the feedback on this @mitchdowney. Your explanation of how live streams are currently handled makes a lot of sense and that Podcasting 2.0 is just one show on the No Agenda stream running around the clock explains my experience. Could a interim "solution" be to have the Podverse player refresh its displayed information on what it is playing at the time of Resume happening, but only when Pause was done during a Live episode? Wouldn't this then tell the user that Podcasting 2.0 was over and now something else was being broadcast on the same stream?

[mitchdowney]

@DocDoo that is a good idea, and yet a fairly complex topic. Basically the podcaster will need to provide us with the information required to know a show has ended on a 24/7 stream and a new one has begun, but no one has tried implementing that use case into RSS yet. It's on the Podcasting 2.0 radar, but I think it may take some time to iron out how to handle it as it's a little more advanced use case. Our livestream functionality is mainly intended for streams that go online and then offline at the moment, so 24/7 ones will be a bit quirky for now.

[DocDoo]

Hi @mitchdowney, (apologies for my ignorance on this subject, and I suspect I will hold my piece after this reply 😋) but are you sure the player needs to know that a live episode has ended? At the time of Pause the player knows if what is being paused is a live episode or not, so when Resume happens, then for good measure couldn't the player just query the source (of the stream) for information on the episode (what is currently being broadcast) and if this is different from what it was at the time of Pause, then it simply drops any stream data it has cached and gives the listener a visual and audio cue that something else (than expected by the listener) is being resumed?

[mitchdowney]

Yeah that sounds pretty much exactly right lol. If we add the handling only on play / pause that would simplify things a lot.

I think our main challenge is dealing with pausing and resuming livestreams. If it's 10:35, and I paused at 10:25, and a new show began at 10:30, I don't know how the player would know what time it is relative to the livestream time position, and therefore know which show info to display 😵‍💫 or worse, I listen to a livestream that isn't a 24/7 livestream, and I paused before the end, then press play, and the app finds out the stream has ended, so it closes the livestream instead of playing the remaining time.

I dunno if we can avoid those issues, except maybe with a new RSS namespace / attribute? AFAIK there isn't a namespace for letting apps know which livestreams are 24/7 or multi-show.

Anyway, I'll still add the play/pause to refresh livestream info feature as part of this ticket, and we can create other livestream bug tickets later.

[mitchdowney]

@DocDoo trying to start a convo with Dave and Alecks about the issue on podcastindex.social: https://podcastindex.social/@mitch/109974517652872362

I'm going to unassign this ticket from me for now, because I think my work is blocked on it until we get answers from the Podcasting 2.0 community, and I try to only assign issues to myself I'm actively working on.