Offline session removed after ECS update : previously downloaded content not playable after update

[loicraux]

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 :
  • Chrome 122.0.6261.139
  • Widevine CDM version 4.10.2891.0
• Shaka Player version for offline content playback
• 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 includes :
  • Chrome 134.0.6998.179
  • Widevine CDM version 4.10.2891.0.
• Shaka Player version for offline content playback
• 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, 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 Shaka Player error:

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

From the Shaka Player documentation, this error means that the required offline session (to be found given its ID) 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.

So it looks like the update of ECS have somehow made the offline sessions of previously downloaded contents invalid...

What happens ? How can I solve this ?

Thank you for your help and suggestions on how to solve this problem... !

[khwaaj]

There are many things that can affect the ability to load a persisted license, but generally speaking they are mostly invalidated on CDM updates or by expiration of the licenses themselves. Updates of Chromium/ECS should not typically invalidate the licenses, but can if something changes that affects the storage identifier. AFAIK there is no guarantee that this is stable over Chromium versions, and the chance of this happening would be larger when you jump several versions like in your case.

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. There are some discussions around this if you search the issue history in this repo.

What it essentially comes down to is that, after an update, you'd loop over your persisted licenses and try to load them. Failing ones need to be renewed by re-requesting them from the source. This of course assumes that you are saving enough information to be able to do that, that any authentication is dealt with, and so on - often making it less than straightforward. And in the case of travel/geo-locking you may end up in a situation where you can't really remedy the situation (even though you should have internet access since the update could be downloaded).

[loicraux]

There are many things that can affect the ability to load a persisted license, but generally speaking they are mostly invalidated on CDM updates or by expiration of the licenses themselves.

The expiry of the licences themselves can't be the cause of the problem because I downloaded the content and then did the update straight away, and the licences in my case have a 30-days lifespan.

Updates of Chromium/ECS should not typically invalidate the licenses, but can if something changes that affects the storage identifier. AFAIK there is no guarantee that this is stable over Chromium versions, and the chance of this happening would be larger when you jump several versions like in your case.

By "Storage identifier" do you mean the offline DRM session ID ? Meaning that these IDs are not guaranteed to be stable over Chromium versions ? And if that's the case, isn't it more to do with the change in versions of the CDM rather than Chromium?

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. There are some discussions around this if you search the issue history in this repo.

What it essentially comes down to is that, after an update, you'd loop over your persisted licenses and try to load them. Failing ones need to be renewed by re-requesting them from the source. This of course assumes that you are saving enough information to be able to do that, that any authentication is dealt with, and so on - often making it less than straightforward. And in the case of travel/geo-locking you may end up in a situation where you can't really remedy the situation (even though you should have internet access since the update could be downloaded).

Thanks. I feel that such a recovery system should be part of shaka-player offline storage API itself.... The problem is, when licenses requests are made through shaka-player, some JS callbacks / network filters are used, which cannot be persisted (as functions).... 🤔

Until this is available in shaka player offline storage API, I'd like to be able to at least detect the sessions/licences that have become invalid. The question is : when to do this check ?

Can I detect a CDM update? I have the impression that CDM updates such as security updates are done in the background with the component updater, is this true? If so, is there any code I can use to detect such an update?

In my case, the CDM version number hasn't changed, that's what I find strange?

Eventually, is this a good idea to set the components.updatesEnabled flag to false after the CDM has been installed successfully to prevent updates of the CDM once installed ?

[khwaaj]

By "Storage identifier" do you mean the offline DRM session ID ? Meaning that these IDs are not guaranteed to be stable over Chromium versions ? And if that's the case, isn't it more to do with the change in versions of the CDM rather than Chromium?

No, this has to do with how the persistent licenses are securely stored, e.g. tied to a specific origin and whatnot. The session id itself is stable.

Can I detect a CDM update? I have the impression that CDM updates such as security updates are done in the background with the component updater, is this true? If so, is there any code I can use to detect such an update?

This is possible. Updates are only applied on restart, so you can use the Components API to check the status of the CDM, including the version. The status string should have different values depending on whether the CDM was updated or not, but the safest might be to save and compare the actual version string.

In my case, the CDM version number hasn't changed, that's what I find strange?

Like I said, there are additional factors that can invalidate offline licenses. To be sure you should check both the CDM and Electron versions for changes, and verify the validity of the offline licenses.

Eventually, is this a good idea to set the components.updatesEnabled flag to false after the CDM has been installed successfully to prevent updates of the CDM once installed ?

Not long term, no. The CDM is updated regularly, and older versions deprecated, so doing this long term will ultimately render the CDM non-functional. It can be used to implement something like a "travel-mode" though, so that updates are not applied at an inconvenient time, like when traveling to region where access to the license servers could be restricted.