Widevine Content Playback Issue with CastLab Electron Version 22

[rranjithk]

CastLab Electron : v22
Shakaplayer : 2
widevine version : 4.10.2710.0
widevine content playback type:offline

We've encountered a significant issue with the Widevine content playback in CastLab Electron version 22. About 15 days ago, the Widevine content playback was functioning correctly, but as of now, it seems to be broken. We are receiving the following error message:
"DOMException: Failed to execute 'load' on 'MediaKeySession': Rejected with system code (72)"

We have not made any significant changes on our end, and it appears that this issue may be related to either updates in Widevine or changes in CastLab Electron version 22. We are seeking assistance to understand and resolve this issue promptly.

If there have been any recent updates or changes in Widevine that may affect the playback of content, or if there are specific updates in CastLab Electron version 22 that could be causing this error, we would appreciate any guidance or information you can provide.

Additionally, we would like to request assistance in troubleshooting and resolving this issue. Are there any known workarounds or solutions for this error? Any insights, debugging steps, or potential fixes would be greatly appreciated.

[khwaaj]

Hi @rranjithk,

I'm pretty sure this is simply because you are using a too old version of ECS that has fallen out of the CDM support window (as well as the Electron support window). When this happens it will not be able to get a CDM from Google and all DRM playback will thus fail. The only viable fix (using the free version of ECS) is to upgrade to a later version of ECS that is within the supported window. More recent versions will also return an error from components.whenReady() when this situation occurs, making it easier to catch.

You can find additional information in #169 and on the Wiki: https://github.com/castlabs/electron-releases/wiki#supported-versions. As you can see you should ideally be on ECS v27-v29, but v24 and later should still be able to get a CDM.

[rranjithk]

@khwaaj ,Thanks for your replay

We are evaluating the possibility of upgrading our application to Electron versions v24, v27 and v29. Could you please provide guidance on the anticipated update frequency for each version and the expected duration during which we can reasonably remain on these versions without encountering significant compatibility issues?

What is the anticipated update frequency?
For Electron version v29:
How many months can we reasonably expect to remain on Electron version v29 without encountering significant compatibility issues?

For Electron version v27:
How many months can we reasonably expect to remain on Electron version v27 without encountering significant compatibility issues?

For Electron version v24:
How many months can we reasonably expect to remain on Electron version v24 without encountering significant compatibility issues?

Update Process Challenges: Our update process poses challenges, especially when dealing with native Node modules. We encounter difficulties during updates, leading to disruptions in the application.

Offline Support: Our customers are currently required to redownload offline content after each update, impacting the user experience and perception of offline support. Are there strategies or best practices to mitigate this, allowing for a smoother transition during updates without requiring customers to redownload offline content?

Our application heavily relies on native Node modules, and a clear understanding of the update timelines will greatly influence our decision-making process.

[khwaaj]

What is the anticipated update frequency?

We are simply following the rules set out by the upstream projects, Electron and Chromium. Ultimately the Chromium release schedule (linked on the Wiki page I shared) is the source of truth when it comes to guaranteed CDM availability. We try to also keep the table on the Wiki page up to date as best we can. The rule Google now enforces essentially guarantees availability of a CDM for ~1 year after a Chromium release goes stable. So if you move to v29 now that is what you should expect, whereas v24 is right at the edge and will likely fall out of the window within weeks (Chromium 112 made stable Tue, Apr 4, 2023). The information is there, you just need to look it up.

This is a relatively recent change btw. The 1 year policy has existed for a long time but was not enforced by Google until recently, which allowed much older releases to get a CDM even though they were out of the support window.

Offline Support: Our customers are currently required to redownload offline content after each update, impacting the user experience and perception of offline support. Are there strategies or best practices to mitigate this, allowing for a smoother transition during updates without requiring customers to redownload offline content?

Unfortunately there is no straightforward or automatic way of handling this. The approach I know of that has been successfully used in the past is that when a CDM update is detected (you can do this by checking the version of the CDM using the components API) some code is triggered that iterates over the persisted licenses and try to load them. If they fail an update is needed and a new license should be requested. This, of course, is often not entirely as simple as it is conceptually since all services are different, authentication may have expired, and so on...

To avoid this happening at an inopportune time, e.g. during a trip abroad, CDM updates can be temporarily disabled. This would avoid invalidating the licenses during the trip. It is inadvisable to keep CDM updates disabled for extended periods of time though since a CDM will be revoked some time after a security update.

I hope that helps bring some clarity.

[rranjithk]

I am encountering an issue with content playback after updating to Castlabs Electron v27. I forgot to mention that even in version v22, WidevineCDM DLL is successfully downloaded, and the widevine version is 4.10.2710.0.
15 to 30 days ago, I downloaded offline licenses, and offline license content played now also without any problem. Therefore, it seems like the issue is not related to the Electron version.
WidevineCDM DLL is downloaded successfully in both versions, and the version is 4.10.2710.0.
components status: {"neifaoindggfcjicffkgpmnlppeffabd":{"name":"Google Widevine Windows CDM","status":"up-to-date","version":null},"oimompecagnajdejgnnjijobebaeigek":{"name":"Widevine Content Decryption Module","status":"new","version":"4.10.2710.0"}}

Issue
Only newly downloaded offline license content faces playback issues.

Questions:

1. As mentioned, the "DOMException: Failed to execute 'load' on 'MediaKeySession': Rejected with system code (72)" when this error comes
2. We are using Windows; is EVS signing compulsory?
3. How can I debug to get detailed information about the playback issue with newly downloaded offline content?

[khwaaj]

Ah, I misunderstood that you had an already stored license that isn't loading. Several things can break loading a persistent license (or even getting one in the first place).

Since you explicitly mentioned EVS, it is crucial that you have a valid VMP status on Windows and macOS. And not only that, you need to make sure you have signed with the --persistent flag of the EVS client (the default is --streaming, which does not allow persistent licenses). If that is not the case you should start there, but I don't see how you would have been able to get a persistent license in the first place unless you had this sorted?

Even with the correct VMP status several things can break a persisted license. Moving it from another installation (user, application, computer, and so on) will break it. As mentioned before, a CDM security update can also break the license. Finally, rules in the license itself can invalidate the license, like expiration time, which is almost always used for persistent licenses for security reasons. IIRC a proper error would be returned the first time a load is attempted on an expired license, but subsequent load attempts will fail with a system error (likely because the license has been automatically removed).

The error in question, Rejected with system code (72), is just passing an error code from the CDM to you. These codes are not publicly documented. I'd say debugging it further is also not likely to yield much since you will ultimately just see this error getting returned by load().

[rranjithk]

Now V29 also has the same issue with EVS signing. I am not sure how to proceed. Please guide me.
Does Widevine support Windows 32-bit?
I would like to draw your attention to another matter. When we utilize the 'loadUrl' function with the parameter 'https://shaka-player-demo.appspot.com/', all the contents play seamlessly.

[khwaaj]

Now V29 also has the same issue with EVS signing. I am not sure how to proceed. Please guide me.

It is hard to know how to help if I don't know exactly what you are doing. Are you still trying to load an old persisted license? If so, I'd give up on that. When a load fails, e.g. due to expiration, the license session would be removed (and you will be seeing some generic error where you try to load it again, since the session does not exist). This might be what is happening.

I would like to draw your attention to another matter. When we utilize the 'loadUrl' function with the parameter 'https://shaka-player-demo.appspot.com/', all the contents play seamlessly.

Using loadUrl() as opposed to what? Are you sure you are waiting for the whenReady() promise to resolve before you open a window for playing back DRM content? If you are not, the CDM availability is not guaranteed (this is essentially a race condition).

[rranjithk]

issue from the axinom server side , they gave the hot fix