Error: Unable to access media file (1000)

App version: 2.2.0 (35259f554)
Android version: 8.0.0

Device model: Samsung Galaxy S7

Expected behaviour: Download and playback normally

Current behaviour: Error: Unable to access media file (1000) when attempting to playback certain, possibly older mp3 files.

First occurred: Within the last month

Steps to reproduce:

  1. Download certain episodes of several Podcasts (The SubGenius Hour of Slack Podcast: Hour of Slack #1125a - Insane SubGenius Pledge Drive Show
  2. Error occurs after attempting playback within Antennapod App
  3. Playback successful when using Sharing Option to copy URL directly and playing via VLC media player app
  4. Have not yet determined why some downloaded episodes will play back and others will not.

Environment: Download location is set to SD card on phone.

Did you change the media player in Settings»Playback?

Haven’t changed it. It’s currently set to “ExoPlayer (recommended)”. But thanks for pointing out that option. The amazing number of options is part of what I LOVE about this app.

I’ve just now tried using “Built-in Android player (depricated)” and it did successfully play the previously “unplayable” episodes. However I found that once the player started playing I could not pause or stop the playback from within the Antennapod app without rebooting.

Next I switched back to ExoPlayer and was again returned the Unable to access media file error.

Finally I changed to “Sonic Media Player (depricated)” and the previously unplayable files played fine and playback functions seemed to work as well.

Should I stick for now with the Sonic Media Player selection? I’m curious if this is somehow a rights or permissions issue wherein ExoPlayer for some reason just does not have the appropriate permissions to access or playback the file.

Thanks so much for your guidance!

1 Like

Thanks for testing. I am pretty sure that it is not a permission issue because all players are included in the app and just use AntennaPod’s permissions. Usually, playback problems only happen when not using ExoPlayer. If you want to help fix the problem, it would be great if you could send me the full log files of AntennaPod from the “report bug” screen. The logs contain details about what podcasts you listen to (and when), so it is probably best to send it by email instead of publicly. My email address is info@<my user name>.com.

Cool! Thanks for your help! Log files sent accordingly.

Oh, sorry. I forgot to tell you the most important point :smiley: Could you please switch back to ExoPlayer, press an episode (so that the error message is displayed) and then send the logs directly afterwards, please? The logs usually only contain the actions of the last few hours.

Another person, Konrad, just sent me an email. Their logs contain the following error messages:

ExoPlayerImplInternal: Source error
ExoPlayerImplInternal: None of the available extractors (MatroskaExtractor, FragmentedMp4Extractor, Mp4Extractor, Mp3Extractor, AdtsExtractor, Ac3Extractor, TsExtractor, FlvExtractor, OggExtractor, PsExtractor, WavExtractor, AmrExtractor, Ac4Extractor, FlacExtractor) could read the stream.
ExoPlayerImplInternal:       at$ExtractorHolder.selectExtractor(SourceFile:1096)
ExoPlayerImplInternal:       at$ExtractingLoadable.load(SourceFile:975)
ExoPlayerImplInternal:       at$
ExoPlayerImplInternal:       at java.util.concurrent.ThreadPoolExecutor.runWorker(
ExoPlayerImplInternal:       at java.util.concurrent.ThreadPoolExecutor$
ExoPlayerImplInternal:       at
System.err: de.danoeh.antennapod.core.util.vorbiscommentreader.VorbisCommentReaderException: Length to read: 47 actual: 0
System.err: 	at de.danoeh.antennapod.core.util.vorbiscommentreader.VorbisCommentReader.readInputStream(SourceFile:63)
System.err: 	at de.danoeh.antennapod.core.util.ChapterUtils.readOggChaptersFromInputStream(SourceFile:113)
System.err: 	at de.danoeh.antennapod.core.util.ChapterUtils.loadChaptersFromMediaFile(SourceFile:62)
System.err: 	at de.danoeh.antennapod.core.feed.FeedMedia.loadChapters(SourceFile:411)
System.err: 	at de.danoeh.antennapod.core.feed.FeedMedia.loadChapterMarks(SourceFile:397)
System.err: 	at de.danoeh.antennapod.core.service.playback.PlaybackServiceTaskManager.lambda$startChapterLoader$3$PlaybackServiceTaskManager(SourceFile:318)
System.err: 	at de.danoeh.antennapod.core.service.playback.-$$Lambda$PlaybackServiceTaskManager$CyYJG8YdrmvA9z0niJUx21Vs_AA.subscribe(lambda)
System.err: 	at io.reactivex.internal.operators.completable.CompletableCreate.subscribeActual(SourceFile:39)
System.err: 	at io.reactivex.Completable.subscribe(SourceFile:2302)
System.err: 	at io.reactivex.internal.operators.completable.CompletableSubscribeOn$
System.err: 	at io.reactivex.Scheduler$
System.err: 	at
System.err: 	at
System.err: 	at
System.err: 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(
System.err: 	at java.util.concurrent.ScheduledThreadPoolExecutor$
System.err: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(
System.err: 	at java.util.concurrent.ThreadPoolExecutor$
System.err: 	at
System.err: Caused by: Length to read: 47 actual: 0
System.err: 	at
System.err: 	at
System.err: 	at de.danoeh.antennapod.core.util.vorbiscommentreader.VorbisCommentReader.findIdentificationHeader(SourceFile:97)

While the first error message looks like a format error, the second one makes me think that AntennaPod somehow can’t access the media file. Did you try deleting and re-downloading?

Yes. Deleted and download again was my first step with each file, thinking that perhaps the file was corrupt or perhaps incomplete. Interestingly, I can toggle between ExoPlayer and Sonic Media Player attempting to playback the same file: ExoPlayer will not play, but Sonic Media Player will. Ze plot thickens!

I received your email @noexit. Looks like ExoPlayer is actually crashing internally - even the most recent version does this. The reason is that the file specifies a broken cover image.

Unexpected exception loading stream
  java.lang.ArrayIndexOutOfBoundsException: length=3; index=3
      at java.util.concurrent.ThreadPoolExecutor.runWorker(
      at java.util.concurrent.ThreadPoolExecutor$

We don’t actually use the cover image that ExoPlayer loads, though. AntennaPod has its own parser for cover images (that cannot parse the broken file either, but a crash there does not prevent playback). I wrote a code change that disables parsing metadata (such as images) in ExoPlayer. I hope that I have not overlooked something and we actually do need the metadata. Let’s see if someone finds a problem when later releasing the change in AntennaPod 2.3.0 beta.