[Offline] OFFLINE_SESSION_REMOVED critical error after Electron update

[loicraux]

Have you read the Tutorials?
Yes.

Have you read the FAQ and checked for duplicate open issues?
Yes.

If the question is related to FairPlay, have you read the tutorial?
N/A

What version of Shaka Player are you using?
Version 4.14.7

What browser and OS are you using?
Chrome 134.0.6998.179 in CastLabs Electron Release v35.1.4
OS is Windows 11, but the issue/question is not related to the OS (could be MacOS as well)

Please ask your question
We have an Electron-based application for offline playback of videos that is build on top of:

• CastLabs Electron Release v29.1.6, that includes a VPM-signed Widevine CDM component.
  • This Electron release contains Chrome 122.0.6261.139 for information.
  • This Electron release contains Widevine CDM version 4.10.2891.0
• Shaka Player version v4.7.11
• Electron-updater for updates of the application.

The user downloads a video, the offline playback is OK. Then he performs an update of the application using the built-in app updater. After the update and relaunch, the application is now built on top of:

• CastLabs Electron Release v35.1.4, that still includes a VPM-signed Widevine CDM component.
  • This Electron release contains Chrome 134.0.6998.179 for information.
  • This Electron release contains Widevine CDM version 4.10.2891.0.
• Shaka Player version v4.14.7
• and of course still Electron-updater for updates of the application.

As you see, Electron has been updated from v29.1.6 to v35.1.4, shaka player has been updated from v4.7.11 to v4.14.7, but the version number of the Widevine CDM component has not changed (still 4.10.2891.0)

Although the version of the Widevine CDM component has not changed, the update of the application may cause I guess the installation of a new Widevine CDM component, since the Electron has been updated.

When the user now tries to play the downloaded video that was downloaded before the update, the playback fails with the following error:

Severity=CRITICAL(2) Category=DRM(6) Code=OFFLINE_SESSION_REMOVED(6013)

From the documentation, this error means that the required offline session was removed. Also it is noted that the content might not be playable "depending of the playback context", which is the case here, since the content is not playable anymore.

I guess session IDs are somehow referenced by the downloads, and after the update, the session identified by this ID is no longer there?

Is there anything I can do within Shaka Player to avoid this issue? A parameter/setting that would allow to create a new session that would be valid after the update for the already downloaded content? I see for instance in the codebase that the persistentSessionOnlinePlayback setting if set turns the severity of such an OFFLINE_SESSION_REMOVED error to RECOVERABLE instead of CRITICAL, but I am not sure if this setting is relevant w.r.t. to the issue I am facing.

Thank you for your help and suggestions on how to solve this problem... I don't know if it's a bug in shaka player, or an evolution to be done or a problem on my side?

[joeyparrish]

When the user now tries to play the downloaded video that was downloaded before the update, the playback fails with the following error:

Severity=CRITICAL(2) Category=DRM(6) Code=OFFLINE_SESSION_REMOVED(6013)

Wild! This is a new situation for me. Someone from Widevine may know more... @xhwang-chromium, does updating the Widevine CDM wipe any persistent DRM sessions in Chrome? Or is this perhaps unique to Electron?

I guess session IDs are somehow referenced by the downloads, and after the update, the session identified by this ID is no longer there?

Shaka stores the persistent DRM session ID in the database next to the content. If that session is no longer present and needs to be recreated, we may need to have some logic added to Shaka to detect that scenario and recover. The original DRM configuration (server URLs, network filters for auth, etc) aren't stored (if I remember correctly), so we may actually need a new API entirely and some coordination with the app to recover.

Is there anything I can do within Shaka Player to avoid this issue?

Avoid it? Not that I know of. I think recovery is all we can hope for if the platform removes stored DRM sessions. My gut says we want:

1. Logic to detect this from Widevine
2. New error code to indicate this scenario to the app
3. New storage API to recreate the missing session (with license server, filters for auth, etc)
4. Maybe this new API requires those DRM and networking settings to be generally applied to the configuration first, and doesn't ask for them separately...

Thank you for your help and suggestions on how to solve this problem... I don't know if it's a bug in shaka player, or an evolution to be done or a problem on my side?

I think it's something we didn't anticipate would happen on the platform side, and so it's a missing feature in Shaka to cope with what might be considered a bug in Electron or Widevine.

[therealfrs]

To understand the problem more, I tried to reproduce on Chrome:

• Go to Shaka demo page https://shaka-player-demo.appspot.com/
• Filter content to 'Downloadable' and 'DRM' is widevine.
• Download a video
• Turn off networking (e.g. via devtools)
• Play content and observe that it works
• Delete widevine. The way to find which dll to remove is by going to chrome://media-internals/#cdms And remove the CDM found there.
• Try to play content and observe that it fails because there Chrome cannot find CDM
• Go to chrome://compnenets and re-trigger downloading widevine.
• After successful download, play the offline content download before and observe that playback is successfull.

That tells me there is something that Electron does that is divergent from Chromium. I am not sure what is going on here.

Can you repeat the steps above in your case? If that works, then the problem can be narrowed down to upgrading the mentioned Electron app. Could it be that part of the upgrade 'wiping' out downloads?

[loicraux]

Thanks for your first analysis. I'll also ask CastLabs, who release Electron releases with CDM Widevine, and see if they have any ideas. I'll link that question here.

I see that there are already two very similar issues that have been opened in CastLabs Electron Releases repository :

• Issue with Widevine New Version Impacting Existing Offline Persistence License
• Widevine Content Playback Issue with CastLab Electron Version 22
• Issue with Widevine Persistence Licenses After Updating Castlabs App from 6.0.2 to 22.0.0
• Offline session removed after ECS update : previously downloaded content not playable after update

[avelad]

@loicraux any update?

[loicraux]

@avelad I'm going to summarise where I'm at, after some feedback from CastLabs (who supply Electron releases with CDM Widevine + signed VMP):

There are many things that can affect the ability to load a persisted license, but generally speaking a persisted license is mostly invalidated on CDM updates or by expiration of the license itself. In my case the expiry of the licence itself can't be the cause of the problem because I downloaded the content and then did the Electron update straight away, and the license in my case has a 30-days lifespan. So the cause is the update of the Widevine CDM component.

Updates of Chromium/ECS should not typically invalidate the licenses, but can if something changes that affects the storage identifier (how the persistent licenses are securely stored, e.g. tied to a specific origin and whatnot). AFAIK there is no guarantee that this is stable over Chromium versions, and the chance of this happening would be larger when several versions are jumped like in my case.

Updates are applied on restart of the Electron executable, and can happen at any of these restarts, e.g. for security purposes.

Unfortunately there is no good solution to this problem, and dealing with offline licenses in EME is cumbersome at best (you get the feeling offline support in EME is a bit of an afterthought). The only real recourse, that I know have been used by others, is to manually deal with the situation.

What it essentially comes down to is that, after an update, I would loop over the persisted licenses and try to load them. Failing ones need to be renewed by re-requesting them from the source. Note that since I have detected an update of Electron/Chromium/CDM, I should be online at this moment. In other words, there should never be a situation where I'm offline with an invalid offline session.

This of course assumes that I have enough information to be able to renew the licenses by re-requesting them from the source, so it is not straightforward. All cases probably cannot be dealt with : for instance in the case of travel/geo-blocking I could end up in a situation where I can't really remedy the situation (even though I have internet access).

Anyway, in my mind, this roughly boils down to the following steps (in sort of JS pseudo-code) :

function atElectronApplicationStart() {
    if (hasWidevineCDMBeenUpdated() || 
        hasChromiumBeenUpdated() ||
        hasElectronBeenUpdated()) {
        // Electron, Chromium or Widevine CDM have been updated
        // Loop over all persisted licenses to check if they are still valid
        // and revalidate them if necessary
        revalidatePersistedLicenses();
    }
}

function revalidatePersistedLicenses() {
    for (let download of shakaStorage.list()) {
        if (shakaStorage.isSessionOK(download)) {
            // License is still there, no action needed
            continue;
        }

        // Re-request the license from the source (new API from shaka player)
        shakaStorage.recreateSession(download);
    }
}

So yes, new APIs are needed in shaka player storage. I don't have all the implications in mind atm, but I think we need to dig deeper into the scenarii and the edge cases to define the specifications for the additional APIs needed.

@joeyparrish How do your 4 previously mentioned ideas (1. Logic to detect this from Widevine. 2. New error code to indicate this scenario to the app 3. New storage API to recreate the missing session 4. Maybe this new API requires those DRM and networking settings to be generally applied to the conf first, and doesn't ask for them separately) now relate to what I've just written?