Seeking in playlist when casting on Android not working

Support
1

When doing a player.playlist.seek(player.playlist.sources.last(), 0.0) nothing happens when the player is casting on Android device, nothing in the logs either. Works on iOS. Any idea?

implementation 'com.google.android.gms:play-services-cast-framework:21.3.0'
implementation 'com.bitmovin.player:player:3.47.0'
2

Hi @alex,
thanks you for raising the issue.

I am able to reproduce your observation and saw a player warning event when seeking to the last source of a playlist with more than 2 elements while casting.

As a side note, usually there are not many logs produced by our android player. To gain more insights on issues I recommend to attach event listeners to the player and source. In this particular situation the PlayerEvent.Warning was the most useful one.
Our Guide on Logging in the Android Player might be useful as well.

We are tracking your reported now internally and will update this thread once we know more.

3

Thanks, but great to hear you are working on it.

The seeking to the last video was just an example, for us this happens consistently for seeking to any item in the playlist, so it’s not just seeking to the last source that is not working while casting.

And thinks for the hint for logging, although not sure logs would’ve helped us in this case, but I’ll keep this in mind in case something else pops up in the future.

4

@alex how many items are there in your playlist and what streaming technology are you using (DASH, HLS, …)?
Also, is there a special trigger on which you are seeking to another source in the playlist? i.e. when are you seeking. (shortly after starting casting?)

5

Hi @matamegger,

We have anywhere from 5 to about 12 at the moment of HLS video’s in the playlist. The playlist is set to preload all video’s (in case that’s relevant).

The trigger is a user interaction that happens at the end of the source where they choose to continue to next part A or B (which is either the next source in the playlist or the one thereafter, so skipping over 1 source at most). This interaction moment starts 15 seconds before the source ends and doesn’t wait for the source to actually end before calling seek() (we always seek() before the source ends, usually few seconds before the end, but could be in the last second) the source length is in testing pretty short, 30 seconds, but in production 10+ minutes and the call to seek() happens well after the cast device has already streamed 15+ seconds.

Hope that helps!

6

Thanks for the details!

We will keep you updated.