# 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 **URL:** \ **Category:** Support\ **Tags:** bitmovin-player, android, bitmovin\ **Created:** [January 24, 2023, 12:44pm UTC](https://community.bitmovin.com/t/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/1651 "2023-01-24T12:44:47Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![kaspar.de.geus](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@kaspar.de.geus](https://community.bitmovin.com/u/kaspar.de.geus)\ **Post date:** [January 24, 2023, 12:44pm UTC](https://community.bitmovin.com/t/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/1651/1 "2023-01-24T12:44:47Z")
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 ```auto 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) ``` ---
**Author:** ![lucky.goyal](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/lucky.goyal/32/506_2.png) [@lucky.goyal](https://community.bitmovin.com/u/lucky.goyal)\ **Post date:** [January 24, 2023, 2:40pm UTC](https://community.bitmovin.com/t/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/1651/2 "2023-01-24T14:40:08Z")
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. ---
**Author:** ![kaspar.de.geus](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@kaspar.de.geus](https://community.bitmovin.com/u/kaspar.de.geus)\ **Post date:** [January 25, 2023, 11:16am UTC](https://community.bitmovin.com/t/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/1651/3 "2023-01-25T11:16:16Z")
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 😉 so I hope the Bitmovin team can do something with it. ---
**Author:** ![lucky.goyal](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/lucky.goyal/32/506_2.png) [@lucky.goyal](https://community.bitmovin.com/u/lucky.goyal)\ **Post date:** [January 25, 2023, 11:26am UTC](https://community.bitmovin.com/t/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/1651/4 "2023-01-25T11:26:41Z")
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. ---
**Author:** ![kaspar.de.geus](https://avatars.discourse-cdn.com/v4/letter/k/439d5e/32.png) [@kaspar.de.geus](https://community.bitmovin.com/u/kaspar.de.geus)\ **Post date:** [February 3, 2023, 3:50pm UTC](https://community.bitmovin.com/t/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/1651/5 "2023-02-03T15:50:13Z")
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…