OkHttpDataSource: onTransferEnd called twice

[pantos27]

seems like listener.onTransferEnd is called twice on OkHttpDataSource

once in close() which later calls closeConnectionQuietly() which calls close() again.

[ojw28]

I'm confused by this statement. There's only one call to onTransferEnd in OkHttpDataSource, and it's here. Furthermore, closeConnectionQuietly does not call close on the instance. Please clarify?

[pantos27]

ok, further investigation shows indeed that closeConnectionQuietly does not call close of the same instance, but the fact remains that onTransferEnd is still called twice in the same instance. once when getBufferedPercentage returns 0 and another time where getBufferedPercentage>90

[ojw28]

• closeConnectionQuietly doesn't do anything that would be externally visible outside of the class/instance. I'm unclear why you're suspicious of that method really. It only contains two lines of code. Two of them just null variables, and the other is calling close on an internal object?
• The same TransferListener can be shared by multiple DataSource instances. Depending on what media you're playing, it may be that there are multiple requests being made. I'm really not sure what the issue is that you're reporting here.

[pantos27]

The issue is that onTransferEnd is called more than once from the same instance of exoplayer and the same DataSource.
Is it not defined as "Invoked when a transfer ends"?

[ojw28]

DataSource instances are not single use. It's valid for a DataSource to be used for more than one request.

[pantos27]

That's great.
Still, in a single used DataSource, it is called twice, every time.
Once right after prepare was called and getBufferedPercentage was at 0 and another time where some actual data was transferred and getBufferedPercentage was close to 100.

What's the logic in onTransferEnd anyway?
should it not fire, if no network issues happen and the request completes at one go, when getBufferedPercentage is actually at 100?

[ojw28]

Your assumption that playing a piece of media maps onto a single network request is incorrect. Some media playbacks will require many (typically bounded) network requests. Each one of them counts as a transfer. Hence this is working as intended.

Depending on exactly what you're playing, it's either necessary to make two requests due to the nature of the media, or it's an inefficiency in ExoPlayer (note: it's not "broken" as such and neither is it doing anything that the player is not legitimately allowed to do; it's just not as efficient as it could be). The main cause of the latter is tracked by #1041.