Do you anticipate any issues with using the DVR on BigSur? I really want to update that server (i use it for other things as well) to Big Sur, but if I break the DVR, the family won't like that.
Thanks!
We are not aware of any issues and don't anticipate any problems for Intel macs.
1 Like
Do you anticipate any issues on the Apple M1 silicon based macs? running iOS apps directly on my mac is very enticing.
We have no idea about Apple silicon yet. I would not expect anything to work until we know more.
My gut feeling: since Apple's M1 (and presumably future processors) are basically arm64/aarch64 compatible, there's nothing a Raspberry Pi 4 can run that Apple's processors can't. This would presume the Go compiler, and therefore Channels DVR server.
While it hasn't been tested yet, I'd be shocked if it didn't work.
Sounds good. The thing I worry about is Apple's TPM. With the M1 & BigSur, apple is forcing signed apps... M1, will bring even stricter enforcement should Apple decide to leverage it down the road. Sigh.
I've been running Channels DVR server on Big Sur (intel mac) for a couple of days now. Recently updated DVR server to 2020.11.18.0639 - everything is stable and I've not had any complaints from my household (5 AppleTVs running a mix of production and beta Channels apps).
Obviously your mileage may vary - but I've seen no problems here 
The first version of golang which supports M1 will be go1.16 and is scheduled for release in Feb 2021
The first version of gcc which supports M1 will be gcc11 and is scheduled for release in May 2021
Hopefully it won't take that long to get the dvr working, but at this point we simply don't know enough.
Current benchmarks are indicating that x64 running on the M1 via Rosetta2 translation is actually faster than bare metal x64 for many instances ... by a factor of 5 in some cases.
I don't think it'll be an issue.
It really depends on what kind of x64 code you're trying to run..
For what it's worth, I've been running Channels DVR on an M1 Mac Mini for the past day and it's been working great so far.
I haven't tried software transcoding yet but frankly I don't think there's any need for it -- hardware transcoding quality is great on the M1, even at low bitrates.
I'd imagine the lowest hanging fruit is comskip because that is both CPU-intensive and it's a separate binary... but despite running under Rosetta translation it still runs so fast (without any audible fan noise) that it's still fine as-is.
3 Likes
Just for fun I tried software transcoding.
Transcoding 1920x1080 60Hz (CBS TVE) using software transcoding at the "1080p @ 10mbps" preset under Rosetta translation...absolutely no drama at all:
4 Likes
Color me shocked. Certainly encouraging. My mini gets here next week.
1 Like
so far the only thing that's broken my workflow is that I no longer get notified that a recording has finished by the sound of fans spinning up for comskip
5 Likes
You went with 8GB RAM? Is this a temporary test or do you plan on running it permanently with 8GB?
I bought it with 8GB and am committed to it (the memory is built into the M1 SoC so it's not upgradeable).
The high RAM utilization that Channels indicates in my screenshot above is a little misleading -- almost all of that utilization is purgeable memory (mostly stuff paged-in from disk that's kept in memory just in case it's needed again) that can be quickly reclaimed if needed.
1 Like
Yep, I think I just ran into this while the DVR was fetching guide data:
2020/11/19 09:40:01.318393 [DVR] Fetching guide data for 117 stations in X-TVE @ 2020-11-19 9:30AM
2020/11/19 09:40:02.776301 [DVR] indexed 836 airings (117 channels) [0s fetch, 0s index]
2020/11/19 09:40:03.288519 [DVR] indexed 45 movies (15 channels) [0s fetch, 0s index]
2020/11/19 09:40:03.396700 [DVR] pruned 32 replaced airings in 0s.
2020/11/19 09:40:03.420734 [DVR] Fetching guide data for 121 stations in USA-CA04487-X @ 2020-11-19 3:30PM
assertion failed [abi_info.kind == AbiKind::TranslatedCode]: emulated forward to an arm pc that isn't in translated code. arm_pc=0x10686e4d8 abi_kind=6 emulation_interval=[0x106ea790c,0x106ea7920) instruction_interval=[0x106ea78f8, 0x106ea7920) x86_rip=0x4bddb6d
(ThreadContextRegisterState.cpp:677 move_to_instruction_boundary)
Had to launchctl stop com.getchannels.dvr;launchctl start com.getchannels.dvr to get it running again.
Although a subsequent, manually initiated "Fetch Guide Updates" ran fine so it doesn't seem to be 100% reproducible.
To try to work around the issue, I've added setenv GODEBUG asyncpreemptoff=1 to /etc/launchd.conf and also ran launchctl setenv GODEBUG "asyncpreemptoff=1". I'll report back if it crashes again!