ExoPlayerImplInternal: NPE

[PaulWoitaschek]

I received an exoplayer error which was quite hard to reproduce. I'll send the files separately via mail.

To reproduce the issue, follow these steps:

• Setup the two files as a concating media source like here
• Seek to 21:00 of the first track
• Play for about a minute and the player will just stop playing in the middle of the file.
• Now jump to the second track -> Crash

E/ExoPlayerImplInternal: Internal runtime error.
                         java.lang.NullPointerException: Attempt to write to field 'long com.google.android.exoplayer2.decoder.DecoderInputBuffer.timeUs' on a null object reference
                             at com.google.android.exoplayer2.extractor.DefaultTrackOutput$InfoQueue.readData(DefaultTrackOutput.java:757)
                             at com.google.android.exoplayer2.extractor.DefaultTrackOutput.readData(DefaultTrackOutput.java:258)
                             at com.google.android.exoplayer2.source.ExtractorMediaPeriod.readData(ExtractorMediaPeriod.java:328)
                             at com.google.android.exoplayer2.source.ExtractorMediaPeriod$SampleStreamImpl.readData(ExtractorMediaPeriod.java:551)
                             at com.google.android.exoplayer2.BaseRenderer.readSource(BaseRenderer.java:263)
                             at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.readFormat(MediaCodecRenderer.java:494)
                             at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:479)
                             at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:479)
                             at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:315)
                             at android.os.Handler.dispatchMessage(Handler.java:98)
                             at android.os.Looper.loop(Looper.java:154)
                             at android.os.HandlerThread.run(HandlerThread.java:61)
                             at com.google.android.exoplayer2.util.PriorityHandlerThread.run(PriorityHandlerThread.java:40)

I generally receive many complaints by users about ExoPlayer. A lot of media out there has problems with metadata so it might make sense to try to play these non compliant files anyway. Like in #2239.

[ojw28]

It would be helpful if you could include all of the information requested in the issue template. For example a proper bug report and (more importantly in this case) the specific version of ExoPlayer that this reproduces with.

[ojw28]

For the final paragraph: If you provide complete information and can demonstrate that particular issues affect more than a single media file, then we'll investigate and put fixes in place. Without the information requested in the issue template we're not able to do this.

[ojw28]

I can reproduce the problem. It's not helpful that both audio files include a text track that's approximately (not exactly) twice as long as the audio. This is why the content appears to have a duration of around 45 minutes when the actual audio is only about 22 minutes long. VLC also ends up with the duration being way too long for the same reason. This is also the reason why the player gets confused and stuck in the buffering state.

The actual stack trace that follows when you manually skip to the next entry in the playlist is a bug, which we will use this issue to track.

[PaulWoitaschek]

Sorry for the incomplete report.
I tested it on Nexus 5x with Android 7.1.1 and ExoPlayer 2.1.1

[ojw28]

We'll push a fix for the stack trace shortly, which will allow the user to advance to the next item without failure. We'll also push a fix for an issue that prevents backward seeking within the same item once in the "stuck buffering" state.

The stuck buffering state itself is due to the media containing an incorrect duration for the text track that's for some reason present. Not getting stuck in this case is tracked by #1874, but when that issue is fixed the behavior will be to play out about 20 minutes of silence up to the stated duration of the media. This is the technically correct thing to do. The only way to avoid this is to fix the media itself.

[PunitD]

@ojw28 #1874 issue happens only on particular set of devices when we try to play videos(in playlist) stored in local storage of device.

Also, it happens only when moving from 1st to 2nd track in playlist and not otherwise.

Any quick workaround like suggested by you in previous comment of always allowing media to play for stated duration can be implemented?
Any suggestions?

[ojw28]

The failure is fixed in dev-v2. #1874 tracks not getting stuck in the buffering case, as described in more detail above.

Any quick workaround like suggested by you in previous comment of always allowing media to play for stated duration can be implemented?

Either way, a user isn't going to want to sit around for 20 minutes waiting for the next item to start. Fixing #1874 is quite technically difficult; it's not a quick workaround. We'll follow up on that issue in due course, but it's not going to be a quick thing.