- cross-posted to:
- jellyfin@lemmy.ml
- cross-posted to:
- jellyfin@lemmy.ml
goal to remove 32-bit ARM support in 10.11.0
I’m still running jellyfin on a rPI 2, performance is not great but not too bad either. Maybe it could be an excuse to finally upgrade my hardware.
I see Jellyfin, I insta upvote
Last time I tried it it was a much worse experience than Emby across all devices and for all media types. I don’t understand all the love it gets.
Worse how? Jellyfin was forked from Emby, and since then has continued to improve in my eyes.
It was forked but somehow lacked a huge amount of functionality that Emby had (and still has) Like I think it only supported films, not music or TV shows. The app infrastructure was awful across fire stick, Roku and android and wasn’t backward compatible with the Emby apps. I just didn’t see the point of forking it if you’re just going to make it worse or only address the server side and neglect the clients. The whole thing has to work together with good clients and server.
Looks like you need a closer view about actual functionality. Jellyfin supports movies, tv-shows, music (there are also apps just for music), e-books and live-tv.
Jellyfin has supported Music and TV shows since the start
It’s free and open source. That alone is a big plus. And it works fairly well. What does emby do better, that warrants paying $120 for it?
I haven’t paid anything for it
As I need hardware transcoding, that makes emby immediately non viable for me. I also usually watch via various apps and on tv, which, if you don’t have emby premiere are also not free to use.
I am loving the new release cadence!
Shame about the network location regression. That’s the only thing that keeps my kodi device from taking 5-15 seconds to load each sub menu.
What’s this about? I didn’t hear anything about it.
I just setup Jellyfin on docker the other day for the first time.
It just occurred to me that I don’t know how to update docker.
Any advice?
no need for
docker compose down
.pull && up
is enoughAlso depends on how you specified image in the docker. If it has no version or latest as version it will update otherwise it may be fixed
You could use a systemd unit file:
[Unit] Description=docker_compose_systemd-sonarr After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 WorkingDirectory=/var/lib/sonarr ExecStartPre=-/usr/bin/docker compose kill --remove-orphans ExecStartPre=-/usr/bin/docker compose down --remove-orphans ExecStartPre=-/usr/bin/docker compose rm -f -s -v ExecStartPre=-/usr/bin/docker compose pull ExecStart=/usr/bin/docker compose up Restart=always RestartSec=30 [Install] WantedBy=multi-user.target
You’d place your compose file in the working dir
/var/lib/sonarr
. Depending on what tag you’ve set for the image in the compose file, it would be autoupdated, or stay fixed. E.g.lscr.io/linuxserver/sonarr:latest
would get autoupdated whereaslscr.io/linuxserver/sonarr:4.0.10
would keep the container at version4.0.10
. If you want to update from4.0.10
, you’d have to change it in the compose file.Check out Watchtower! Auto-update your containers. Don’t forget to set WATCHTOWER_CLEANUP to true, or your disk will be filled with old images.
Thanks! I’ll check that out, I’m really loving how quick and easy docker has been so far.
Did you use docker compose file or just run a command to start the container?
Edit: I always use compose files. For that you can do the following:
docker compose pull docker compose down docker compose up -d
You don’t technically need the stop, but I’ve found once or twice in the past where it was good to stop because of image dependencies that I forgot to put in my compose.
For running a command directly I found this website that seems to summarize it pretty well I think:
https://www.cherryservers.com/blog/how-to-update-docker-image
Yes, I used docker compose. Do I need to do anything to clean up with this method?
Now that you mention it, I always do a
docker system prune -f
This will clean up old images that are no longer used. I setup an alias command in Linux to do all of those commands.
I just named it docker_update and saved it in my ~/.bashrc
I see someone mention watchtower, while not a bad thing, I just prefer to manually update. This helps to ensure any breaking changes don’t break my system. Especially with something like Immich at it’s had a lot of them recently as they work towards stable. I just generally subscribe to their release and do updates as necessary.
And there are breaking changes in this Jellyfin release.
If you set up using compose and don’t have the version pinned:
dockee compose down && docker compose pull jellyfin && docker compose up -d
What about if I am using Podman and have the container as a systemd unit file?
Podman supports auto updating natively by setting a label.
I use systemd service files for running containers, but you can add the same label on the command line or in quadlet files.
Jellyfin has been rock solid for me, especially since the move to .NET 8. Looking forward to this release.
I rate it a 10.10.0 out of 10.