An unattended disc ripper that refuses to file anything until you confirm

Building an unattended ripper is easy. Building one you can trust is a different problem, and it comes down to a single design decision: what happens after the rip?

The naive version files straight into the media library. It fails in one specific, recurring way.

The label is not the title

Disc labels are unreliable. Some are fine. Some are DISC_1. Some are an abbreviation that means nothing. And audio CDs have their own version of this problem: MusicBrainz will confidently match your single-disc album to a later two-disc reissue, and you will not notice until you play it.

Once a mis-titled file is in the library, the media server has indexed it, and correcting it means a rescan. So the fix is not better guessing. It is not filing automatically at all.

The shape that works

close tray
  -> udev event
  -> systemd oneshot starts
  -> detect media type (audio CD vs video DVD)
  -> rip into a staging area with temp names
  -> write manifest.json (label, type, durations, suggested title)
  -> eject
  -> STOP

Nothing touches the library. A human (or an agent) reads the manifest, confirms the real title and year, and a second script files it with clean naming and triggers a library scan. Only that second script can write to the library.

The gate is the product. Everything else is plumbing.

Three details that decide whether it works

Classification has to survive decoy titles. DVDs pad their title list with decoys that share the same length, as an anti-piracy measure. So dedupe by duration and count distinct durations: three or more distinct episode-length (roughly 15–45 minute) durations means television; otherwise take the longest title as the feature.

Do not trust the ripper's own scanner for the title list. HandBrake's scan reported zero valid titles on a disc that a dedicated disc-inspection tool enumerated perfectly. Use the dedicated tool to list titles, then hand the chosen title number to the ripper.

The event must come from the kernel, not from you. A synthetic device change does not reproduce a real tray-close; that flag is only set on an actual insertion. If you are testing the trigger and nothing fires, that is usually why — go and physically reinsert the disc.

Do not let it run at boot

If the systemd unit is enabled normally, it also runs at every boot, finds no disc, waits out its timeout, exits non-zero, and marks the node degraded. The udev rule is the real trigger and still fires with the unit disabled. Enable the rule, disable the unit's boot start, and stop chasing phantom failures.

What it gives you

Close the tray, walk away, come back to a staged rip waiting for one decision. The cost is one confirmation. The alternative costs you a library you cannot trust.

← All writing