Need release after onPlayerError

[sneltyn]

Do I need to release a player after an error? This link https://github.com/sneltyn/ExoPreload is a demo that demonstrates the problem (if it is a problem). The demo shows how the player gets stuck on state STATE_BUFFERING

During the launch of the demo, turn off the Internet;)

The demo does the preloading of the HLS or mp4 using the ConcatenatingMediaSource

Maybe I'm doing something wrong.

ExoPlayer: 2.9.4

[ojw28]

You should always call release when you no longer require the player instance. However, a player can be re-used (e.g. re-prepared) after an error occurs. So if you plan on re-using the player after the error, you should not call release at that point.

[sneltyn]

@ojw28 thank! Then I do everything right, but after the error the player can no longer play anything. Please see the demo.

[ojw28]

@tonihei - Could you take a look at this? Could be wrong, but it looks like the player has a ConcatenatingMediaSource containing a single ClippingMediaSource, which wraps an ExtractorMediaSource. Before the second prepare call the ConcatenatingMediaSource is cleared and a new ClippingMediaSource -> ExtractorMediaSource is added. The player then ends up stuck in the buffering state.

It looks like replacing the ConcatenatingMediaSource with a new instance rather than clearing it solves the problem, but this shouldn't be necessary?

[ojw28]

A little extra info: It looks like ConcatenatingMediaSource.scheduleListenerNotification is called (sets listenerNotificationScheduled=true and posts MSG_NOTIFY_LISTENER). Then ConcatenatingMediaSource.releaseSourceInternal is called (removes MSG_NOTIFY_LISTENER). From that point on scheduleListenerNotification is broken, because listenerNotificationScheduled=true even though there's no pending MSG_NOTIFY_LISTENER.

I guess releaseSourceInternal needs to set listenerNotificationScheduled=false, but I'm not sure what should happen to pendingOnCompletionActions. Maybe they all need dispatching in releaseSourceInternal?

[ojw28]

Fixed in dev-v2. The fix will be part of 2.9.5.