←back to thread

353 points HunOL | 8 comments | | HN request time: 1.289s | source | bottom
Show context
mangecoeur ◴[] No.45782293[source]
Sqlite is a great bit of technology but sometimes I read articles like this and think, maybe they should have used postgres. I you don’t specifically need the “one file portability” aspect of sqlite, or its not embedded (in which case you shouldn’t have concurrency issues), Postgres is easy to get running and solves these problems.
replies(11): >>45782439 #>>45782829 #>>45782906 #>>45782930 #>>45782932 #>>45783524 #>>45784757 #>>45784918 #>>45787275 #>>45788143 #>>45788886 #
1. throwaway894345 ◴[] No.45782930[source]
As a user of Jellyfin, I’m very sad that it doesn’t just use Postgres. I basically have to run an NFS system just for Jellyfin so that its data can be available to it no matter which node it gets scheduled on and also that there are never multiple instances running at the same time, even during deployments (e.g., I need to take care that deployments completely stop the first Jellyfin instance before starting the subsequent instance). There are so many unnecessary single points of failure, and Postgres would make a pretty big one go away (never mind addressing the parallelism problems that plague the developers).

Jellyfin is by far the least reliable application I run, but it also seems to be best in class.

replies(3): >>45784370 #>>45786762 #>>45789135 #
2. KingMob ◴[] No.45784370[source]
I gave up on Jellyfin after media library updates kept hanging on certain video files, and switched to the original Emby it was forked from (iiuc).

Emby has a scarily-ancient install process, but it's been working just fine with less hassle.

3. ants_everywhere ◴[] No.45786762[source]
I have the same experience. SQLite has been a source of most Jellyfin problems, and Jellyfin has more problems than the rest of the ~ 150 containers I run regularly.

A stateless design where a stateless jellyfin server talks to a postgres database would be simpler and more robust.

replies(1): >>45787739 #
4. throwaway894345 ◴[] No.45787739[source]
Yeah, honestly I’m kind of thinking about a media server architecture that has a stateless media server that vends links to pre-transcoded media in object storage (which video players would source from), since pretty much anything can handle mp4/h264/acc video. Maybe in the future I could add on some on-the-fly transcoding (which would happen on a dedicated cluster, reading and writing to object storage), but that seems like a pretty big undertaking.
5. apitman ◴[] No.45789135[source]
You're from the current generation of selfhosters, which culturally is very similar to kit car builders. The next generation of selfhosters/indiehosters just want a car to get from point A to point B. Sqlite is better for those people.
replies(1): >>45790425 #
6. throwaway894345 ◴[] No.45790425[source]
That’s a bit of a strange argument considering all the hoops one needs to jump through to make Jellyfin work on account of Sqlite. I just want to run the software I use on the computers I have.
replies(1): >>45790876 #
7. apitman ◴[] No.45790876{3}[source]
You're having issues because you're trying to shoehorn it into your desired architecture. Most people just want to run an app on their Windows laptop and start streaming their videos.
replies(1): >>45792506 #
8. throwaway894345 ◴[] No.45792506{4}[source]
Maybe that’s what most users want, but that’s not what the software was designed to target, judging from all of the documentation and marketing. But yes, clearly the software wasn’t designed to run in a distributed fashion, and that’s kind of the point of my criticism—they had to go out of their way to couple their application in a way that precludes distributed execution. Well designed server software is trivial to distribute, and even if you never run it in a distributed configuration it makes it easy to do the basic parallelism described in this article.