1.17.4 Deleting Failed RIP
1.17.4 Deleting Failed RIP
I updated from 1.17.3 to 1.17.4 today. I had (2) blu-ray rips fail and their .mkv files deleted when I acknowledged the failed attempt. I like to keep the files and compare them to additional attempts on another drives/PCs. I don't see an option in Preferences to go back to how 1.17.3 worked. Am I missing something in this new version?
Re: 1.17.4 Deleting Failed RIP
MakeMKV has always deleted rips that could not be completed. If you want to compare the files to others, you have to catch them before the delete occurs, which would be rather difficult.
MakeMKV Frequently Asked Questions
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
Re: 1.17.4 Deleting Failed RIP
Something in 1.17.3 didn't and that was a very useful "feature." When a RIP fails, I try it on a second computer/drive. If it fails with the exact same file size, I assume it's the disc and work on getting ahold of a second copy. If it's a completely different size I often restart MakeMKV on the first computer and a decent number of them will then succeed. I was having issues when working on my collection conversion from disc to network drive. Forgot why I was using 1.17.3 and upgraded to 1.17.5 to see if that fixed anything so ran into this deletion on fail issue again. Will try to revert back to 1.17.3 again to get my saved failed files back. Would be nice if deletion was an option in future versions.
Re: 1.17.4 Deleting Failed RIP
All versions of MakeMKV I've tried (going back to 1.5.6 in 2010) have removed failed rips automatically; if the rip completed, the file was left on the disk, otherwise it was deleted. It has been a pain at times, but, if MakeMKV left the file, it was ripped "properly".
That's ripping by FILE, not a "full disk rip" done on a bluray disk. Those can end up with certain files m2ts and mpls files deleted as unreadable, but ripping to MKV files should only leave the file if it was read completely. I have a few of those hanging around from tests I did.
Which are you doing?
That's ripping by FILE, not a "full disk rip" done on a bluray disk. Those can end up with certain files m2ts and mpls files deleted as unreadable, but ripping to MKV files should only leave the file if it was read completely. I have a few of those hanging around from tests I did.
Which are you doing?
MakeMKV Frequently Asked Questions
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
Re: 1.17.4 Deleting Failed RIP
I'm ripping MKV files. Converting my disc collection to a NAS Plex Server collection.
Guess I got lucky then that my 1.17.3 version was leaving the files behind. They've been very useful. Especially ripping on 2 computers at once or when my mind blanks on what I was just trying to rip.
Re: 1.17.4 Deleting Failed RIP
Ah, another Multi Ripper! It gets phun when you're ripping on computers with more than one drive in them, running multiple copies of MakeMKV so you can do them all at the same time. Which disk did I put in which drive?
(but I would NEVER do anything like THAT!)
(but I would NEVER do anything like THAT!)
MakeMKV Frequently Asked Questions
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
Re: 1.17.4 Deleting Failed RIP
I haven't tried multiple copies of MakeMKV to do dual rips on the same machine. I've a big desk and picked up a second computer for $99. I did revert both of my computers from 1.17.5 back to 1.17.3 They are now both saving the failed RIP files. Appears 1.17.3 Windows release has a bug that I consider a feature.
Re: 1.17.4 Deleting Failed RIP
If you do decide to go with multiple rips on one machine, you'll want to tell MakeMKV to ask about single-drive mode on start-up. That's on the Preferences->IO page, "Ask for single drive mode". The default is "all drives", but it lets you run with multiple copies, each tied to a single drive.
MakeMKV Frequently Asked Questions
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
FAQ about BETA and PERMANENT keys.
How to aid in finding the answer to your problem: Activating Debug Logging
Re: 1.17.4 Deleting Failed RIP
Thank you. That worked well. Perfect for loading up the machines when I'm stepping away from the desk for a while. Combined time for by my DVD and Blu Ray drive on same machine ripping MKV files was a bit more than if I'd run them individually.
Re: 1.17.4 Deleting Failed RIP
I know this is an older thread, but I ran across it while hoping to find a setting that would prevent makemkv from automatically deleting failed rips. There isn't one. But, if you're on linux (and probably mac, but I don't know because I don't care, and for all I know but seriously doubt Windows, but I care even less), you can prevent automatic deletion via a small workaround. You just have to hardlink the file before it gets deleted. So, supposing you have /directory/file1 as the output of your rip, and you want to make sure it doesn't get deleted. Just hardlink it thusly:
Now, when makemkv deletes /directory/file1, /directory/file2 will still exist and contain the exact same contents as /directory/file1 contained when it was deleted (file2 is a pointer to the same inode as file1, so the filesystem doesn't mark that space as freed and thus won't overwrite it). Obviously you have to do this before the rip fails and file1 is deleted, and file1 and file2 must be on the same filesystem (for example, if /directory and /directory2 are on different filesystems, you cannot hard link them like this), but otherwise, it will work like a charm, and you'll have access to the full contents of the file up to the point the rip failed.
This was useful for me because I had a rip that was failing to read within a couple KB of the end of the read, and I was willing to sacrifice a couple frames for the whole shebang.
Code: Select all
ln /directory/file1 /directory/file2
This was useful for me because I had a rip that was failing to read within a couple KB of the end of the read, and I was willing to sacrifice a couple frames for the whole shebang.