When (too late) trying to get `currentTime` the player throws an exception `No state for o with ID null is registered` instead of returning 0.0

Support
, ,
1

Hi,

I was (granted too late) asking the Player for the currentTime, which resulted in a fatal exception with message “No state for o with ID null is registered” (see below obfuscated StackTrace). The documentation for currentTime mentions “Returns 0.0 if there is no active playback session.” so I kind of expected to at least get a 0.0 back instead of an error being thrown.
I have update my call to stop checking the currentTime but I still feel the behaviour might be incorrect, so would like to ask you to check.

To reproduce make a Timer, or other async process, to make a call to currentTime after the stream/player was already stopped/destroyed.

Kind regards,
Kaspar

com.bitmovin.player.j.b: No state for o with ID null is registered.
	at com.bitmovin.player.i.i.c(SourceFile:4)
	at com.bitmovin.player.i.d.c(Unknown Source:12)
	at com.bitmovin.player.i.b.getPlaybackState(SourceFile:38)
	at com.bitmovin.player.n.d.l(SourceFile:1)
	at com.bitmovin.player.n.d.getMaxTimeShift(SourceFile:1)
	at com.bitmovin.player.n.h.getMaxTimeShift(SourceFile:1)
	at com.bitmovin.player.n.h.getTimeShift(SourceFile:1)
	at com.bitmovin.player.f.c0.getTimeShift(SourceFile:1)
	at com.bitmovin.player.f.i.getTimeShift(SourceFile:1)
	at com.bitmovin.player.a.b.getTimeShift(SourceFile:1)
2

Hi @kaspar.de.geus , thanks for raising this query. In general player APIs related to playback information APIs should not be called when no source is added to the player. When player is destroyed, the source/playlist sources are removed/destroyed as well, leading to observed behaviour as no source is available which is different from no active playback session.

Regarding below statement in docs, no active playback session is pointing to the scenario where none of the sources in playlist is playing currently, so this could be before start of playback of first source or transition phase between different sources in playlist. But I agree this does not come out explicitly in the statement.

“Returns 0.0 if there is no active playback session. ”

Thanks for the feedback and I will forward it to concerned Bitmovin team for consideration.

3

You are right @lucky.goyal that we shouldn’t make the call in the first place, therefor I now remove the timer earlier and before I make the currentTime call I now first do a check to see if this player.source?.isActive is true. Is this the correct check?

But still, a warning or a throwable would be nice instead of a fatal exception :wink: so I hope the Bitmovin team can do something with it.

4

Hi @kaspar.de.geus , thanks for the feedback. This is a good check to ensure that source exists and is active. I have forwarded your valuable feedback to our engineering team. This definitely helps us to improve integration experience.

1 Like
5

Sadly it seems the check player.source?.isActive isn’t enough to ensure we don’t get a fatal exception in some edge cases.
I have noticed that even though it nearly never happens we still sometimes have a request for the currentTime or timeShift when the source is already being unloaded or is in some way disabled. Even though we first do a check to see if isActive still returns true we still get a fatal exception when we do the request for the timeShift…

@lucky.goyal Can you ask the engineering team if there is a better check I can do? (I tried player.source?.isAttachedToPlayer == false, but that also seems to still return true) For now I will have to wrap these calls in a general try/catch but that is of course not the desired behaviour…