I don’t disagree, but if it’s a case where the janky file problem ONLY appears in Jellyfin but not Plex, then, well, jank or not, that’s still Jellyfin doing something weird.
No reason why Jellyfin would decide the French audio track should be played every 3rd episode, or that it should just pick a random subtitle track when Plex isn’t doing it on exactly the same files.
One thing I ran into, though it was a while ago, was that disk caching being on would trash performance for writes on removable media for me.
The issue ended up being that the kernel would keep flushing the cache to disk, and while it was doing that none of your transfers are happening. So, it’d end up doubling or more the copy time because the write cache wasn’t actually helping removable drives.
It might be worth remounting without any caching, if it’s on, and seeing if that fixes the mess.
But, as I said, this has been a few years, so that may no longer be actively the case.
If you share access with your media to anyone you’d consider even remotely non-technical, do not drop Jellyfin in their laps.
The clients aren’t nearly as good as plex, they’re not as universally supported as plex, and the whole thing just has the needs-another-year-or-two-of-polish vibes.
And before the pitchfork crowd shows up, I’m using Jellyfin exclusively, but I also don’t have people using it who can’t figure out why half the episodes in a tv season pick a different language, or why the subtitles are somtimes english, and sometimes german, or why some videos occasionally don’t have proper audio (l and r are swapped) and how to take care of all of those things.
I’d also agree your thought that docker is the right approach to go: you don’t need docker swarm, or kubernetes, or whatever other nonsense for your personal plex install, unless you want to learn those technologies.
Install a base debian via netinstall, install docker, install plex, done.
Timely post.
I was about to make one because iDrive has decided to double their prices, probably because they could.
$30/tb/year to $50/tb/year is a pretty big jump, but they were also way under the market price so capitalism gonna capital and they’re “optimizing” or someshit.
I’ve love to be able to push my stuff to some other provider for closer to that $30, but uh, yeah, no freaking clue who since $60/tb/year seems to be the more average price.
Alternately, a storage option that’s not S3-based would also probably be acceptable. Backups are ~300gb, give or take, and the stuff that does need S3-style storage I can stuff in Cloudflare’s free tier.
+1 for Frigate, because it’s fantastic.
But don’t bother on an essentially depreciated google product, and skip the coral.
The devs have added the same functionality on the GPU side, and if you’ve got a gpu (and, well, you do, because OpenVino supports intel iGPUs) just use that instead and save the money on a coral for something more useful.
In my case, I’ve both used a coral AND openvino on a coffee lake igpu, and uh, if anything, the igpu was about 20% faster inference times.
Working rootkit anti-cheat, so I can dump Windows.
Stuttering and texture pop-in makes me immediately wonder if your SSD shit itself.
Maybe see if there’s anything in the system logs and/or SMART data that indicates that might be a problem?
I think the thing a LOT of people forget is that the majority of steam users aren’t hardcore do-nothing-but-gaming-on-their-pc types.
If you do things that aren’t gaming, your linux experience is still going to be mixed and maybe not good enough to justify the switch: wine is good, and most things have alternatives, but not every windows app runs, and not every app alternative is good enough.
Windows is going to be sticky for a lot longer because of things other than games for a lot of people.
A thing you may not be aware of, which is nifty, is the M.2 -> SATA adapters.
They work well enough for consumer use, and they’re a reasonably cheap way of adding another 4-6 SATA ports.
And, bonus, you don’t need to add the heat/power and complexity of some decade old HBA to the mix, which is a solution I’ve grown to really, really, dislike.
The chances of both failing is very rare.
If they’re sequential off the manufacturing line and there’s a fault, they’re more likely to fail around the same time and in the same manner, since you put the surviving drive under a LOT of stress when you start a rebuild after replacing the dead drive.
Like, that’s the most likely scenario to lose multiple drives and thus the whole array.
I’ve seen far too many arrays that were built out of a box of drives lose one or two, and during rebuild lose another few and nuke the whole array, so uh, the thought they probably won’t both fail is maybe true, but I wouldn’t wager my data on that assumption.
(If you care about your data, backups, test the backups, and then even more backups.)
You can find reasonably stable and easy to manage software for everything you listed.
I know this is horribly unpopular around here, but you should, if you want to go this route, look at Nextcloud. It 's a monolithic mess of PHP, but it’s also stable, tested, used and trusted in production, and doesn’t have a history of lighting user data on fire.
It also doesn’t really change dramatically, because again, it’s used by actual businesses in actual production, so changes are slow (maybe too slow) and methodical.
The common complaints around performance and the mobile clients are all valid, but if neither of those really cause you issues then it’s a really easy way to handle cloud document storage, organization, photos, notes, calendars, contacts, etc. It’s essentially (with a little tweaking) the entire gSuite, but self-hosted.
That said, you still need to babysit it, and babysit your data. Backups are a must, and you’re responsible for doing them and testing them. That last part is actually important: a backup that doesn’t have regular tests to make sure they can be restored from aren’t backups they’re just thoughts and prayers sitting somewhere.
I use the *arr stack for deletion, usually.
Lots of people have accounts on the jellyfin/jellyseerr stack, but I’m the only one with access to the *arrs, so I just manage it (mostly) from there.
The only thing I’d mention on the cache is to be a little careful, because depending on your actual use case you can use a LOT of transcode cache space.
If it’s just you, doing one stream, it probably doesn’t matter.
If it’s you, and your 20 closest friends, well, uh, it can be quite a lot and maybe you won’t want it in RAM.
As for the media, a bind mount is the way to go, and I’d also recommend doing it as a read-only mount: Jellyfin doesn’t need the ability to modify that data, and in the event of a security oopsie (or a misconfigured user, or a 6 year old that gets 5 minutes alone with your mouse or…), it keeps someone from trashing your entire media library, assuming that’s something you wouldn’t want to have to spend the time gathering again.
For the user, I just have a ‘service’ account, and run the vast majority of my containers under that UID. Sure, maybe that’s not the MOST secure, but it’s worlds better than root, and container escapes are not exactly common so it’s probably sufficient.
…and if you get DLNA working let me know, because I never have. I just use Jellyfin clients everywhere because that at least does what you expect in terms of showing the media in a usable format and playing it.
I’d also argue it makes it harder to use, period: something that takes me 10 seconds to read somehow ends up being a 5 minute video, of which 90% is fluff that’s not related to the problem.
I’ve yet to land on a tutorial video that gets to the point and doesn’t feel the need to waste a ton of time introducing themselves, a paragraph about what we’re doing, asking me to subscribe, talking about their sponsor and so on.
I lament the death of the text-based tutorial and strongly dislike the youtube format video.
ArchiveBox is great.
I’m big into retro computing and general old electronics shit, and I archive everything I come across that’s useful.
I just assume anything and everything on some old dude’s blog about a 30 year old whatever is subject to vanishing at any moment, and if it was useful once, it’ll be useful again later probably so fuck it, make a copy of everything.
Not like storage is expensive, anyway.
Honestly, I think we’re 3 years out from Windows being replacable for a gaming platform.
Anti-cheat is a big one (sure, there’s “support”, but if none of the games people play are supported, is that support?), but VRR and HDR are also huge.
That trifecta is the only reason I’m still sitting in Windows, and I find myself hopeful we land there sooner rather than later so I can dump Windows and never have to think about whatever dumb crap Microsoft is going to do next.
It is mostly professional/office use where this make sense. I’ve implemented this (well, a similar thing that does the same thing) for clients that want versioning and compliance.
I’ve worked with/for a lot of places that keep everything because disks are cheap enough that they’ve decided it’s better to have a copy of every git version than not have one and need it some day.
Or places that have compliance reasons to have to keep copies of every email, document, spreadsheet, picture and so on. You’ll almost never touch “old” data, but you have to hold on to it for a decade somewhere.
It’s basically cold storage that can immediately pull the data into a fast cache if/when someone needs the older data, but otherwise it just sits there forever on a slow drive.
nVidia released drivers that aren’t a complete tire fire under Wayland.
(It’s more of a regular pile of discarded tires now, but it’s still dramatically better.)
…depends what your use pattern is, but I doubt you’d enjoy it.
The problem is the cached data will be fast, but the uncached will, well, be on a hard drive.
If you have enough cached space to keep your OS and your used data on it, it’s great, but if you have enough disk space to keep your OS and used data on it, why are you doing this in the first place?
If you don’t have enough cache drive to keep your commonly used data on it, then it’s going to absolutely perform worse than just buying another SSD.
So I guess if this is ‘I keep my whole steam library installed, but only play 3 games at a time’ kinda usecase, it’ll probably work fine.
For everything else, eh, I probably wouldn’t.
Edit: a good usecase for this is more the ‘I have 800TB of data, but 99% of it is historical and the daily working set of it is just a couple hundred gigs’ on a NAS type thing.
I agree but also say that learning enough to be able to write simple bash scripts is maybe required.
There’s always going to be stuff you want to automate and knowing enough bash to bang out a script that does what you want that you can drop into cron or systemd timers is probably a useful time investment.