Can't stream to AppleTV 13.3

Hi @Aaron_Turner,

Thanks for that additional info, I have some feedback for you if you would like to look into this further:

The trial is not an issue, I will reach out via private message regarding this.

I believe the Docker aspect might be playing a part into this issue. If you install RoonServer on Ubuntu nativity it would be much easier to troubleshoot.

According to the logs you sent, it looks like Roon is trying to use a busy socket, maybe Docker is using it for something else so checking on native Ubuntu will be a good step in the right direction, you can install Roon there by using our Linux Install Instructions.

Thank you for extending the trial.

Sorry, sounds like a miscommunication:

I was running Docker for something else, not RoonServer which runs directly on the Ubuntu OS. I’ve turned off Docker and as I previously mentioned I flushed the iptables rules so everything is clear:

$ iptables -nvL
Chain INPUT (policy ACCEPT 3769K packets, 3474M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 5091K packets, 5662M bytes)
pkts bytes target prot opt in out source destination

More debug:

TCP ports open

$ netstat -an4 | grep LIST
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9091 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:36035 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:60741 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:41445 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:41737 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9004 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9100 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:34573 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9101 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:27117 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 172.16.2.100:53 0.0.0.0:* LISTEN
tcp 0 0 172.16.1.100:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:50807 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:56027 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:35995 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:42267 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:44733 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9150 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5023 0.0.0.0:* LISTEN

UDP ports open

$ netstat -an4u
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:56534 0.0.0.0:*
udp 0 0 0.0.0.0:60741 0.0.0.0:*
udp 0 0 0.0.0.0:48600 0.0.0.0:*
udp 0 0 0.0.0.0:57320 0.0.0.0:*
udp 0 0 172.16.2.100:53 0.0.0.0:*
udp 0 0 172.16.1.100:53 0.0.0.0:*
udp 0 0 127.0.0.1:53 0.0.0.0:*
udp 0 0 127.0.0.53:53 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 172.16.1.255:137 0.0.0.0:*
udp 0 0 172.16.1.100:137 0.0.0.0:*
udp 0 0 172.16.2.255:137 0.0.0.0:*
udp 0 0 172.16.2.100:137 0.0.0.0:*
udp 0 0 0.0.0.0:137 0.0.0.0:*
udp 0 0 172.16.1.255:138 0.0.0.0:*
udp 0 0 172.16.1.100:138 0.0.0.0:*
udp 0 0 172.16.2.255:138 0.0.0.0:*
udp 0 0 172.16.2.100:138 0.0.0.0:*
udp 0 0 0.0.0.0:138 0.0.0.0:*
udp 0 0 0.0.0.0:33292 0.0.0.0:*
udp 0 0 0.0.0.0:53840 0.0.0.0:*
udp 0 0 0.0.0.0:642 0.0.0.0:*
udp 0 0 127.0.0.1:716 0.0.0.0:*
udp 0 0 0.0.0.0:9001 0.0.0.0:*
udp 0 0 0.0.0.0:9001 0.0.0.0:*
udp 0 0 0.0.0.0:9003 0.0.0.0:*
udp 0 0 0.0.0.0:9003 0.0.0.0:*
udp 0 0 0.0.0.0:9003 0.0.0.0:*
udp 0 0 0.0.0.0:9003 0.0.0.0:*
udp 0 0 0.0.0.0:9003 0.0.0.0:*
udp 0 0 0.0.0.0:9003 0.0.0.0:*
udp 0 0 0.0.0.0:9003 0.0.0.0:*
udp 0 0 0.0.0.0:50192 0.0.0.0:*
udp 0 0 0.0.0.0:33834 0.0.0.0:*
udp 0 0 0.0.0.0:38577 0.0.0.0:*
udp 0 0 0.0.0.0:51188 0.0.0.0:*
udp 0 0 0.0.0.0:2049 0.0.0.0:*
udp 0 0 0.0.0.0:43904 0.0.0.0:*
udp 0 0 0.0.0.0:56326 0.0.0.0:*
udp 0 0 0.0.0.0:52298 0.0.0.0:*

Roon processes

$ ps auxww | grep Roon
aturner 17806 0.0 0.0 14428 1000 pts/4 S+ 18:11 0:00 grep --color=auto Roon
root 18760 0.0 0.0 12884 2108 ? Ss Jan14 0:00 /bin/bash /opt/RoonServer/start.sh
root 18776 0.0 0.4 431096 34384 ? Sl Jan14 0:30 /opt/RoonServer/RoonMono/bin/RoonServer --debug --gc=sgen --server RoonServer.exe
root 18798 4.9 9.0 2598404 732308 ? SLl Jan14 210:09 /opt/RoonServer/RoonMono/bin/RoonAppliance --debug --gc=sgen --server RoonAppliance.exe -watchdogport=44733
root 18799 0.0 0.0 8088 1112 ? S Jan14 0:00 /opt/RoonServer/Server/processreaper 18798
root 18846 0.0 0.2 1069624 19764 ? Sl Jan14 2:23 /opt/RoonServer/RoonMono/bin/RAATServer --debug --gc=sgen --server RAATServer.exe

What open TCP/UDP sockets RoonAppliance and RAATServer have

$ lsof -p 18798,18846 -a -Pi4
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
RoonAppli 18798 root 12u IPv4 8384681 0t0 TCP brix.int.synfin.net:49966->80.185.73.34.bc.googleusercontent.com:9200 (ESTABLISHED)
RoonAppli 18798 root 18u IPv4 6162308 0t0 TCP *:9100 (LISTEN)
RoonAppli 18798 root 25u IPv4 6162313 0t0 UDP *:9003
RoonAppli 18798 root 38u IPv4 6162314 0t0 UDP *:33292
RoonAppli 18798 root 39u IPv4 6164860 0t0 TCP localhost:38534->localhost:44733 (ESTABLISHED)
RoonAppli 18798 root 42u IPv4 6164868 0t0 UDP *:9003
RoonAppli 18798 root 43u IPv4 6164084 0t0 TCP *:9101 (LISTEN)
RoonAppli 18798 root 44u IPv4 6164869 0t0 UDP *:9003
RoonAppli 18798 root 54u IPv4 6162325 0t0 TCP localhost:54348->localhost:9004 (ESTABLISHED)
RoonAppli 18798 root 77u IPv4 6162389 0t0 UDP *:9001
RoonAppli 18798 root 78u IPv4 6162390 0t0 UDP *:52298
RoonAppli 18798 root 79u IPv4 6162391 0t0 UDP *:9001
RoonAppli 18798 root 80u IPv4 6162392 0t0 UDP *:53840
RoonAppli 18798 root 86u IPv4 6164893 0t0 TCP *:9150 (LISTEN)
RAATServe 18846 root 5u IPv4 6164087 0t0 TCP localhost:9004 (LISTEN)
RAATServe 18846 root 6u IPv4 6164088 0t0 TCP localhost:9004->localhost:54348 (ESTABLISHED)
RAATServe 18846 root 14u IPv4 6164097 0t0 UDP *:9003
RAATServe 18846 root 15u IPv4 6164098 0t0 UDP *:48600
RAATServe 18846 root 16u IPv4 6164099 0t0 UDP *:9003
RAATServe 18846 root 17u IPv4 6164100 0t0 UDP *:57320
RAATServe 18846 root 18u IPv4 6164101 0t0 UDP *:9003
RAATServe 18846 root 19u IPv4 6164102 0t0 UDP *:56534
RAATServe 18846 root 20u IPv4 6164103 0t0 UDP *:51188
RAATServe 18846 root 21u IPv4 6164104 0t0 UDP *:9003
RAATServe 18846 root 23u IPv4 6164105 0t0 TCP *:34573 (LISTEN)
RAATServe 18846 root 33u IPv4 6162404 0t0 TCP *:41737 (LISTEN)

Hi @Aaron_Turner,

Thanks for confirming that this behavior occurs on the regular Ubuntu setup and not in Docker. I believe it’s best if we try using a different Core to determine weather the Ubuntu networking settings is playing a part in this behavior.

Would it be possible for you to temporarily host the Roon Core on one of your MacOS laptops and let us know if the issue is the same there? This should help clarify if this issue is related to the Core or elsewhere on the network.

You can assign the MacOS as the Core by installing Roon on it, and on the “Choose your Core” page select “Use this PC” (instead of connecting to the Ubuntu Core). You may be presented with an “Authorizations” screen and be prompted to un-authorize the Ubuntu Core, there are no adverse affects for switching between Cores and you can do so as many times as you wish, but you are limited to just one “active” Roon Core at a time.

Installed Roon on my MBPro. Mounted the same songs off my Synology and things seem much better. Meaning: things play without a hitch for the most part. Occasionally some brief pauses mid-song which may just be wifi network congestion or whatever, but at least songs seem to play pretty consistently.

Hi @Aaron_Turner,

Glad to hear the MacBook is working out better for you. Since switching the Core helped here, something about the initial Ubuntu setup is affecting Roon adversely. I can’t comment on where exactly things are going wrong with the routing on Ubuntu, but you may want to take a closer look there or keep the Core on the Mac/a different platform.

So can you explain these log messages I reporter earlier???

Basically, it looks to me like Roon tried (and failed) establishing a new airplay/RTSP connection to my AppleTV named “Home Theater” at 172.16.2.1 on TCP port 7000. That AppleTV device has a MAC address of 08:66:98:f3:af:c1 which corresponds to the “DeviceId” in the log as well as being named “Home Theater”.

Is that your reading of those log messages too or am I misunderstanding them?

Yes, that looks about right based on the log. Do you have anything else using port 7000 on your Core/Apple TV? Perhaps an Emby/Plex server or some other kind of server?

So the problem then isn’t that the port has a conflict then (TCP source ports are random). The issue is that Roon for some reason is using the wrong destination IP address for the AppleTV. The AppleTV is at 172.16.1.157 not 172.16.2.1.

172.16.2.1 is the firewall to the internet. So why is Roon trying to talk to the firewall when it’s supposed to be talking to the AppleTV? As I explained earlier, the Ubuntu Core box has an IP of 172.16.1.100 - so it can talk directly to the AppleTV and doesn’t need to go through the firewall. Also, the Core correctly discovered the IP address of the AppleTV based on the configuration:

For clarity, the Ubuntu Core box is multi-homed- meaning it has multiple IP addresses assigned to it (172.16.2.100/24 and 172.16.1.100/24). My MacBookPro only has an IP address on the 172.16.1.0/24 network so maybe that’s why Roon isn’t confused on my Mac, but if Roon is confused by this, that as best as I can tell is a bug in Roon. That or maybe someone who understands the Apple Airplay/RTSP protocol can guess what is going on?

Hi @Aaron_Turner,

Thanks for clarifying the issue and for letting me know about the multiple subnets/interfaces here. I have discussed your case with our senior technical team today and we believe that this is the main cause of the issue here:

Testing Roon on multiple network interfaces is not something we typically do, but in this case we are going to try and reproduce your findings in the lab and see if there is a bug here we can address.

Can I please request you share some more information on how you have the multiple IPs assigned to the Ubuntu Core? Are you using two different Network Adapters or are they configured virtually? What kind of firewall are you using, just the USG or something else as well?

One physical NIC, but two logical networks (VLAN’s):

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 9920841  bytes 4793692893 (4.7 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9920841  bytes 4793692893 (4.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p3p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.1.100  netmask 255.255.255.0  broadcast 172.16.1.255
        inet6 fe80::feaa:14ff:fedc:9396  prefixlen 64  scopeid 0x20<link>
        ether fc:aa:14:dc:93:96  txqueuelen 1000  (Ethernet)
        RX packets 121897244  bytes 123264994650 (123.2 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 106640527  bytes 118595095376 (118.5 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p3p1.100: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.2.100  netmask 255.255.255.0  broadcast 172.16.2.255
        inet6 fe80::feaa:14ff:fedc:9396  prefixlen 64  scopeid 0x20<link>
        ether fc:aa:14:dc:93:96  txqueuelen 1000  (Ethernet)
        RX packets 5002070  bytes 1268848214 (1.2 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 296707  bytes 30284347 (30.2 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ ip route
default via 172.16.1.1 dev p3p1 onlink
172.16.1.0/24 dev p3p1 proto kernel scope link src 172.16.1.100
172.16.2.0/24 dev p3p1.100 proto kernel scope link src 172.16.2.100

So the untagged interface is 172.16.1.100 and the tagged (vlan100) is 172.16.2.100.

I have my home network broken up across a few networks and the Ubuntu server is on two of them. The USG is also on both (172.16.1.1 and 172.16.2.1) while the AppleTV is only on 172.16.1.157.

Thanks for the additional info @Aaron_Turner, I have added it to the case notes.

QA will try to reproduce as I mentioned, but this may take some time to track down and I can’t comment on exactly when it will reach the queue.

In the meantime, if the MacOS is working as expected I suggest you use this for the time being. Thanks!

Sadly, since all (well both of them) my OS X boxes are laptops- mine and my wife’s. My wife shuts her laptop down when not in use and I travel/etc. As you can imagine, explaining to my wife she can’t listen to music when I’m not around because I took the music server with me isn’t gonna fly.

Anyways, I’ve got a few more weeks on my free trial; so hopefully you’re able to look into this before it expires. Let me know if I can be of any more assistance.

1 Like

Just got the notification that my free trial is about to expire. Any luck reproducing/fixing the issue?

Thanks!

Hi @Aaron_Turner,

I just checked the status of your ticket and I see that it is still pending review by QA.

I pinged QA again and they will attempt to reproduce the behavior and file a ticket, but as I mentioned above, I can’t quite specify when this ticket will reach their queue.

How has your Roon experience been like except for this issue? Have you found Roon to meet your needs? Are you ready to make the switch or is this issue preventing you from purchasing a license?

Well this bug prevents me from streaming audio probably 90% of the time so I really haven’t been able to effectively evaluate Roon for my needs. At this point, I really can’t see purchasing a license.

Hi @Aaron_Turner,

I have followed up via private message.

A post was split to a new topic: Node 2i Airplay Issues

So honestly, I never got it working. Roon extended my eval lic a few times and we got nowhere.

FWIW, I think the problem was my roon server was multi-homed on multiple subnets and that was causing confusions with the multicast announcements. Roon never contacted me to try any fixes they might of cooked up.

I’ve actually recently re-designed my network and traffic is now routed between networks and none of my hosts are multi-homed anymore. I’m kinda curious if that fixes the problem, but I’ve never bothered to reach out to Roon again for another eval lic.

Hi @Aaron_Turner,

I’ve followed up via private message!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.