Sun, 23 Aug 2026 13:39:15 +0000PPNAS

mr's Preposter.us Blog

I've been talking with some friends about self-hosting their media libraries.  I assume their motives are similar to mine: convenient access to your physical media and reducing dependencies on services you have no control over.

This seemed like a pretty straightforward thing, I've been using Jellyfin for a year or so, mostly to manage music but some movies as well.  I figured I could pitch Jellyfin to them and experiment a bit with what a stand-alone Jellyfin box might look like with a few conveniences (Jellyfin itself, SMB/Windows-style shared folders for adding media files, etc.) but the one hang-up is that they want to access the library from work and home.

There's a few ways this sort of thing is usually done, but they all involve either semi-advanced network configuration (which in some cases isn't even possible due to ISP constraints) or additional products, often with some sort of membership or subscription cost which kind of defeats the purpose of "cutting the cord".

Looking at the little Le Potato on the desk, I wondered if it would be easier just to take the thing to work with you?

I've been rolling this idea around in my head a bit since then and what I'm thinking now is how you could use something like this to create a pocket-sized portable media center.  Not just a media player like an iPod or Tangara, but a complete media center you can use to consume media on a phone, laptop, television, etc.  When I thought about what it would take to do that it was obvious that you could use it for general file storage and such as well, and this sort of intersected with ideas I've had in the past about the digital bug-out-box.  A personal, pocket-sized NAS or PPNAS.

I've written about things like this in the past, in this case I'm going to propose something more concrete and something that can probably be realized from off-the-shelf parts.

Here's the basic recipe:
* A "standard" Raspberry Pi-style SBC that is supported by Raspbian, with WiFi
* A 1TB SD card
* A tidy case that can be pocketed comfortably
* Optionally, a rechargable battery

There's nothing special about the hardware.  Raspian supports a wide-range of single-board computers.  The "standard" Raspberry Pi style is selected primarily because it provides all the right interfaces (including a headphone jack) that eliminate the need for additional hardware.

The software and the configuration are where the magic happens.  Raspbian is chosen for the operating system because it makes creating, configuring and managing network service devices simple.  I've used it for many years and in the case of my HomeAssistant server, completely neglected it for years at a time with no problems.  It's particularly well-designed to avoid corrupting SD cards which is especially important in his application.

In addition to Raspbian the software stack looks like this:
* Samba
* Jellyfin

That's really all that is needed to accomplish this mission.  Samba exposes some network folders for adding media and other files to the device, Jellyfin provides a web interface for consuming it, as well as an API that client applications for phones, computers and televisions use to access the media library.  Samba requires a little manual work to install and configure but Jellyfin can be installed easily using the armbian-config tool.

The trickier part of the setup to get right is the networking.  First of all, I want to make it possible to address the device by the same name no matter what network you're on.  This is doable but requires some careful configuration of things like mdns and the hostname and since collisions are theoretically possible, each device will need a personalized name.  All things I've done before but I want to make it easy and foolproof.  The harder part is making it easy to use across multiple networks in multiple places.  The simple-but-hard way to do this is to manually configure the credentials for all the WiFi networks you use in advance, but I think for this to be really useful something easier and more flexible is needed.  The best idea I have right now is to configure the device to create it's own WiFi network when it can't find one that it already knows and provide a "portal" where you can add new WiFi networks.  I don't know off-hand if there's an off-the-shelf solution for this but I'm sure there is, I just need to do a little digging.  It might even already be a part of Armbian, but if not, I could make it so as I've become familiar with how to extend armbian-config recently.

At this point you could say "mission accomplished", but I think there's a few more improvements that would make day-to-day living with the device more pleasant.  One is exposing some physical interfaces so that there's a way to see the state of the device without having to use another machine to look at the web interfaces, etc.  The other is a way to deal with the fact that when you move it from place-to-place it won't be plugged-in.

The first concern could be trivially addressed by hanging a few LED's (with current-limiting resistors) off the GPIO pins of the sbc to indicate useful state information like "on", "full" and "error".  Exactly what these indicate and how they do it is pretty flexible but I feel like those three states ("on" meaning actually ready for use as opposed to simply being plugged-in) cover the essentials.  There's endless possibilities to provide more fun and interesting physical interfaces into the internal state of the device of course but for now this is plenty.  

The second issue, power loss could also be handled through a physical interface to turn-off the device.  You could of course just unplug it, and Armbian takes measures to make this less traumatic than other operating systems but it's still not ideal.  Instead a switch or button could be connected to the GPIO pins to tell the device to shut-down when you're ready to hit the road and the LED's can indicate when this process is complete and it's safe to unplug.

Alternatively, the optional rechargable battery can cover this concern as well.  This avoids the need to shut-down entirely (at least for trips where access to a power cord returns before the battery expires).  I've seen a few off-the-shelf solutions for tightly integrating a battery with a Raspberry Pi-style SBC, but a simple USB battery pack with passthrough charging could fit the bill as well.  The added benefit of a battery is that it also reduces the power supply requirements when plugged-in (many USB power supplies can't provide the amount of power these SBC's want when running at full speed).

The final piece of the puzzle is a case to contain all this that will protect the parts and also fit nicely into a pocket (or otherwise be attached to you on-the-go).  Here again there's no shortage of "prior art", although I'm inclined to design a printable case specifically for this application that incorporates the physical controls and the optional battery in a tidy way.

I'm going to experiment with constructing a couple of these devices and enlist my friends to field test them.  I may even have most of the parts I need on-hand (although most of my Raspberry Pi-style SBC's are lacking built-in WiFi).  I'll post an update in the future once I have a complete prototype to share.


Jason J. Gullickson, 2026