Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
6th May 2020, 21:09 | #501 | Link |
Registered User
Join Date: Jun 2005
Posts: 259
|
It started when DVDFab added UHD support in Passkey v9.3.0.2 early 2018. So anything newer only uses UK so FindVUK can only get UK. Maybe you can still get other keys with FindVUK using older DVDFab versions for discs with lower MKB versions (like < 60). But for those discs that maybe will work you can get all keys yourself with aacskeys using public PK and HC
Last edited by candela; 6th May 2020 at 21:33. |
7th May 2020, 07:07 | #502 | Link | |
Guest
Posts: n/a
|
Quote:
|
|
7th May 2020, 09:52 | #503 | Link | |
Registered User
Join Date: Dec 2010
Posts: 65
|
Quote:
git is great when managing text files with incremental modifications, and it's very, very efficient when synchronizing local and remote copies. What if FindVUK did:
(and, btw, there are plenty of git hosting sites out there) |
|
8th May 2020, 19:20 | #504 | Link |
Registered User
Join Date: Dec 2013
Posts: 490
|
I'm not sure that GIT is really an option - because the problem is that not all changes of every user are relevant for all the other users...
Usually GIT is used in case each change is relevant for everyone else .. but in our case there might be manual changes to the file that might remove data from the repository. And as always with systems like GIT theres always the option that merge conflicts might occur - and the only way to handle them easily would be to perform a hard-reset to the current repository. Finally I just want to tell that the only reason for me to start the online database has been the strange disappearance of Starbuck ... But in case someone else wants to create a better solution I've absolutely no problem to stop my current implementation or add support for the new approach to FindVUK. |
14th May 2020, 11:23 | #505 | Link |
Registered User
Join Date: Jun 2003
Posts: 22
|
Hi nalor!
The upload part when submitting new keys always seems to work fine and obviously it's just the download part of a sync where the free hosting problems kick in. I was going to suggest some sort of stop-gap measure like a monthly keydb.cfg update via tinyupload.com (or similar) so people could keep relatively up to date without needing to hammer the free host so much. However, out of curiosity I just tried a sync for the first time in ages and the speed seemed to be a lot better and I noticed that it downloaded about 11mb instead of the full 31mb and then proceeded to unpack it. Basically, I was able to do a full sync with no problems. I'm guessing you've made a few changes somewhere so a sync doesn't require so much data to be downloaded? If so, it certainly seems to be working ok at the moment. Just thought I'd mention it in case you wanted any feedback(!?) and also thought I'd just say a quick thanks for all the work you've put in to FindVUK |
16th May 2020, 22:22 | #506 | Link |
Registered User
Join Date: Dec 2013
Posts: 490
|
I've changed only something really small - but maybe this did the trick.
In the beginning the file to download has been <10MB and everything has been fine. Than at some point in time the file got bigger than 10MB and personally I think it still worked, but later on it started to get really slow. In parallel I noticed that when downloading the file with a browser I don't get a progress information and started to analyze why this isn't working and finally got the info from the bplaced-support that each php-interpreter is limited to 10MB of memory and as the file is transmitted by a php-file and does exceed the assigned memory size, the filesize is not available in advance any longer and therefore it's not available to the browser. So finally I've changed the behaviour so that the php-file just takes care the file is updated in case it's necessary and afterwards there's a redirect to the file in the filesystem. So the data is now delivered directly by the webserver and a few days after this change the download problems disappeared... Don't know if it's really related or if it's just a coincidence - but finally everything back to 'useable' |
2nd June 2020, 22:01 | #507 | Link |
Registered User
Join Date: Dec 2013
Posts: 490
|
Just want to tell that I'm working on a better synchronization feature - I think it will speed up the sync dramatically.
Basically FindVUK will store a hash of the file after a full-sync and the date of the sync and as long as the file is not modified externally it will just request delta-files for synchronisation (such a file is around 200kb for the last 60 days). The server part is already done - see here: Delta File since 2020.05.04 23:00:00 In case the requested date is older than 60 days or in the future or cannot be parsed at all, the full file is offered instead. The delta file includes all entries that got either created or modified in this time area. Next I'll implement the required changes in FindVUK - but this will take a few days. Small note: It's also possible to use relative deltadate attributes - e.g. this here will always return a file with all entries changed during the last 24h: Changed entries in last 1 day Last edited by nalor; 14th June 2020 at 22:25. |
9th June 2020, 21:35 | #508 | Link |
Registered User
Join Date: Dec 2013
Posts: 490
|
Released FindVUK 1.34 - it includes the delta-synchronization and in my small tests it's working fine.
As long as the keydb.cfg isn't modified manually the delta sync is active. To check for modifications a hash is stored in a keydb_hash.ini file together with a timestamp used for the delta-sync. The timestamp is the time of the last change in the online database - it has nothing to do with the time of the last synchronisation. The easiest way to trigger a full-sync again is to delete this ini file. |
12th June 2020, 03:57 | #509 | Link |
Registered User
Join Date: Jun 2020
Posts: 9
|
Wanted to say thanks for your efforts to help expand the control people have over their material. You, candela, mick0, and many more have allowed me and others to overcome some of the key issues with owning Blu-rays and you all have my gratitude for that.
Beyond the simple thanks, I believe I have something that might be of interest to you. I've been using your program to get the various codes and keys and whatnot from my own Blu-rays uploaded to the main database you have. However, a strange error occurred when I used it on my copy of "The Usual Suspects". It was the first movie I had to enter the name for manually and it seemingly didn't like that. However, I then had to do the same for "Total Recall" and that went just fine without any weird error. Don't really know what the issue is but I thought you'd maybe find it helpful. Just in advance, I hope I got the right parts for this for you to look at and sorry if I didn't. *Wanted to use the scrolling CODE phrasing to put it up here and have a nicer flow, but it would have taken multiple posts so I just put it on TinyUpload instead as a RAR.* Tiny Upload Link: http://s000.tinyupload.com/?file_id=...36899647016775 PS. I replaced my account name with *Account Name* in the logs. Hope that's ok. |
13th June 2020, 21:26 | #510 | Link |
Registered User
Join Date: Dec 2013
Posts: 490
|
This problem is one I already know -but I still don't know how to solve it properly. The uploads from findvuk are directly processed and written to the database, this is working fine as long as everything is in perfect condition.
But with discs that require a manual title input there might be the chance that it already got uploaded previously with a different title. In the current example the disc got uploaded the first time at 23.03.2019 with a title 'THEUSUALSUSPECTS' and now you're entering another title 'The Usual Suspects' and finally my script only knows that those are not equal - but cannot decide which title is better and therefore the 'manual processing required' result is returned. All those uploads are now flagged with 'manual processing required' and from time to time I'll check them manually and decide what to do. But I think it might be an improvement to still report it as success instead of showing an error.... |
14th June 2020, 18:42 | #511 | Link |
Registered User
Join Date: Jun 2020
Posts: 9
|
Ah got it. Thanks for looking into it and for the succinct explanation!
-----Didn't want to make two posts one after another so I'm just editing this one----- Encountered a new error. I used the program on my Guardians of the Galaxy and Star Trek The Motion Picture Blu-rays (the Star Trek one is from that big 50th Anniversary collection in case that matters) but it spit out an error at the end about something involving a "hash file". I think the uploads for both of the discs to the database went fine, as the log says that they did. However, I wanted to let you know before I continued doing any more discs just in case it was something important that could corrupt the data or something. Just in case these details matter, I updated Passkey from 9388 to 9389 (the logs say that's ok but I just wanted to let you quickly know), I got a new version of the KeyDB (6-14-20) before I used the program with my discs to make sure it was as up to date as possible before adding new entries, and updated my VUK program to the new 1.34 version by extracting everything in the folder and letting it overwrite everything it wanted. Here's a link to the Tiny Upload of the Logs: http://s000.tinyupload.com/?file_id=...97325744329857 Last edited by Roof Tile; 14th June 2020 at 20:10. |
15th June 2020, 22:44 | #512 | Link |
Registered User
Join Date: Dec 2013
Posts: 490
|
Thanks for reporting!
Just checked my code and I think it's a stupid error from my side. At the end of each scan it tries to update the stored hash of the keydb.cfg file so that it's still detected as 'unchanged' - but this is only possible in case the hash-file is really available. I never tried it without this file ... and I guess this is the situation in your case. Please either:
I think both options should help. I'll fix the bug with the next release. |
15th June 2020, 22:52 | #513 | Link |
Registered User
Join Date: Jun 2020
Posts: 9
|
Glad to help and will do! Just to ask though, what does the hash-file do exactly? Do I need to redo my previous disc reads to make sure they have everything correct, or is it an "extra" sort of thing to make things easier for collecting info or uploading things?
|
16th June 2020, 06:07 | #514 | Link | |
Registered User
Join Date: Dec 2013
Posts: 490
|
Quote:
So there is really no need to redo your reads. Gesendet von meinem H8324 mit Tapatalk |
|
25th June 2020, 20:52 | #516 | Link |
Registered User
Join Date: Mar 2019
Posts: 23
|
I came across a bug in the new version. Apparently, when writing to the "keydb" file, FindVUK 1.34 was looking for uppercase letters "KEYDB". I had lowercase letters "keydb" and it failed that operation with:
13:11:55 - Successful upload to OnlineDB 13:11:56 - ERROR! Couldn't open hash-file >C:\Users\***\AppData\Roaming\aacs\keydb_fvhash.ini< 13:11:56 - ERROR! Couldn't update hash file >C:\Users\***\AppData\Roaming\aacs\KEYDB.cfg< 13:11:56 - Eject the disc now from drive >E:\< When I changed my keydb.cfg to uppercase "KEYDB.cfg", it completed that operation with: 13:19:38 - Successful upload to OnlineDB 13:19:38 - Eject the disc now from drive >E:\< Also, I don't see a "keydb_fvhash.ini" file in my directory. So it doesn't create one when there is none. That's a problem, too. Last edited by Buck; 26th June 2020 at 16:57. |
29th June 2020, 17:10 | #517 | Link | |
Registered User
Join Date: Dec 2013
Posts: 490
|
Quote:
So I guess when you rename back to 'keydb.cfg' it's also working - very likely it's been a problem with the first run. |
|
29th June 2020, 20:42 | #518 | Link |
Registered User
Join Date: Dec 2013
Posts: 490
|
Uploaded a new release 1.35
It includes 2 changes: -> FIX for the error message when using without synchronization -> an auto-update function I know it's not really required because I don't update that often - but I wanted to try and I think it's working well, at least in my tests. It can be disabled in the ini-file. Additionally I've linked to the website of the online-database for download instead of using tinyupload. |
3rd July 2020, 22:13 | #519 | Link |
Registered User
Join Date: Jun 2020
Posts: 3
|
This is my first time using this forum, so I apologize if this isn't the proper thread to post this. I have some VUKs that aren't in the online database and would like to add them to my local keydb.cfg file and upload those changes to the online database for others to use. I obtained these VUKs by adding the DKs, PKs, and HCs from this post to my local keydb.cfg file and playing the Blu-rays in VLC: https://forum.doom9.org/showthread.p...55#post1883655
The VUKs for each disk showed up in AppData\Roaming\aacs\vuk. However, I don't know how to go about doing the proper formatting for the disk title, the VUK, and all the other necessary entries to match the existing entries in keydb.cfg. Do I have to manually input everything in my local keydb.cfg file or is this formatting usually done automatically by FindVUK when using it with a DVDfab program? |
3rd July 2020, 23:26 | #520 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
This is the per-disc key backup script I use. Grew out of a solution I used prior to switching to FindVUK, but then repurposed to pretty-print things and continue to make sure that I have backups of the keys for the discs I actually own.
Code:
#!/bin/bash VOLUMEDRIVE="$(ddwin64 --list 2>&1 > /dev/null | grep -A1 CD-ROM | grep Mounted | tail -c4)" VOLUMENAME="$(cmd //c "vol $VOLUMEDRIVE" | grep "Volume in drive" | sed 's/is/\t/' | cut -f2 | sed 's/^ //')" echo "$VOLUMENAME" > "$VOLUMENAME.aacsinfo.txt" aacs_info "$VOLUMEDRIVE" >> "$VOLUMENAME.aacsinfo.txt" DISCID="$(aacs_info "$VOLUMEDRIVE" | grep "Disc ID" | cut -f2 -d : | sed 's/ //g')" VID="$(aacs_info "$VOLUMEDRIVE" | grep "VID" | cut -f2 -d : | sed 's/ //g')" #VUK="$(cat $(echo $APPDATA\\aacs\\vuk\\$DISCID) | tr '[:lower:]' '[:upper:]')" MEDK="$(aacs_info "$VOLUMEDRIVE" | grep -w "MK" | cut -f2 -d : | sed 's/ //g')" FULLKEYS="$(cd "/e/Programs/aacskeys/bin/win64/" && aacskeys.exe "$VOLUMEDRIVE" v "$VID")" VUK="$(cd "/e/Programs/aacskeys/bin/win64/" && aacskeys.exe "$VOLUMEDRIVE" "$VID" | grep "Volume Unique Key" | cut -f2 -d : | sed 's/ //g')" MKB="$(grep MKB "$VOLUMENAME.aacsinfo.txt" | cut -f2 -d : | sed 's/ //g')" fromdos "$VOLUMENAME.aacsinfo.txt" sed -i '/VID/aVUK : '"$VUK"'' "$VOLUMENAME.aacsinfo.txt" todos "$VOLUMENAME.aacsinfo.txt" grep $DISCID "$APPDATA\\aacs\\KEYDB.cfg" > "$VOLUMENAME.keydb.txt" mkdir -p aacsbk/vuk echo "$VUK" > aacsbk/vuk/"$DISCID" echo "$FULLKEYS" > "$VOLUMENAME.fullkeys.txt" echo "0x$DISCID = $VOLUMENAME | V | 0x$VUK | M | 0x$MEDK | I | 0x$VID ; MKBv$MKB" > "$VOLUMENAME.keydb_forinsert.txt" Note: it does use the old key order, but FindVUK adjusts it when it verifies the info. It also assumes aacskeys resides in E:\Programs\, so adjust that accordingly, especially if on something other than Windows. Run the script first, see what differs between the *.keydb.txt and *.keydb_forinsert.txt. If the plain keydb output either lacks some keys or has NOTVALIDATED / LEGACY, then copy the line (or just the missing parts of the line) from _forinsert.txt into the main keydb.cfg. Then optionally run FindVUK to let it fix things up (maybe just Synchronize if you don't care about some of the meta stuff), and then to re-verify, run the above script again and compare the *keydb/*forinsert files again to ensure things look okay. The script is a little older, obviously; with libaacs allowing the MK cache and such now, those values could probably be read out a lot easier than they had to be at the time (although since the VUK isn't printed by aacs_info, that still needs aacskeys). |
Thread Tools | Search this Thread |
Display Modes | |
|
|