Netflix not working in Vivaldi Snapshot when installed with scoop

petedebiase

Howdy all, I am a huge fan of Vivaldi since discovering it earlier this year. Finally, a browser my way!

Since my initial install, I have had extreme difficulty getting Netflix to work in Vivaldi Snapshot when Vivaldi Snapshot is installed with scoop (the excellent Windows package manager). I believe I may have isolated this to Vivaldi Snapshot being installed with scoop, as follows.

Installed with Scoop

When I do a fresh install of Vivaldi Snapshot via Scoop, Netflix throws error M7121-1331 ("This title is not available to watch instantly. Please try another title. -1044") when I attempt to play a video. Some Googling seemed to indicate that this error may be related to the Widevine CDM component.

I have checked that WideVine CDM is up to date in vivaldi://components, and I have also checked that 'Sites can play protected content' and 'Sites can use identifiers to play protected content' are enabled in chrome://settings/content/protectedContent.

When I visit https://demo.castlabs.com/ as suggested by Vivaldi help and attempt to play the Protected • MPEG-DASH Multi-Key DRM test video, I get the attached error output and the attached log output.

Installed with Installer from Vivaldi Website

When I install Vivaldi snapshot using the installer on the Vivaldi website, Netflix initially throws Error Code M7701-1003 ("Please visit chrome://settings/content/protectedContent and make sure 'Sites can play protected content is selected'"). After toggling 'Sites can play protected content is selected' and 'Sites can use identifiers to play protected content' on/off several times and restarting Vivaldi in between, I can eventually get Netflix to work. (Appears to start working once Vivaldi downloads the WidevineCdm component.)

Now, when I visit https://demo.castlabs.com/ and play the DRM video, the video plays successfully.

Summary / Followup

The only difference I can see is the install method: scoop versus the official Vivaldi installer.

Any ideas what might be causing this or how to fix it? I'm fresh out of ideas and wondering if anyone has ever experienced similar - reading around, it looks like Netflix issues have been a point of recurring pain for many Vivaldi users over the years.

I have also raised an issue on the scoop GitHub to see if anyone there may have additional insight.

Environments:
Windows 11 21H2
Vivaldi Snapshot 5.6.5829.3, installed via scoop (Netflix error M7121-1331 → Netflix never works)
Vivaldi Snapshot 5.6.5829.3, installed via Vivaldi installer (Netflix error M7701-1003 → Netflix eventually works)

Edit: I do not appear to have privileges to attach the error/log files.

DoctorG

@petedebiase said in Netflix not working in Vivaldi Snapshot when installed with scoop:

vivaldi://components

Which Widevine version is used after install with Scoop and which after Vivaldi Installer.

DoctorG

@petedebiase Had you opened vivaldi://components and manually updated the widevine component?

I was told, that after Vivaldi started (or max. 5 minutes later), it checks for new modules.
You should always get the latest Widevine component.

Pathduck

@petedebiase Hello and Welcome to the Vivaldi Community

I don't have Netflix nor Windows 11. But I do watch DRM protected content in Vivaldi and the Widevine demo page works fine.

I'm not sure how Scoop should influence the way Widevine works. From looking at the "bucket" for Snapshot it seems to install as Standalone (stp.viv), but that still shouldn't influence anything with Widevine.

But of course - Widevine relies on being able to read/write decryption keys in your browser's profile folder. Not sure where these keys are stored exactly. But if your user does not have write access to wherever Scoop installs the Standalone install, it might cause problems.

So that's my primary guess.

Here are some other DRM demo pages:
https://bitmovin.com/demos/drm
https://www.theoplayer.com/theoplayer-drm-aes-128-encryption (select DRM first)
https://www.visualon.com/index.php/html5-player-drm-demo/

If you go to the debug URL and find the related player:
vivaldi://media-internals
You should see references to:
kVideoDecoderName "DecryptingVideoDecoder"

Some other things to try:

Install Stable as Standalone (not with Scoop) and test
Install Snapshot as Standalone (not with Scoop) and test

I believe also Spotify uses Widevine encrypted content so in theory if Widevine does not work, Spotify should also not work. But Netflix is probably more complicated.

As for "attaching" logs - if you have a lot of log it tends to catch on the spam filter for new users. Better to use a pastebin of some sort and post the link. And you don't "attach" logs, you can paste it using a code block (</> icon)

petedebiase

Howdy again, I made some good progress and am reporting back with some good news and some bad news.

@DoctorG
Both the scoop install of Vivaldi and Vivaldi installer install of Vivaldi are currently using WidevineCdm 4.10.2449.0. During the course of my testing, 4.10.2391.0 and 4.10.59ish were in play at one point or another. I tried copying every version of Widevine I saw into both installs, and this did not seem to change any of the behavior of either install.

@Pathduck

Widevine relies on being able to read/write decryption keys in your browser's profile folder

This very helpful insight led me to the root cause. I tried using scoop to install Vivaldi Snapshot to three different "scoop homes" on my machine: C:\scoop , C:\Users\pete\scoop , and D:\scoop. I then configured these directories to have different read/write privileges, but I still got the same results as originally (scoop Vivaldi no dice, Vivaldi installer Vivaldi many dice). So I was able to rule that out, but this felt very close.

Root Cause (I think)

Scoop uses directory junctions (basically hardlinks) as described here to try to ease the pain of updating software.

In this case, I discovered that the directory junction that hardlinks C:\scoop\apps\vivaldi-snapshot\current\User Data to C:\scoop\persist\vivaldi-snapshot\User Data may be the root cause of the problem - Widevine functionality does not appear to survive the redirection.

Workaround

Manually replacing the C:\scoop\apps\vivaldi-snapshot\current\User Data directory junction with a hard true copy of C:\scoop\persist\vivaldi-snapshot\User Data solved the issue - Netflix, Udemy, and other DRM sites now work in the Vivaldi Snapshot instance installed via scoop.

Further Thoughts

This is a decent workaround, but still a bit interesting/confusing. Before I got into scoop, I used to manually set directory junctions to link things like my text editor/IDE configs from a Dropbox folder to the appropriate folders in C:\Users\<user>\AppData so my app configs would automatically sync between machines. From doing this, I always got the impression that apps could not distinguish a directory junction from a true copy of the underlying data - it was one and the same.

This experience is proof that at least in this case, there is a difference between a directory junction and a true copy of the data.

Summary

I will continue to talk to the scoop folks to see if anything can be done to improve this limitation and report back with more info. Out of curiosity (and I know this is a long shot), does anything come to mind in terms of making Vivaldi's User Data folder more amenable to directory junctioning? Perhaps I just need to roll my own script to automatically move a true copy of my User Data to the better location when scoop updates Vivaldi.

Thanks so much to you both @DoctorG and @Pathduck for helping to unstick me and point me in the right direction! I hope to fix/alleviate or at least thoroughly document this issue to save the next poor soul who comes along from similar pain .

Pathduck

@petedebiase That's great

Well... at least it works with the workaround

Widevine functionality does not appear to survive the redirection.

Hmm, that's strange. I use junction links on my Win10 system as well. Not for Vivaldi, but I use it for Chromium, linking:
AppData\Local\Chromium\User Data --> d:\bin\Chromium\User Data
Because I don't use Chromium except for testing and I don't want its user data on my system drive. And the Widevine tests still work fine.

I always got the impression that apps could not distinguish a directory junction from a true copy of the underlying data - it was one and the same.

It really should be, but there may be subtleties underlying here. And this Widevine stuff is hard enough to troubleshoot as it is, without taking junctions into account.

Vivaldi is basically just a UI built on top of a (slightly modified) Chromium base. The user data directory structure is basically the same. And I would've expected that if Scoop's use of junctions caused issues for Chromium browsers there would be more reports of it on the Scoop community?

It should be easy enough to test if Vivaldi behaves differently though. Just install Vivaldi as Standalone, launch once to create the dir structure, then link "User Data" off somewhere else. Then test if Netflix/DRM still works. I might do the same test myself, should be quick enough, I have plenty of Standalone installs here.

If you can show there's a difference between Chromium/Chrome and Vivaldi then that would be a good case for a bug report. Not sure how much priority such a report would get though, as junctioning off User Data is probably not a supported setup.

Thanks for your well-researched and thoughtful issue investigation - we don't get many users willing to investigate this thoroughly on their system

petedebiase

More great ideas! Here are my latest discoveries in this vein:

Standalone Vivaldi and Chrome Testing

I can confirm that with a standalone install of Vivaldi, I can reproduce Netflix error M7121-1331 by moving my %AppData%\Local\Vivaldi\User Data folder somewhere else and then creating a directory junction from %AppData%\Local\Vivaldi\User Data → somewhere\else.

Repeating the same experiment with a fresh standalone install of Chrome, Netflix does not break. This may be due to a difference in where the Widevine files/DLLs are stored:

Vivaldi: Widevine DLLs in %AppData%\Local\Vivaldi\User Data\WidevineCdm.
Chrome: Widevine DLLs in C:\Program Files\Google\Chrome\Application\107.0.5304.88\WidevineCdm. Notably, %AppData%\Local\Google\Chrome\User Data\WidevineCdm is completely empty.

In other words, hardlinking Chrome's User Data folder does not break Netflix because Widevine is not located in Chrome User Data to begin with. Other interesting and/or confusing observations:

Outright deleting C:\Program Files\Google\Chrome\Application\107.0.5304.88\WidevineCdm causes Netflix to throw Error Code M7701-1003 in Chrome. Makes sense. I guess this error really means "couldn't find Widevine".
I tried moving my Vivaldi Widevine directory from User Data to Vivaldi\Application\5.6.2829.3\ (copying what Chrome does) - no dice. Netflix goes back to Error Code M7701-1003 (no Widevine found).
Several other open reports of Netflix not working in Chromium-based browsers installed via scoop:
- https://github.com/ScoopInstaller/Scoop/issues/4172
- https://github.com/ScoopInstaller/Extras/issues/5742

Think I Nailed It

Installed Chrome via Scoop. (Recall that Chrome's Widevine lives near its main app directory rather than in its User Data directory). Discovered the following:

Launching Chrome via <scoophome>\apps\googlechrome\current\chrome.exe results in all of the above problematic DRM behavior. This executable lives in a hardlinked directory, so its Widevine gets hardlinked.
Launching Chrome via <scoophome>\apps\googlechrome\106.0.5249.119\chrome.exe allows DRM sites to work fine. This executable lives in a normal non-hardlinked directory, so its Widevine does not get hardlinked.

I think this may prove that the issue is with the directory junctions.

Possible Takeaways / Workarounds

Vivaldi could potentially consider moving Widevine from its User Data directory to its Application\<version> directory. This would align more closely with Chrome (shoot, they might not care about Chrome, should have tested in Chromium) and intuitively makes a kind of sense - Widevine feels much more like a core app component than user data. (There may be a good reason for putting Widevine in User Data, I'm too new to know so please forgive me if so ).
Widevine could potentially consider seeing whether they can do anything to make their DLLs hardlinkable.
Scoop users of Chromium-based browsers should launch their browsers from a non-hardlinked executable or move their Widevine directories to a non-hardlinked location that can be accessed by a non-hardlinked executable.

Bonus: Testing Without Netflix

Note for testing with the DRM video on https://demo.castlabs.com/ as an alternative to Netflix:

Netflix Error M7701-1003 corresponds to Castlabs error FATAL Clpp-Error [Category 6 - Code 6001]. This happens when the Widevine files are not found at all.
Netflix Error M7121-1331 corresponds to Castlabs error FATAL Clpp-Error [Category 6 - Code 6007]: Error while fetching license! Caused by FATAL Clpp-Error [Category 1 - Code 1001]. This happens when the Widevine files are present in roughly the right location but are being accessed via a directory junction.

petedebiase

PS - I am more than happy to keep working on this for everyone's benefit, but I'm not sure of the next steps. Any thoughts?

Pathduck

@petedebiase Hey - you're doing good detective work and documenting your findings, excellent

This may be due to a difference in where the Widevine files/DLLs are stored:

Hmm. Not sure. For Chrome yes, they do it differently. But for Chromium the Widevine DLL is located in User Data far as I can tell, just like Vivaldi.

So would be good if you could test the same with Chromium as well, comparing to Chromium is the best way to have a good case for a bug report to Vivaldi.

I did actually test with junctioning off Vivaldi's User Data. Got the same errors you got - apparently the junction caused it to not load Widevine properly.

Did the same in Chromium, and Widevine still worked on the demo page.

However, it appears only the Castlabs demo is affected. The other DRM tests still worked in Vivaldi after junctioning.

So this is really a rabbit hole: Different players, different requirements, different ways to fail. DRM sucks...

There may be a good reason for putting Widevine in User Data,

Widevine is a "component" and they all get downloaded to User Data per user. The reason Vivaldi/Chromium does things like this is probably the different types of install. For instance a user would not have write permissions in C:\Programfiles if installed for all users. And when components are updated they need to be written somewhere that does not require elevated permissions.

But Chrome for instance has its own "Helper" services running with higher privileges that can update these things in the background.

petedebiase

@Pathduck Thanks for the feedback and encouragement .

Glad to know that you were also able to reproduce the issue with a directory junction. And interesting to hear that Chromium may behave differently.

I will investigate more with Vivaldi versus Chromium specifically on a range of DRM sites and post back with a summary of my results!

NeonTheCoder

@petedebiase
I believe the hardlinking is the issue.
I just got netflix, and have the latest version of vivaldi as well as Widevine Content Decryption Module, but videos wont play.

For a year or two now I've had my AppData moved to a different drive and hard linked so apps would stop eating away at my miniscule 256gb ssd. I did not install it via "scoop" simply updated the browser over time through the official notification balloon. It used to work, but it seems a update some time ago broke it? It still doesn't work now. I'm upgrading soon but this is such a weird issue that shouldnt exist.

petedebiase

@NeonTheCoder

Good to know that I'm not the only one with this use case!

I haven't forgotten about this thread and still intend to do more testing/report back. Next steps are to try to demonstrate a difference in the behavior of Vivaldi and Chromium - such a difference will give us better footing to file a bug report with Vivaldi that might actually get some attention.

Recently I've been strapped for time due to switching my dev environment from Sublime/IntelliJ to Neovim - it's been uniquely frustrating and disruptive to my productivity (hopefully, just in the short term) but also uniquely rewarding.

So, whether it's another month from now or another year from now, I will be back to keep chipping away on this .