Tizen: Playback won't start after application is hidden during playback

We have an issue on certain Tizen devices (verified on 2018, 2019 & 2020 models). 2017, 2021 & 2022 models were also tested, but the behaviour differs. The latter don’t have issues when the application is restored.

Tizen devices support this Multitasking feature, which allows to store the application state when switching to another application. Whenever the application is reopened, this state should be restored. What we’ve implemented, is that we stop the player when the application is hidden (using player.stop()) and whenever the application is restored, we try to resume playback using player.loadVideo().

I’ve collected some logs when setting RxPlayer.LogLevel = "DEBUG" and gathered some relevant data:

Start playback using loadVideo

player.loadVideo({
    transport: "dash",
    url: "https://{redacted}GlobalManifest.mpd",
    keySystems: [{
        type: "widevine",
        ...
    }],
    autoPlay: true,
    enableFastSwitching: false,
    onCodecSwitch: "reload",
    textTrackMode: "html",
    textTrackElement: document.createElement("div"),
});

Logged data with API prefix:

Calling loadvideo https://{redacted}GlobalManifest.mpd dash
API: playerStateChange event LOADING
API: DRM session cleaned-up with success!
API: current playback timeline: timeupdate
API: current playback timeline: loadedmetadata
API: current playback timeline: seeking
API: current playback timeline: play
API: current playback timeline: ratechange
API: current playback timeline: seeked
API: current playback timeline: canplay
API: playerStateChange event LOADED
API: playerStateChange event PLAYING
API: current playback timeline: ratechange
API: current playback timeline: timeupdate

Then, we switch to another application, which fires this visibilitychange event. In the handler, we stop playback using player.stop():

player.stop();

After this call, 2 more logs will be visible:

API: playerStateChange event STOPPED
API: DRM session cleaned-up with success!

After a short period (10 - 20 seconds), we switch back to our app & again, the visibilitychange event fires, but this time we try to resume playback using player.loadVideo():

player.loadVideo({
    transport: "dash",
    url: "https://{redacted}GlobalManifest.mpd",
    keySystems: [{
        type: "widevine",
        ...
    }],
    autoPlay: true,
    enableFastSwitching: false,
    onCodecSwitch: "reload",
    textTrackMode: "html",
    textTrackElement: document.createElement("div"),
});

Again the logs with API prefix have been collected:

Calling loadvideo https://{redacted}GlobalManifest.mpd dash
API: playerStateChange event LOADING
API: DRM session cleaned-up with success!
API: current playback timeline: timeupdate
API: current playback timeline: loadedmetadata
API: current playback timeline: seeking
API: current playback timeline: ratechange
API: current playback timeline: timeupdate
API: current playback timeline: seeked
API: current playback timeline: canplay
API: current playback timeline: ratechange
API: current playback timeline: timeupdate

The player doesn’t seem to get into next state, as it stays in LOADING state, and keeps firing timeupdate events

[peijkelhardt]

Yes, that might be the best option right now.

I’ve tested it, by disposing the player first (calling player.dispose()), and creating a new instance of the player (together with a new video element).

After all this, playback starts as expected 😄

So this may be a browser/Tizen issue instead I guess.

Anyway, thanks for your help & feedback

[peaBerberian]

OK interesting. Changing the media element this way may be risky because an RxPlayer considers that it is always linked to the same media element. Maybe the proper way would be to re-create a new RxPlayer associated to a separate media element.