The Amateur

[MrPenguin]

leider auch keinen Erfolg

Verfügen Sie über Leseberechtigungen für die Datei KEYDB.cfg?

[technik22]

lesen und schreiben

[technik22]

oh man manchmal hat man ein Brett vor dem Kopf!!!! Man sollte die Zugriffsrechte auch im Verzeichnis setzen. Jetzt läuft es.
Ich bin Froh das ich eine Lizenz gekauft habe, dann ist mein schlechtes Gewissen etwas kleiner.
Ich möcht mich bei Euch recht herzlich Enschuldigen und bedanken. sorry für die Mühe.
Es rennt.

Vielen Vielen Dank

[MrPenguin]

Vielen Vielen Dank

Das ist eine Erleichterung! Mir sind die Vorschläge ausgegangen .

[technik22]

ich bin Dir echt dankbar, (einmal nur mit Profis arbeiten)

[YannToberen]

Hallo zusammen.

Sorry, wenn ich diesen "alten" Beitrag nochmal anstubbse. Ich hab die The Amateur BluRay hier und hab massiv Probleme beim Einlesen.

Starte ich die Kiste neu, ist die Disk fix erkannt und die Übersicht offen. Er beginnt auch zügig mit dem Einlesen. Aber irgendwo zwischen 1.6GB bis 4 GB Lesemenge fängt er an immer langsamer zu werden, das Laufwerk dreht ständig hoch und runter, und die gelesene Menge Daten wird von Minute zu Minute weniger. Bei Hochrechnungen wie "verbleibende Zeit: 23:xx:xx" hab ich dann meist abgebrochen.

Mit einem anderen Laufwerk erkennt er die Diak gar nicht.

Hab Linux, ein Verbatim Laufwerk (BD-RE PIONEER BD-RW BDR-UD04 1.14 ACDL069050WL), das andere ist ein Samsung SE-506CB/RSBD

Eure Tipps mit keydb.cfg (bzw. auch KEYDB.cfg) im /home/ralph/.MakeMKV Ordner, Lese- und Schreibrechten auf der Datei bzw. Datei Anlegen- und Löschen-Recht im Ordner hab ich durch.

Wo ich nicht klarkomme: das TGZ-File. Was muss ich tun, dass er die erstellt? Oder legt er die unter Linux evtl. woanders ab? Hab ein Ubuntu 24 LTS. Wenn die woanders liegt, dann muss die keydb.cfg ja auch dorthin. Hab nur noch nix gefunden ...

[Update]
Ich hatte noch MakeMKV 1.18.1 drauf. Hab schnell auf 1.18.4 hochgezogen, jetzt wird die Disk auch nicht mehr erkannt, wenn ich die Kiste neu gestartet habe. Im Debug Log steht dazu:

Debug log started at Sat Jun 27 09:43:10 2026 , written by MakeMKV v1.18.4 linux(x64-release)
001005:0000 MakeMKV v1.18.4 linux(x64-release) gestartet
001004:0000 Debug-Aufzeichnung eingeschaltet. Aufzeichnung wird gespeichert als file:///home/ralph/MakeMKV_log.txt
Using 262272KB for read cache.
Network access is ENABLED, CURL version 8.5.0/OpenSSL/3.0.13/1.59.0 (x86_64-pc-linux-gnu) , proxy server not set.
001003:0020 DEBUG: Code 0 at KG]XmhY0,A.yRLL3a@B-s>:29393631
SDF v0a6: PIONEER_BD-RW___BDR-UD04_1.14_ACDL069050WL
001003:0020 DEBUG: Code 100864261 at *}j?hjZQgNv E|Ei:121271617
001003:0020 DEBUG: Code 100864261 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 100864261 at *}j?hjZQgNv E|Ei:121271617
001003:0020 DEBUG: Code 100864261 at A]hSf8<?`bfP]%7a:213130559

(die letzten beiden Zeilen wiederholen sich dann alle paar Sekunden, bis ich den Vorgang abbreche).

Zeitgleich hab ich Hagen - im Tal der Nibelungen erworben. Hier gabs die selben Probleme mit dem Lesen (zwischen 1.6 - 4 GB Lesemenge, unterschiedlich bei mehreren Einleseversuchen, Einbruch und ständiges rummörbelm des Lesekopfes). Beim erneuten Versuch mit der heruntergeladenen keydb.cfg und MakeMKV 1.18.4 jetzt erste Verringerung der Lesegeschwindigkeit bei ca. 2700 M, wieder hochfahren bei ca. 3500 M, bis ca. 5700 immer wieder hoch und runterfahren der Geschwindigkeit, danach setzen erste Pausen von einer halben Sekunde bis ca. 2 Sekunden ein, Laufwerkslämpchen blinkt immer wieder auf (leuchtet sonst durchgehend). Bei ca. 7800 M fällt die Lesegeschwindigkeit auf 0,7 und weiter ab. Im Log steht:

005014:0000 1 Titel werden in Verzeichnis file:///home/ralph/Videos gespeichert
001003:0020 DEBUG: Code 0 at KG]XmhY0,A.yRLL3a@B-s>:29393631
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741945 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 100864261 at *}j?hjZQgNv E|Ei:121271617
001003:0020 DEBUG: Code 100864261 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559
001003:0020 DEBUG: Code 1073741885 at A]hSf8<?`bfP]%7a:213130559

Ich meine, das sind zwei Disks von unterschiedlichen Publishern ... mit dem selben Verhalten???

[Update 2]
Beide Disks weichen in der Volumesize von den Angaben in der keybd.cfg ab (bei The Amateur stimmt keine der Angaben, bei Hagen ist nur eine Disk in der cfg, stimmt auch nicht überein)

Wenn ich Unterstützen kann, gerne. Sagt mir, was ich tun soll!

[MrPenguin]

Sorry, wenn ich diesen "alten" Beitrag nochmal anstubbse. Ich hab die The Amateur BluRay hier und hab massiv Probleme beim Einlesen.

Hallo,

erstens hat Google Translate ein Limit von 3000 Zeichen .

Zweitens klingt es so, als verfüge MakeMKV bereits über alle erforderlichen Schlüssel zur Entschlüsselung deiner Disc – weshalb auch keine TGZ-Dump-Datei erstellt wird. Vielmehr scheint es so zu sein, dass dein UHD-Laufwerk nicht genügend Strom erhält, um den Rip-Vorgang abzuschließen.

[YannToberen]

Hi,

After the initial failures with those two discs, I grabbed three random discs off the shelf—ones I’d already ripped in the past—and the drive read them all perfectly and quickly.

I did try swapping the cable, though; I used the USB-C/USB-C cable from my docking station (a full-spec USB 3.2 Gen 2x2 cable, supporting up to 80 Gbps and 240 watts). I also have a Framework laptop, so I plugged the drive into one of the four ports that support laptop charging. That didn't help either.

I’m familiar with what happens when a drive doesn't get enough power—I’ve used the wrong cable once or twice in the past. Usually, when the disc starts spinning up, the drive disconnects from the laptop due to the power issue. That isn't happening here; access to the drive is maintained.

I watched the reading process: it ran smoothly up to about 5,500 MB, then performance dropped again. As I’m writing this, the estimated time remaining has gone from 1:50 to 9:50.

Again: with this same cable, it rips one of the other discs from my shelf (another one picked at random) cleanly and quickly.

Why do you say the discs are in the `keydb` when I specifically mentioned that the total volume size of my disc doesn't match the discs listed in the config?

And what makes you suspect the drive isn't getting enough power?

Please enlighten me—I’m always happy to learn.

Regards,

Ralph

[MrPenguin]

I watched the reading process: it ran smoothly up to about 5,500 MB, then performance dropped again. As I’m writing this, the estimated time remaining has gone from 1:50 to 9:50.

And what makes you suspect the drive isn't getting enough power?

Your drive is struggling to read this particular disk. Lack of power would be one reason for a drive to give up, and another reason would be that the disk just needs cleaning.

Why do you say the discs are in the `keydb` when I specifically mentioned that the total volume size of my disc doesn't match the discs listed in the config?

MakeMKV obviously already has the keys it needs to decrypt your disk, and it's getting those keys either from the KEYDB.cfg file, or from MakeMKV's own hashed keys database. And if your disk has a "(NOTVALIDATED)" entry in KEYDB then it really doesn't matter what its "volume size" is declared to be, so long as its keys are correct.

To be honest, there's more than one way to calculate a disk's volume size even if the KEYDB entry is validated, these different methods don't necessarily agree, and AFAIK different versions of FindVUK have used different methods anyway .