[FEATURE REQUEST] Option to automatically rip when low on space

[vertigo]

Oftentimes I'll get a message that there's not enough space for the rip, forcing me to delay the start of the rip until I can clear some, or to have to manually uncheck some tracks, rip what I can, then move files around and go back and rip the rest. This takes a lot more time, whether due to the juggling of tracks to rip or waiting to start a rip, which often takes a long time, so the sooner I can start it the better.

It would be a big time saver and make things a lot easier if there was an option to automatically start the rip, warning that there's not enough space (could still be a pop-up, or could be a prominent entry in the log), and rip as much as possible until running out of space (preferably allowing the user to set an amount of space to keep free), then pausing until space is cleared, at which point it would auto-resume (or could even require user input to resume).

[Radiocomms237]

Eww, that sounds... messy. Pausing and resuming a rip mid-file is just asking for data corruption if you ask me, and I already find enough of that as it is!

I do occasionally butt up against the 'not enough space' warning, but usually it's only if I've been a bit slack when it comes to moving previously ripped titles up to my NAS.

If you're getting that warning often, I'd suggest it may be time to buy a bigger hard drive!

[vertigo]

Doesn't have to pause mid-file. If there's not enough space for the next file, it can just pause after finishing the last track there's enough room for. Yes, a larger drive would be ideal, and eventually that's the plan, just not currently. It's not as big a problem as it used to be since I did clear some stuff off of it, but it still occurs regularly enough that it would be nice to have the software handle the situation more automatically/intelligently. But also a minor enough problem that it's certainly understandable if it's determined more work than it's worth.

[dcoke22]

Ripping discs is tough to do with limited space. On macOS, there's the opposite problem. The Finder will lie to you about how much free space is on the system drive, which is typically the only drive most people have (aka the C: drive on Windows). It might tell you there's 80GB free, but there really isn't; there's a bunch of stuff that will eventually be deleted/dealt with whenever the OS gets around to it that will eventually free up a total of 80GB. But ripping discs can fill up space faster than the OS can clean up stuff in the background. The easiest solution seems to be to get an external drive and do all ripping/transcoding/whatever work on there since all of the complicated/fancy/lie-to-you things aren't done on external drives.

The upside to having plenty of space and/or an external drive is it allows one to make a decrypted backup of a disc with MakeMKV, then load the backup into MakeMKV and create .mkv files from the backup. The creation of .mkv files happens at the speed of the storage in this scenario. You can let the slow part, the reading of the disc, happen while you sleep or whenever.

[vertigo]

The upside to having plenty of space and/or an external drive is it allows one to make a decrypted backup of a disc with MakeMKV, then load the backup into MakeMKV and create .mkv files from the backup. The creation of .mkv files happens at the speed of the storage in this scenario. You can let the slow part, the reading of the disc, happen while you sleep or whenever.

Doing it this way doesn't really make sense. You're turning what can be one step into two. Instead of just ripping straight to mkv, which should take roughly the same amount of time as creating a copy of the disc, you're copying it then making the mkv's. The only way this would be worthwhile would be if you want an actual image of the disc as a backup, but I personally don't. I just have it make the mkv's straight from the disc onto an SSD (hence the limited storage, especially since I use it for other stuff, too), then from there to hard drives. I don't go straight to the hard drives even though there's far more space available there because they're a lot slower and to minimize wear on them (not a big issue, and more due to the speed, but still). And btw, I realize the speed won't affect the ripping, it's for when I'm doing various things with them afterward. I'll be bumping up the SSD space before too long, so it's not a huge deal really, I just figured I'd throw it out as a possible improvement to make things a bit easier.

Also, "ripping" from an image to mkv's doesn't actually go the speed of the storage. Even with fast SSDs, it takes longer, by a fair margin, than it would to copy the same amount of data. Even with a fast CPU, plenty of fast RAM, and fast storage, it still takes a while, longer than it seems like it should, and I've never been able to figure out why. It's strange because there's no clear bottleneck.

[dcoke22]

In my experience, reading from and writing to the same SSD, MakeMKV often ends up moving data at around 400MB/s, which is roughly in line with what I would expect my external SSD scratch space to do. At those speeds, a typical movie only takes a few minutes to rip. I haven't tried it on a faster system with faster storage. YMMV of course.

I try to get lots of details correct in my .mkv files, labeling commentary tracks as such, etc. I also like to capture the 'extras' on the disc as well. Getting all of that correct on the first try is hard to do in my experience. Making the decrypted backup lets me play the .m2ts files directly to determine which title is which, so I can get things labeled in MakeMKV correctly. Ripping everything and sorting it out later, updating things with MKVToolNix is not my preferred method. When I buy a movie or TV show, I generally make backups of all the discs right away and get to making .mkv files later, as my time allows. This lets me know all the discs are good (or not) before the return window expires.

So, yeah, I turn what could be a single step into two steps, but I think the benefits outweigh the downsides.