A Linux-Based Video Player Appliance (Shallow Thoughts)

A Linux-Based Video Player Appliance

Our MP4 player box died. It was a little cheapo device that reads video files (mostly ripped from CD) off an SD card or flash drive, then plays them on the TV over HDMI.

We've had a couple of them, and they're not great: the user interface is terrible, the playback is sometimes laggy and doesn't always have good audio/video sync. But they're cheap, they do play videos, more or less, and they're easy to drive from an infrared remote. On the other hand, I've also read about how this sort of device is often riddled with malware. That's maybe not a huge risk because we don't give them access to our network, but still, it seems like a bad idea.

"Let's use a #RaspberryPi as our media center", I said. "It'll be so much better than those cheap MP4 players. And I'm sure there are options for training an IR remote, or maybe a way to use a phone as a remote." Little did I know what I was getting into.

Hardware (Not a Pi 4)

First, the Raspberry Pi idea was a complete flop.

I was an early RPi adopter, so I have a bunch of ancient first-gen Pis, but those really don't have enough processing power for video. So I needed to order something more modern. A little research showed that the RPi 3 was considered marginal for video streaming, while the 4 and 5 were fine. I ordered a 4.

But I was unable to get the Pi 4 to connect reliably with my network. It turns out the Pi 4 has known hardware problems with its networking, especially when it's displaying over an HDMI cable: apparently the HDMI signal can interfere with the wi-fi signal. I tried everything I could think of: a USB wi-fi dongle known to work on older Raspberry Pis; configuring the router to use a higher channel number (a few people reported that helped); a second, different router chained off our main router; configuring the Pi as its own hotspot, skipping the router altogether. Nothing worked. The Raspberry Pi OS was also flaky in other ways. I finally gave up and returned the Pi 4.

But I didn't give up on the Linux player idea. We have plenty of older retired machines sitting around. First we tried an old jailbroken Chromebook, running Debian, but Dave wasn't happy with the video quality. I thought it was a lot better than the cheapie MP4 player we were replacing (at least audio and video were synchronized!) but he wanted something with a faster processor.

Next we tried an old Mac Mini. It was running Linux Mint, because Debian doesn't offer a kernel that supports the Intel Mini or its wi-fi chip. However, it had some weirdnesses related to how it connected to our network, possibly related to the wi-fi chip which isn't in the standard Debian install. I'll write about the networking issues in a separate article.

Eventually Dave unearthed an old Dell laptop that had plenty of CPU, could run plain Debian and actually connected to the net like a normal machine, and had a slot for a fast internal SSD. That's what we're running now. Dave named it Zeno because he was getting exasperated and figured this project was never going to be done.

Software

For Raspberry Pi 4 and 5, there are dedicated OSes like LibreElec and OSMC that boot straight into the Kodi media player with a simple menu. With more standard hardware, boot-into-Kodi OSes aren't an option, so the choices of which video player to use and how to drive it remotely are less obvious.

Now that I was no longer looking at a Pi, I concentrated on apps where s I could use a phone as a remote, because I don't have an easy way to plug in an IR receiver to a normal computer (Raspberry Pis have GPIO pins and I have an IR receiver that I've used with them before). There is a USB IR receiver called a FLIRC that a lot of people seem to like, but I'd have to order one, whereas we already have plenty of phones.

I was surprised to find all the phone-based video remote options I found used wi-fi, not bluetooth. But on reflection, that makes sense: Bluetooth tends to be super fiddly and hard to use, so wi-fi is probably the more reliable choice. (It turns out that's not necessarily true, but that's a whole different story that I'll cover in a separate article.)

Kodi

Kodi was the obvious media player choice, since it's what all the Pi media center OSes use (though that may be partly because it's optimized for Pi hardware). Kodi has its own phone remote app, called Kore (Kodi Remote).

But I was underwhelmed with Kodi's user interface. It's super hard to browse files: you have to set up each new directory as a library, a fiddly process that tends to fail (or else Kodi forgets you've done it) so you have to keep doing it over and over. Even once you've set up a libarary or two, it takes a lot of clicks to get from the power-on screen to where you're actually browsing your libraries. Deleting files after you've played them happens on a different screen so that's even more clicks. In general, I found the UI annoying and hard to use. Kore wasn't any better, and didn't connect reliably.

VLC

VLC, a staple of the open source video world, has a web interface you can enable.

There are a couple of VLC Remote apps available for phones, but I didn't have much luck with either of them. They wouldn't connect very reliably to my VLC. And really, VLC's built-in web interface is just as good, easier to connect to and has a cleaner UI.

Which is not to say it's perfect: it's missing some key things we needed, like a way to delete video files after playing them. (The apps also lacked this.)

It is apparently possible to customize VLC's web interface: on Linux it lives in /usr/share/vlc/lua/http. When I made changes there, they showed up on Linux but not on Android, so maybe the phone interface is stored somewhere else, though I never figured out where. There are also a few different forks of a project called vlc-web-interface on GitHub.

But I never got that far, because I couldn't find a way to get VLC to remember its position in the last video played, which is a firm requirement for our movie watching. There's a setting you can enable — set Continue Playback to Always — but Always doesn't actually mean always, and mostly it didn't work. I found a few comments that the setting only works with some video file types and not others ... but that means after shutting down for the evening, you never know if you'll have to remember where you were the previous day and then fast-forward to it. Not acceptable.

It later turned out that all the video apps have this problem, and I'm sure I could have worked around it in VLC, but by the time I realized that, I had moved on.

Mplayer

Mplayer has been a staple of video playing on Linux for many years. It doesn't have plug-and-play remote apps, but I found Josh Heidenreich's mplayer-web-remote project, a set of PHP pages that implement an mplayer remote as a website. Mplayer accepts commands through a FIFO, and mplayer-web-remote uses that under the hood. The pages weren't beautiful, but that's fixable, and the PHP implementation meant that I could add whatever was missing, like Delete File and Power Off.

mplayer-web-remote didn't immediately work for me (it's a fairly old project and doubtless some things have changed since Josh last updated it), but I was able to get it working pretty easily, and it did almost everything I needed. I added a Delete File button, easy peasey.

But mplayer has the same problem as VLC: mplayer doesn't remember its position in videos. Unlike VLC, mplayer doesn't even claim to offer this. Turns out lots of people over the years have asked for that feature, and the most common answer is "There are mplayer wrappers that remember playback position; use one of them if you want that." Kind of odd given the plethora of other features mplayer does implement, But there you go.

Mplayer's FIFO commands include getting and setting the play position. So in theory, I could solve the problem that way. I experimented with that for a day or so (dealing with the FIFO is a bit fiddly) when it occurred to me: wouldn't it be easier if I just used a video player that has this functionality built in?

MPV

Remember how mplayer discussions tended to brush off queries about saving position with "you should run a wrapper that handles that"? Two such wrappers that showed up in my queries were mpv and smplayer.

I never did investigate smplayer, because I tried mpv first and am pretty happy with it. It lets you send commands via a socket (similar to mplayer's FIFO) and there's pretty good documentation on what's available, better than the docs I found for mplayer or VLC.

Saving position? You can run with --save-position-on-quit and sometimes that works. Or you can add to ~/.config/mpv/mpv.conf

save-position-on-quit
watch-later-options=vid,aid,sid,volume,start,speed,sub-visibility
write-filename-in-watch-later-config

and that makes it a little more likely to remember. But not likely enough: it remembered maybe half the time.

So, ironically, after giving up on VLC and mplayer because of position saving, I ended up needing to write position save/restore code for mpv. But it turned out I like mpv for other reasons.

For one thing, it's easy to control remotely. It takes commands via a socket/named pipe, rather than mplayer's FIFO or VLC's web interface, and unlike the other two, the commands are fairly well documented in MPV Command Interface. It didn't take long to rewrite the mplayer-web-remote PHP files to be an mpv web remote instead. It has commands for everything I need (except delete and shut down): skip ahead, adjust volume, go to a specific time or percent, switch to another video file, and so forth. (Many of these were missing in mplayer.)

Really, the hardest part was getting the CSS working so the remote looked nice on a phone, plus a few caching issues when shutting down.

The project is at mp-web-remote on GitHub. which has the just-barely-working mplayer version as well as the spiffed-up mpv version. I kept the UI separate from the backend so it'll be easy to use the same UI for mplayer if I (or anyone else) should ever want to.

Running the PHP

The mplayer-web-remote project didn't include hints on how to run it. Being PHP, any web server would work — except that the video player, which is started from the PHP code, needs to run as the user who's running the X server. So either you need to run the web server as the logged-in user, or you need to find the logged-in user do a sudo when starting mpv.

I opted for the former. PHP has a mini-server you can run from the command line, and it worked just fine:

php -S 0.0.0.0:8000

Of course, you can use any port, and the 0.0.0.0 part can be localhost or a hostname. If you use localhost, the interface won't be visible to other machines on the local net.

Volume on Mint

When I was using the Mac Mini, Linux Mint didn't remember its audio volume from one session to the next. So sometimes the sound would be blasting, sometimes barely audible. Mint uses pipewire, so I added this to my startup script:

wpctl set-volume @DEFAULT_AUDIO_SINK@ 100%

and I use the volume control I built into mp-web-remote. That worked well enough. I didn't need it once I switched back to Debian, which seems to remember its volume pretty well automatically.

Conclusion

We've been watching videos using this setup for a few weeks now. I've tweaked things here and there, but it mostly seems to be working pretty well, including deleting the video we just watched, saving position, and shutting down, and I built in one feature that none of the other options seemed to have: it remembers not only its position in the last video, but which video was playing. That's been a huge win since it saves us from the every-evening "What were we watching? Where did we leave off?" which you'd think would be easy to remember, but it isn't.

An unexpected bonus: a web-based, wi-fi-based UI means it's easy to have multiple remote controls. So instead of one person bogarting the remote, anyone can hit pause or adjust the volume without needing to ask whoever is sitting next to the remote.

I really hadn't intended this to be another case of "none of the existing options works, I'll write my own", but somehow, that seems to be how everything ends up going, since we're picky about options and not happy with settling for something that seems stupid or poorly designed.

It turns out there's another mpv remote out there: well after I finally got my setup working, I stumbled upon simple-mpv-webui which looks like a much more mature version of what I have. I haven't tried it (did I mention: Dave exasperated and wanting this to be done) but if you're looking for an mpv web remote, you should probably start there rather than with my project, unless you're specifically looking for something simple and hackable.

Tags: linux, video, programming, php, web
[ 15:46 Jul 12, 2026    More linux | permalink to this entry | ]