Apple TV Recording Playback "Unauthorized"

Beta Community DVR Beta
#1

Hello -

Got the server side set up and running great with web playback to both my Mac and iPhone working well within the limits of my server’s processor.

My problem is now my Apple TV - I can see the recordings but not thumbnails nor am I able to play the recordings back from the tvOS interface.

When I capture the conversation using tcpdump between the Apple TV and the server it appears that the server is responding with the same “Authorization Code” page at is does for other devices but the Apple TV interface has no method for dealing with this.

In my case, my Apple TV’s Apple ID is not the same email address as my Channels DVR account. This is also occurring over IPv6 on my home network.

Any ideas?

Thanks!

#2

Sounds like this might be an IPv6 related bug. What is the IP address of your ATV and Mac?

#3

IPv4 -

Server (ubuntu 14.04) - 10.11.2.10
ATV - 10.11.2.166

This network is configured as a /24.

On IPv6 they’re all in the same /64 but assigned by dhcpv6. I won’t be posting them here as they’re globally unique. :slight_smile:

To test, I disabled IPv6 on the server and restarted channels-dvr. After letting everything settle down I can play recordings but with the same delay experienced by others. When I turn IPv6 back on it fails again as before.

In this testing I discovered that the service does not appear to retain the DVR Enabled setting when “initctl start (stop) channels-dvr” is used. In fact, now it reports a IO error with a LOCK being held on one of the guide files and the ATV interface directs me to set up the DVR server again.

It also appears that this file lock causes channels-dvr to crash and restart thus resetting the DVR Enabled setting again…

I started the service using initctl start channels-dvr, waited a minute, then checked the DVR box, then clicked through the tabs from right to left and when I tried to view the guide it appears the io error caused channels-dvr to restart.

NOW at 23:07 it appears to be running properly without further intervention from its own restart at 23:03.

Logs:

2017/01/10 23:01:42 [SYS] Starting Channels DVR v2017.01.10.0517 (linux-x86_64)
2017/01/10 23:01:44 [HDR] Found 3 devices
2017/01/10 23:01:44 [SYS] Bonjour service running for dvr-server.local. [10.11.2.10 192.168.122.1]
2017/01/10 23:01:44 [SYS] Started HTTP Server
2017/01/10 23:03:03 [DVR] Recording engine started
2017/01/10 23:03:03 [IDX] Pruning expired airings…
2017/01/10 23:03:03 [DVR] Deleting expired job 1484103600-ch806
2017/01/10 23:03:03 [IDX] Finished pruning 15 airings.
2017/01/10 23:03:03 [IDX] Pruning expired airings…
2017/01/10 23:03:03 [SYS] Created database snapshot: backup-20170110.230303
2017/01/10 23:03:04 [IDX] Finished pruning 210 airings.
2017/01/10 23:03:55 [NAT] Failed to discover upnp: write udp4 0.0.0.0:45817->239.255.255.250:1900: i/o timeout
2017/01/10 23:03:55 [NAT] Failed to discover router using natpmp and upnp.
2017/01/10 23:03:55 IO error: lock USA-PA37810-X.airings/store/LOCK: already held by process
2017/01/10 23:03:55 [SYS] Starting Channels DVR v2017.01.10.0517 (linux-x86_64)
2017/01/10 23:03:56 [HDR] Found 3 devices
2017/01/10 23:03:56 [SYS] Bonjour service running for dvr-server.local. [10.11.2.10 192.168.122.1]
2017/01/10 23:03:57 [SYS] Started HTTP Server

Thanks!

#4

Can you tell me what subnet the ipv6 addresses are being assigned from?

The server currently whitelists a few subnets reserved for local networks, and allows requests from those clients through without authentication.

"fc00::/7",
"fe80::/10",
"::1/32",
#5

This usually means more than one copy of the server is running. You can double check with ps aux | grep channels-dvr. Since you’re using the systemd service it seems unlikely there’d be multiple though…

Must be a dirty shutdown that left the lock file in place. Try removing that file and restarting the server.

#6

Yes, they’re from Comcast - 2601:98a:4001::

#7

Hmm I see okay. So you’re getting public ips for all your devices? I have to admit I don’t have a lot of experience with ipv6.

#8

I stopped the service, cleared the LOCK files under data, then started the service again - it crashes with the same error but a different file… Perhaps I am getting too jumpy in clicking the DVR click box and causing the error. I will give it a few minutes to see if it starts the DVR service on its own after restarting.

#9

Yes, I think you will find many (most) modern routers will provide public IPv6 to internal devices from a /64 - really the way it works with Comcast is your cable modem has a /56 (or similar depending on provider) for you and your router (in my case pfsense) does a DHCP-PD (prefix delegation) request for a /64 out of that /56 then distributes that /64 to your private network.

And they are truly public addresses - no NAT and globally unique. I’ve got a few non-critical things I’ve just set up IPv6 rules for and no longer have to VPN for which makes life a little nicer.

For now the simple solution might be to have your application not bind to ipv4/ipv6 but rather to only ipv4 until you have a solid method to detect local IPv6 networks.

#10

I see. Yea the log shows it taking a while. The UI shouldn’t let you slam the checkbox off and on in the first place. Will fix.

#11

I utilized some patience here and after a few minutes the daemon started everything up on its own without errors and works as expected now.

In my case it looks like it took just over two minutes. Might be a function of a crappy ZFS array - these are slow 5400 RPM disks just intended to store tons of data. Maybe I should move the application to the ssd and point it to the ZFS for the storage only. I’m highly surprised at the size of the guide data so if it must be scanned on startup then I will be motivated to move it to ssd. :slight_smile:

#12

Ouch, quite slow indeed. You would indeed be better off with data on SSD and pointing the recordings dir at your array.

The IPv6 issue should be fixed in the upcoming ATV app build, which forces IPv4 for DVR server communication.

#13

You can try also stopping and starting again, to see if it is just as slow. Once loaded into the file system cache, it should be faster. The database was also perhaps performing self repair from an earlier issue.

#14

I moved the data to the ssd partition and I suspect it is related to the network timeout in trying to active upnp for my router - since I am running pfsense and do not allow upnp on my network.

Is it possible to start the recording engine concurrently or prior to trying to activate upnp - or perhaps a disable upnp check box under Remote Access.

I understand it is difficult to consider every use case and appreciate your help in sorting out my situation.

Thanks!

logs from ssd -

2017/01/10 23:51:50 [SYS] Starting Channels DVR v2017.01.10.0517 (linux-x86_64)
2017/01/10 23:51:51 [HDR] Found 3 devices
2017/01/10 23:51:51 [SYS] Bonjour service running for dvr-server.local. [10.11.2.10 192.168.122.1]
2017/01/10 23:51:51 [SYS] Started HTTP Server
2017/01/10 23:54:02 [NAT] Failed to discover upnp: write udp4 0.0.0.0:51523->239.255.255.250:1900: i/o timeout
2017/01/10 23:54:02 [NAT] Failed to discover router using natpmp and upnp.
2017/01/10 23:54:04 [DVR] Recording engine started
2017/01/10 23:54:04 [IDX] Pruning expired airings…
2017/01/10 23:54:04 [SYS] Created database snapshot: backup-20170110.235404
2017/01/10 23:54:04 [IDX] Finished pruning 14 airings.
2017/01/10 23:54:04 [IDX] Pruning expired airings…
2017/01/10 23:54:05 [IDX] Finished pruning 119 airings.

#15

Good catch. That was meant to be concurrent but currently is blocking bootup. I will fix.

In the mean time, you can simply uncheck the “Remote Access” option as all it does it try to open ports for you.