If you run it on a container, it should be enough to just make a copy of the set up volumes, right? (with permissions and all the metadata kept of course)

Matrix is newer, afaik it is used by more foss projects for communication than xmpp, and it has a more widely accepted standards base for things compared to xmpp, where I have often heard that it has multiple different implementations for things like voice calling and encryption which are incompatible with each other. Don’t take my word on it, but I hope that at least by reading this those interested can search for the issues and whether they are valid.

But then, what do you mean by xmpp being easier to host? I’m not familiar with XMPP hosting.
Matrix requires a home server, and a database server. If you want voice calls it also needs webrtc voice infra.

Wow, what kind?

That’s sounds cool!

Though I have to ask something. Does the LG store manipulate the app in any way after you upload a release to them?
Asking because there are some weird stores that do so, like the amazon android app store embeds data mining (stated in the tos).

Because if they do, then homebrew is still a better way, even if I have to click a button every 3 weeks (even though it isn’t needed, it can be scripted)

You also need hardware behind the client, for it being able to do hardware decoding. Unless you want the server to constantly transcode everything you watch, for all phones and PC clients…

I don’t think unmounting in itself does any difference to it’s longeviy. I think what you want is powering it down.

There’s a Jellyfin app for webos, but the garbage store does not really let them to publish/update it. You can get an up to date version from the store app called Homebrew Channel.

This store app can also handle rooting related things, but that’s not needed for Jellyfin, and both can be installed on a nonrooted TV.
That’s an other question that the TV will regularly delete these apps until you root it… but take it as an “evaluation period” haha, if you like the app there are a few ways to make the app persistent.

Maybe this is the solution. If they can’t be trusted to behave, they’ll be able to see the pictures at the next family gathering.

Containers have to run somewhere too…

but scrubbing still is SLOW, 10 seconds ahead takes 20-30 seconds to do

Probably because your TV needs the media to be transcoded, but not sure what’s wrong there as it’s much smoother here on a Ryzen 1200 (!), media being read from HDD (!), with no help from a GPU. When you skip ahead to a part that hasn’t yet been transcoded, the process needs to start over basically, and that always takes a few seconds, maybe for keeping a minimal buffer but not sure about that, but it really shouldn’t take that much time.

Obviously JF doesn’t continue where I stopped

Not sure how you kill the app, but if you actually kill it, it has no chance to save where you were if it wasn’t able to do so continuously. These 2 might be implemented differently by the client, so the “success rate” may differ. Though, so far every time I was casting it (not to chromecast, but to various jellyfin clients) it followed nicely where I was, that may work differently in devices made by certain user-hostile companies. I don’t know that.

Jellyfin cannot play a movie or show without stuttering at least a few times, flat out freezing for minutes during shows, especially in the second episode for that day… If I run transmission in parallel, it just freezes up so much that it’s undoable.

That’s just resource exhaustion. If your system is overloaded (even if just the media disk’s queue being full) Jellyfin can do nothing with it. Either move other IO-heavy processes off of that disk, or set them to a lower IO priority (or Jellyfin to higher), or try a different IO scheduler, maybe also apply more of these if needed.

System utilization was near zero.

Where do you measure that? Did you look at disk utilization stats? Or how much the CPU has spent on waiting on the disk to respond? This last stat is called “iowait”, you can graph it in e.g. btop/bpytop, or see details in iotop-c/iotop (former of both is better when available, but linux-only tools).
If you are using for server for other things too, you might want to look into a monitoring system with grafana, prometheus and node exporter. It records a lot of different stats, most of which you won’t use, but cpu stats including iowait, memory stats including used and cached, and the like can be very useful in these situations. Sometimes there’s a bottleneck that’s not obvious without seeing how a stat was changing over a longer time or out of context, and depending on what monitoring too have you used so far, it might have not shown you important things like aspects of disk utilization. Enterprise grade drives can also have poor performance in certain situations.

Edit: Really? 17 downvotes? I’m trying to tell you that the thing doesn’t work and that I’ve spent plenty of time trying to fix it, reading docs, posting questions, nothing has fixed anything so far but can’t have people talk about that, or what’s wrong?

I’m honestly sorry for that instead of everyone else. I think it’s just that we haven’t experienced problems like these, and you were a bit harsh, in the sense that you are confidently saying it’s Jellyfin’s fault, where it is probably something else.

If you feel like it, you could keep testing it “in secret” (not from us, from your wife), and when you have fixed it and been going stable for a week or two announce to her that you found the problem, it was on you (if it was), and now it’s much better, and reintroduce it to “production” use.
Though it’s a bit weird that besides perf issues, if I understand right you also have major bugs. If you only tried it with the chromecast, test it with normal jellyfin clients (web client, desktop client, mpv shim, tv app, whatever you like), and see if it’s better there. I suspect it has to do with the chromecast.

Yes, but if using an android phone, the Aegis app may be a better choice. Guaranteed to not have tracking, and secrets are encrypted