Pi 4 for serving M3U and XMLTV only

I'm in process of changing things around so Channels will be doing nothing but serving m3u streams to Emby. Emby will be doing all of the DVR recording, any transcoding for remote, etc. All Channels will be doing is running tuners and building a guide to be served as m3u and XMLTV respectively.

That being said, how many simultaneous m3u streams would a Pi 4 be capable of?

Because while I could run Channels on Docker right next to Emby, there's something to be said for getting off the NAS. That way during any sort of NAS outage the tuners will still be available, and anyone wanting to watch TV in the house could open Tivimate and pull directly from the Pi.

Keep in mind, I've never touched one of these Pi boxes before. So please be clear with any specifics. Thanks in advance!

I'm doing something similar using NextPVR on Docker as my actual DVR and Channels on a Pi4 pushing the TVE streams out (and 14 days of the XMLTV guide). I have mine capped at 2 streams because I don't want any risk of drop outs. As long as the streams are NOT MPEG2 (which would have to be transcoded and is limited to 1 stream), I bet you could do twice that for sure.

1 Like

If the PI is just serving the tuners it will do no transcoding. Transcoding will be done by EMBY if using EMBY for remote access.

1 Like

Yeah and I'm gonna need up to 6 simultaneous to accommodate live viewing while the DVR is running. I don't see the load getting heavier than that. So the plan is to order a Pi off Amazon. If it doesn't do the job I'll send it back, and turn an old i7 laptop into the Channels/tuner server.

I just connected 7 streams. 3 live view and 4 active DVR. Channels is currently running on my main desktop. It's a 9900k cpu, and Channels is restricted to using ONE core (15). Seven streams are collectively using between 10 and 15 percent of one core.

The Pi is worth some testing for this purpose I guess. I'll order a "Canakit" from Amazon today and report back when I complete some tests.

Looking forward to your findings.

I just ordered the following to run this...


With the way things are shipping right now it should show up anywhere from a week to a month from now, lol.

To save time, I'm going to overclock it to 1.8ghz before testing. That's what Canakit overclocks their Pi 400 kit to so apparently it's stable.

I think instead of tuning and walking away I'm just going to set 6 simultaneous streams to DVR. Then test at 8, and then at 10. Then I'll watch all 24 recordings over a few days to ensure there were no issues, or figure out when the issues begin to show up. After 10 it's probably a moot point but if I can get my hands on more tuners or streamer accounts I'd love to see how high it would go.

FWIW, this isn't overclocked, this is the clock speed the Pi 400 ships with because of the nutty heat sink in the keyboard.

1 Like

Ahhh, thank you. I didn't read too much into it. I figured it's not going to make TOO much of a difference so it's either going to work or it won't, overclock or not.

How do they get a better heat sink in there with a keyboard case? I didn't even think they did anything but OC'ing because of that case.

The Pi 400 uses a different PCB which was redesigned for better heat distribution.

From https://www.jeffgeerling.com/blog/2020/raspberry-pi-400-teardown-and-review:

1 Like

Alright, let's give it a go. I canceled the Amazon order and ordered the 400 from Canakit directly. (not in stock on Amazon)

I wasn't suggesting to use the Pi 400. Honestly even the 8GB model is overkill. Overclocking is completely unnecessary and will only make your system more unreliable. The constraints are on I/O more than anything else. I bet a 2GB Pi 4 + SSD could do 30 streams no problem.


Well it's my first. So I figured if this doesn't work out then I can use it for something else related to smart home crap, or who knows what else. These apparently have the AES-NI instruction so before I make it permanent for Channels I want to test it out with PFSense. It sure would be nice to lower the electric bill without sacrificing performance.

....and I agree. After what I saw when testing today I can't imagine the m3u streams would overpower a desk calculator. LOVE that!

I'd highly suggest not purchasing the raspberry pi that's built into a keyboard in that case. Just pick up a 2gb pi 4 and you're good to go.

Yeah I won't be buying another in the keyboard case. The rest will be the basic Pi boxes. This one just makes it easy to carry around and plug into anywhere with a TV present.

Whoa, this thing is wicked efficient.

On a goof tonight I decided to look at the Android version of the CDVR server. When I pulled it up on Google Play it said "this app is compatible with some of your devices". In the list of compatible devices were my Ematic AGT418 and 419's. One of those boxes is having some sort of issue when if I connect a VPN client it drops the wired connection. It's a code issue, because I reproduced it using a UGREEN gigabit dongle in addition to the onboard 10/100.

Anyway, I installed it on the Ematic box, and added the tuners. The channels come right up no matter the device, and play perfectly. (Quatro, Prime, and Verizon TVE) The only issue is the guide took FOREVER to build, but it ultimately did start working.

This is hilarious. My m3u server might end up residing on repurposed junk, lol, for less than the cost of a Pi.

So I canceled the Pi order, and right now I have 7 streams recording via Emby.

My question is, do I get an award for running the Channels server successfully on quite possibly the worst piece of hardware for the task? If so, start melting the bronze for the trophy, lol. I'll post an update when I'm done reviewing the recordings.

Btw, as it turns out the Ematic is really just the 2gb Pi bloated with some droid crap that I'll have to selectively disable to get back some memory.


So Emby is currently getting its channels from an Ematic AGT419 running the Channels-DVR server for Shield app. Of the 7 simultaneous recordings I had going on, all are fine. No noticeable issues. The time to activate a stream varies, but it did that when I was running it on a 9900k. The only difference I could see is it took forever to populate the guide. But after that no issues. Although I won't need the guide as soon as I can find a paid EPG that will give me 14 days. The few days Channels gives me through XMLTV isn't very useful.

So I guess it will stay that way for a while until I feel like moving it over to a Pi. Works like a charm!

You may want to look into a Schedules Direct subscription for getting the data. (Their upstream provider is Gracenote, the same as Channels. They provide 14–20 days of data, depending upon the channel.) If I remember correctly, their rate is $25/yr.

To get that data into XMLTV format, their are two main options. For Windows users, you can use EPG123. For other platforms, I personally recommend tv_grab_zz_sdjson_sqlite. (More info about XMLTV grabbers can be found on their project's wiki.)

Although if you're using Channels to feed Emby, why do you need to pay extra for the guide data? Just use Channels' guide data, exported to XMLTV.

Channels can output its entire guide database. Have you tried changing the duration parameter? GET /devices/ANY/guide/xmltv?duration=604800 will give you a week of data. Upping the duration to 1209600 will give you 2 full weeks.

I'll have to play more with sched direct, but the channels server caps at some point. There's a mention of it in a thread somewhere, but yeah I've changed the duration in emby to a few values and it doesn't seem to want to go beyond 4 days if I remember correctly.

I just checked again. It stops at 5 days. That reminded me of all I did when testing it the first time. I tried doubling the duration number, I tried lowering the guide size on the Emby side to 10 days, and I tried other numbers in between. It stops at 5 days. That's when I read something about addressing it in the next build. I run the stable build, so I won't see any fixes for a little while.