cybrnook

Balls, I could easily see that being the case, because YES, I am known to hit the eject button on the drive itself. I got tons of discs to rip through this weekend, will try this out and report back. Thanks @saarg

@Djoss hope all is well! Had a quick question..... Now that I am really cranking on this container in particular (and handbrake), I am noticing something. As you know, I am running two instances of this container (as seen above) on separate ports. It's working fine, and I can rip from both containers at the same time against the 2 x ASUS USB BD drives I have attached (both drives are mounted to both containers, not just one to one). What I am just now seeing, and maybe has been that way for some time, is that let's say I start a backup before bed on both drives, then walk away..... I come back in the am or two days later, and the containers have the nice "Backup Complete" message and all seems well. Click okay, and MakeMKV goes back to it's primary screen. At that point in time, I head over to the server, eject, and swap in two more discs, and come back to the PC interface. However, the containers are still presenting the "old" discs I just previously took out, like it's not refreshing. I need to restart the containers to refresh/re-initiate. AT THIS POINT, I am also noticing that when the container goes down, it's not always return code (0) in the advanced logs view in UnRaid. It's ending with a 2xx code (I forget exactly). But nevertheless they do come back up, and work fine from that point. Have you seen any time outs or any sequencing issues with the MakeMKV container if you let it sit running for an extended period of time perhaps on a display window with a disc inserted?

I should have my E3 1275 v6 and SM board waiting for me when I get home. Can't wait to play ? Want to bench mark it against my E5 2650 v4. Many slow cores vs few fast cores ? (with QS) - I got seasons 1 - 7 of GoT BD to convert from MKV RAW backup.

Super cool Quick Sync is finally making it's way to Handbrake. It's only been what, 7 years? ? I remember encoding years ago in a desktop based CPU using quick sync (another program other than handbrake) and it was amazingly fast, as stated in your git.

Ended up working out just fine ? Only thing is I needed to remap some ports, so I just ended up remapping them all a bit cleaner, at least in my eyes: Outside of that, dual ripping worked fine. FYI, "Backup" mode does convert to a three folder format (CERTIFICATE, BDMV, and MAKEMKV). Handbrake seems to understand that structure well enough to convert out of it.

I know I could (and likely will) just try, but if you're bored, I have a question. If you change the default output from MKV to BACKUP, does this produce an ISO structure? Or does it just create the folder structure, which I could then just compress to an ISO (similar as rip to iso does in anydvd)?

Hmm, to go back on your original thought. Or, I could map all drives to all containers, and then just choose from the drop down of each container what disc it will rip. I actually like that better. Thanks @Djoss

This will let be rip multiple discs at once? EDIT: I should have clarified that, as that is the ultimate goal.

Hye @Djoss If I have more than one USB Blu-Ray drive I am looking to use. I assume I just need to install your makemkv container, once per blu-ray drive and map appropriately? i.e. two drives two containers, three drive three containers

I would think it's likely because it's "background" process encoding, not a foreground GUI driven process.

@Djoss Saw in the logs a new version is available, just FYI.

No issues were found with your server that may hinder the OS upgrade. You should be good to go Done

No worries, take your time. The ride is over at this point. But remember, it's always 16 somewhere :-).

Mucho Gracis sir! Keep up the great work, and for being thorough, it is appreciated.

root@noah:~# fdisk -l /dev/nvme0n1 Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 64 1000215215 1000215152 477G 83 Linux EDIT: udpated to your latest push and still get the same error: Checking cache drive partitioning Issue Found: Cache drive partition doesn't start on sector 64. You will have problems. See here https://lime-technology.com/forums/topic/46802-faq-for-unraid-v6/?tab=comments#comment-511923 for how to fix this. NOTE: Currently there may be false positives associated with this test

noah-diagnostics-20180315-2021.zip Here ya go! Shoot me whatever syntax you had in mind...

Unfortunately not at the moment, at work...... Give me 10 -12 hours? :-)

Looking forward to it, send it over when you have time and I will run it tonight for you.

I upgraded to 6.50. from 6.4.1 last night, and the upgrade went fine.... However, prior to that I noticed (IIRC) that Common Problems had an update that offered one new item, a script that offers a check list for upgrade compatibility (6.4.1 -> 6.5.0 for example), I thought it would be good to update and test it out prior to the upgrade. Everything came back clean except for my cache drive, complaining that my SSD cache did not start on sector 64, with a link to a process of moving items to array, formatting, and moving back (on at least 6.4.0). My SSD in a Samsung PM961 512 GB NVMe drive formatted as btrfs (originally formatted by unraid in 6.3.5). Up until now, coming from 6.3.5 to 6.4.0 to 6.4.1 I have had no issues with it not being detected, but I figured why not, this is pretty straight forward. So I followed the advice, and: - Marked cache shares to move to array - "moved" - stopped array and changed to XFS for my cache, formatted, then changed back to btrfs and formatted - started array - ran script, still error 64 - stopped array - unassigned cache - started array - performed upgrade - added ssd back as cache, was picked up as btrfs - did the same mark to xfs, format, mark as btrfs, format - still sector 64 So with the above, is it really an error or issue here? I am only using unraid, to format/reformat (not UD) the SSD and is continually being flagged for not starting at sector 64, what gives?

Sure do, and your other containers as well.

1.12.0 loaded up fine! Thanks @Djoss Sent you a little bit (more)

Super cool! Downloading now. Been needing something like this to do a mass cleanup on my library, this adds one more tool to your arsenal.

Thanks!

:-) Is there a way to comma separate the --device string? I just did --device /dev/sr0 --device /dev/sg1 thinking maybe I can --device /dev/sr0:/dev/sg1 ? @Djoss thanks for the log hint, made it a breeze :-)

Are we literally wild carding the third character (sr*, sg*), or is the * representation just an example, users still need to identify the numeric value for their device, then pass it through?