FindVUK tool - get VUK of all Blurays supported by DVDfab applications

[SamuriHL]

Link worked for me and download keydb_red.zip.

[nalor]

Honestly really incredible - when I check the source of the site and find timestamps from 2018 .... unbelievable how long this thing is running already.

[SamuriHL]

It's awesome work you do!

[markfilipak]

Link worked for me and download keydb_red.zip.

https://fvonline-db.bplaced.net/fv_download.php?reduced gives me a 404.
https://fvonline-db.bplaced.net/ gives me a 404.
https://www.bplaced.net/ works.

[mick0]

https://fvonline-db.bplaced.net/fv_download.php?reduced gives me a 404.
https://fvonline-db.bplaced.net/ gives me a 404.
https://www.bplaced.net/ works.


You need to use http:// and not https://

[SamuriHL]

They're using a browser that automatically forces HTTPS for links. Which no workie. You have to set an exclusion or use a different browser.

[lamp]

Hmm... I get a 404 on that.

It seems to be working for me, maybe it just needed some time to update?

[markfilipak]

They're using a browser that automatically forces HTTPS for links. Which no workie. You have to set an exclusion or use a different browser.

Good try but not true. FireFox shows HTTP. It just prompts, first.

PS: https://www.bplaced.net/ does work.

[coricopat]

sorting stabilized
Initially I only sorted by VolumeLabel when creating the file - but when there are multiple entries with the same VolumeLabel, the resulting order was undetermined. So I've added a 2nd criteria to sort by DiscId as 2nd priority.
As result the order of the entries is hopefully stable now :)

Thanks, though I think it would have been even nicer, if the sorting would include at least the MEK and probably also the UK before the Disc ID.
That way one would get any "siblings" adjacent.

Perhaps also the date after MEK/UK but before DiscId... then one would also see "siblings" odered by date (but that's less important).

[coopervid]

I had also trouble. Open the link in a new browser window. Then it just spins and spins but if you check the download arrow on the right top it will have downloaded the zip file after a while.

[nalor]

Good try but not true. FireFox shows HTTP. It just prompts, first.

PS: https://www.bplaced.net/ does work.

The "free" account does not support https :(

The "paid" account requires to pay with the bank account - and this is something I don't want.

So we're stuck with 2 limitations:
* really slow speed
* http and no https

[markfilipak]

I had also trouble. Open the link in a new browser window...

I tried that and received an immediate 404 from bplaced.net, which is the host of fvonline-db.

bplaced seems to have problems. I think it's trying to use tracking and my HOSTS file is defeating tracking.

PS: Uh, no, that isn't right. It can't be my HOSTS file because if it was, bplaced tracking would not respond and I'd get a twirling 'busy' icon that never stops. Instead, I get an immediate 404 _from_splaced_. I don't know what's happening except that the download is unreachable for me.

[markfilipak]

The "free" account does not support https :(

The "paid" account requires to pay with the bank account - and this is something I don't want.

So we're stuck with 2 limitations:
* really slow speed
* http and no https

You're writing nonsense.

Correction: You're writing about _YOUR_ account at bplaced, not your browser. Oops!
Let me clear this up right now:
Yes, FireFox will visit HTTP. No problems.

Nalor, get yourself a good hosting service.

[coopervid]

You're writing nonsense.

Correction: You're writing about _YOUR_ account at bplaced, not your browser. Oops!
Let me clear this up right now:
Yes, FireFox will visit HTTP. No problems.

Nalor, get yourself a good hosting service.

I agree regarding the hosting service. Mega is free and fast and comes with 20GB of space. What is used here is somehow outdated.

[SamuriHL]

We don't necessarily know all Nalor's requirements on the back end for a free service. It's not just "hosting a file". He's running a whole PHP back end.

[coricopat]

You're writing nonsense.
Nalor, get yourself a good hosting service.

Certainly a helpful tone towards someone who's been developing, maintaining and providing core components for FLOSS BDMV playback for years... for free, in his spare time.

(Regardless of what one might have thought he'd have been writing about).

So perhaps at least for myself (and probably a great deal silent users):
Big hug and thanks for all that to Nalor!


I agree regarding the hosting service. Mega is free and fast and comes with 20GB of space. What is used here is somehow outdated.

Doesn't mega only offer file hosting? How should he run the software that maintains the DB (takes uploads, merges them, etc.) there?

[nalor]

You're writing nonsense.

Correction: You're writing about _YOUR_ account at bplaced, not your browser. Oops!
Let me clear this up right now:
Yes, FireFox will visit HTTP. No problems.

Nalor, get yourself a good hosting service.

Back in the days when I starting the site I tested really a lot of "free" hosting providers: most of them were showing ads on the page, which means they interfere with the original code and insert the ads into the page before delivering to the browser. This prevents e.g. uploads or automatic downloads and in the end bplaced was the one free provider without any technical limitations.

Maybe I should start another round of tests... but honestly I always had the hope that also bplaced would add new features to the "free" account .. but this didn't happen so far.

And the problem with services operated in a complex legal situation is that a free "no questions asked" solution is preferred.

[nalor]

Found the problem with the metadata archive, the root cause is a bad implementation from my side only working when db errors are ignored, this working as this kind of "ignoring" was the default in older php versions, but has been changed in 8.1: https://www.php.net/manual/en/mysqli-driver.report-mode.php

I'll improve the implementation tomorrow.

[markfilipak]

... And the problem with services operated in a complex legal situation is that a free "no questions asked" solution is preferred.

So, Nalor, do I read you right? You wouldn't use a paid host even if I paid for it?

[max25]

Found the problem with the metadata archive, the root cause is a bad implementation from my side only working when db errors are ignored, this working as this kind of "ignoring" was the default in older php versions, but has been changed in 8.1: https://www.php.net/manual/en/mysqli-driver.report-mode.php

I'll improve the implementation tomorrow.

Thank you very much.

[nalor]

Thank you very much.

Fixed it yesterday morning - so the metadata archive should be up2date again.

[nalor]

So, Nalor, do I read you right? You wouldn't use a paid host even if I paid for it?

Note it's not about the costs, it's about being the one who is visible as the one paying for the hosting.

I don't want to step into the light - but when someone else is willing to please send me a pm and we discuss it in detail.

Or when someone has an idea of a better provider post here and we can check.

(I'm aware of other "free" providers that look good in the first place, but in detail they do not allow filehosting and basically the keydb files are nothing else but "filehosting" - so I don't want to move everything to a different hoster with the danger of getting disabled due to ignoring their terms)

[markfilipak]

Ah! Now I see. I added http://fvonline-db.bplaced.net as an HTTPS-Only Mode exception in Firefox. The instructions are below. All is Joy, now.

Menu: Edit > Settings - opens Settings tab
Settings tab: Privacy & Security > HTTPS-Only Mode > Manage Exceptions... - opens Exceptions dialog
Exceptions dialog: Address of website - add http://fvonline-db.bplaced.net
Press 'Turn Off'.

[lamp]

Hello, I have a question about an entry not getting updated keydb.cfg, I have a UHD disc and when I use DVDFab it is able to get the keys which match, however it still says it is a legacy unvalidated entry. Even when I try manually doing FindVUK.exe ValidateDisc Drive=E it confirms it is valid but does not actually update the entry. Is there some reason why it doesn't get updated?

Here is the entry in my keydb.cfg

0xDA7EA4606C19E9A29B49D1DC41F9EBD9F35A491E = GHOST_IN_THE_SHELL_UHD (Ghost in the Shell - Ultra HD Blu-ray™) | D | 2020-08-02 | M | 0x54AF19A7EB689F50A4094EC96EC7FEDE | I | 0xBAB066D5AF55C3F3CD60AFA49E86617A | V | 0x6B9A84BA9AC7E270742EADCE74560253 | U | 1-0x201A7CA8AD05FD669470910F096C6A7E ; MKBv76/BEE/UHD/FindVUK 1.82 (LEGACY) (NOTVALIDATED) (BD)


Here is the Meta XML (not sure if from DVDFab or ValidateDisc, not sure if that matters either)

<?xml version="1.0" encoding="UTF-8"?>
<Bluray>
<FileType>BlurayMetaXML</FileType>
<DiscId Date="2020.08.02">DA7EA4606C19E9A29B49D1DC41F9EBD9F35A491E</DiscId>
<DiscType>UHD</DiscType>
<VolumeId>BAB066D5AF55C3F3CD60AFA49E86617A</VolumeId>
<MediaKey>54AF19A7EB689F50A4094EC96EC7FEDE</MediaKey>
<VolumeUniqueKey>6B9A84BA9AC7E270742EADCE74560253</VolumeUniqueKey>
<Validated>1</Validated>
<VolumeLabel>GHOST_IN_THE_SHELL_UHD</VolumeLabel>
<BDplus>0</BDplus>
<BusEncryptionEnabled>1</BusEncryptionEnabled>
<MKBrev>76</MKBrev>
<MainPlaylist />
<UnitKeys>
<UnitKey Nr="1" Status="valid">201A7CA8AD05FD669470910F096C6A7E</UnitKey>
</UnitKeys>
<EncryptedValues>
<UnitKeysENC>
<UnitKey Nr="1">9EC07AC3FEAB835A1B21CC1FC411372E</UnitKey>
</UnitKeysENC>
</EncryptedValues>
<MetaTitles>
<MetaTitle Language="eng">Ghost in the Shell - Ultra HD Blu-ray™</MetaTitle>
</MetaTitles>
<Hashes>
<Hash Type="MD5" File="MKB_RO.inf" Size="5242880">D29EFBF6BDD73F5C8D5CDEC4A31BAFAA</Hash>
<Hash Type="MD5" File="Unit_Key_RO.inf" Size="65536">9BACDD5AA9E2B4B91BB6359252DC5E79</Hash>
</Hashes>
<Application>FindVUK 1.82</Application>
<VolumeSize>68018962432</VolumeSize>
</Bluray>


I also attached the logs (too long to add to post).

Thanks!

[nalor]

Not sure whether you got my PM ~ week ago or so... there had been some pretty large character encoding mess up in the DB between 2025-08-18 and 2025-08-19 with ~ 16670 entries being changed, things like:
"Lovecká sezóna" => "Lovecká sezóna"


I still have no idea where the problem is coming from. All internal functions to update data also update a "modification" column so I can see when the last modification happened to a specific entry inside a table.
For the wrong entries no modification happened at this time.
I've learned that I had an error in the db setup: the characterset is "utf8mb4" but the "collation" (the db internal sorting rules) has been set to an "utf8_.." rule instead of an "utf8mb4_..." one.
I've fixed this problem - but this is something that has been wrong since the beginning and I don't think that this is really the root cause.

But I've fixed the entries (and hopefully I didn't destroy others).

In case you notice wrong entries tell me - thanks!

[nalor]

Hello, I have a question about an entry not getting updated keydb.cfg, I have a UHD disc and when I use DVDFab it is able to get the keys which match, however it still says it is a legacy unvalidated entry. Even when I try manually doing FindVUK.exe ValidateDisc Drive=E it confirms it is valid but does not actually update the entry. Is there some reason why it doesn't get updated?


I checked the online db and can see that you tried it 5 times and it already got changed to a validated entry with the first upload.

You have to synchronize the keydb.cfg file in order to get the entry updated (ValidateDisc does not update the local file).

[lamp]

I checked the online db and can see that you tried it 5 times and it already got changed to a validated entry with the first upload.

You have to synchronize the keydb.cfg file in order to get the entry updated (ValidateDisc does not update the local file).

I see, that is good to know, I thought I tried to synchronize it but maybe I didn't. Good to know that it was just a stale keydb and not an issue with the submission. Thank you!

[coricopat]

But I've fixed the entries (and hopefully I didn't destroy others).

In case you notice wrong entries tell me - thanks!

I checked them all (from my git where I track the file and there from the commit that introduced the mess up, took all removed lines, grepped the current entries of their DiscIDs, and then diffed them).
Assuming the title field cannot contain a string matching the regexp | [DUI] |, I'd be sure that all titles had been reverted :-)

So, thanks for fixing :-)


Apart from that:
a) can it be that the XML archive download is broken again? [Edit: forget that... seems to work]

b) Last time you said you'd have adapted the sorting of the entries in KEYDB.cfg (i.e. the rows, not the fields within the rows).
Can it be that you haven't put that live (cause I never saw a bigger change).
But as said... it's really not that important for me. Merely cosmetic... and if you change, it should perhaps well thought trough how.

[mole733]

Hello, I got a problem when I want to get a vuk of FINAL_FANTASY_VII_ADVENT UHD.
I tried playing it with Xreveal and the newest keydb.cfg, failed. DVDFab 12 can backup the disc, so I used FindVUK, but failed, too.
I read the log and made a new line like this:
0x3ECEC9C74973E3C19B96ED2B09C6E6371F031C6F = FINAL_FANTASY_VII_ADVENT (Final Fantasy VII: Advent Children - 4K Ultra HD) | D | 2021-03-29 | U | 1-0x2E00F9A1A58005C6A78926B19E482552 ; MKBv76/BEE/FindVUK 1.82 - VolumeSize: 84055359488 (UHD)
0x91C50ED3146FAD6257B2C6E75B8E3CD901A37AB4 = FINAL_FANTASY_VII_ADVENT (Final Fantasy VII: Advent Children - 4K Ultra HD) | D | 2021-03-29 | U | 1-0x2E00F9A1A58005C6A78926B19E482552 ; MKBv76/BEE/FindVUK 1.38 - MainPlaylist: 00000.mpls - VolumeSize: 84055359488 (UHD)
0x9A4AF5469AD330480D3295B0C54B8317910E38E7 = FINAL_FANTASY_VII_ADVENT (Final Fantasy VII: Advent Children - 4K Ultra HD) | D | 2021-03-29 | U | 1-0x2E00F9A1A58005C6A78926B19E482552 ; --- I add this line

Then all is ok. This disc only has a new id, FindVUK seems to think it has a new vuk. Attachment is the log.

[MrPenguin]

Then all is ok. This disc only has a new id, FindVUK seems to think it has a new vuk. Attachment is the log.
Decrypting a UHD requires knowing the following:

The disk's Unit Key, which is the "| U |" field of its KEYDB entry. You have added this information :).
Defeating bus encryption, either by knowing the Read Device Key (RDK) or by disabling bus encryption completely using something like MakeMKV's LibreDrive code.

AFAIK FindVUK uses DVDFab to discover a disk's Unit Key and RDK, but not its VUK. All of the UHD VUKs in KEYDB.cfg have presumably been found via other means.

Do you know your disk's RDK? And if not, how have you defeated bus encryption please?

[mole733]

Decrypting a UHD requires knowing the following:

The disk's Unit Key, which is the "| U |" field of its KEYDB entry. You have added this information :).
Defeating bus encryption, either by knowing the Read Device Key (RDK) or by disabling bus encryption completely using something like MakeMKV's LibreDrive code.

AFAIK FindVUK uses DVDFab to discover a disk's Unit Key and RDK, but not its VUK. All of the UHD VUKs in KEYDB.cfg have presumably been found via other means.

Do you know your disk's RDK? And if not, how have you defeated bus encryption please?

In fact, I guessed them out. I think the same kind of number strings, they may have the same length, similar formats, etc. I found these number strings from the log and tested them.

[coopervid]

I'm getting this today when I try to synchronize:

ERROR! #HTTPA_ERR_HEADERNOTFOUND

[SamuriHL]

No issues here. Those kinds of problems are either temporary network glitches or are DNS server related. I have a rotating DNS server configuration that will resolve when one DNS server is having issues. IOW, try another DNS server when you get that proboem.

[coopervid]

I had it again a few hours ago and now it works again. I don't think that it is a DNS issue but something on the server.

[DrinkLyeAndDie]

I had it again a few hours ago and now it works again. I don't think that it is a DNS issue but something on the server.

I've had what you describe happen a couple times a week. In the past it's always impacted both the FindVUK version check and updating the keydb.cfg but the other day it only impacted checking for an update for FindVUK while the keydb updated without issue. There's never a rhyme or reason that I can pinpoint. I just try again later and it usually works. I've always assumed it might be bad timing on my request and/or a DNS issue.

[coricopat]

I've seen the problem only once, but then it wasn't DNS but a HTTP 503.

You can easily check whether DNS is broken with tools like dig.

I'd rather guess the ISP (bplaced.net) might simply throttle accesses if there are too many and do so in a poor way (with 503)?

[coopervid]

I think coricopat is right. The site has most likely now many more visits from users of the Makemkv forum since a special thread has been established to add keys and update the databases of these users. Also SamuriHL's tool KeyDB_helper makes that very easy for these people.

[axymeus]

I have a couple discs that are absent from the VUK database. I followed the guide on the first page but can't get any results.

First I tried with Passkey, but FindVUK is unable to detect it, is it no longer supported? I did find the Disc ID in Passkey's log, but not the VUK. I searched through the memory dump of Passkey, but the tutorial didn't exactly specify what the VUK is supposed to look like... Judging by the database it looks like it needs 3 different hex strings? I maybe found one but that's it. And then I don't know how to add it to key database anyways.

So, I tried with regular DVDFab. The program starts and does nothing. I try to "add source" in the ripper menu of DVDFab and select my drive, and it does nothing. The source does not appear in DVDFab when selected. Do I need to make an ISO of the disc before it? The tutorial only says to insert a disc with DVDFab open, but FindVUK doesn't do anything by itself at that point.

Here's Passkey's report at least. FindVUK says "everything should work as expected" by the way.

Info for drive [D:\] (Passkey 9.4.7.7)
Vendor: ATAPI, Product: iHBS112 2
Revision: PL06, Vendor specific: 2012/09/17 10:50
Drive region: 2 (RPC II), changes left: 4(user) / 4(vendor)
AACS v1, AGIDs: 2, revocation level: MKBv76+
Support: BUS_ENCRYPTION=NO BN_GENERATION=NO

Disc media: Blu-ray (BDMV)

Region Code is removed. (Region B, Region Mask '')
AACS protection (AACSLA) is removed. (MKBv19)
BD+ protection (Macrovision) is removed. (gen7)
BluPath: full disc copy/play is supported.
Main playlist: 00801.mpls

[coopervid]

You are not supposed to start DVDFab but you run FindVUK to start it automatically.

Here is an alternate solution. Post the Makemkv files here in this thread:

https://forum.makemkv.com/forum/viewtopic.php?f=12&t=38293

[axymeus]

You are not supposed to start DVDFab but you run FindVUK to start it automatically.

Here is an alternate solution. Post the Makemkv files here in this thread:

https://forum.makemkv.com/forum/viewtopic.php?f=12&t=38293

I also did it in that order, FindVUK starts DVDFab by itself and that's it, nothing after that. I've been wondering, is it required to have an active DVDFab licence? I assumed perhaps wrongfully that it would work with the trial version.

I will check with MakeMKV thank you.

On a side note I've noticed that my old copy of AnyDVD can still work its magic on some of the BluRays I have. I find this surprising because naturally it can't check its database online and it's not a BluRay I ever read so the key isn't stored locally either. Furthermore, the key is not in the FindVUK database... Any way I can leverage that to add the key to the database perhaps?

[Bandits]

I also did it in that order, FindVUK starts DVDFab by itself and that's it, nothing after that. I've been wondering, is it required to have an active DVDFab licence? I assumed perhaps wrongfully that it would work with the trial version.

I will check with MakeMKV thank you.

On a side note I've noticed that my old copy of AnyDVD can still work its magic on some of the BluRays I have. I find this surprising because naturally it can't check its database online and it's not a BluRay I ever read so the key isn't stored locally either. Furthermore, the key is not in the FindVUK database... Any way I can leverage that to add the key to the database perhaps?

You can try the Generate Keys in my signature. Only good for Blu-Rays, but it can get you past v81 if you are using a LibreDrive unit.

[metalsonic88]

Having an odd issue using the Validate Disc feature with Mortal Kombat (2011). It works just fine when FindVUK is run as normal, but when I try to just validate it then after FindVUK seemingly successfully validates all 17 .m2ts files (though the log says 18 are detected?), it then throws an unknown error. Worth noting that I can play the blu-ray just fine using VLC. I can post full logs or additional details as needed, but here are some excerpts.

FindVUK no arguments run:

-------------------------------------------------------------------------------
16:14:03 - --- PART 2 --- VALIDATE VUK/UNITKEYS ---
-------------------------------------------------------------------------------
16:14:03 - Drive is detected as 'REAL BLURAY' drive
16:14:03 - M2TS files found >18<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00036.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00020.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00019.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00017.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00012.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00000.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00901.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00031.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00016.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00007.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00001.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00003.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00002.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00006.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00005.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00004.m2ts< with UnitKey >1<
16:14:03 - Decrypted first unit of file >F:\BDMV\STREAM\00014.m2ts< with UnitKey >1<

-------------------------------------------------------------------------------
16:14:03 - Validation successful! UnitKeys are valid!!
-------------------------------------------------------------------------------


FindVUK Validate Disc:

-------------------------------------------------------------------------------
16:14:59 - --- PART 2 --- VALIDATE VUK/UNITKEYS ---
-------------------------------------------------------------------------------
16:15:00 - Drive is detected as 'REAL BLURAY' drive
16:15:00 - M2TS files found >18<
16:15:00 - Decrypted first unit of file >F:\BDMV\STREAM\00036.m2ts< with UnitKey >1<
16:15:00 - Decrypted first unit of file >F:\BDMV\STREAM\00020.m2ts< with UnitKey >1<
16:15:00 - Decrypted first unit of file >F:\BDMV\STREAM\00019.m2ts< with UnitKey >1<
16:15:00 - Decrypted first unit of file >F:\BDMV\STREAM\00017.m2ts< with UnitKey >1<
16:15:00 - Decrypted first unit of file >F:\BDMV\STREAM\00012.m2ts< with UnitKey >1<
16:15:01 - Decrypted first unit of file >F:\BDMV\STREAM\00000.m2ts< with UnitKey >1<
16:15:01 - Decrypted first unit of file >F:\BDMV\STREAM\00901.m2ts< with UnitKey >1<
16:15:01 - Decrypted first unit of file >F:\BDMV\STREAM\00031.m2ts< with UnitKey >1<
16:15:01 - Decrypted first unit of file >F:\BDMV\STREAM\00016.m2ts< with UnitKey >1<
16:15:01 - Decrypted first unit of file >F:\BDMV\STREAM\00007.m2ts< with UnitKey >1<
16:15:01 - Decrypted first unit of file >F:\BDMV\STREAM\00001.m2ts< with UnitKey >1<
16:15:02 - Decrypted first unit of file >F:\BDMV\STREAM\00003.m2ts< with UnitKey >1<
16:15:02 - Decrypted first unit of file >F:\BDMV\STREAM\00002.m2ts< with UnitKey >1<
16:15:02 - Decrypted first unit of file >F:\BDMV\STREAM\00006.m2ts< with UnitKey >1<
16:15:02 - Decrypted first unit of file >F:\BDMV\STREAM\00005.m2ts< with UnitKey >1<
16:15:02 - Decrypted first unit of file >F:\BDMV\STREAM\00004.m2ts< with UnitKey >1<
16:15:02 - Decrypted first unit of file >F:\BDMV\STREAM\00014.m2ts< with UnitKey >1<
16:15:02 - ERROR! Validation of VUK failed >AACS UNKNOWN ERROR >0<<

Please press ENTER or ESC to exit


Edit: At some point this resolved itself. Whether it was an issue with my disc, my drive, or something in FindVUK that changed is unknown to me.

[Toad King]

For the past day running `FindVUK.exe synchronize` seems to download the entire KeyDB instead of an incremental update. Is this a known issue?

Running under Linux with Wine in case it makes a difference.

[MrPenguin]

For the past day running `FindVUK.exe synchronize` seems to download the entire KeyDB instead of an incremental update. Is this a known issue?

Running under Linux with Wine in case it makes a difference.
I'm noticing the same thing. I get the impression that the KEYDB file crossed some kind of threshold on Friday, and now FindVUK no longer tries to compute the delta.

[magician]

I'm noticing the same thing. I get the impression that the KEYDB file crossed some kind of threshold on Friday, and now FindVUK no longer tries to compute the delta.

It stopped working because FindVUK expects the timestamp in keydb_fvhash.ini to be in yyyy.MM.dd HH:mm:ss format for delta mode, but something (presumably a recent server-side change) caused it to start writing yyyyMMddTHHmmssZ instead. FindVUK probably passes through the timestamp on write, but the current release cannot parse the new format on read.

[MrPenguin]

It stopped working because FindVUK expects the timestamp in keydb_fvhash.ini to be in yyyy.MM.dd HH:mm:ss format for delta mode, but something (presumably a recent server-side change) caused it to start writing yyyyMMddTHHmmssZ instead.
Thanks, that works :).

[coopervid]

Thanks, that works :).

Can you elaborate how to fix this, please?

[MrPenguin]

Can you elaborate how to fix this, please?
Edit the keydb_fvhash.ini file, and reformat its timestamp field back to
yyyy.MM.dd HH:mm:ss
You'll obviously need to keep doing this until a permanent fix arrives.

[coopervid]

Edit the keydb_fvhash.ini file, and reformat its timestamp field back to
yyyy.MM.dd HH:mm:ss
You'll obviously need to keep doing this until a permanent fix arrives.

No such file in FindVUK for Windows.

[SamuriHL]

No such file in FindVUK for Windows.

Yes there is. It's in the aacs directory that FindVUK downloads and extracts the keydb.cfg to.

[coopervid]

Yes there is. It's in the aacs directory that FindVUK downloads and extracts the keydb.cfg to.

Thanks a lot, Sam! That was not trivial to look there. So hopefully nalor fixes that soon. Otherwise this has to be done manually if you want to avoid to download the whole keydb.cfg file.

[SamuriHL]

Not for me it doesn't. ;) I fix it automagically before I do the sync.

[SamuriHL]

Just run this powershell script before you run the findvuk sync.


# Script to convert keydb_fvhash.ini timestamp format
# From: yyyyMMDDTHHmmssZ (e.g., 20260303T161635Z)
# To: yyyy.MM.dd HH:mm:ss (e.g., 2026.03.03 16:16:35)

$filePath = "$env:APPDATA\aacs\keydb_fvhash.ini"

if (-not (Test-Path $filePath)) {
Write-Error "File not found: $filePath"
exit 1
}

# Read the file
$content = Get-Content $filePath -Raw

# Replace timestamps in yyyyMMDDTHHmmssZ format with yyyy.MM.dd HH:mm:ss format
$content = $content -replace '(\d{4})(\d{2})(\d{2})T(\d{2})(\d{2})(\d{2})Z', '$1.$2.$3 $4:$5:$6'

# Write back to file
Set-Content -Path $filePath -Value $content -NoNewline

Write-Host "Timestamp format updated successfully!"
Get-Content $filePath

[coopervid]

Just run this powershell script before you run the findvuk sync.


# Script to convert keydb_fvhash.ini timestamp format
# From: yyyyMMDDTHHmmssZ (e.g., 20260303T161635Z)
# To: yyyy.MM.dd HH:mm:ss (e.g., 2026.03.03 16:16:35)

$filePath = "$env:APPDATA\aacs\keydb_fvhash.ini"

if (-not (Test-Path $filePath)) {
Write-Error "File not found: $filePath"
exit 1
}

# Read the file
$content = Get-Content $filePath -Raw

# Replace timestamps in yyyyMMDDTHHmmssZ format with yyyy.MM.dd HH:mm:ss format
$content = $content -replace '(\d{4})(\d{2})(\d{2})T(\d{2})(\d{2})(\d{2})Z', '$1.$2.$3 $4:$5:$6'

# Write back to file
Set-Content -Path $filePath -Value $content -NoNewline

Write-Host "Timestamp format updated successfully!"
Get-Content $filePath


Nice workaround. Thank you!:thanks:

[nalor]

For the past day running `FindVUK.exe synchronize` seems to download the entire KeyDB instead of an incremental update. Is this a known issue?

Running under Linux with Wine in case it makes a difference.

I'm sorry - I've changed something and did not notice that this resulted in a problem for FindVUK as the change itself was by design non-breaking ... but in the end it revealed a bug in FindVUK that exists since 2020: when it tries to read the http header "FVDB_ChangeDate" it does not search for an exact header of this name but instead just for a header that begins with this name .. and I added a new header "FVDB_ChangeDate_ISO" that includes the changedate as ISO8601 with a UTC timestamp ...
Finally I changed the order of the headers: first the UTC and next the other one - because FindVUK takes the last matching header.
The next release will fix the header-bug correctly.
In the meantime the changed order on the server fixed the problem a few hours ago.

Another finding: my change also removed a feature where I thought nobody is using it: to specify a relative delta date like "-1day" - this is also fixed again.

[Xuqiwu]

First time user of this tool.

DVDFab Passkey v9.4.7.8 Not Working

DVDFab 13.0.5.7 Working

[nalor]

First time user of this tool.

DVDFab Passkey v9.4.7.8 Not Working

DVDFab 13.0.5.7 Working

Your're right - Passkey support stopped at 9.4.5.2 a long time ago - I've updated the first post to show this.

[KH]

Hi nalor, I'm trying to update the keydb entry for All Quiet on the Western Front (0x9B55936E76E564DDEB69A363FB2654AD67651C03) but no changes are reflected in the public keydb. I haven't recently encountered this issue with any other title.

Any thoughts?

[SamuriHL]

I have that disc and tried doing a validate on it several times and while it shows that it uploaded the entry, it does not seem to be updating it.

[nalor]

Hi nalor, I'm trying to update the keydb entry for All Quiet on the Western Front (0x9B55936E76E564DDEB69A363FB2654AD67651C03) but no changes are reflected in the public keydb. I haven't recently encountered this issue with any other title.

Any thoughts?

I'm checking what is happening here.

It got uploaded the first time in 2023 with a unitkey labelled as "invalid" and although better uploads happened in the meantime, no update has been performed ... strange.

[nalor]

I'm checking what is happening here.

It got uploaded the first time in 2023 with a unitkey labelled as "invalid" and although better uploads happened in the meantime, no update has been performed ... strange.

Found the problem - "optimized" the processing too much, need to change that. When I detect that the old entry is already "validated" everything else is skipped... and this makes it impossible to add additional data with a manual validation :(

[KH]

Found the problem - "optimized" the processing too much, need to change that. When I detect that the old entry is already "validated" everything else is skipped... and this makes it impossible to add additional data with a manual validation :(

Thanks for following up nalor. The record for 0x9B5593... is now complete after resubmitting, so that is great to see.

Are you able to tell from your end whether any other titles may have encountered a similar issue? The original failed submission attempt for the full record of 0x9B5593... was 30 December 2024, so it seems possible that other titles may have been affected.

[nalor]

Thanks for following up nalor. The record for 0x9B5593... is now complete after resubmitting, so that is great to see.

Are you able to tell from your end whether any other titles may have encountered a similar issue? The original failed submission attempt for the full record of 0x9B5593... was 30 December 2024, so it seems possible that other titles may have been affected.

Found 3 other entries with "invalid" unitkeys, 2 of them being UHDs.

First I want to improve my fix a little bit further - and once this is done I'll check those 3 entries also.

[magician]

@nalor: While you're here, I wonder if you can take a look at the logic in the workarounds for the latest versions of DVDFab. I have found that in FindVUK >= 1.79 and DVDFab >= 13.0.2.5, on discs with bus encryption, it will sometimes locate the RDK in the memory dump and decide that it is also the first decrypted UnitKey. Since it is not the real UnitKey, it will fail to validate the disc. I often have to retry FindVUK several times before it succeeds. In every case I have seen, the value that it kept finding in the failed runs did turn out to be the correct RDK for my drive/disc. It just didn't identify the correct UnitKey.

I sent you a logfile for a similar report in 2024 by PM but you did not respond.

[nalor]

@nalor: While you're here, I wonder if you can take a look at the logic in the workarounds for the latest versions of DVDFab. I have found that in FindVUK >= 1.79 and DVDFab >= 13.0.2.5, on discs with bus encryption, it will sometimes locate the RDK in the memory dump and decide that it is also the first decrypted UnitKey. Since it is not the real UnitKey, it will fail to validate the disc. I often have to retry FindVUK several times before it succeeds. In every case I have seen, the value that it kept finding in the failed runs did turn out to be the correct RDK for my drive/disc. It just didn't identify the correct UnitKey.

I sent you a logfile for a similar report in 2024 by PM but you did not respond.

I'm sorry for not responding :(

The problem is already fixed in 1.83 and I'll published it now.

This is a release with fixes/improvements I've implemented in the last 12 months, but never managed to create a release.

After the fix of the problem above I've created the 1.83 and it's available for about 2 weeks - but I missed to post anything (so only a few users did test it so far).

But afaik it's working fine - so making it public now :)

Generally I wanted to finish another feature and publish a 1.84, but it's still in the works: in case the online db is not available it's retried for 60 seconds and afterwards the file is saved and when findvuk is started the next time, the transmission is retried again.

[Xuqiwu]

Have you already taken down v1.83 since i'm getting "503 Service Unavailable" all the time.

[Xuqiwu]

Link is working now, thank you.

[magician]

I'm sorry for not responding :(

The problem is already fixed in 1.83 and I'll published it now.

This is a release with fixes/improvements I've implemented in the last 12 months, but never managed to create a release.

After the fix of the problem above I've created the 1.83 and it's available for about 2 weeks - but I missed to post anything (so only a few users did test it so far).

But afaik it's working fine - so making it public now :)

Generally I wanted to finish another feature and publish a 1.84, but it's still in the works: in case the online db is not available it's retried for 60 seconds and afterwards the file is saved and when findvuk is started the next time, the transmission is retried again.

Thank you! And thanks also for the new release, glad you already fixed a number of bugs.

[nalor]

Have you already taken down v1.83 since i'm getting "503 Service Unavailable" all the time.

I don't think this is related to the new release ... the 503 problem is due to the load on the website in combination the free offer I'm using.

So usually it takes a few seconds/minutes and it's working again (in the kodi plugin I've released recently it retries every 10 seconds until it's succesful again).

[lamp]

I was able to capture the download for 1.83 in the internet archive in case anyone runs into issues in the future, just throw the download URL into the wayback machine

[coricopat]

@Nalor, maybe overkill, but the following might help with the site load:

- (you) generate a OpenPGP key and publish the public one as yours here
- then e.g. daily, or perhaps every few hours, sign the full keydb.cfg and XML archive ZIPs with your private key
- upload the ZIPs and their signatures to some file hoster which you can use anonymously (and script)
- continue to provide the full ZIPs at least for a while on the current website, remove that later should people still download manually from there)
- provide a txt file on that website (perhaps also signed) which names the current download place
- let tools merely download the link, get the files from there and let them verify the sigs with your public key

So people who do full downloads can do it from there, and not put load on the main site (which eventually, if necessary, might even be changed to delta only - and of course uploads).
You might even sign the FindVUK program package that way and move downloads somewhere else.

[MrPenguin]

The problem is already fixed in 1.83 and I'll published it now.

I've started seeing delta mode failing with FindVUK 1.83:

2026-03-30 12:05:25 # 373381 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / INFO! DeltaFile requested, but got full file - disable delta mode
2026-03-30 12:05:25 # 373383 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Uncompress downloaded OnlineDB file ####

So I'm requesting the delta file, but sometimes getting the full file instead. Is anyone else seeing this?

[Xuqiwu]

For me the DeltaMode is working as expected with v1.83

[magician]

So I'm requesting the delta file, but sometimes getting the full file instead. Is anyone else seeing this?

I get frequent 503s when trying to access the site, so it may have been overloaded and/or not responding correctly.

Amusingly, I saw this in my log while running a delta sync (notice the progress percentage is wildly off due to the denominator being a lot less than what was supposedly fetched).
11:49:15 - Downloading OnlineDB - Progress: 56.51% - 16.46KB/29.12KB - Speed 33.64 KB/s
11:49:15 - Downloading OnlineDB - Progress: 173.50% - 50.53KB/29.12KB - Speed 69.50 KB/s
11:49:16 - Finished download of OnlineDB - received 62.35KB in 1,504 seconds

[magician]

A few bug reports I've been meaning to submit about ValidateDisc mode (ordered from most to least certain, as in how certain I am that you can reproduce it):
- It complains that MK+VID != VUK when VUK is empty, even though it's correctly computed and not actually cleared.
- If |UK|>1, it refuses to compute VUK from MK+VID (AACS unknown error).
- When configured not to exit after processing, it locks the keydb.cfg files. During subsequent validations in the same process, it may complain that files do not exist even though internally it is still holding onto the contents in memory and does not try to output an empty file. It also does not seem to work correctly (e.g. "Something went wrong enriching data!", does not update keydb_fvhash.ini, etc.).

[coopervid]

I've started seeing delta mode failing with FindVUK 1.83:

2026-03-30 12:05:25 # 373381 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / INFO! DeltaFile requested, but got full file - disable delta mode
2026-03-30 12:05:25 # 373383 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Uncompress downloaded OnlineDB file ####

So I'm requesting the delta file, but sometimes getting the full file instead. Is anyone else seeing this?

I have the same issue. Synchronize just loads the full file.

[MrPenguin]

I have the same issue. Synchronize just loads the full file.
But not every time either! It currently appears to be random whether I receive the delta or not :confused:.

[coopervid]

But not every time either! It currently appears to be random whether I receive the delta or not :confused:.
Yap. Same here. Last run had 28 new entries and the one after that loads again the full database.

[metalsonic88]

This might be a stupid question, but historically I haven't paid much attention to the output/logs that are generated by FindVUK unless there is an issue. But lately I have been watching them a bit closer and I've noticed that every now and then a disc is coming up with no VUK, MEDIAKEY, or VOLUMEID, but no errors or warnings or anything happen and the verification continues as normal. Is that how things should work? Do some discs simply lack this information, or is something wrong here?

An example:

-----------------------------------------------------------
22:53:30 - ----------- FindVUK 1.83 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
22:53:30 - SettingsFile: >C:\{redacted}\FindVUK\config\FindVUK.ini<
22:53:30 - Logfile >C:\{redacted}\FindVUK\log\2026-03-31_FindVUK.txt< Default Loglevel >2<
22:53:30 - Update enabled - check for update
22:53:31 - No update required
22:53:31 - Open Main-KEYDB file: >C:\ProgramData\aacs\KEYDB.cfg<
22:53:33 - Open Backup-KEYDB file: >C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg<
22:53:33 - DVDfab Version >12.1.1.5< found
22:53:33 - >>> everything should work as expected!

22:53:33 - Preferred application >PassKey< is not available
22:53:33 - DVDfab is available!
22:53:33 - DVDfab-MainFile: >C:\Program Files\DVDFab\DVDFab 12\DVDFab64.exe<
22:53:33 - DVDfab-LogFile: >C:\Users\{redacted}\Documents\DVDFab\DVDFab12\Log\dvdfab_internal.log<
22:53:33 - KEYDB-Path: >C:\ProgramData\aacs\<
22:53:33 - KEYDB-Backup-Path: >C:\{redacted}\FindVUK\VUKbackup\<
22:53:33 - ProcDumpFile: >C:\{redacted}\FindVUK\tool\procdump64.exe<

###############################################################################
22:53:33 - --- PART 1 --- GET DUMP ---
-------------------------------------------------------------------------------

22:53:33 - No running application process discovered
22:53:33 - >> Start it now >C:\Program Files\DVDFab\DVDFab 12\DVDFab64.exe<

22:54:17 - Drive opened
22:54:17 - Volume Label detected >DEAR BROTHER DISC 2<
22:54:19 - DriveLetter detected >F<
22:54:19 - Detected CopyProtections AACS >1< BD+ >0<
22:54:19 - DiscID found >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:22 - MainPlaylist found >00000.mpls<
22:54:22 - DVDFab64 got Unit Keys - create memdump now!
22:54:23 - Dump successful! >1<
22:54:23 - MemDump successfully finished!
22:54:23 - Cancel DVDfab decryption now!
-------------------------------------------------------------------------------
22:54:23 - Get basic AACS data
-------------------------------------------------------------------------------
22:54:23 - AACS folder >F:\AACS< on disc is reachable - Validate is possible
22:54:24 - VolumeName >DEAR BROTHER DISC 2<
22:54:24 - VolumeSize >46881177600<
22:54:24 - DiscId >AD0274C51352D03668DC41A25200106720EB50F4< (2021-03-07)
22:54:24 - DiscType >BD<
22:54:24 - MKB Revision >70<
22:54:24 - Disc-BusEncEnabled >0<
22:54:24 - Drve-BusEncCapable >1<
22:54:24 - UnitKeyCount >1<
22:54:24 - >>> UnitKeyENC (1) >5E8EEDE3CBA99D3B80533E75D3FD51F0<
-------------------------------------------------------------------------------
22:54:24 - Analyze dump
-------------------------------------------------------------------------------
22:54:24 - Start to analyze '2018' MemDump now!
..-...............................-
22:54:25 - DiscID >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:25 - UnitKeyCount >1<
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413<
-------------------------------------------------------------------------------
22:54:25 - --- PART 2 --- VALIDATE VUK/UNITKEYS ---
-------------------------------------------------------------------------------
22:54:25 - Drive is detected as 'REAL BLURAY' drive
22:54:25 - M2TS files found >19<
22:54:25 - Decrypted first unit of file >F:\BDMV\STREAM\00016.m2ts< with UnitKey >1<
22:54:25 - All UnitKeys are VALID! No need to test other files

-------------------------------------------------------------------------------
22:54:25 - Validation successful! UnitKeys are valid!!
-------------------------------------------------------------------------------

22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details
22:54:25 - -------------------------------------------------------
22:54:25 - MetaTitle : Dear Brother Disc 2
22:54:25 - VolumeName : DEAR BROTHER DISC 2
22:54:25 - DiscID : AD0274C51352D03668DC41A25200106720EB50F4
22:54:25 - DateDiscID : 2021-03-07
22:54:25 - DiscType : BD
22:54:25 - VUK :
22:54:25 - MEDIAKEY :
22:54:25 - VOLUMEID :
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413< (Valid)
22:54:25 - MKBrev : 70
22:54:25 - BusEncrEn : 0
22:54:25 - AACS : 1
22:54:25 - BD+ : 0
22:54:25 - MainPlaylist: 00000.mpls
22:54:25 - -------------------------------------------------------


-------------------------------------------------------------------------------
22:54:25 - --- Write entry in main-keydb file ---
-------------------------------------------------------------------------------

22:54:25 - Keys in Keyfile: 179944 keys - KeyFile: C:\ProgramData\aacs\KEYDB.cfg
22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details

22:54:25 - KEYDB: Identical entry already present in keydb-file
22:54:25 - >> Identical: TITLE, VUK, DATE, MEDIAKEY, VOLUMEID, UNITKEYS, COMMENT - Different: nothing >> will NOT write new entry in keydb-file

22:54:25 - Identical entry already present in keydb-file - file is not changed


-------------------------------------------------------
22:54:25 - --- Write entry in backup-keydb file ---
-------------------------------------------------------

22:54:25 - Keys in Keyfile: 469 keys - KeyFile: C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg
22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details

22:54:25 - KEYDB: Identical entry already present in keydb-file
22:54:25 - >> Identical: TITLE, VUK, DATE, MEDIAKEY, VOLUMEID, UNITKEYS, COMMENT - Different: nothing >> will NOT write new entry in keydb-file

22:54:25 - Identical entry already present in keydb-file - file is not changed


-------------------------------------------------------
22:54:25 - --- Write entry in main-bluraydb file ---
-------------------------------------------------------

22:54:25 - Entries in DB-File: 303 entries - DB-File: C:\Users\{redacted}\AppData\Roaming\bluray\bluraydb.cfg

22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already >1< times in the bluraydb-file
22:54:25 - -------------------------------------------------------
22:54:25 - BLURAYDB: Identical entry already present in bluraydb-file (line 302)

22:54:25 - Identical entry already present in bluraydb-file - file is not changed

22:54:25 - -------------------------------------------------------
22:54:25 - --- Upload MetaXML to OnlineDB file ---
22:54:25 - -------------------------------------------------------
Establishing connection
Establishing connection
HTTP-POST success
22:54:26 - Successfully posted to the OnlineDB! >
Preconditions fulfilled - process upload now
Detected BlurayMetaXML - DiscId >AD0274C51352D03668DC41A25200106720EB50F4<
Upload written to database!
Meta-Upload successfully processed!
<
22:54:26 - Successful upload to OnlineDB
22:54:26 - Eject the disc now from drive >F:\<

22:54:30 - Successfully ejected the media in drive F!

[MrPenguin]

Yap. Same here. Last run had 28 new entries and the one after that loads again the full database.
This isn't an "April 1st" joke, but it looks like there a "Content-Length" HTTP header missing:

2026-04-01 15:06:11 # 8743 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / Hash identical - DeltaMode enabled with date >20260401t135309<
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Download from OnlineDB ####
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / DownloadFile / Establishing connection
2026-04-01 15:06:11 # 9247 # [W] FindVUK_Main / DownloadFile / ContentSize unknown >-1802< (#HTTPA_ERR_HEADERNOTFOUND)
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading - Filename >KeyDbDelta.cfg< Filesize >-1802< Filedate >2026.04.01 15:38:50<
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 34.54 KB/s
2026-04-01 15:06:12 # 9751 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:12 # 10253 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 37.54 KB/s
2026-04-01 15:06:13 # 10757 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:13 # 11261 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 35.60 KB/s
2026-04-01 15:06:14 # 11763 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:14 # 12266 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 36.41 KB/s
2026-04-01 15:06:15 # 12769 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:15 # 13271 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5048.% - 88.84KB/-1802 B - Speed 36.92 KB/s
2026-04-01 15:06:16 # 13773 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 25.92 KB/s
2026-04-01 15:06:16 # 14275 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:17 # 14778 # [I] FindVUK_Main / DownloadFile / Received a HTTP 200 - save response now
2026-04-01 15:06:17 # 14781 # [I] FindVUK_Main / DownloadFile / Finished download of OnlineDB - received 101.55KB in 6,033 seconds

[lamp]

This might be a stupid question, but historically I haven't paid much attention to the output/logs that are generated by FindVUK unless there is an issue. But lately I have been watching them a bit closer and I've noticed that every now and then a disc is coming up with no VUK, MEDIAKEY, or VOLUMEID, but no errors or warnings or anything happen and the verification continues as normal. Is that how things should work? Do some discs simply lack this information, or is something wrong here?

An example:

-------------------------------------------------------------------------------
22:54:23 - Get basic AACS data
-------------------------------------------------------------------------------
22:54:23 - AACS folder >F:\AACS< on disc is reachable - Validate is possible
22:54:24 - VolumeName >DEAR BROTHER DISC 2<
22:54:24 - VolumeSize >46881177600<
22:54:24 - DiscId >AD0274C51352D03668DC41A25200106720EB50F4< (2021-03-07)
22:54:24 - DiscType >BD<
22:54:24 - MKB Revision >70<
22:54:24 - Disc-BusEncEnabled >0<
22:54:24 - Drve-BusEncCapable >1<
22:54:24 - UnitKeyCount >1<
22:54:24 - >>> UnitKeyENC (1) >5E8EEDE3CBA99D3B80533E75D3FD51F0<
-------------------------------------------------------------------------------
22:54:24 - Analyze dump
-------------------------------------------------------------------------------
22:54:24 - Start to analyze '2018' MemDump now!
..-...............................-
22:54:25 - DiscID >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:25 - UnitKeyCount >1<
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413<


My understanding is that DVDFab only loads the Unit Keys into memory so the memdump is only able to extract that. This is technically all that would be needed to be decrypt a disc (as most of the other keys are used to end up derive/decrypt the unit keys), however some software (such as MakeMKV) may also want the VUK. Unfortuantely with the just the Unit Keys I don't think there is a way to work backwards to get any of the other keys. Since this is technically all that is needed for libaacs I don't think there are any issues here.

If you have a drive that has not seen a MKBv82 disc then you can use Device keys and Host Certificates from other threads and use .\FindVUK.exe aacskeys=<drive> in order to have it actually calculate the keys and it will populate everything, however if you have ever put a MKBv82 disc in then we don't have a valid host certificate so you would need to do extra steps to try and calculate everything. The logs will tell you if it has been revoked already. This method does not work on AACS 2.0 discs (4k UHD Blu-Rays).

[nalor]

This isn't an "April 1st" joke, but it looks like there a "Content-Length" HTTP header missing:

2026-04-01 15:06:11 # 8743 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / Hash identical - DeltaMode enabled with date >20260401t135309<
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Download from OnlineDB ####
2026-04-01 15:06:11 # 8745 # [I] FindVUK_Main / DownloadFile / Establishing connection
2026-04-01 15:06:11 # 9247 # [W] FindVUK_Main / DownloadFile / ContentSize unknown >-1802< (#HTTPA_ERR_HEADERNOTFOUND)
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading - Filename >KeyDbDelta.cfg< Filesize >-1802< Filedate >2026.04.01 15:38:50<
2026-04-01 15:06:11 # 9247 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 34.54 KB/s
2026-04-01 15:06:12 # 9751 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -962.1% - 16.93KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:12 # 10253 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 37.54 KB/s
2026-04-01 15:06:13 # 10757 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2007.% - 35.34KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:13 # 11261 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 35.60 KB/s
2026-04-01 15:06:14 # 11763 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3003.% - 52.86KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:14 # 12266 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 36.41 KB/s
2026-04-01 15:06:15 # 12769 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4020.% - 70.75KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:15 # 13271 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5048.% - 88.84KB/-1802 B - Speed 36.92 KB/s
2026-04-01 15:06:16 # 13773 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 25.92 KB/s
2026-04-01 15:06:16 # 14275 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5770.% - 101.55KB/-1802 B - Speed 0.00 Byte/s
2026-04-01 15:06:17 # 14778 # [I] FindVUK_Main / DownloadFile / Received a HTTP 200 - save response now
2026-04-01 15:06:17 # 14781 # [I] FindVUK_Main / DownloadFile / Finished download of OnlineDB - received 101.55KB in 6,033 seconds



Hmm - maybe I've damaged something ... either in 1.83 or on the website .. .I'm currently adding php7 type declarations to the code and sometimes I get strange results :D

Give me a minute, I'll check on my side.

[nalor]

What I can say so far: the Content Length header is missing because the server uses chunked transfer. The progress display in FindVUK needs this header, so the progress is way off.
But in general it should download the correct file and also sync properly ...

Will fix it tomorrow .. sorry :(

[MrPenguin]

What I can say so far: the Content Length header is missing because the server uses chunked transfer. The progress display in FindVUK needs this header, so the progress is way off.
But in general it should download the correct file and also sync properly ...

Will fix it tomorrow .. sorry :(
OK, that makes sense, thanks. Can you also see why a "delta mode" request is sometimes receiving the full file please?

[nalor]

OK, that makes sense, thanks. Can you also see why a "delta mode" request is sometimes receiving the full file please?

I'm trying to fix all bugs recently introduced :( Not sure if it was a good idea to add the type declarations .. but I thought it might be a good idea to modernize the code a little bit ...

[SamuriHL]

I'm trying to fix all bugs recently introduced :( Not sure if it was a good idea to add the type declarations .. but I thought it might be a good idea to modernize the code a little bit ...

The curse of every developer, sadly. No good dead goes unpunished. :D

[coopervid]

The curse of every developer, sadly. No good dead goes unpunished. :D

Deed you mean. You can't punish deads.:sly:

[SamuriHL]

Deed you mean. You can't punish deads.:sly:

You never know :D

[nalor]

"Progress" Bug is fixed, finally understood why it's happening (although I don't understand why the behaviour changed):

I didn't compress the delta-files but always delivered them as play .cfg file

=> in this case Apache performs an on-the-fly compression and as it does not know the final number of bytes to transfer, the whole transfer is done as "chunked" transfer and no content-length is available to the client receiving the data.

So I've changed this to compress the file always into a zip file and so the content-length is present again :)
(And FindVUK knows how to uncompress and use the file)


Now I'm checking the next problem: the frequent full-download.

This is something that I have somehow introduced with my changes for the KODI plugin... the requested timestamp is detected as being in the future and in this case the full-file is delivered as no delta is possible.

Hve to check why this is happening.

[nalor]

"Full" instead of "Delta" problem should be fixed too .. I defined the wrong timezone in the settings and as result the comparison of delta-time and "now" was 1h off since the switch to summertime in central europe ... now the timezone matches the regional one and the result looks good in my tests :)
(and fixed another problem introduced with the type declarations ... )

[SamuriHL]

Nice that should make things more stable.

[metalsonic88]

If you have a drive that has not seen a MKBv82 disc then you can use Device keys and Host Certificates from other threads and use .\FindVUK.exe aacskeys=<drive> in order to have it actually calculate the keys and it will populate everything, however if you have ever put a MKBv82 disc in then we don't have a valid host certificate so you would need to do extra steps to try and calculate everything. The logs will tell you if it has been revoked already. This method does not work on AACS 2.0 discs (4k UHD Blu-Rays).


I'm near certain that my drive has seen an MKBv82 disc and thus this method will not work, but FindVUK sure isn't interested in telling me anything either way.

This is the output from the same disc as earlier:

-----------------------------------------------------------
20:31:05 - ----------- FindVUK 1.83 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
20:31:05 - MODE: AACSkeys

20:31:05 - DriveLetter : F

20:31:05 - SettingsFile: >C:\{redacted}\FindVUK\config\FindVUK.ini<
20:31:05 - Logfile >C:\{redacted}\FindVUK\log\2026-04-03_FindVUK.txt< Default Loglevel >2<
20:31:05 - Update enabled - check for update
20:31:06 - Update check failed >#UPD_ERR_READFILE<
20:31:06 - Open Main-KEYDB file: >C:\ProgramData\aacs\KEYDB.cfg<
20:31:08 - Open Backup-KEYDB file: >C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg<
20:31:08 - Driveletter for AACSkeys set to >F<

###############################################################################
20:31:08 - --- PART 1 --- GET AACSKEYS DATA ---
-------------------------------------------------------------------------------


And that's it. It crashes or something when it reaches Part 1 without any further message or error. I can't imagine this is intended behavior.

[lamp]

And that's it. It crashes or something when it reaches Part 1 without any further message or error. I can't imagine this is intended behavior.

That looks like the behavior when you have a 4k disc in, which uses AACS 2.0, the aacskeys program is kind of old so it seems to break on that. Usually for normal blu-rays I see it printing the host certificate and saying that it was revoked on this drive or something similar. Just to confirm, is that a normal blu-ray? or a UHD one?

[MrPenguin]

"Progress" Bug is fixed, finally understood why it's happening (although I don't understand why the behaviour changed):

Hmm, this download progress is still broken:

...
2026-04-04 16:11:16 # 8663 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / Hash identical - DeltaMode enabled with date >20260404t112124<
2026-04-04 16:11:16 # 8664 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Download from OnlineDB ####
2026-04-04 16:11:16 # 8665 # [I] FindVUK_Main / DownloadFile / Establishing connection
2026-04-04 16:11:16 # 9166 # [W] FindVUK_Main / DownloadFile / ContentSize unknown >-1802< (#HTTPA_ERR_HEADERNOTFOUND)
2026-04-04 16:11:16 # 9167 # [I] FindVUK_Main / DownloadFile / Downloading - Filename >KeyDbDelta.zip< Filesize >-1802< Filedate >2026.04.04 16:48:27<
2026-04-04 16:11:16 # 9167 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -449.0% - 7.90KB/-1802 B - Speed 16.15 KB/s
2026-04-04 16:11:17 # 9669 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -449.0% - 7.90KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:17 # 10171 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -898.2% - 15.81KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:18 # 10674 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -898.2% - 15.81KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:18 # 11176 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -1347.% - 23.71KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:19 # 11678 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -1347.% - 23.71KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:19 # 12180 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -1796.% - 31.62KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:20 # 12682 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2245.% - 39.52KB/-1802 B - Speed 16.12 KB/s
2026-04-04 16:11:20 # 13185 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2245.% - 39.52KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:21 # 13687 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2245.% - 39.52KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:21 # 14190 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -2695.% - 47.43KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:22 # 14693 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3144.% - 55.33KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:22 # 15197 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3144.% - 55.33KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:23 # 15700 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3593.% - 63.24KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:23 # 16203 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -3593.% - 63.24KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:24 # 16705 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4042.% - 71.14KB/-1802 B - Speed 16.12 KB/s
2026-04-04 16:11:24 # 17208 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4042.% - 71.14KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:25 # 17711 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4523.% - 79.60KB/-1802 B - Speed 17.21 KB/s
2026-04-04 16:11:25 # 18213 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4523.% - 79.60KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:26 # 18716 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4972.% - 87.50KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:26 # 19217 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -4972.% - 87.50KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:27 # 19720 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5421.% - 95.41KB/-1802 B - Speed 16.13 KB/s
2026-04-04 16:11:27 # 20223 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5421.% - 95.41KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:28 # 20726 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5870.% - 103.32KB/-1802 B - Speed 16.10 KB/s
2026-04-04 16:11:28 # 21228 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -5870.% - 103.32KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:29 # 21730 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6346.% - 111.68KB/-1802 B - Speed 17.06 KB/s
2026-04-04 16:11:29 # 22233 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6346.% - 111.68KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:30 # 22734 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6722.% - 118.30KB/-1802 B - Speed 13.54 KB/s
2026-04-04 16:11:30 # 23237 # [I] FindVUK_Main / DownloadFile / Downloading OnlineDB - Progress: -6722.% - 118.30KB/-1802 B - Speed 0.00 Byte/s
2026-04-04 16:11:31 # 23739 # [I] FindVUK_Main / DownloadFile / Received a HTTP 200 - save response now
2026-04-04 16:11:31 # 23742 # [I] FindVUK_Main / DownloadFile / Finished download of OnlineDB - received 118.30KB in 15,074 seconds
2026-04-04 16:11:31 # 23743 # [I] FindVUK_Main / DownloadFile / Return result >1<
2026-04-04 16:11:31 # 23744 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Uncompress downloaded OnlineDB file ####
2026-04-04 16:11:31 # 23756 # [I] FindVUK_Main / FVMAIN_Mode_Synchronize / #### Open downloaded OnlineDB file ####
...

[metalsonic88]

Just to confirm, is that a normal blu-ray? or a UHD one?

It is a normal blu ray.

[nalor]

Hmm, this download progress is still broken:


You're right - I'll create a support ticket for the provider because I have no further ideas, whatever I try to disable the Apache compression is ignored :(

[nalor]

For information: I've upgraded the account and hopefully it's more stable now (at least for the next 12 months :D ).

But this also introduces an automatic redirect from http to https ... hopefully this does not introduce another level of problems ....

[magician]

For information: I've upgraded the account and hopefully it's more stable now (at least for the next 12 months :D ).

But this also introduces an automatic redirect from http to https ... hopefully this does not introduce another level of problems ....

Website is lightning fast now. Plus no more HTTPS confusion. Thank you!

[nalor]

I noticed my KODI plugin stopped working and after some hours of digging I noticed it's a bug in PHP 8.5:
https://github.com/php/php-src/issues/21018

I wasn't aware of this "replace" feature at all - but setting it to "false" helps.

(and I've learned that underscores in headers are against the rules...)

And I disabled the redirection from HTTP to HTTPS .. so HTTPS is working, but requires to adjust the urls.

[metalsonic88]

Any chance you have done or could do a bit of digging into my aacskeys issue from earlier? Like I said, I'm reasonably confident that this method won't actually work for getting keys in my case, but a bit of output actually saying what went wrong would clarify that.

[nalor]

Any chance you have done or could do a bit of digging into my aacskeys issue from earlier? Like I said, I'm reasonably confident that this method won't actually work for getting keys in my case, but a bit of output actually saying what went wrong would clarify that.

It only crashes? And no helpful details in the logfile?
You can try to add this to your config file:


[LogLevel]
Default=4


This logs on "trace" level, so "maybe" I've added more logoutput in the past the can help here :)

Please send me your logfile to check what's really going - thanks!

[magician]

It only crashes? And no helpful details in the logfile?

aacskeys 0.4.0f and earlier will simply hang when it encounters a UHD in the drive. I don't believe it crashes per se.

Maybe an option can be added so that in the AACSkeys mode, FindVUK will by default first check whether the disc in the drive is a UHD and if so, it emits an error or warning before delegating to the aacskeys binary. (But this will slow down the program for regular usage so that's why I'd want it to be configurable if you already know it won't work for UHD.)

Some time ago, in the Xreveal support page, a user reported that aacskeys has been privately updated to work correctly with AACS 2.x, but they didn't believe the code would be released publicly. Ultimately it may be useless unless you have access to a AACS2 HC and DK/PK.

[metalsonic88]

I think that actually I've been barking up the wrong tree. For starters, apparently the aacskey command fails on every disc I try to use. And in fact, it seems to actually be due to an issue with handling paths. I suspect that there are 2 bugs here:

1. I think the code handling the file path doesn't like spaces in it. Below is a small excerpt from my log right before the crash.


2026-04-25 23:07:57 # 3114 # [E] bluray_keydb / BRKDB_GetProcessingKeys / ERROR! File >c:\users\{user name with a space in it}\appdata\roaming\aacs\keydb.cfg< has never been opened!
2026-04-25 23:07:57 # 3114 # [E] bluray_aacskeys / BRAKEYS_CreateProcDevFile / Couldn't read ProcessingKeys from keydb.cfg file >#BRKDB_ERR_NOTOPEN<


That file certainly does exist at this location and has been opened. However...

2. The path used here does not respect what is assigned as the Main_Path for FindVUK. I have it set to use %ProgramData%\aacs and indeed, earlier in the log you can see it using this value


2026-04-26 02:45:17 # 665 # [I] FindVUK_Main / / Open Main-KEYDB file: >C:\ProgramData\aacs\KEYDB.cfg<
2026-04-26 02:45:17 # 666 # [I] bluray_keydb / _OpenFile_CFG / KeyDB file >c:\programdata\aacs\keydb.cfg< opened!


But obviously, as you can see above, it is instead trying to open the file at the default location associated with my user. The files at the user location are untouched from several years ago that I simply forgot to delete when I changed that setting. While the files do exist and aacskey should be able to use them, it's not the place where I want the files to live and I will be deleting them soon.

---

Anyways, I think that may solve some mysteries about this particular aspect of the program. But if I'm wrong and you want a full log file, let me know and I'll post it.

[magician]

aacskeys 0.4.0f and earlier will simply hang when it encounters a UHD in the drive. I don't believe it crashes per se.

Just to clarify my post was about a separate issue. Didn't mean to hijack the discussion. metalsonic88 was working with a regular BD.

[Warbington]

Just wanted to mention that the latest DVDfab release 13.0.6.0 (supports Pioneer drives) is NOT compatible with FindVUK.

[Toad King]

A small bug: If you add a disc using the aacskeys command any future sync has to do a full sync again instead of an update one. With the new server update the actual sync only takes a second or two but I figure I'd report it still.

Attached logs of the aacskeys command and subsequent sync one.

EDIT: The issue also seems to appear if you validate a disc and convert it from a legacy entry so maybe it's just something that happens whenever the local KEYDB file is updated? Attached that log as well.

[ZA0kFF4mIG0oC1]

Just wanted to mention that the latest DVDfab release 13.0.6.0 (supports Pioneer drives) is NOT compatible with FindVUK.

Tested 13.0.6.2 today and FindVUK works OK.

[Toad King]

Another small bug I noticed: The count of added/changed entries when you do a sync seems to be double what it should be.

23:28:14 - Finished download of OnlineDB - received 1.56KB in 0,500 seconds
23:28:14 - #### Uncompress downloaded OnlineDB file ####
23:28:14 - #### Open downloaded OnlineDB file ####
23:28:14 - #### Synchronize local and online file ####
23:28:14 - Title - LocalKeyFile >185459< keys - OnlineKeyFile >8< keys
23:28:14 - LocalKeyFile: add >7< new/changed Title entries
23:28:14 - Different Title entry >C3C80F1BB3C0A322A17232FCA6CEBFFCAD7B7964< - sync changes to LOCAL file
23:28:14 - Title entry missing in LOCAL file >48FEB386572B8BA539730E1A9335B460B4E5B72E<
23:28:14 - Title entry missing in LOCAL file >D8E7AA72B5AFECA663E6F6B2620E2D15F70A6FAD<
23:28:14 - Title entry missing in LOCAL file >EA370B144A125507515DC1DDAD38C8184CAA4359<
23:28:14 - Different Title entry >6448FC59F21EDB7CED2ADAB3546BEE75ADE528F1< - sync changes to LOCAL file
23:28:14 - Different Title entry >F18389D09FD38F0D4D03AF68F950618A9F643422< - sync changes to LOCAL file
23:28:14 - Different Title entry >210F3EC3D4C10FDFF00F82B7E61F96426D265F88< - sync changes to LOCAL file
23:28:14 - DeviceKey - LocalKeyFile >28< keys - OnlineKeyFile >0< keys
23:28:14 - LocalKeyFile: add >0< new/changed DeviceKey entries
23:28:14 - HostCertificate - LocalKeyFile >5< keys - OnlineKeyFile >0< keys
23:28:14 - LocalKeyFile: add >0< new/changed HostCertificate entries
23:28:14 - ProcessingKey - LocalKeyFile >3< keys - OnlineKeyFile >0< keys
23:28:14 - LocalKeyFile: add >0< new/changed ProcessingKey entries
23:28:15 - LOCAL-Keyfile:
Title 6 new entries, 8 changed entries
DeviceKey 0 new entries, 0 changed entries
HostCertificate 0 new entries, 0 changed entries
ProcessingKey 0 new entries, 0 changed entries
23:28:15 - DeltaSync done

This lists 6 new entries and 8 changed entries, but the list of changes only show 3 new entries and 4 changed entries.

[nalor]

Another small bug I noticed: The count of added/changed entries when you do a sync seems to be double what it should be.

This lists 6 new entries and 8 changed entries, but the list of changes only show 3 new entries and 4 changed entries.

Will check soon - really strange, I guess it's incorrect since a long time :D

[nalor]

Another small bug I noticed: The count of added/changed entries when you do a sync seems to be double what it should be.


Fixed in next release - introduced the bug in october 2021 with release 1.50

After comparison of local and online file the numbers are calculated to show an information of the details of the upcoming changes ... and while performing the actual changes it's counted again :(
During the enhancement of the sync with the other types (before release 1.50 only titles where synchronized) I somehow removed the reset of the numbers in between - so they end up exactly doubled ..

[Toad King]

Fixed in next release - introduced the bug in october 2021 with release 1.50

After comparison of local and online file the numbers are calculated to show an information of the details of the upcoming changes ... and while performing the actual changes it's counted again :(
During the enhancement of the sync with the other types (before release 1.50 only titles where synchronized) I somehow removed the reset of the numbers in between - so they end up exactly doubled ..

Good to hear.

In case you missed it, were you able to look at this other bug I found? I think this one is a more recent issue because I don't remember it happening in 1.81 or 1.82 - https://forum.doom9.org/showthread.php?p=2031173#post2031173

[nalor]

Good to hear.

In case you missed it, were you able to look at this other bug I found? I think this one is a more recent issue because I don't remember it happening in 1.81 or 1.82 - https://forum.doom9.org/showthread.php?p=2031173#post2031173

:goodpost:

Thanks for the reminder! Will check immediately!

[nalor]

A small bug: If you add a disc using the aacskeys command any future sync has to do a full sync again instead of an update one. With the new server update the actual sync only takes a second or two but I figure I'd report it still.

Attached logs of the aacskeys command and subsequent sync one.

EDIT: The issue also seems to appear if you validate a disc and convert it from a legacy entry so maybe it's just something that happens whenever the local KEYDB file is updated? Attached that log as well.

Fixed and I think you're right, it's something I introduced in 1.83

[nalor]

I've just published FindVUK 2.03

It's now an x64 executable :)

In addition to a few fixes there's also a new feature that I started to implement before I've decided to pay for the higher tier at the provider:

a "retry" feature for failed uploads to the database


In general it's working in 2 steps:

when the upload fails with HTTP503 there are up to 6 retries with 10sec pause in between
different errors or still failing after the 6 retries results in a "retry" file being written


On each startup it's checked if there are retry files and if so, the upload is retried. Note that the files have a hash and a signature and no upload is performed if a manipulation is detected. Also each upload has a random uuid and so each file can only be uploaded once.

I think the upload in general is currently stable and the retries are of no use at the moment - but I think the feature can also be used for a different purpose - for a general 2 step process:

validate discs on a computer without any internet access
move to location with a public internet and perform the "retry" upload


I know from various messages received through the years that there are locations in the world where the users are quite nervous when using the tool ... so maybe this feature can be used to make the process less critical for them.

Another small feature: it's now possible to enable a "keypress before exit" in the settings file - sometimes I want to read the last messages and the 3sec delay are too short, so I added this option mainly for my own needs :D

I've not enabled the auto update so far, will do it in a few hours unless someone posts problems with the new release :D

[SamuriHL]

Oh very nice. This is very helpful. Thanks!

[coricopat]

It's now an x64 executable :)

Feels like the a native Linux version might be waiting around the corner. 🤭️😁️

[metalsonic88]

I sent you a pm nalor, but I'm poking here as well for completion and visibility sake. The issue I was having with the aacskeys command still exists on this version. Logs and such are in the pm.

[nalor]

I sent you a pm nalor, but I'm poking here as well for completion and visibility sake. The issue I was having with the aacskeys command still exists on this version. Logs and such are in the pm.

In case my fix is working, I'll enable auto-update for release 2.04 (it does not contain anything else - so not really relevant for users not affected by an error in aacskeys mode in combination with a custom keydb.cfg file path)

Thanks for the report! :goodpost:

[metalsonic88]

Your fix does indeed solve the issue of aacskeys mode just sort of stopping without useful output. However, the original issue that I was hoping to resolve was the fact that I am not getting MediaKey, VolumeId or VUK from discs sometimes. Using aacskeys mode was supposed to be a means to debug that issue. With this fix in place there is additional info available that I have sent you. My naive impression of the info from those logs is that there is a similar bug with file paths that is causing this, but the details are in the log I pm'd you. Of course, I could be way off base, or this could even be correct behavior.

The quoted post below is the initial report of the issue I am really concerned with and that I hope can be investigated if not resolved before another proper release.

---

This might be a stupid question, but historically I haven't paid much attention to the output/logs that are generated by FindVUK unless there is an issue. But lately I have been watching them a bit closer and I've noticed that every now and then a disc is coming up with no VUK, MEDIAKEY, or VOLUMEID, but no errors or warnings or anything happen and the verification continues as normal. Is that how things should work? Do some discs simply lack this information, or is something wrong here?

An example:

-----------------------------------------------------------
22:53:30 - ----------- FindVUK 1.83 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
22:53:30 - SettingsFile: >C:\{redacted}\FindVUK\config\FindVUK.ini<
22:53:30 - Logfile >C:\{redacted}\FindVUK\log\2026-03-31_FindVUK.txt< Default Loglevel >2<
22:53:30 - Update enabled - check for update
22:53:31 - No update required
22:53:31 - Open Main-KEYDB file: >C:\ProgramData\aacs\KEYDB.cfg<
22:53:33 - Open Backup-KEYDB file: >C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg<
22:53:33 - DVDfab Version >12.1.1.5< found
22:53:33 - >>> everything should work as expected!

22:53:33 - Preferred application >PassKey< is not available
22:53:33 - DVDfab is available!
22:53:33 - DVDfab-MainFile: >C:\Program Files\DVDFab\DVDFab 12\DVDFab64.exe<
22:53:33 - DVDfab-LogFile: >C:\Users\{redacted}\Documents\DVDFab\DVDFab12\Log\dvdfab_internal.log<
22:53:33 - KEYDB-Path: >C:\ProgramData\aacs\<
22:53:33 - KEYDB-Backup-Path: >C:\{redacted}\FindVUK\VUKbackup\<
22:53:33 - ProcDumpFile: >C:\{redacted}\FindVUK\tool\procdump64.exe<

###############################################################################
22:53:33 - --- PART 1 --- GET DUMP ---
-------------------------------------------------------------------------------

22:53:33 - No running application process discovered
22:53:33 - >> Start it now >C:\Program Files\DVDFab\DVDFab 12\DVDFab64.exe<

22:54:17 - Drive opened
22:54:17 - Volume Label detected >DEAR BROTHER DISC 2<
22:54:19 - DriveLetter detected >F<
22:54:19 - Detected CopyProtections AACS >1< BD+ >0<
22:54:19 - DiscID found >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:22 - MainPlaylist found >00000.mpls<
22:54:22 - DVDFab64 got Unit Keys - create memdump now!
22:54:23 - Dump successful! >1<
22:54:23 - MemDump successfully finished!
22:54:23 - Cancel DVDfab decryption now!
-------------------------------------------------------------------------------
22:54:23 - Get basic AACS data
-------------------------------------------------------------------------------
22:54:23 - AACS folder >F:\AACS< on disc is reachable - Validate is possible
22:54:24 - VolumeName >DEAR BROTHER DISC 2<
22:54:24 - VolumeSize >46881177600<
22:54:24 - DiscId >AD0274C51352D03668DC41A25200106720EB50F4< (2021-03-07)
22:54:24 - DiscType >BD<
22:54:24 - MKB Revision >70<
22:54:24 - Disc-BusEncEnabled >0<
22:54:24 - Drve-BusEncCapable >1<
22:54:24 - UnitKeyCount >1<
22:54:24 - >>> UnitKeyENC (1) >5E8EEDE3CBA99D3B80533E75D3FD51F0<
-------------------------------------------------------------------------------
22:54:24 - Analyze dump
-------------------------------------------------------------------------------
22:54:24 - Start to analyze '2018' MemDump now!
..-...............................-
22:54:25 - DiscID >AD0274C51352D03668DC41A25200106720EB50F4<
22:54:25 - UnitKeyCount >1<
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413<
-------------------------------------------------------------------------------
22:54:25 - --- PART 2 --- VALIDATE VUK/UNITKEYS ---
-------------------------------------------------------------------------------
22:54:25 - Drive is detected as 'REAL BLURAY' drive
22:54:25 - M2TS files found >19<
22:54:25 - Decrypted first unit of file >F:\BDMV\STREAM\00016.m2ts< with UnitKey >1<
22:54:25 - All UnitKeys are VALID! No need to test other files

-------------------------------------------------------------------------------
22:54:25 - Validation successful! UnitKeys are valid!!
-------------------------------------------------------------------------------

22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details
22:54:25 - -------------------------------------------------------
22:54:25 - MetaTitle : Dear Brother Disc 2
22:54:25 - VolumeName : DEAR BROTHER DISC 2
22:54:25 - DiscID : AD0274C51352D03668DC41A25200106720EB50F4
22:54:25 - DateDiscID : 2021-03-07
22:54:25 - DiscType : BD
22:54:25 - VUK :
22:54:25 - MEDIAKEY :
22:54:25 - VOLUMEID :
22:54:25 - >>> UnitKeyDEC (1) >CFB1F8EAA8F4BA50900B2E2D30230413< (Valid)
22:54:25 - MKBrev : 70
22:54:25 - BusEncrEn : 0
22:54:25 - AACS : 1
22:54:25 - BD+ : 0
22:54:25 - MainPlaylist: 00000.mpls
22:54:25 - -------------------------------------------------------


-------------------------------------------------------------------------------
22:54:25 - --- Write entry in main-keydb file ---
-------------------------------------------------------------------------------

22:54:25 - Keys in Keyfile: 179944 keys - KeyFile: C:\ProgramData\aacs\KEYDB.cfg
22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details

22:54:25 - KEYDB: Identical entry already present in keydb-file
22:54:25 - >> Identical: TITLE, VUK, DATE, MEDIAKEY, VOLUMEID, UNITKEYS, COMMENT - Different: nothing >> will NOT write new entry in keydb-file

22:54:25 - Identical entry already present in keydb-file - file is not changed


-------------------------------------------------------
22:54:25 - --- Write entry in backup-keydb file ---
-------------------------------------------------------

22:54:25 - Keys in Keyfile: 469 keys - KeyFile: C:\{redacted}\FindVUK\VUKbackup\KEYDB.cfg
22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already in file - need to compare the details

22:54:25 - KEYDB: Identical entry already present in keydb-file
22:54:25 - >> Identical: TITLE, VUK, DATE, MEDIAKEY, VOLUMEID, UNITKEYS, COMMENT - Different: nothing >> will NOT write new entry in keydb-file

22:54:25 - Identical entry already present in keydb-file - file is not changed


-------------------------------------------------------
22:54:25 - --- Write entry in main-bluraydb file ---
-------------------------------------------------------

22:54:25 - Entries in DB-File: 303 entries - DB-File: C:\Users\{redacted}\AppData\Roaming\bluray\bluraydb.cfg

22:54:25 - Disc with ID >AD0274C51352D03668DC41A25200106720EB50F4< is already >1< times in the bluraydb-file
22:54:25 - -------------------------------------------------------
22:54:25 - BLURAYDB: Identical entry already present in bluraydb-file (line 302)

22:54:25 - Identical entry already present in bluraydb-file - file is not changed

22:54:25 - -------------------------------------------------------
22:54:25 - --- Upload MetaXML to OnlineDB file ---
22:54:25 - -------------------------------------------------------
Establishing connection
Establishing connection
HTTP-POST success
22:54:26 - Successfully posted to the OnlineDB! >
Preconditions fulfilled - process upload now
Detected BlurayMetaXML - DiscId >AD0274C51352D03668DC41A25200106720EB50F4<
Upload written to database!
Meta-Upload successfully processed!
<
22:54:26 - Successful upload to OnlineDB
22:54:26 - Eject the disc now from drive >F:\<

22:54:30 - Successfully ejected the media in drive F!

[magician]

I've noticed that every now and then a disc is coming up with no VUK, MEDIAKEY, or VOLUMEID, but no errors or warnings or anything happen and the verification continues as normal.

Not nalor here, but maybe I can answer this. DVDFab memory dumps only expose the UnitKey(s) for a disc. When running in that mode, FindVUK can only show you what else it knows from the KeyDB. If no one has verified and submitted those other data points for the disc, they just show as blank during your run. Although the public KeyDB does now have the VUK etc. for the disc in your log, that data was not uploaded to the OnlineDB until 2026-05-10, about a month after your original submission.

[metalsonic88]

It may be the case that for some reason I still just can't get that info, but the log seems to indicate that FindVUK is trying to open keydb.cfg to get host certificates from an incorrect location similar to the custom path issue that was already fixed.

2026-08-17 18:04:34 # 3100 # [E] bluray_keydb(1697) / BRKDB_GetHostCertificates / ERROR! File >c:\users\{private}\appdata\roaming\aacs\keydb.cfg< has never been opened!

That aside, is the inability to obtain VUK, MediaKey, and VolumeId a limitation of using DVDFab specifically? If PassKey or something else can find that info but DVDFab can't then that's news to me and I'll make the switch.

[nalor]

2026-08-17 18:04:34 # 3100 # [E] bluray_keydb(1697) / BRKDB_GetHostCertificates / ERROR! File >c:\users\{private}\appdata\roaming\aacs\keydb.cfg< has never been opened!



Fixed in FindVUK 2.05 - hopefully it's working now.

[metalsonic88]

Wonderful! That has resolved things. As I believe lamp and magician both suspected earlier, my drive isn't getting the VUK, MediaKey, or VolumeID because the host certificates for the drive have been revoked. But now I'm actually getting FindVUK to tell me that correctly. Thank you very much for fixing this for me nalor!

[rco133]

Hi.

When I start syncronize.bat it says that it needs to update from 2.04 to 2.05, downloads something, but seems to end in an endless loop, where it tries to update from 2.04 to 2.05 for ever.

20:59:07 - ----------- FindVUK 2.04 x64 -----------
-----------------------------------------------------------
To close FindVUK simply press the ESC key
-----------------------------------------------------------
20:59:07 - SettingsFile: >f:\MakeMKV\config\FindVUK.ini<
20:59:07 - Logfile >f:\MakeMKV\log\2026-08-21_FindVUK.txt< Default Loglevel >2<
20:59:07 - Update enabled - check for update
20:59:07 - OnlineRelease is newer, update is required - >2.04< -> >2.05<
20:59:07 - Download update file
20:59:08 - Update process started >f:\MakeMKV\mod.update.exe< - end current process now
-----------------------------------------------------------
20:59:09 - ----------- FindVUK 2.04 x64 -----------

It goes on like that for ever.

rco133.

[SamuriHL]

Yea seeing the same. That's unfortunate.

[coricopat]

@nalor, now that you have TLS, you might change the download links to https schema :-)

[nalor]

Yea seeing the same. That's unfortunate.

Fixed - I missed to update the internal release number - so the "new" release is 2.04 instead of 2.05 ... changed it to download 2.04 instead.

[SamuriHL]

Fixed - I missed to update the internal release number - so the "new" release is 2.04 instead of 2.05 ... changed it to download 2.04 instead.

Thanks! Much appreciated!

[metalsonic88]

I think the stats displays on the website are broken. PC, phone, and laptop all using various different browsers and networks all can't get it to load

[nalor]

I think the stats displays on the website are broken. PC, phone, and laptop all using various different browsers and networks all can't get it to load

Fixed - it only worked when opening with "http" but failed with "https" as the data was still loaded from a "http" source and the browser refuse to load this as it would be unsecure. So it's not a pure html page any longer but a php page instead and it properly handles if opened with http or https.

[metalsonic88]

Fixed - it only worked when opening with "http" but failed with "https" as the data was still loaded from a "http" source and the browser refuse to load this as it would be unsecure. So it's not a pure html page any longer but a php page instead and it properly handles if opened with http or https.

I don't see any changes on my end? Just to make sure it wasn't something with my cache or some other nonsense I tried it from my work computer that's never visited that site before. Still not working though.