Debian 13 cleans /tmp, and Plex's EAC3 transcoding dies ten days later

EAE's watch folder is not a cache Plex can rebuild on demand. It is the interface between two processes: Plex drops audio in, EAE picks it up and writes the converted file back ^[2]. Both ends resolved that path once, when plexmediaserver started, and nothing in the running system re-checks it or touches it to keep it fresh ^[18]. That makes it durable state parked in the one directory the operating system reserves the right to empty.

The reaping rule is stricter than it sounds. systemd-tmpfiles removes an entry only when its access, modification and change times are all past the threshold, and the shipped rule sets that threshold at 10 days for /tmp ^[5][4]. The clean timer runs 15 minutes after boot and then once a day ^[5], so the gap between the last EAC3 transcode and the directory going away is 10 days plus up to a day of timer latency ^[14]. A household that hits Dolby Digital Plus content most weeks keeps the timestamps warm and never learns any of this ^[19]. One that mostly direct-plays does not.

Diagnosis then works against the operator. The client says "Conversion failed. The transcoder failed to start up." ^[6], which describes nothing. The signature the dev.to writeup gives is exit code 187 alongside "EAE watchfolder is not writable" in Plex Media Server.log ^[7], and confirming the cause means leaving Plex entirely to ask when the clean timer last fired ^[12]. Restarting plexmediaserver recreates the whole tree and EAC3 works again at once ^[20], which is why so many threads end in a shrug ^[21]. The restart is also what destroys the evidence, and the fault cannot return for another 10 days ^[15], long enough that nobody still believes there is a pattern.

None of this required a vendor to ship a bug. Debian 13 enabled automatic /tmp cleaning by default, and hosts that ran for years on Debian 11 or 12 acquire the failure mode by upgrading, with no Plex setting touched ^[17]. The lifetime of one application's IPC directory is now decided by another project's default, and the only party that knows the directory matters is a daemon that never mentions it again after startup ^[18].

The prescribed exemption is one file in /etc/tmpfiles.d ^[8], and the case of a single letter carries the whole fix. Lowercase x spares the path and everything beneath it ^[8]; uppercase X spares only the directory while its contents keep ageing out, which reproduces the outage with the pms-* parent still standing ^[9]. Because globs in exclusion rules are evaluated when cleaning runs ^[11], the rule keeps matching after a restart mints a new per-instance UUID in the path ^[16]. Worth verifying that systemd actually loaded the drop-in rather than assuming it ^[10], since the failure it prevents is invisible for ten days either way.