non_burglar

I don't disagree that logrotate is a sensible answer here, but making that the responsibility of the user is silly.

Sorry, maybe that was a knee jerk.

Don't get me wrong. I like jellyfin and I try to use it over Plex most days. But it does have out-of-the-box issues.

I've installed jellyfin several times with both docker and bare metal methods over the last 4 years. The transcodes have been an issue every time.

Maybe its my usage, but watching roughly 5 episodes of a show fills up roughly 3gb of the /var/lib/jellyfin/transcodes folder. In a 4gb container image, that's death. Jellyfin is the only container I need to expand to 16gb to adequately deal with this.

The default transcodes cleanup task is limited to every 24h at smallest interval, the option "delete segments" does absolutely nothing (I've watched).

Did you read my comment?

If you are referring to fastboot oem unlock, there are almost no phones that don't have dual or even triple bootloader partitions, so that won't work by itself.

click the buttons on the web page

I wouldn't trust a chrome USB TTY permission to touch anything hardware of mine.

Although I have my issues with plex, jellyfin has its own problems:

• STILL can't clear out the TS transcoded files automatically. So if you watch a bunch of TV episodes on a weekend, your jellyfin container will run out of space and break.
• STILL can't handle subtitles properly. I swear, this must be jellyfin's Waterloo.
• jellyfin cannot demux 5.1 and present stereo sound on certain streams. I think this is a tooling issue. But it's low level enough that I can handle it manually with mkvtoolnix myself on the few cases it happens.

Flashing the phone's bootloader and image is still done with adb and fastboot, but unlocking the bootloader is by now pretty much done with tools only made for windows.

Mostly this is because the exploits use factory flashing tools provided by manufacturers, which are nearly always windows.

Have... Had you not heard any Linus rant before this? This is pretty tame.

These projects are poorly maintained and abandoned because the industry of email has been reduced to a very few players, and they don't care about IMAP standards, dmarc, dkim or any of it.

You're running head on into the primary reason no one self-hosts email anymore; it has gone from being a nuisance to being adversarial.

Oh, nice. Thanks!

This is me showing my docker ignorance, I suppose.

I just snapshot the parent lxc. The data itself isn't part of the container at any level, so if I bung up compose yml or env, I can just flip it back. The only real benefit is that all my backups are in the same place in the same format.

Like I'm not actually opposed to managing docker in one unit, I just haven't got there yet and this has worked so far.

If I were to move to a single platform for several docker, what would you suggest? For admin and backups?

Lxc and docker are not equivalent. They are system and software containers respectively.

I use individual lxc for each docker compose so I don't have to revert 8 services at once if I need to restore.

I would also argue that an alpine lxc runs in 22mb ram by itself ... Significantly smaller footprint on disk and in memory. But most importantly, lxc can actually share memory space effectively, one doesn't need to reserve blocks of ram.