In the last week I've had two friends ask me about setting-up a home media server. Around this same time we had a major outage of one of the basically two ISP's in town of which one of these friends is a customer. This enhanced his interest in setting something like this up.
I have been running Jellyfin on an old Backblaze Pod in the lab for close to a year and I use it almost every day for listening to music while I'm at work. I've also used it to manage and play a few movies using the Roku app, and in general I've been pretty impressed with it, so this is what I'm going to recommend to my friends.
However something like the 'pod is overkill for an application like this so I wanted to experiment with something more reasonable. I happened to have a "Le Potato" single-board computer in the SBC box and since I know it runs Armbian without complaint I thought I'd start there.
Jellyfin runs fine on the 'pod but it has a beefy (if a bit dated) Intel processor, 16GB of RAM and a ZFS array of SATA SSD's. Le Potato has a 4-core ARM SoC, 2GB of ram and an SD card. My main concerns with using Le Potato for Jellyfin are I/O and RAM, but also if there's a lot of transcoding work the CPU could get swamped as well. It also has no cooling (not even a heatsink) so I'm wondering if it's going to get throttled for thermal reasons under load.
The easiest way to find out is to try it, so I picked a software configuration that I thought would be most useful to my friends (and anyone who might want a similar media streaming device):
* Armbian O/S
* avahi-daemon (so the device can be found by name w/o DNS, installed via armbian-config)
* Jellyfin (media streaming, installed via armbian-config)
* Samba (media uploads via shared folders, installed via armbian-config)
Hardware-wise the only thing I used in addition to Le potato was a rando 32GB SD card from the flash drawer.
Armbian provides a number of downloadable images for Le Potato so I downloaded the minimal image, unpacked it and "burned" it to the SD card. I slotted the card into Le Potato, connected it via Ethernet to the network and powered it via USB cable from a 1.4A USB-A outlet. I located it on my network using the management software for my WiFi bridges (it runs the DHCP server) and ssh'd into it using the default credentials of root and 1234.
Armbian provides a configuration tool called armbian-config which handles most configuration duties and does so in a way that doesn't work against the distro. I used this to configure the hostname and install avahi-daemon, Jellyfin and Samba. After a reboot, I could access Jellyfin from a browser using the name I gave the device and the default Jellyfin port (http://kgl-mediapal.local:8096). Jellyfin walked me through the initial setup with no surprises until I got to the Library configuration step.
This was the first snag of the setup. When Armbian installs Jellyfin it runs in a Docker container and by default this container only has access to specific pre-configured directories on the underlying filesystem. What this means is that when you're configuring libraries in Jellyfin, you can only point them to one of three pre-configured paths on the SD card. The preconfigured paths include a "movies" and "tvseries" directory but no music directory, and while you could (ab)use say the tvseries directory to store music, that's likely to confuse someone (possibly yourself) down the road.
I looked into how to make more directories on the SD card visible to Jellyfin but everything I could come-up with would interfere with Armbian's ability to manage the setup. Normally I wouldn't care about this, but since the purpose of this adventure is to make something that other people can use I'm inclined to avoid too much hacky shit. In the end the best answer I came up with was to submit a pull request to the Armbian project to add a couple new media directories to the armbian-config installer. As of now this hasn't been accepted but one can hope.
Since then I realized that a better solution might be to simple get rid of the media-specific directories in the container configuration and simply add a single "media" path under which the end-user can create subdirectories for media types of their own choice. I haven't tested this but I don't see any reason it shouldn't work, and it would be much more flexible than the current configuration or my proposed changes.
To continue the experiment I chose to (ab)use the tvseries directory and use it for music since this is a temporary setup and I don't want to wait until the PR is merged to continue.
The next step was to copy some music and movies to the device. There's many ways to do this but again since I'm making this for other people I wanted to select the way most likely to work with the widest range of other devices. As much as it pains me to admit it, "Windows file sharing" is the most universal easiest-thing-to-use for this task as every O/S I know of can "mount" a Windows-style shared folder. Fortunately the Samba software package provides exactly this functionality and is easily installed via armbian-config.
Once Samba is installed it needs to be configured to share the media folders with the network. This is probably the messiest part of the setup, but the default configuration requires minimal changes to get the job done. The changes needed amount to configuring the "Workgroup" and adding "Shares" for each media directory. Here's the steps I took:
First, add the non-root user created during Armbian setup to Samba:
sudo smbpasswd -a jason
Open /etc/samba/smb.conf
Find the line that starts with "workgroup =" and set it to "workgroup = KGL"
Go to the end of the file and add an entry for each of the Jellyfin media directories, for example, here's what the entry for the "Movies" directory looks like:
[Movies]
comment = Jellyfin Movie files
path = /armbian/jellyfin/movies
valid users = jason
read only = no
browseable = yes
Finally, save the config file and restart Samba:
sudo systemctl restart smbd nmbd
At this point I was able to mount the Movies directory on my Linux laptop using this address and providing the username and password for the non-root user I created during Armbian's initial setup:
smb://kgl-mediapal.local/Movies
I copied a handful of albums (CD's ripped in FLAC format) and a movie (DVD ripped in mp4) and casually observed the transfer speed. Copying the files didn't seem unusualy slow or any slower than copying similar files to the 'pod over a "windows" share like this. I monitored cpu, memory and other resource usage on Le Potato during the copy and utilization was reasonable even when Jellyfin began to index the files. I played-through an entire album with no noticble issues and watched the first 15 minutes or so of the movie I copied-over and it played back fine. During this time Le Potato's utilization peaked here and there but it was surprisingly idle for most of the time. I even tested playing back music while copying more files over the network and there were no drops or other interruptions in playback.
All of that testing was done using the web interface so I installed the Jellyfin app on my phone (iOS) to see if there would be any issues there. I didn't get a chance to test this extensively, but music playback and downloading for offline listening all seemed to work fine. I haven't had a chance to test Roku playback yet but unless it has different CODEC requirements that involve a lot of transcoding I don't expect to have any problems there either.
Overall I'm impressed with how this cheap (at least at the time I bought it) little board handles the role of a streaming media server. Maybe it would struggle with more than one user at a time but in a home/personal use environment I don't imagine that would be a constant thing, or if so it might amount to maybe two or three concurrent streams. I'll test that out, as well as Roku playback and anything else I can come-up with and if that changes the outcome I'll write more about it later. For now, this seems like a viable solution to my friend's needs.
I still have concerns about the long-term reliability of using an SD card this way, but I also have similar concerns about SSD's, and with the price of both SSD's and mechanical hard disks driven up by AI datacenters SD storage is more attractive than it would have been to me in the past. It also makes the hardware requirements incredibly simple, which is a big plus for this application. I added it up and I could easily fit my current audio + video library on a 512GB SD card, and 1TB cards can be had for around $100 which would give me plenty of room to grow. That means I could replace what I use the 'pod for most for under $200 and doing so would probably pay for itself over the course of six months of electricity savings.
I'm going to work on setting-up a couple of these for my friends, maybe with smaller/cheaper SD's to start out and see how they hold-up in the field.
Jason J. Gullickson, 2026