Closed Bug 1958667 Opened 1 year ago Closed 21 days ago

Firefox 137 + Windows 11 24H2 DRM video playback fails when not installed at C:

Categories

(Core :: Audio/Video: GMP, defect, P3)

Firefox 137
Desktop
Windows 11
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mdprivate, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

When I install Firefox 137 on any other drive than C:, I cannot play DRM videos.
Both the portable versions as the installer versions. A fresh install with a virgin profile does not fix this.

Firefox x64 Windows 11 24H2
ESET Internet Security 18.0.12.0

Actual results:

https://npo.nl/start/serie/nos-journaal/seizoen-25_23/nos-journaal_98527/afspelen fails to play. When I move the browser to the C: drive it magically works.

Expected results:

Playback of DRM protected videos should not depend on the drive the browser is being launched from.

https://developer-tools.jwplayer.com/stream-tester

Firefox launched from D: or Z: drive
Video plays, DRM video does not play.

Firefox launched from C: drive:
Video plays, DRM video plays.

The Bugbug bot thinks this bug should belong to the 'Firefox::Installer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Installer
Component: Installer → Untriaged
OS: Unspecified → Windows 11
Hardware: Unspecified → Desktop

I think the bot is wrong. I think the installer is fine, but the bug is in the installed product.

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

Issue dot not occur with Firefox 136. Only with 137.

Blocks: media-triage
Component: Audio/Video: Playback → Audio/Video: GMP
Flags: needinfo?(aosmond)
Keywords: regression

The regression doesn't make sense for this explanation but there is bug 1763978 where we have issues with plugins on ramdisk drives.

What is the nature of the Z: and D: drives? Are they ramdisk, network, a different physical disk, just a partition on the same drive as the C: drive? Thanks!

Flags: needinfo?(aosmond) → needinfo?(mdprivate)

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #6)

What is the nature of the Z: and D: drives? Are they ramdisk, network, a different physical disk, just a partition on the same drive as the C: drive? Thanks!
In my case:

C: is a system encrypted VeraCrypt partition
D: is a mounted encrypted VeraCrypt container
Z: is a mounted encrypted VeraCrypt container

I use no RAM disk

Flags: needinfo?(mdprivate)

Interesting, this really does feel similar to bug 1763978 save for the fact that this is a regression....

Are you able to reproduce this using mozregression? This would be the fastest way to understand what changed in 137 that regressed this:
https://mozilla.github.io/mozregression/quickstart.html

Hi, would you mind follow this instruction to capture a media profile? Thanks!

Flags: needinfo?(mdprivate)

Also, does the build below solve your problem? This includes the patch that was backed out which solved the ramdisk problem:
https://treeherder.mozilla.org/jobs?repo=try&revision=68353a794b95f80c9e25c61f81060d6cda0951be&selectedTaskRun=CtzveuKdQ5mr9vrdX1D8Mw.0

You can download the target zip (just extract and run firefox binary) or exe (installer) from the artifacts tab.

(In reply to Alastor Wu [:alwu] from comment #10)

Hi, would you mind follow this instruction to capture a media profile? Thanks!

https://share.firefox.dev/4lsy1XK

Flags: needinfo?(mdprivate)

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #11)

Also, does the build below solve your problem? This includes the patch that was backed out which solved the ramdisk problem:
https://treeherder.mozilla.org/jobs?repo=try&revision=68353a794b95f80c9e25c61f81060d6cda0951be&selectedTaskRun=CtzveuKdQ5mr9vrdX1D8Mw.0

You can download the target zip (just extract and run firefox binary) or exe (installer) from the artifacts tab.

Still only works from my C: drive. Not my Z: drive. And as this is a fresh install it also rules out my profile and the many add-ons I use on my main (portable) version.

No longer blocks: media-triage
Severity: -- → S3

I am on Windows 26H2 and this week Firefox Portable 158 and any Firefox install on VeraCrypt D drive stopped to play Netflix and Disney DRM, Chrome Portable from same drive works file.

I tried Beta, Nights all stopped to work.

Once Portable folder moved to C drive it magically starts to work.

Removed gmp* folders and they have been downloaded with same versions but no luck....

Anything that I can double check?

Thank you for the new report.

Analysis

The media profile in comment 12 shows that the site gets Widevine access. After that, no GMP process starts and the CDM does not load. The profile does not show the step that fails. Bug 1763978 shows a similar Widevine failure on drives that a third-party driver creates.

Next steps

Could you please run Firefox from the VeraCrypt D: drive and capture a profile there? Keep the tab open until the DRM video fails.

Please capture a profile:

  1. Open about:logging.
  2. On the Logging presets tab, choose the "Media playback" preset.
  3. Under Logging output, select "Logging to the Firefox Profiler".
  4. Click Start Logging.
  5. Reload the page. Then do the steps that show the problem.
  6. Click Stop Logging. The profile opens in the Firefox Profiler.
  7. Click Upload Local Profile. This is the share button.
  8. Copy the share URL. Add it to this bug.

The instruction video shows these steps. If the profile or the media content is private, send it to media-alerts@mozilla.com instead.

Could you please also attach the text of about:support from that Firefox? Use the Copy text to clipboard button.

The bug also still waits for the mozregression range from comment 8.


To give feedback on this comment, add a thumbs-up or thumbs-down reaction.

Flags: needinfo?(vrtareg+mozilla)
Priority: -- → P3
See Also: → 1763978
Attached file Support Summary —

Here is the log upload: https://share.firefox.dev/4ymGlxz

Flags: needinfo?(vrtareg+mozilla)

A lot of time and releases have past since I posted this issue. I can now say that the problem does not occur anymore on my configuration:

Windows 11 26H2
Firefox ESR 153.5.0
Firefox installed on Z: (Veracrypt mouted container)
Veracrypt v 1.16.29

Status: UNCONFIRMED → RESOLVED
Closed: 21 days ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: