electron-releases
electron-releases copied to clipboard
Error Code #6002 in Shaka Player
When I use ECS, I run into an error.
So far, the error characteristics observed are
- Error Code #6002 in Shaka Player
The browser found one of the requested key systems, but it failed to create an instance of the CDM for some unknown reason.
Browser Message: Failed to execute 'createMediaKeys' on 'MediaKeySystemAccess': CDM creation failed
- According to the output of 'components.status(),' widevine CDM is the most recent version.
{
status: {
oimompecagnajdejgnnjijobebaeigek: {
name: 'Widevine Content Decryption Module',
status: 'updated',
version: '4.10.2391.0'
}
},
MEDIA_FOUNDATION_WIDEVINE_CDM_ID: 'neifaoindggfcjicffkgpmnlppeffabd',
WIDEVINE_CDM_ID: 'oimompecagnajdejgnnjijobebaeigek'
}
I have not discovered a reliable method of reproducing this error.
I'd appreciate any thoughts on the cause of the error or additional suggestions on how to debug this.
Things like this typically happens if you open a browser window too early, before the CDM is properly registered. This would launch and lock down the CDM utility process if the loaded page triggers EME calls - effectively creating a race condition between CDM installation/registration and first use. As your comment on reproducing the error suggests that it is intermittent, it fits well with this type of error.
With that in mind the first thing I would check is the sequence of things, i.e. that the components.whenReady() promise has been resolved before you open the first browser window.
Btw, on with platform are you seeing this?
For some reason I assumed Windows, but when I read your report again it is not clear. If you are on macOS failing to properly notarize your application when code-signing can also cause issues similar to this.
Thank you for your prompt response.
I see all errors in the Windows Platform. My app is also published in the Mac Platform, but I haven't seen any error reports in macOS.
I have checked my code to make sure it correctly waits for "components.whenReady()" before creating the first window.
Are there any other possible causes for this error?
Please let me know if you require any additional information.
Ok, then I'll need some more information to be able to help, like:
- What are the specifics when this happens? Does it always happen on certain machines or does it happen intermittently regardless of machine?
- What are the platform characteristics where this happens? 32- or 64-bit Windows? ARM? Any other special configuration on the machines that exhibit the problem?
- Exactly what release of ECS are you using? Is it for x64 or ia32? Or does it happen for both?
I have an older app that includes CEF (Chromium Embedded Framework), and the installation directory is the same as the electron app.
Directory:C:\\Users\{UserName}\AppData\Local\{appName}
The old one keeps some data and CEF in the directory mentioned above. And the new one, which is an electron app, saves the main app in the directory mentioned above.
As far as I know, not every computer has this two apps that will encounter the error. and I am unable to reproduce this error on my computer using any method. 🥲
I'm not sure if the above feature is the cause of this error, but this is the most suspicious point I can think of at the moment
The electron version that is being used is 18.3.5 x64.
The error tracking tool informs me that errors may occur on Windows 10, Windows 8, and Windows 7.
Did you ever publish any of the apps through the Windows Store? I'm asking because there are known issues in this case since the Desktop Bridge uses a kind of overlay filesystem inside AppData, which is incompatible with the Chromium sandbox. Something like that might cause issues similar to what you are seeing since the CDM wouldn't be able to correctly load.
Btw, the same is also true if the user directory is network mounted, or other similar setups.
Something you could try to rule out a few things if you get access to a rig where you can reproduce the problem is to pass --no-sandbox on the command line when you start your application. This would disable the Chromium sandbox, which is not generally recommended but can be a valuable data-point here.
Sorry for the delayed response. During this time, I attempted to remote access the computer that was experiencing this issue. obtain a Chromium log when an error occurs.
This is the log.
[5460:0816/111748.748:VERBOSE1:component_installer.cc(284)] StartRegistration for Widevine Content Decryption Module
[5460:0816/111748.754:VERBOSE1:component_installer.cc(427)] FinishRegistration for Widevine Content Decryption Module
[5460:0816/111748.754:VERBOSE1:component_updater_service.cc(131)] CrxUpdateService starting up. First update attempt will take place in 60 seconds. Next update attempt will take place in 18000 seconds.
[5460:0816/111748.754:VERBOSE1:component_installer.cc(464)] Component ready, version 4.10.2449.0 in C:\Users\{UserName}\AppData\Roaming\{AppName}\WidevineCdm\4.10.2449.0
......
[5460:0816/111748.854:VERBOSE1:widevine_cdm_component_installer.cc(123)] Register Widevine CDM with Chrome
......
[18176:0816/111751.437:ERROR:cdm_module.cc(138)] CDM at C:\Users\{UserName}\AppData\Roaming\{AppName}\WidevineCdm\4.10.2449.0\_platform_specific\win_x64\widevinecdm.dll could not be loaded.
[18176:0816/111751.437:ERROR:cdm_module.cc(139)] Error: 5
......
[5460:0816/111751.478:INFO:CONSOLE(775)] "Uncaught EncryptedMediaError: EncryptedMediaError (CREATE_MEDIA_KEYS_ERROR) Failed to execute 'createMediaKeys' on 'MediaKeySystemAccess': CDM creation failed", source: http://localhost:55680/assets/js/chunk-vendors-main.f950ef8f.js (775)
The error platform is Windows 10, and I've tried two versions of Electron: 19.0.11 (Chromium / 102.0.5005.167) and 18.3.5 (Chrome/100.0.4896.160).
After deleting the entire folder under C:\Users\{UserName}\AppData\Roaming\{AppName}\WidevineCdm\ and restart the app, I was able to resolve the issue and playback
was back to normal.
What does Error: 5 means in chromium log?
Is there any api that can trigger reinstall widevine CDM directly?
On Windows LoadLibraryExW/LoadLibraryW is used to load the CDM library, so the code is just a Windows System Error Code - in this case ERROR_ACCESS_DENIED.
So it looks like there may be some permission issue on the machines seeing this error. Either that or if an app from the Windows Store using the same AppData name was ever installed the problem I previously mentioned could potentially be the cause.
Unfortunately there is currently no way to directly force an update in the APIs we expose (and I'm not entirely sure the Component Updater can support it, at least not without an app restart). A potential workaround could be to do it in your Electron code by removing the directory and forcing an app restart for now, at least as long as you can reliably detect when the problem happens. Alternatively it might be possible to correct the permissions in your code, before the whenReady() call, if you can figure out what is the root cause.
Thanks for your help. I will close this issue.