1704022 - Widevine 4.10.2209.1 fails to load for builds that do no have code changes from bug 1701089 but are targeted by new rules

Status: RESOLVED DUPLICATE of bug 1701089

(Core :: Audio/Video: Playback, defect, P1)

Description

[Kalvin Lee]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

• I attempted to load a DRM-protected video on Disney+.

Actual results:

• The page loaded and drew a spinner.
• Firefox dropped a yellow butterbar: "Firefox is installing components needed to play the audio or video on this page. Please try again later."
• Eventually, the page recognizes that playback is unable to start. This message is logged to the console:

(ERROR):  [ErrorEpic] Fatal Error 
Object { playhead: 0, cause: "error", errorName: null, error: "drmOther", errorDetail: "[DRM_FAILED] BamHLS was not able to authorize playback (drmNoSupportedKeySystem)", errorSource: {…} }
playerADK.js:7:148031
[snip]

Expected results:

Having previously enabled Widevine and played content-protected videos successfully from this service provider, I would have expected the video to play normally.

Comment 1

[Kalvin Lee]

I neglected to mention that this is Firefox 87.0 packaged for Fedora 34. At least one other Arch Linux user has reported a similar issue.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Thaodan]

(In reply to Kalvin Lee from comment #1)

I neglected to mention that this is Firefox 87.0 packaged for Fedora 34. At least one other Arch Linux user has reported a similar issue.

I was who reported the issue. My Firefox build is from:
https://aur.archlinux.org/packages/firefox-kde-opensuse/#pinned-654014

When I try to load Netflix I hid a timeout and get these messages in the browser console:

MediaKeySystemAccess::GetKeySystemStatus(com.widevine.alpha) result=cdm-not-installed msg='CDM is not installed'

navigator.requestMediaKeySystemAccess promise rejected 0x80530009 'Timed out while waiting for a CDM update'

Comment 4

[Thaodan]

Attachment: support_info.txt

Comment 5

[Tom S]

[Tracking Requested - why for this release]:

I am using a Mozilla provided Nightly build and Widevine seems to missing from about:addons > Plugins.

Comment 6

[Tom S]

Actually sorry. I think I had a different issue. DRM supported was inexplicably disabled? I definitely watched Netflix with this profile before. Maybe this is a related problem.

Comment 7

[Thaodan]

(In reply to Tom Schuster [:evilpie] from comment #6)

Actually sorry. I think I had a different issue. DRM supported was inexplicably disabled? I definitely watched Netflix with this profile before. Maybe this is a related problem.

Someone on Reddit claimed it works with nightly. I feel like the wrong Widevine version was pushed for the Release channel.

Comment 8

[Ali Akbar]

I'm also having this issue on Linux Solus OS (KDE Edition), Firefox v87.

Spotify and other DRM content keep displaying the top yellow bar stating "Firefox is installing components..." while Widevine plugin v4.10.2209.1 is installed! Also get this message in Console:

MediaKeySystemAccess::GetKeySystemStatus(com.widevine.alpha) result=cdm-not-installed msg='CDM is not installed'

Comment 9

[dsalvatore384]

Having the same issue, after the latest update of Widevine to version 4.10.2209.1, I've been unable to play DRM content as well. But the issue is only present in stable build of firefox and not nightly.

I'm running firefox 87.0 (64bit) on fedora 34 beta.

Comment 10

[Steeve McCauley]

Same issue, Firefox 87 on Fedora 34. On the netflix page I get a message banner at the top of the page saying that firefox is installing components needed to play audio or video.

In the console I see a bunch of messages like this,

unreachable code after return statement cadmium-playercore-6.0029.684.911.js:1:760391

and if I attempt to play something,

Uncaught (in promise)
Object { code: 7701, "$b": 1003, od: undefined, Bm: undefined, hv: undefined, message: "Unable to create media keys system access. Timed out while waiting for a CDM update", Dq: "Timed out while waiting for a CDM update", data: DOMException, fj: undefined, OMb: undefined, … }

Comment 11

[Steeve McCauley]

It does work as expected on firefox-88.0b9.tar.bz2 after syncing my profile.

Comment 12

[Marcel Guzik]

Also having this issue with Spotify.
Affected versions:

• Firefox Developer Edition 88.0b4
• Widevine 4.10.2209.1

Unaffected versions:

• Firefox 87.0
• Widevine 4.10.1582.2

Comment 13

[Steeve McCauley]

I just verified that spotify works with Firefox 88.0b9 (64-bit) Widevine Version: 4.10.2209.1

Comment 14

[Thaodan]

After downgrading to the version used in ESR 78 it works again.

Comment 15

[Mads Kiilerich]

I also see the problem on Fedora 34 with firefox-87.0-7.fc34.x86_64 (and firefox-87.0-1.fc34.x86_64) which install 4.10.2209.1 .

I can confirm it works fine with:

• firefox-86.0.1-1.fc34.x86_64 (which install 4.10.1582.2)
• firefox-87.0-7.fc34.x86_64 also works for a while after upgrading from firefox-86, until it auto updates to 4.10.2209.1
• Flatpak 87.0
• a manually installed mozilla.org 88.0b9 binary (using 4.10.2209.1)

I found that the crucial difference is in .mozilla/firefox/*/gmp-widevinecdm/4.10.2209.1/manifest.json where 4.10.2209.1 in "x-cdm-codecs" has "vp09". DRM starts working after manually changing it to "vp9.0", as in 4.10.1582.2 from Firefox 86. That workaround seems to work for me.

It could thus seem to be a problem in the way Firefox in some versions is compiled or packaged in Fedora (and perhaps other distros). Perhaps a difference in the lib that provide vp support? Should Fedora patch the firefox package to make vp09 an alias for vp9.0?

(It doesn't seem to be reported in the Fedora bugtracker - https://bugzilla.redhat.com/show_bug.cgi?id=1895721 is slightly similar ... but different.)

Comment 16

[Robert Mader [:rmader]]

(In reply to Mads Kiilerich from comment #15)

I found that the crucial difference is in .mozilla/firefox/*/gmp-widevinecdm/4.10.2209.1/manifest.json where 4.10.2209.1 in "x-cdm-codecs" has "vp09". DRM starts working after manually changing it to "vp9.0", as in 4.10.1582.2 from Firefox 86. That workaround seems to work for me.

Thanks, can confirm this works as a workaround.

I also opened a new bug at RH bugzilla as the old one is IIUC about a different issue (sandbox related): https://bugzilla.redhat.com/show_bug.cgi?id=1948321

Comment 17

[Ryan VanderMeulen [:RyanVM]]

This sounds like bug 1701089, which is already fixed for Fx88 and 78.10esr shipping in a bit over a week.

Comment 18

[Robert Mader [:rmader]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #17)

This sounds like bug 1701089, which is already fixed for Fx88 and 78.10esr shipping in a bit over a week.

Thanks, that indeed sounds like it. Is there a way to meanwhile contact distro maintainers so they can ship it sooner? Not being able to use major content sites is quite bad IMO.

Martin, Jan, this may be relevant for you.

Comment 19

[Steeve McCauley]

(In reply to Mads Kiilerich from comment #15)

I also see the problem on Fedora 34 with firefox-87.0-7.fc34.x86_64 (and firefox-87.0-1.fc34.x86_64) which install 4.10.2209.1 .

I can confirm it works fine with:

• firefox-86.0.1-1.fc34.x86_64 (which install 4.10.1582.2)
• firefox-87.0-7.fc34.x86_64 also works for a while after upgrading from firefox-86, until it auto updates to 4.10.2209.1
• Flatpak 87.0
• a manually installed mozilla.org 88.0b9 binary (using 4.10.2209.1)

I found that the crucial difference is in .mozilla/firefox/*/gmp-widevinecdm/4.10.2209.1/manifest.json where 4.10.2209.1 in "x-cdm-codecs" has "vp09". DRM starts working after manually changing it to "vp9.0", as in 4.10.1582.2 from Firefox 86. That workaround seems to work for me.

It could thus seem to be a problem in the way Firefox in some versions is compiled or packaged in Fedora (and perhaps other distros). Perhaps a difference in the lib that provide vp support? Should Fedora patch the firefox package to make vp09 an alias for vp9.0?

(It doesn't seem to be reported in the Fedora bugtracker - https://bugzilla.redhat.com/show_bug.cgi?id=1895721 is slightly similar ... but different.)

Amazing forensics. Can confirm that it works for me in FF87 on Fedora 33 with the older widevine plugin (4.10.1582.2) but not on F34 as above.

Good to know there's a workaround

Comment 20

[Jan Alexander Steffens [:heftig]]

(In reply to Robert Mader [:rmader] from comment #18)

Martin, Jan, this may be relevant for you.

Thanks, backported.

Comment 21

[Martin Stránský [:stransky] (ni? me)]

Backported, Thanks.

Comment 22

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Assigning this to me as I'm the Widevine person. I think this will mostly need to be fixed down stream (as is already happening). I'll see if we can do anything on the Moz end to see if we can avoid some of these mismatches.

---

Expanding on why this is happening for those interested, Firefox connects to an update server and receives updates based on various rules. For the new Widevine version some of those rules are based on buildid (essentially a datetime when the build was done). Because downstream builds may have different binaries than Mozilla builds given the same buildid we can end up with mismatches.

Comment 23

[Kalvin Lee]

Fedora 34 is carrying a working fix packaged as 87.0-12. I expect F33 and other distros will be getting their fixes shortly, so this bug is — for my purposes — resolved+verified.

Comment 24

[Julien Cristau [:jcristau]]

Should this be closed as duplicate of bug 1701089?

Setting as wontfix for 87 as the release of 88 is next Monday.

Comment 25

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

(In reply to Julien Cristau [:jcristau] from comment #24)

Should this be closed as duplicate of bug 1701089?

Since it's being fixed by pulling those changes that makes sense to me.

Comment 26

[Thaodan]

The title of the bug is misleading since it affects not only downstream builds of firefox-87 but also the mozilla build of it.

Comment 27

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

(In reply to Thaodan from comment #26)

The title of the bug is misleading since it affects not only downstream builds of firefox-87 but also the mozilla build of it.

Which Mozilla builds are affected? Edit: a link to the download of the affected version would be useful to verify.

Comment 28

[Thaodan]

(In reply to Bryce Seager van Dyk (:bryce) from comment #27)

(In reply to Thaodan from comment #26)

The title of the bug is misleading since it affects not only downstream builds of firefox-87 but also the mozilla build of it.

Which Mozilla builds are affected?

Sorry I did not read #22 properly. The title just sounds wrong since it is not directly downstream fault that this happened but because of how widevine detects which version to choose.

Comment 29

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

The title was not meant as a judgement, but to describe that some downstream builds did not yet have code changes that are expected by the new CDM (and which gets sent to those builds due to updater setup). I've rewarded it to be more specific, and remove the 'lack'.