Resident Evil collection

[mazzetta86]

Have you guys tried the tool created by @domy94 here?

viewtopic.php?f=12&t=17597&p=90648#p90648

It sounds like Mike might be incorporating his methods into the next release.

Yes we have tried but sadly it doesn't work. I filled up an issue https://github.com/domyd/mlp/issues/10

It seems like this UHD disc uses a different way for the Atmos track. When the audio drops, the audio goes completely out of sync and I have to restart the playback to solve. In Disney/Pixar discs, the audio was just "bumping" and it was playing without going out of sync.

[SamuriHL]

It behaves like Incredibles 2. That one also had drops where sync would get messed up and audio sometimes refused to come back after a drop.

[agressiv]

How do you "force" the hashed keys update? I'm still getting volume unknown on these disks.

I thought it might be _private_data.tar (deleting) but that didn't help.

[SamuriHL]

Ensure that the setting to download updates is checked in preferences.

[agressiv]

Ensure that the setting to download updates is checked in preferences.

It is already Hence why I want to somehow manually trigger it; this happened with the GOT Boxset as well. Everyone else had been able to decrypt them for several days and I tried probably 20x over the next few days and it *finally* downloaded the hashed keys at some point and then worked just fine.

Just looking for a way to force it rather than waiting on dumb luck it would seem.

[SamuriHL]

It's entirely possible you have a set that hasn't been decrypted yet. I'm assuming you sent in your dumps, yes?

[agressiv]

I'll certainly submit them, but after I deleted that _private_data.tar, NO disk decrypts. I put in my copy of Black Panther (which I had ripped a week earlier) and now it's unknown.

So, I'm missing something. There's gotta be a way to trigger that hashed key download manually. My gut is that there's nothing special about my box set of Resident Evil.

[Woodstock]

Often the problem is with your DNS server - some DNS servers will not allow any host in the domain *.fairuse.org to resolve. If you have one of the google DNS servers, 8.8.4.4 or 8.8.8.8, in your list of DNS servers, it will usually work.

[agressiv]

Google DNS is what I use for everything

Why it decides to randomly download it though is beyond me. Would be nice to have an easy way to trigger the download.

[agressiv]

Moved the drive to a different computer and sure enough, it downloaded the hashed keys and is working fine even with the new Resident Evil.

Just need to figure out how to do it on the server I use for ripping rather than my workstation. Simply copying the _private_data.tar wasn't good enough.

[Woodstock]

The sdf.bin file that controls a lot of stuff is hosted on the same server as the forum, so it is accessible by your regional cloudflare access point. That is one of the components of _private_data.tar, which should be recreated when you start MakeMKV after deleting it. You can manually download it from this link: https://www.makemkv.com/svq/sdf.bin . You should drop the file in your MakeMKV data directory, where _private_data.tar used to be.

sdf.bin contains the current whereabouts of the hash key file, because it can move about. The current domain hosting the hashkey file host is "hkdata.fairuse.org".

But the link is going to probably resolve to an IP in the Russian Federation; if you have anything in your network that blocks connections to the RF, that can be a problem. Although the forum is hosted in the RF, Cloudflare is taking care of routing you through local portals to it.

Direct requests, though, might might be blocked by antivirus programs, too, unless you make exceptions.

sdf.bin should be loaded whenever MakeMKV starts, and the hashkey file should be loaded when a disk with an unknown key is loaded. And both events will be logged in the debug logging file.

[agressiv]

Still no go, and that sdf.bin is from November 6th - well before Resident Evil came out.

Code: Select all

-rw-rw-rw- 1 agressiv agressiv 3322368 Nov 26 10:47 _private_data.tar
-rw-rw-r-- 1 agressiv users     715408 Nov  6 16:52 sdf.bin

Oddly, the sdf.bin inside the _private_data.tar is dated Dec 31 1969, so perhaps the date/time stamps aren't really relevant. Even when I turn on debug logging, it makes no mention of outbound web calls, so there's not much for me to trace. Loading up a packet capture inside a docker container wasn't going to be my first course of action either.

The box which is running MakeMKV is running linux; there is no antivirus software and I'm running jlesage's popular MakeMKV container. It's on the same network as my workstation running Windows - which downloaded the hashed keys just fine. And again, it will *eventually* download a new key, but what is happening underneath the covers is a bit cryptic - which is why I wanted to simply force it. MakeMKV simply deletes sdf.bin after it starts anyways.

Code: Select all

Debug log started at Thu Nov 26 16:45:41 2020 , written by MakeMKV v1.15.3 linux(x64-release)
Using 262272KB for read cache.
001005:0000 MakeMKV v1.15.3 linux(x64-release) started
001004:0000 Debug logging enabled, log will be saved as file:///config/MakeMKV_log.txt
001003:0020 DEBUG: Code 0 at 'Jysl4DHlj1n;d*uA-/9i\:29393631
001003:0020 DEBUG: Code 0 at 2`pU]YS":6E[{?XI:29407201
001003:0020 DEBUG: Code 3 at :]7u!2S2C0xy4cK6<wy::29394367
SDF  v07b: BUFFALO_Optical_Drive_BU10_211705301728_KZ8H8UI2421
SDF  v07b: BUFFALO_Optical_Drive_BU10_211705301728_KZ8H8UI2421
SDF  v07b: BUFFALO_Optical_Drive_BU10_211705301728_KZ8H8UI2421
001011:0000 Using LibreDrive mode (v06.2 id=F046CEB2F3AB)
003007:0000 Using direct disc access mode
005085:0000 Loaded content hash table, will verify integrity of M2TS files.
DEBUG: Code 2147483648 at 2`pU]YS":6E[{?XI:121264786
DEBUG: Code 0 at 2`pU]YS":6E[{?XI:121267040
003332:0000 Saved AACS dump file as file:///config/data/MKB20_v68_Resident_Evil_5408.tgz
003303:0000 The volume key is unknown for this disc - video can't be decrypted
DEBUG: Code 0 at 8p484H Too-'r[U*:29396069
DEBUG: Code 0 at 8p484H Too-'r[U*:29395149
005010:0000 Failed to open disc
DEBUG: Code 0 at 'Jysl4DHlj1n;d*uA-/9i\:29393631

I looked up 2147483648, pretty generic error. Not much else to really decipher unless these gibberish password-looking strings are of value.

[Woodstock]

The date on sdf.bin is not critical to UHD, really - the file allows different capabilities, like adding speed controls for some drives, to be transferred.

If you've deleted _private_data.tar, the log should show TWO downloads, "Downloading latest SDF to ...", and "Downloading latest HK to ..."

If you manually downloaded sdf.bin, it will be found and the download will be skipped, but the HK download should still occur when the UHD disk is detected, assuming you have "Contact the web server for updates" turned on, AND your system will allow MakeMKV to connect.

[SamuriHL]

Usually a sign of the machine messing with the connection. Firewall, antivirus, security software, etc can all block the connection.

[agressiv]

There's no firewall, no antivirus, no security software; allow internet updates is checked. If I delete _private_data.tar, it simply does nothing - 99% of the time, and then no discs decrypt.

The debug log simply doesn't say anything and there's really no good way to troubleshoot. I can say it never even attempts to download anything, and nothing is ever logged.

I still go back to my original request: allow me to run makemkvcon --forcehashupdate or something to that extent - take random luck out of the equation.

On my windows box, if I delete _private_data.tar, it will re-download it again *every* time - 100%:

Code: Select all

Downloading latest SDF to C:\Users\agressiv/.MakeMKV ...

On linux, it simply doesn't do that. It won't even log that it's attempting to download anything. My gut is that it's some sort of bug in the linux version itself.