Closed Bug 1704022 Opened 3 years ago Closed 3 years ago

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

Categories

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

Firefox 87
defect

Tracking

()

RESOLVED DUPLICATE of bug 1701089
Tracking Status
firefox87 - wontfix
firefox88 + fixed
firefox89 + fixed

People

(Reporter: hikaph+mozilla, Assigned: bryce)

Details

Attachments

(1 file)

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.

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.

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.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

(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'
Attached file support_info.txt

[Tracking Requested - why for this release]:

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

Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Flags: needinfo?(bvandyk)

(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.

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'

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.

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, … }

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

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

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

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

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.)

(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

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

(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.

Flags: needinfo?(stransky)
Flags: needinfo?(jan.steffens)

(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

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

Martin, Jan, this may be relevant for you.

Thanks, backported.

Flags: needinfo?(jan.steffens)

Backported, Thanks.

Flags: needinfo?(stransky)

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.

Assignee: nobody → bvandyk
Severity: -- → S2
Flags: needinfo?(bvandyk)
Priority: -- → P1
Summary: Widevine 4.10.2209.1 appears inoperable → Widevine 4.10.2209.1 fails to for downstream builds that lack code changes but are targeted by new rules
Summary: Widevine 4.10.2209.1 fails to for downstream builds that lack code changes but are targeted by new rules → Widevine 4.10.2209.1 fails to load for downstream builds that lack code changes but are targeted by new rules

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.

Should this be closed as duplicate of bug 1701089?

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

(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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE

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

(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.

(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.

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'.

Summary: Widevine 4.10.2209.1 fails to load for downstream builds that lack code changes but are targeted by new rules → 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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: