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.
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.
I’d argue perhaps the opposite: if you want full moderation and admin freedom, running it on your own instance is the only way to do it.
If you run it on someone else’s server, you’re subject to someone else’s rules and whims.
Granted, I have zero reason to think the admins of any of those listed instances would do anything objectionable, but that’s today: who knows what happens six months or a year or two years from now.
Though, as soon as you start adding stuff to your personal instance, you’re biting off more maintenance and babysitting since you assumably want your stuff to be up 100% of the time to serve your communities, so that’s certainly something to consider.
Cloudflare tunnels are the thing you’re looking for, if you’re not opposed to cloudflare.
You run the daemon on your local system, it connects to cloudflare, and presto, you’ve bypassed this entire mess.
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.
Considering what’s going on in the world, I for one would certainly love to hear from someone who’s done the emigration thing more than once.
Very relevant to my interests going into 2025, that’s for damn sure.
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.
Listen, is it really a 3d printer hobby if you don’t have 5 or 6 printers, none of which could actually print anything, and five boxes of parts laying around for you to fix your printers?
Oh also see above while planning another printer project, because none of those printers will do something you might want to do.
(/s, kidding, etc, but there’s That Guy somewhere, and you know who you are.)
Oh, that’s neat and I can certainly see why that’s useful.
I have to do a little gcode header swapping by hand because I’m cheap and bought a p1p and am certainly making it do things it’s not really designed to do, and that kind of functionality could save a bit of time.
Man, I wish this had been a thing ~8 months ago when I was building these for my stuff.
…mine are awful, and these look awesome, so maybe it’s time to re-do that.
What is a macro in this context that requires custom firmware?
My googling makes it just look like gcode stuff to work around hardware issues, but I’m confused how that requires Klipper, since you can drop any gcode block you want into any slicer I’ve ever seen?
I was just curious if they had done their own thing. Some companies just ship Cura, some have done their own thing, and I wasn’t aware of which way they went.
I’m not a giant Cura fan* so was just curious.
(* Cura has the problem of trying to be everything for everyone and to do everything anyone ever might want to do, and ends up just being… a bit much.)
The software was easy to pick up.
Are they shipping something other than Cura?
I’m a fan of the Bambu printers because they just simply work.
You want to print something, they print something, done.
If you want to fiddle, then they’re the wrong printers, but if you want to model shit and make things then they’re really hard to beat right now.
And, yes, I have reservations about the closed sourced nature, but honestly ask yourself: are you going to contribute to the code? Are you going to build your own firmware to run on your printer? If the answer is no, then that’s probably not really a concern that should be driving your decisions.
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.