Clarifying behaviour when widevine-ready fires after upgrade to v3

I’m working on our next release which sees us moving up to Electron v3. Reading your docs on widevine-ready I understood the event fires once it’s possible to use the CDM. However it always fires during upgrade scenarios where the older, existing 1.4.8 version of the CDM is loaded into v3, this isn’t something I’d anticipated. As all our licences are persistent this leaves us with content that doesn’t play (as expected).

The widevine-update-pending then fires shortly after and on restarting the app and re-fetching the licences all is well again.

As this leaves users without the ability to play content in the interim period I’ve got a few questions:

• If licenses are re-fetched with v3 and 1.4.8 will they work, are they restricted ie online only?
• I’m expecting widevine-update-pending to fire at any point the app is running, are the actual cases more restricted than that?
• Are clients expected to maintain a compatible list of CDM versions based on the features they want then fail to holding/error states until a suitable widevine-update-pending event fires? If so what are the rules?

[simongregory]

Thanks Emil. I’ve returned our logic back to it’s original state - renewing the licences when you report a cdm upgrade. My initial tests were good so I’ve built and shipped to QA.

[khwaaj]

I just released electron 3.0.11-wvvmp.1, which makes sure to always update to 1.4.9 during first launch. The whole point of having 1.4.8 support in the first place was to support migration between the two, which we were initially under the impression was possible, but now that it has been established not to be, doing the upgrade immediately will only create a clearer migration path (i.e. always re-requesting the persisted sessions when the widevine-ready signals an update from 1.4.8 to 1.4.9).

Let me know how it goes!