Raspberry Pi Setup

So with the roll out of the DVR service in the UK, looking at how best to set up a Pi 3.

I’m looking to run the Pi headless and the only storage will be on the SD card (64 or 128gb) - I won’t be recording much and playback will only be via the aTV which is all connected via ethernet. Does comskip work in the UK and will it work on the Pi? I’m assuming as I’m not playing anything on the mobile/remotely, I don’t have to worry about transcoding?

Can I install the DVR on RASPBIAN JESSIE LITE or UBUNTU CORE? Does it run better on either?

Many thanks,

Transcoding is totally out for the Pi. It doesn’t have near enough power to do that. As for commercial detection, that’s probably out as well. It will take a realllllly long time to complete with the simple ARM chip on the Pi.

As for recording directly to the SD card, you can give it a go, but it might not be the most stable thing in the world. Your best bet is to use an external USB hard drive. But beware, on the Pi, the hardware shares resources for ethernet and USB so things will be constrained while streaming.

That being said, go for it! Report back on how well it works for you.


Pi 3 with raspbian jessie lite installed on a 64gb sd card and the channel dvr server is installed onto this as well, with recordings also saved to the sd card.

All running ok, aTV app smooth and playing back recordings is pretty flawless (Similar to Dell 3050). Comskip for a 60min tv show took just under 2 hours so this does take a while.

Only issue so far, I get the following warning in the log:

[WRN] Buffer for 12312F15 ch6 is more than 95% full (clients=1, len=0)

but haven’t noticed any issues as of yet. The DVR settings page shows RAM as 968.21 MB / 80.2% free but checking the memory via ssh is showing only 30mb free RAM. Any ideas? Running server version 2017.04.28.2317.

Hrm… do you see other similar warnings? Are they all 95%, or do you see 50%, 75% etc too?

Do they all say “len=0”? That part is very unexpected…

Just that one warning, same everytime and it only comes up when the DVR is about to record.

2017/05/03 21:00:00 [DVR] Starting job 1493841600-ch104 Confessions of a Junior Doctor on ch=[104] 2017/05/03 21:00:00 [DVR] Waiting 1h29m59.991579306s until next job 1493847000-1 Newsnight 2017/05/03 21:00:00 [TNR] Opened connection to 12312F15 for ch104 2017/05/03 21:00:00 [WRN] Buffer for 12312F15 ch104 is more than 95% full (clients=1, len=0) 2017/05/03 21:00:00 [DVR] Recording for job 1493841600-ch104 from 12312F15 ch104 into "TV/Confessions of a Junior Doctor/2017-05-03-2100 Confessions of a Junior Doctor 2017-05-03.mpg" for 59m59.991457848s

1 Like

Thanks. This is a harmless 32-bit overflow bug that has been fixed for the next build.

I would like to set up the Channels DVR on my Pi 3 as well. I currently have TVheadend installed, that runs at start up. Should I disable and/or remove TVheadend before installing channels DVR? I want to avoid running into a problem that may result in having to reformat the card and start from scratch. It took me forever to get my pi working with apple homekit and my lights and loathe trying to figure it out again.

AFAIK there should be no conflicts with TVHeadend running.

The Pi 3 should work, but it struggle in the US with multiple streams due to severe network speed limitations (100 Mbits/sec). MPEG-2 ATSC broadcasts may peak on paper at around 11 Mbits/sec, but with multiple streams there is some pretty big overhead.

It has similar (slightly worse) specs than the ODroid C2, which I have discussed in depth here:

If you do get it working, I’d be grateful for your report on that thread. With the ODroid C2 I wasn’t able to watch a show reliably while it was recording. It also had problems recording and/or playing 4 streams simultaneously sometimes, despite (on paper) sufficient drive speeds and a better ethernet speed. I suspect there is a fair amount of overhead for multiple streams, and possibly the combination with a slow hard drive (USB-2, 3.5") caused issues. For some reason, it was always ABC broadcasts that suffered; I have no idea why, but this hasn’t been an issue since changing to a faster ARM SOC.

As Maddox said, transcoding is probably out. I hear mixed reports on the hardware transcoding capabilities of the Pi 3, which require extra work to set up and I don’t think the Channels DVR transcoder uses it. With hardware transcoding enabled, it might be able to handle a live stream, but bear in mind that scaling resolution is also likely to be a bottleneck, and so it might even then only work for SD and possibly 720p sources. Also, the hardware transcoding is difficult (maybe impossible?) to optimize to look good, as it is very crude in its approach.

If you run my software transcoding scripts, you can at least prepare copies for Plex serving that are also optimized for small bandwidth and high quality, negating the need for the integrated web transcoder. These will work for Direct Play/Stream to pretty much any client.

Note that I anticipate pretty slow transcoding (maybe 4x slower than broadcast by default), but if you can wait until the next day that might not be a problem for you.

I have just setup the DVR on the PI. So far recording is going fine. A commercial skip process is running and is indeed taking a while to chew through a pretty small recording. I did notice that the com skip process is only using 1 core of the processor, maybe adding another core would help? Did you do this on purpose to make the Pi not completely unusable while this process is going? Just curious…

Will mess around with playback shortly and report back.

Yes exactly

In my situation I think adding 1 more core would be fine. My PI is just being used for a DVR so having 2 cores working on the commercial skip wouldn’t be a big deal. Recording itself seems pretty tame processor wise. Maybe having it configurable would be good?

Anyways great product you guys did a great job with it! Ill let you know how things are going with the PI if your still interested

comskip will happily peg your CPU at 100% and impact new recordings

I second that for arm systems, most of which are 4-, 6- or 8-core. I can’t see any situations in which using up to half of the cores would be an issue, certainly not if the job was set with a friendly “niceness”/priority.

I’ve updated the DVR to use half the available cores for comskip.

1 Like


Apologies for the thread necromancy but there's now a Pi4, quad 1.5GHz Arm Cortex-A72 CPU cores, up to 4GB RAM USB C with VideoCore VI graphics, supporting OpenGL ES 3.x
4Kp60 & hardware decode of HEVC video.
Any chance of further optimization on the DVR as this is a lot cheaper than a Synology?