Downloaded episode playback stops after losing internet access

[mitchdowney]

I thought this was fixed in a previous release, but it is still being reported...

I seem to be having an issue with the downloaded episodes. In simplest terms, there are several cellular 'dead spots' on the way to work which interfere with streaming. So I figured I'd download the episodes at home over wifi, and problem solved, right? Apparently not.

For whatever reason, when I hit that cellular dead spot, the playback in the Podverse app stops soon after. Any attempt to hit 'play' just results in the spinning circle for a few seconds, and then... nothing. Back to the 'paused' state.

I've tried restarting the app, switching in and out of airplane mode, etc. to try and jog things a bit, but no success as of yet.

Platform: android / Version: 4.6.7 build 1095

[mitchdowney]

Possibly blocked by #1179

[mitchdowney]

Still haven't been able to reproduce this issue. I'm wondering if it could be related to device settings rather than app logic.

[jncosideout]

I'm experiencing it on Android 12 (LineageOS MicroG 19.1) on Moto G7 Power. Ver 4.8.0 for F-Droid

I haven't used the app in a long time, then it just started happening when I recently started using it again.

1. Subscribed to a podcast
2. Downloaded an episode
3. Turned off wifi
4. Playback stops after 3 min of play, won't start again until I turn wifi back on

Reproduced again after deleting and redownloading. Also reproduced after deleting all downloads by going to Settings > Downloads > Delete downloads and downloading the episode again.

[mitchdowney]

@jncosideout I just tried but couldn't reproduce the bug on a Google Android Pixel 4a.

I tried the following:

1. Downloaded an episode of Podcasting 2.0
2. Turned off wifi and network data
3. Tapped the play button to load and play the downloaded episode.

I let the phone play for 30 minutes, and it never stopped playing...

If you haven't already, can you update to the latest Podverse F-Droid v4.10.2? I'm doubtful an upgrade will fix it for you, but a lot has changed since 4.8.0.

Also, are you using an SD card with Podverse?

Since this is a LineageOS issue, it may be difficult for @kreonjr and I to work on. I just installed GrapheneOS for the first time a few weeks ago on a Pixel 3 though. I'll try testing on that soon.

[jncosideout]

Yes I am using an SD card for podcast downloads on Podverse. Maybe it's not related to LOS since I use a Moto G7 Power and the user who reported #1461 also has a Moto G Power of some kind.

I will update to 4.10.2 and report back. But first I'll try to repro without downloading to SD.

[jncosideout]

ok I updated to 4.10.4 and tested a downloaded episode and it failed again after a min or so of playback. I still had downloads set to SD. Deleted the all episodes and tried again after switching downloads from SD -> device storage and tried again. Still doesn't work.

[mitchdowney]

@jncosideout thanks for the update.

Hmm this is difficult without the ability to reproduce the bug locally. We'll be rolling out major updates to our audio and video player in 4.11.0 beta. If you'd have a chance to retest with that beta I'd appreciate it. I'm not aware of a fix for this specific issue in the update, but the audio/video libraries we're upgrading contain a ton of changes, so we're lucky a fix is included.

I should have it ready for beta within the next few days.

[jncosideout]

cool, I just heard about that upgrade on PC2.0 # 116. Looking forward to it!

[mitchdowney]

@jncosideout this might be fixed in v4.12.0.

https://github.com/podverse/podverse-rn/pull/1651

If it is isn't fixed, then it might be worth re-testing after https://github.com/podverse/podverse-rn/issues/1611 is finished.

[mitchdowney]

@jncosideout 4.12.0 is available on Podverse now. If you have a chance I'd appreciate if you can confirm if you're still running into this issue.

[jncosideout]

Updated to 4.12.0 and still encountered the error.

1. Downloaded an episode
2. Turned off WiFi and network data
3. Played the episode
4. Episode does not play, play button has a :warning: icon on it
5. Turn Wifi back on, press play, episode starts
6. Turn Wifi off, episode plays for a few more minutes before shutting off again (same warning icon)

[mitchdowney]

@jncosideout thanks again...dang I just tried all of those steps, and made sure the phone doesn't have internet access, even turned off wifi on my computer, and still can't reproduce the issue.

The only thing I can think of causing this is some kind of file storage path issue...where the downloaded episodes for some reason aren't being found on your device...or some strange player issue, where it doesn't want to accept the downloaded episode format for some reason.

Until I can reproduce the issue I'm pretty stuck unfortunately :(

[mitchdowney]

@jncosideout this is a long shot...but if the issue is still happening for you, can you try turning battery settings to "Unrestricted" for the app sometime, and retest? It seems like Android can do funky things for media player apps due to battery optimization settings. It doesn't make sense to me that would be related, but https://github.com/doublesymmetry/react-native-track-player/issues/818#issuecomment-569304463 made me think it might be possible.

[jncosideout]

Ok I just tried Unrestricted battery for the app and it didn't work. I also tried turning off and on Settings > Downloads > To external storage to reset the path before testing again, no luck.

[mitchdowney]

@jncosideout alright, dang 😞 thanks for trying. Will keep investigating.

[jncosideout]

I just did two tests to see how long it plays if I start a downloaded episode with wi-fi on, then immediately shut wi-fi off and resume play:

1. with Unrestricted battery it played for about 7 min
2. with Optimized (normal) battery it played for about 3 min

In every case, after a few min it shuts down with the same :warning: icon and won't play again until I turn wifi or cellular data back on. The play icon shows the spinning circle for a second before failing again.

I'll do this test a few more times to get some averages.

[jncosideout]

those last two tests were on Wi-fi. Then I did two on cellular (which I rarely use)

1. with Optimized (normal) battery it played for about 3 min
2. with Unrestricted battery it played for about 4 min

I don't think the variables I'm testing have much effect. But I think the tests show that when it plays, it is in streaming mode, and the length of time played after disconnecting from all networks is only a function of how much data was buffered.

[jncosideout]

also, the first of these last 4 tests was right after I finished downloading an episode. The subsequent 3 tests were done while playing that episode, not on other episodes or after starting a new download. I just changed those variable, then went back to the app

[mitchdowney]

@jncosideout ok thanks again for your help.

Hmm the only thing I can imagine is that there is a file path or file permissions issue preventing our checkIfFileIsDownloaded function from finding downloaded episodes for some Android devices.

The getDownloadedFilePath function it uses is pretty straightforward...using downloader.directories.documents.

I don't want to make you do any more testing 😬 but I am wondering:

1. Are you testing with the Podcasting 2.0 podcast? That's the only one I tested with. In theory there could be issues with the id or episodeMediaUrl parameters we are using in our checkIfFileIsDownloaded helper, than only fail with specific episodes.

2. You mentioned you were using SD card storage at one point, then disabled it. I wonder if there is a bug with our SD storage card handling AND if when you disabled it, the app isn't properly removing the SD card setting. I can look into that...

Other info...we are using the react-native-background-downloader library which is deprecated and has not been updated for years. Whether it fixes this issue or not, we should upgrade to the actively maintained fork. #1722

Issues for me to look into if they are related...

https://github.com/EkoLabs/react-native-background-downloader/issues/67

https://github.com/kesha-antonov/react-native-background-downloader/issues/3

[jncosideout]

I'm testing with Hog Story's feed. The first one was the episode Adam appeared on, # 333, on Jan 3rd. But the latest tests I ran were the latest episodes from that feed.

Most of these tests I did with SD card downloads, but I have tested 'on device' downloads before. I'll try saving to device again if you want.

I'm an iOS dev, btw. I have done one sample learning project before and set up Android Studio. Maybe I can do some debugging (if I can free up time). Is it an easy env to setup?

[mitchdowney]

@jncosideout any help trying to debug the code would be appreciated! We are up past our ears in work to do.

I think it is actually pretty easy to get Podverse running locally, but I don't know if anyone has done it outside our core team?

These docs have not been updated in years, but you can find a startup guide here: https://github.com/podverse/podverse-rn/blob/master/Contributing.md

One thing that might be missing for that doc is our clean.sh script which is intended for first time startup install. I could get you a copy of a .env you could use with prod data too.

If you would be up for pairing, even if it is just to iron out our Contributing documentation and make sure it is up-to-date, and you're able to run the app on your machine, I'd greatly appreciate it, and could hop on a screenshare or chat through Matrix or Discord.

[jncosideout]

Cool. I'll give it a shot and let you know how far I get. Then we can do a screenshare onboarding.

[jncosideout]

Tested with local storage downloads instead of SD Card today (still on v4.12.3) and did not get the "playback stops" error. So it must be caused by saving downloads to an external card.

[mitchdowney]

@jncosideout very interesting. Thanks that should help narrow things down a lot.

Unfortunately I still don't know when I'll have time to work on this, but it is a critical bug we need to fix...

[mitchdowney]

Please refer to #1737 for what appears to be a duplicate of this bug.

[mitchdowney]

This has been a huge problem for a long time, but it only seems to affect some listeners. I have never been able to reproduce the issue, and none of us are actually Android developers, so we've been stumped.

We're looking into posting to freelancer websites to see if we can afford to hire people to fix bugs like this. Unfortunately I don't think @kreonjr and I will be able to solve this one on our own.

[amugofjava]

Hey @mitchdowney,

I have managed to reproduce this issue a couple of times using an Android emulator.

Setup

1. Create an Android emulator - in my case Android 10 - and assign an SD card to it.
2. Start Podverse, go into settings and choose the SD card for downloads. Switch off auto-downloads when subscribing.

Reproduce issue

1. Subscribe to a podcast - in my testing I used No Agenda.
2. Download an episode and leave it to complete - do not move off the main screen.
3. Once downloaded, start playing the episode.
4. As soon as you can, switch on Airplane mode - and wait.

After a few minutes, playback stops. It looks to me that, once the download is complete, Podverse is still attempting to play the streaming version rather than the freshly downloaded one.

Checking the logs, I see see a couple of significant errors.

When attempting to play:

2023-06-10 13:25:29.173 13755-13863 System.err              com.podverse                         W  java.lang.UnsupportedOperationException: Unsupported Uri content://com.android.externalstorage.documents/tree/primary%3AMusic/document/primary%3AMusic/a7HwG33Og.mp3
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:174)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.database.DatabaseUtils.readExceptionFromParcel(DatabaseUtils.java:142)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.content.ContentProviderProxy.query(ContentProviderNative.java:472)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.content.ContentResolver.query(ContentResolver.java:1183)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.content.ContentResolver.query(ContentResolver.java:1115)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.content.ContentResolver.query(ContentResolver.java:1071)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at com.rnfs.RNFSManager.getOriginalFilepath(RNFSManager.java:93)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at com.rnfs.RNFSManager.stat(RNFSManager.java:626)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at java.lang.reflect.Method.invoke(Native Method)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.os.Handler.handleCallback(Handler.java:938)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.os.Handler.dispatchMessage(Handler.java:99)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at android.os.Looper.loop(Looper.java:223)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
2023-06-10 13:25:29.175 13755-13863 System.err              com.podverse                         W  	at java.lang.Thread.run(Thread.java:923)

And later on:

2023-06-10 13:27:26.331 13755-13888 ExoPlayerImplInternal   com.podverse                         E  Playback error
                                                                                                      UnknownHostException (no network)
2023-06-10 13:27:26.333 13755-14494 CCodecConfig            com.podverse                         I  query failed after returning 7 values (BAD_INDEX)
2023-06-10 13:27:26.333 13755-14494 Codec2Client            com.podverse                         W  query -- param skipped: index = 1342179345.
2023-06-10 13:27:26.333 13755-14494 Codec2Client            com.podverse                         W  query -- param skipped: index = 2415921170.
2023-06-10 13:27:26.333 13755-14494 CCodecBuffers           com.podverse                         D  [c2.android.mp3.decoder#200:Output[N]] popFromStashAndRegister: output format changed to AMessage(what = 0x00000000) = {
                                                                                                      int32_t channel-count = 2
                                                                                                      string mime = "audio/raw"
                                                                                                      int32_t sample-rate = 44100
                                                                                                    }
2023-06-10 13:27:26.333 13755-14494 CCodecBufferChannel     com.podverse                         D  [c2.android.mp3.decoder#200] MediaCodec discarded an unknown buffer
2023-06-10 13:27:26.333 13755-14494 chatty                  com.podverse                         I  uid=10155(com.podverse) identical 2 lines
2023-06-10 13:27:26.334 13755-14494 CCodecBufferChannel     com.podverse                         D  [c2.android.mp3.decoder#200] MediaCodec discarded an unknown buffer
2023-06-10 13:27:26.336 13755-14494 hw-BpHwBinder           com.podverse                         I  onLastStrongRef automatically unlinking death recipients
2023-06-10 13:27:26.339 13755-13755 BaseAudioPlayer         com.podverse                         D  Abandoning audio focus...
2023-06-10 13:27:26.344 13755-13862 ReactNativeJS           com.podverse                         I  src/services/playerAudioEvents.ts
2023-06-10 13:27:26.344 13755-13862 ReactNativeJS           com.podverse                         I  playback-error
2023-06-10 13:27:26.344   743-743   MediaTimeout            com.android.systemui                 V  schedule timeout for 0|com.podverse|1|null|10155
2023-06-10 13:27:26.345 13755-13862 ReactNativeJS           com.podverse                         I  { message: 'Source error',
                                                                                                      code: 'android-io-network-connection-failed' }

The download is working though as I can see the files in the device explorer:

[mitchdowney]

@amugofjava thanks so much for the investigation. Your test case sounds like #1717, and while #1717 is definitely causing this issue sometimes, I'm not sure it explains all of our offline playback issues (but maybe?). In any case I'm going to try to fix this scenario today.

[mitchdowney]

@amugofjava I attempted to apply a fix for the other offline playback failure issue I described, and I think that may help, but the steps you described sound like something else.

I just tried reproducing the bug with the steps you provided, and I could not make it happen while using Android Emulator > Pixel 3a > API 34 > Android 13. I tested with No Agenda and Podnews Weekly Review. I let No Agenda play for 5+ minutes, and skipped the position forward and backwards with no issues.

I also just tried reproducing the bug with Android Emulator > Pixel 3a > API 29 > Android 10, and couldn't reproduce it with that version either.

I wonder what is different about our test environment?

[amugofjava]

Hi @mitchdowney,

Hmmm, it could be a difference in test environment. My main dev box is a PC running Ubuntu. I have a Mac too, but I don't have a Play Store version of the emulators on there. If you can send me an APK I would be happy to repeat the testing on my Mac too.

I've tried again this morning on an Android 13 emulator, with 3GB SD Card provisioned and a fresh install of Podverse from the Play Store (production track). I managed to reproduce it consistently. I've included a screen recording below in case it is something I am doing - could it be the way I am setting up Podverse to use the SD Card? When you tested, did Android prompt you to select a folder to store the episodes and, if so, which folder did you choose?

podnews_testing_android13_linux_30.webm