The long road to Jellyfin
January 19, 2026
Last week, I mentioned that we at home use Jellyfin. Jellyfin is fantastic, open source, keeps your privacy, but nothing, not even Jellyfin, is perfect. I’ve heard bad things about it and we do have our complaints, such as its docker container using 4GB of RAM even when nothing is playing and while casting it ignores the chosen audio language, but it does strike a good balance between functionality and privacy.
The great thing about open source is that you can fix everything yourself, if you have the time.
Disuse
Jellyfin’s container runs on our home server, a Debian LTS machine that runs a few other things, like a Matrix server with Signal and WhatsApp bridges, WireGuard and MediaWiki. That last one is what I’ve been using since June 2013, among other things, to make notes about how I set up the server and the software running on it.
I dedicate a page with configuration and maintenance logs for each container or other piece of software, and when I stop using it, I don’t delete that page. It’s mostly text, so that’s not expensive, and to make sure it goes out of my way, I have a little procedure for those pages:
- At the top of the page, place a {{ Warning|Removed due to/Replaced by [[Application]] by date }}.
- Replace all categories with [[Category:Disuse]] so that the page no longer appears in category searches
- Remove all occurrences from Template:ToDo so that they no longer appear when enumerating the tasks and suggestions
I’ve been self-hosting since before I started this blog, but I kept my notes in a file hierarchy then, which I integrated into the wiki in 2013. But because the wiki goes back thirteen years now, the [[Application]] link in the first of the three points above gets me a complete history of what I’ve been using, when I stopped using it, why, and what replaced it. And it appears, we’ve been hopping media servers for years before we landed on Jellyfin.
Solutions
Plex is what we started with, around 2010, when we bought our first smart TV, from LG. It had a Plex app, so we looked up what Plex was and installed it. It worked brilliantly, and we used it for years, until we suddenly had to create an account to keep using the server software.
That didn’t sit well with us, so we looked around for open source solutions, and in December 2015 we landed on Mediatomb. Mediatomb implemented the UPnP MediaServer v1.0 so we could use the DLNA app on our TV and on other devices.
I know DLNA is a very simple protocol that is far from secure, but it’s very convenient.
Closing in
Mediatomb did not have the transcoding facilities that Plex had, so we landed on BubbleUPnP Server in May 2017. I have no collection of that, my notes are very brief, and they don’t mention why we moved to Serviio in September that same year, but according to their webpage, Serviio talks to LG TVs, which must have meant a lot for us.
Never judge software by its screenshots. Serviio appeared very good with video, not so with audio, so for the third time in the same year, we switched, this time to then free and open source Emby, which did both audio and video well, had many plug-ins and did DLNA. In 2018, Emby decided to publish all their future releases as close source, but, according to my notes, it took me until August 2021, when its DLNA just stopped functioning, to switch to Jellyfin, an Emby fork that is fully open source and has functioning DLNA.
The great thing about closed source is that if something inexplicably stops working, you can rant and complain as much you want without feeling any responsibility.
Jellyfin can transcode but not over DLNA, so when I rip a disc I use MPEG4 and MP3. Our current TV is growing a bit old, but given a high enough bitrate, MPEG4 is fine, and Jellyfin will cast 1080p without problem. From a docker container on my home server that is. The framerates appeared a bit much for that poor Raspberry Pi 4 that I ran it on before.
Famous last words
January 15, 2026
Me: “What are all of you using to sync your calendars? Radicale and Baïkal don’t work.”
Someone else: “Nextcloud and system account.”
Me: “Thanks”
Another helpful person: “Radicale does for me, so if it doesn’t it might be a server issue instead”
Me: “I’d really love to avoid Nextcloud and go back from Baïkal to Radicale. Do you have a docker run
command or yaml file for me, or do you run it natively?”
A third helpful person: “any particular reason you are avoiding nextcloud?”
Me: “Unix philosophy. One thing per goal, and also bad experiences with Nextcloud: lots of maintenance work for bad synchronising, but admittedly, those experiences are years old.”
Those experiences were in fact from before I used containerisation on my home server. This generally worked fine, but Tiny Tiny RSS, PiWiGo, Nextcloud and Mediawiki (seriously, PHP is the most important language, and I’m not even mentioning WordPress) all had to share a single version of PHP. And that did not work fine, as each of those had their own PHP version and configuration requirements, which meant that synchronising the pictures I took with my phone didn’t always go smooth. I have configuration reports in my personal documentation that, if you read it, would have *you* pull your hair out in frustration.
When I started using Docker, I had long given up on Nextcloud. In 2020 someone on Reddit mentioned Syncthing and I never looked back.
Until now.
If Ubuntu Touch’s calendar app does not talk to Radicale and inconsistently to Baïkal, it won’t hurt to take a Raspberry Pi out of the drawer, put Nextcloud on it, an see if that works, I overheard myself thinking.
Baïkal is so slow that Gnome kindly offers to take down Thunderbird each time I create a calendar item anyway. Serves Thunderbird right for communicating synchronously, I suppose.
Yes, my KDE excursion didn’t last long, but that is for another post.
Nextcloud’s calendar solution is much more convenient than either Radicale’s or Baïkal’s. In Radicale, to share calendars, you have to create symlinks on your server. In Baïkal, you have to log into its separate caldav maintenance site. With Nexcloud, you open a calendar and tell it with whom to share it.
But Nextcloud does more.
Jellyfin, when run in Docker, can either cast over DLNA, or be found by Nginx and/or WireGuard. Yet, we use Jellyfin in this home, but why, is for another post. So some time ago I put Jellyfin on a Raspberry Pi instead, which meant we could cast at home and I could listen to my Bach CDs at the office.
Sadly, the Raspberry Pi was too slow for some of the movies we wanted to see last Christmas, so I put Jellyfin back in a Docker container on my home server. This meant Jellyfin could cast, but wouldn’t be available when away from home.
Nextcloud, I noticed, can mount files over ssh and has a music player. It works brilliantly. Problem solved.
Regular readers might wonder what happened to my paper calendar. Apart from the fact that it ended on December 31st and I didn’t buy a new one yet, I also got tired of effectively using two calendars and having to manually keep them in sync, so that didn’t last very long either.
So now I’m using Nextcloud again, for the first time in six years, and I’m still not running it in a container. I’m not going to upload my pictures to it, since Syncthing puts them in a directory of my choosing without going through a server, which is simply too convenient. My Ubuntu Touch phone’s calendar app is happy now and I only have to make sure not to install many more useful Nextcloud apps.
I wonder how that will go.
Re: Thinking about email workflows
January 12, 2026
In 1993, when I was still blissfully unaware of the internet, Amsterdam based hacker club Hack-Tic founded the (locally) legendary internet service provider XS4ALL. They were late to the game. Five others had beaten them to it, but since their founding, XS4ALL were always fighting for things such as internet privacy, net neutrality and free (internet) speech, in partnership with NGO Bits of Freedom. They also sponsored projects like Python, Debian and SquirrelMail. XS4ALL had ipv6 before anyone else and static IPs were standard. I wanted to be their customer, but they were also a bit more expensive than others.
What does this have to do with my email workflow?
Well, in 1998, years before I started using Gmail, XS4ALL was sold to KPN, and in 2019, when I wasn’t using Gmail any more, KPN decided to finally integrate XS4ALL. By that time I was in fact a customer and KPN was a company that tried very hard how to suck at internet the American way, so I wasn’t the only one unhappy with this situation. A group of customers actually founded a new ISP, Freedom internet, that has become the moral successor to XS4ALL. Obviously, I was one of their original customers and still am. I also invested financially in them.
When you run Internet facing server software at home, like this blog, and you do a small but slightly too careless migration and your ISP tells you your git(1) history is world readable, you figure they are looking out for you. They confirm your trust in them. This is why they do my email. They have web clients, but I use Thunderbird, which is the Firefox of email clients. Perhaps I should give Emacs a try. As for my inbox, I do the same thing that Wouter does: I archive what makes me smile and delete anything else when I’m done with it.
I used Gmail for over a decade. The emails stored there are so old now, they don’t contain anything that could be considered a privacy leak any more, so I’m not deleting it. The auto reply doesn’t even mention one of my new email addresses.
When I say Freedom does my email, I mean most of it, because the email I use for this blog I receive at home. This is also the address I use to subscribe to mailing lists. Because they go through my own server, I can do a rather nifty thing with them. I take them apart and convert them to RSS feeds, so that I can import them in FreshRSS, my feed reader. I find FreshRSS more convenient to consume blog posts and articles than an email client, which is, after all, meant for conversations. It use a script that you can find here, with instructions, if you want to do the same.
I wonder if SquirrelMail still runs.
I’m back
January 08, 2026
Let’s say, you’ve been daily driving Ubuntu Touch for a few weeks and it kind of seems to work for now and around the same time on your PC you really miss grabbing windows easily so you’re returning from Gnome to KDE, which apparently also means going back from pass(1) and git(1) to KeePassXC and Syncthing.
Funny how one choice leads to a lot of others, sometimes.
Switching from KDE to Gnome early last year wasn’t because I found Gnome that much better. It was quite different from KDE, but it was the little annoyances, like not easily switching between audio outputs, that was so elegantly solved in Gnome, that made me bite the bullet and switch.
Selecting audio outputs in KDE
Using Gnome for about a year made its own little annoyances surface. I was moving files by cutting and pasting instead of dragging them, and at some point I actually copied a file while trying to move a window. This madness has to stop, I heard myself thinking, and I installed KDE, re-logged and noticed that switching audio outputs was taken care of.
Pass is a command line password manager that uses git(1) to synchronise between devices. It stores each password in its own GPG encrypted file and uses a folder hierarchy for storage and fast and easy retrieval, especially with excellent fish (and bash) tab completion. For Android, there’s at least an unmaintained app that works. For Ubuntu Touch, there is one as well, UTPass. It is maintained, but for as long as I remember, it has a bug making it show just a white screen instead of its UI. Many of the apps for this platform are maintained by a single person. UTPass is no exception.
To my surprise, after logging into KDE, pass(1) didn’t really seem to work here either. Just doing a pass -c something popped up a window asking for my password (fair enough) but then pass(1) would just sit there without giving me my password or my prompt back, as if something was getting in the way.
Unsure what was going on, I took a long hard look at my phone laying next to the keyboard and decided not to spend the time troubleshooting why gnome-keyring was still active and probably screwing up ssh-agent, but to take the opportunity to again install KeePassXC, the last password manager I used before switching to pass(1).
Let’s go
There was one small problem though. While there are plenty of scripts to import passwords to pass(1), exporting from pass(1) to KeePassXC appeared not already facilitated. So I spend the afternoon creating a python script that traversed my ~/.password-store, decrypted all the GPG files and put everything in a CSV file that KeePassXC would accept. You can find it where I publish my code.
After some debugging, the script worked, and I could import my passwords into KeePassXC. I added a folder to the directory that I share with all my devices using Syncthing and put the password file there. Then I opened up the Open Store on my phone to install KeePassRX, finding that an update for UTPass had become available, fixing the white screen bug.
I wonder whether I will keep using KDE or that new or old annoyances will (re)surface, making me escape back to the windows with too crowded title bars and with corners that are so round that, a couple of years from now, they will probably be circular.
On PostmarketOS and Ubuntu Touch
December 22, 2025
The other day I was listening to the latest PostmarketOS podcast in which they spoke about their participation DEFCON 33, WHY 2025 and FrOSCon 2025, and it sounded like they had fun, sold merch and got stickers. They also briefly mentioned that a meaningful difference between Ubuntu Touch and their own PostmarketOS is that the former still uses a layer of Android for hardware abstraction (Halium) while they themselves attempt to go without that.
Ubuntu Touch uses Libhybris to talk to Android HAL
They didn’t mention it, but this could be what makes porting devices to PostmarketOS very much harder than for Ubuntu Touch, as indicated by the number of devices offered on both sides with full and complete hardware support. Ubuntu Touch has many, PostmarketOS just one, the Purism Librem 5, a device that wasn't build with Android in the first place. GPS fixes with Ubuntu Touch can take some time, but the warning notice about that is just to prevent disappointments. I have a OnePlus Nord N10 that gets a GPS fix within half a minute. Although much slower than with phones tied to Google or Apple, this really is fine.
Sharing pictures
Another thing they mentioned was that people who daily drive Linux phones always find workarounds for what they’re missing, such as actual snapshot cameras. I do that too, but not only won't let it me share immediately the pictures I took, I also cannot show them on my phone when I'm with someone. But while hardware problems mire PostmarketOS, it’s the state of the software that is Ubuntu Touch’s problem. Native apps are few and far between, and more than a few need fixes and updates.
The default calendar app sometimes ignores timezones, the running tracker doesn’t reliably track runs, the contacts app doesn’t sync contacts and sharing images to the matrix client doesn’t work, to name just a few issues. It particularly doesn’t help that PostmarketOS apps don’t run on Ubuntu Touch (and vice versa). You can install snaps and even NixOS packages, but those are hit or miss. With so few apps, there will typically only be one app for each of your use cases, if at all, and if that one doesn’t suit your needs, you’re out of luck.
Great, but not too great
Just yesterday, at an orchestra rehearsal (I always have a lot of those at this time of the year, which is precisely why I’m blogging less at the moment) a friend told me he ditched his smartphone altogether. Too many stimuli, he said. I think that is great, if not outright brave. Sometimes I’m in a shop wondering why my payment isn’t accepted and realising I didn’t put enough money in my account. Not having a smartphone means not being able to correct that then and there.
But you don’t just use smartphones for yourself. My friend is in fact the ensemble’s project leader. Today I spoke with someone else from his team. She told me that she and others now have to send him SMS text messages, while the rest is reading everything in their WhatsApp group. So now everyone has to type everything twice, which often turns out to mean that he misses things.
Perfectly
I like to tinker with technology and am generally okay with things not working perfectly for myself, but often I don't have the time and things do need to work. I also need people to be able to reach me without it becoming too much work for them. So even though PostmarketOS gives me more freedom, Ubuntu Touch is in fact more suited for me. And adb(1)’ing into a phone and then adb(1)’ing from it’s own terminal into a virtual LineageOS device running on it (you’ve got to have a banking app) is just funny. And now that I can use Matrix for WhatsApp and Signal. I could probably daily drive my N10.