Question from SRF Apps Android

[defagos]

Question from @peyerc / @chjaeggi:

I have a question about playerError state behavior in Pillarbox 8.0.0
Last week, we upgraded Pillarbox in our Android apps from version 6.0.1 to 8.0.0. While testing the Livestream Countdown, we noticed some unexpected behavior:
When the Pillarbox player enters the error state PlaybackException (cause => StartDate), we display a countdown to the user. However, if we lock the test device, wait about 10 seconds, and then unlock it to resume the app, the Pillarbox player’s error state becomes null.
We are observing the error state using:
player.playerErrorAsFlow()
Have you noticed any similar behavior or made any recent changes related to the error state handling?

Update

Unfortunately it also happens with all the videos in our app. I watch something, I put it into background, and after restart we receive a different state / error and the video stops and can’t be reloaded as the state seems IDLE or READY in the Player… We need to restart / open the view. I could not reproduce it in the Pillarbox Demo and I look into it what we do differently and keep you posted

Update 2

I figured out why this happens on our side I think but I will invest more time tomorrow:

override fun onPlayerChanged(oldPlayer: PillarboxPlayer, newPlayer: PillarboxPlayer) {
    super.onPlayerChanged(oldPlayer, newPlayer)
    newPlayer.prepare()
    oldPlayer.stop()
    oldPlayer.clearMediaItems()
}

This callback triggers when we come back to the app after a short screen lock (onResume I guess)…
The oldplayer then is the CastPlayer and has zero items in it and in the super call
newPlayer.setMediaItems(oldPlayer.getCurrentMediaItems(), oldPlayer.currentMediaItemIndex, oldPlayer.currentPosition)
happens, which copies 0 items now into the running PillarBox on Screen

Remark

Can pair with the SRF app Android devs if this helps.

[chjaeggi]

So i put every puzzle piece together and I wanted to tell you what I found out.

In our app we basically use the video player as follows:
val currentVideoPlayer by viewModel.castPlayerSynchronizer.currentPlayer.collectAsStateWithLifecycle() whereas you in the demo app use val player by mainViewModel.currentPlayer.collectAsState(). Spot the difference with state collection? We make it dependent on lifecycle (for instance if the app goes into background, it may not collect flows anymore to perserve battery/data).

Not let's look at this from the Class CastPlayerSynchronizer:

val currentPlayer = castPlayer.isCastSessionAvailableAsFlow()
        .map { if (it) castPlayer else localPlayer }
        .distinctUntilChanged()
        .onEach { switchPlayer(it) }
        .stateIn(coroutineScope, SharingStarted.WhileSubscribed(5_000), if (castContext.isConnected()) castPlayer else localPlayer)

There you exactly create a state flow that is only emitting when someone is subscribed with a timeout after that of 5 seconds. Now this isn't an issue per se I think, but what happens next is.
Let's assume we never used the PillarboxCastPlayer only a local PillarboxExoPlayer running on the device but the app going into the background and in forground within a 10 seconds timeframe. What then happens is, this flow gets re-subscribed with initial values AND the switchPlayer function will be called.

Inside it at the very bottom you call:

override fun onPlayerChanged(oldPlayer: PillarboxPlayer, newPlayer: PillarboxPlayer) {
            newPlayer.repeatMode = oldPlayer.repeatMode
            newPlayer.playWhenReady = oldPlayer.playWhenReady
            newPlayer.setMediaItems(oldPlayer.getCurrentMediaItems(), oldPlayer.currentMediaItemIndex, oldPlayer.currentPosition)
            newPlayer.prepare()
        }

with the problematic line that calls setMediaItems.

Because the oldPlayer here is assumed to be the castPlayer that has no media items in it and not the correct one, namely the localPlayer with the loaded item and, hence, the media item will be taken from castPlayer which is no media item and the localPlayer stops playing.

How did we solve it on our side for the moment? We just wrapped your cold flow with a hot flow so yours is always emitting. This looks like this:

public val currentPlayer: StateFlow<PillarboxPlayer> =
        castPlayerSynchronizer?.currentPlayer?.stateIn(
            coroutineScope,
            SharingStarted.Eagerly,
            castPlayerSynchronizer.currentPlayer.value,
        ) ?: MutableStateFlow(localPlayer)

you also see a subtle detail, in our case the CastPlayer may be null.

So where to go from here? I think in your library you should implement a mechanism to detect which player is currently active and after resubscription this could be actually the same player and switchPlayer then must not be called. We can also discuss that further if you team is back from holidays.

Cheers from Zürich,
Christian

[StaehliJ]

@chjaeggi I created a dedicated issue for the flow issue. #1223