# Android v3 player random readyness issue at stream startup

**URL:** <https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481>\
**Category:** Support\
**Tags:** android\
**Created:** [November 7, 2022, 8:53pm UTC](https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481 "2022-11-07T20:53:55Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![it1](https://avatars.discourse-cdn.com/v4/letter/i/9de0a6/32.png) [@it1](https://community.bitmovin.com/u/it1)\
**Post date:** [November 7, 2022, 8:53pm UTC](https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481/1 "2022-11-07T20:53:55Z")

</div>

Dear Bitmovin community,

Since our recent migration from Bitmovin Android player v2 to v3 we have discovered a random readyness issue of the Bitmovin player, including with latest v3.25.1  
When the problem is triggered the player is NOT reporting back “Ready” even with a generous 30s of timeout.  
No error is thrown, it is just hanging.

The issue is :

- not device specific

- not Android version specific

- not related to DRM

- not related to HTTPs

- not related to specific CDNs (also duplicated with Akamai tears of steel)

- affecting both Live and VOD streams

- Manifest got downloaded and parsed correctly

- Audio and Video 1st chunks got buffered

- No audio or video got decoded/rendered

- Affected customers are usually impacted once and then a retry will work.

- Only tested against DASH Manifests

- Issue could be duplicated with Bitmovin demo sample running in 10s loop

- Issue can NOT be duplicated with Exoplayer (same 10s loop, same setup)

- Bitmovin support cannot duplicate it with emulator or with their device yet.

I could not find similar issue in the community yet. Is-it known somewhere ?  
What would be your suggestion to troubleshoot / fix this issue ?

Thanks for your help,  
Nicolas

---

<div class="post-metadata">

**Author:** ![daniel](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/daniel/32/121_2.png) [@daniel](https://community.bitmovin.com/u/daniel)\
**Post date:** [November 15, 2022, 3:19pm UTC](https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481/2 "2022-11-15T15:19:46Z")

</div>

Hi Nicolas,  
We haven’t heard about this issue from any other customer so far. Can you reproduce this with any content? I.e. if you use simply [bitmovin-player-android-samples/BasicPlaybackKotlin at main · bitmovin/bitmovin-player-android-samples · GitHub](https://github.com/bitmovin/bitmovin-player-android-samples/tree/main/BasicPlaybackKotlin) as is (adding your license key and potentially the 10s loop you mention), you can reproduce the problem?

Also, what do you do in the 10s loop, simply reloading the same stream into the player? Or creating a new player instance? Can you share any sample code please?

---

<div class="post-metadata">

**Author:** ![it1](https://avatars.discourse-cdn.com/v4/letter/i/9de0a6/32.png) [@it1](https://community.bitmovin.com/u/it1)\
**Post date:** [November 18, 2022, 10:03am UTC](https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481/3 "2022-11-18T10:03:20Z")

</div>

Hi Daniel,  
Thanks for your feedback, we can duplicate this issue with any content from any CDN, including Bitmovin sample.  
We are already using Bitmovin player android samples for this test and we have shared our source code with Alberto Cabaleiro on the ticket 10687.  
It seems the problem is now understood by your team (video decoder flush) and a fix is under preparation.  
🤞

---

<div class="post-metadata">

**Author:** ![daniel](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/daniel/32/121_2.png) [@daniel](https://community.bitmovin.com/u/daniel)\
**Post date:** [November 18, 2022, 1:02pm UTC](https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481/4 "2022-11-18T13:02:32Z")

</div>

True, Alberto and I discussed this internally after my post here, I missed updating this thread. Thanks for the update 👍

---

<div class="post-metadata">

**Author:** ![albertobitmovin](https://sea1.discourse-cdn.com/flex015/user_avatar/community.bitmovin.com/albertobitmovin/32/256_2.png) [@albertobitmovin](https://community.bitmovin.com/u/albertobitmovin)\
**Post date:** [November 18, 2022, 2:35pm UTC](https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481/5 "2022-11-18T14:35:01Z")

</div>

Hi Nicolas,

Just a quick clarification here: At this stage we **suspect** of potential issues at decoder level only on very specific devices such as Swisscom STB (not officially supported by the way), but it hasn’t been confirmed yet and there’s no ongoing fix from our end. As discussed on the ticket you mention, we’re still looking forward to your results when running our modified demo app on your end on Swisscom STB. When running that app on a Swisscom STB on our end, the issue can no longer be reproduced, which points to issues on the way you are/were initializing the player on your app.

Also, I’d like to clarify that the above only applies to Swisscom STB devices. For any other affected device, the investigation is still ongoing.

---

<div class="post-metadata">

**Author:** ![Nicolas.Stefani](https://avatars.discourse-cdn.com/v4/letter/n/c2a13f/32.png) [@Nicolas.Stefani](https://community.bitmovin.com/u/Nicolas.Stefani)\
**Post date:** [January 16, 2023, 7:18am UTC](https://community.bitmovin.com/t/android-v3-player-random-readyness-issue-at-stream-startup/1481/6 "2023-01-16T07:18:48Z")

</div>

Update on this issue: we have applied the recommanded mitigations from Bitmovin support :

- force initialBandwidthEstimateOverride to 2Mbps to ensure the player will decode SD resolution first and then trigger ABR to HD
- destroy the player after each usage.  
It’s helping to fix one problem detected in our lab but the field the is still seriously affected by “this player readyness” issue.  
Stay tuned.

Nicolas
