03 / APPLE TV × BTV
Move the Apple TV without running a long Ethernet cable.
Btv’s wired-connection requirement limited where I could place my Apple TV. I used OpenWrt on the NAS and a Raspberry Pi to carry the long stretch over Wi-Fi, with only a short Ethernet cable beside the Apple TV.
The problem
Btv’s wired-link requirement limited where I could put the TV.
My approach
I joined the Pi and NAS OpenWrt over Wi-Fi/VXLAN and used a short cable to Apple TV.
What changed
Live TV played without a long Ethernet run, and I retained recovery steps after an AP change.
More freedom to place your TV.
Run a long cable to the TV for live channels.
Wi-Fi for the long stretch; a Pi and short cable beside the Apple TV.
FROM REQUEST TO RESULT
How I made it work.
- 01
Identify the constraint
I separated the app’s Ethernet requirement from the upstream provider network path.
- 02
Extend the network path
I linked the required network segment through a VXLAN tunnel between OpenWrt and the Pi.
- 03
Provide Ethernet locally
The Pi joins Wi-Fi and provides the Apple TV with a short local Ethernet connection.
- 04
Test playback and recovery
I tested live playback and packet loss, then restored the tunnel and connection after an AP change.
PLACEMENT FREEDOM, WITH A REAL NETWORK PATH
Wi-Fi for the long stretch. Ethernet for the last connection.
The obstacle in my setup was the connection path. OpenWrt and a Pi extended that path so the Apple TV could keep its Ethernet connection while the long upstream stretch ran over Wi-Fi.
Recorded traffic during playback
Packet loss in the observation
5-second samples; uninterrupted playback
These figures come from a 25-second playback check in my setup, not a long-duration or universal-provider test. After an AP change, I restored Wi-Fi on the Pi, the tunnel and then the Apple TV connection.
THE ROUTER SOFTWARE INSIDE THE NAS
What is OpenWrt?
OpenWrt is an open-source Linux operating system for configuring and extending router functions. I installed it in a NAS virtual machine to handle my home internet connection, device addresses and firewall rules.
LuCI provides the web settings interface, while UCI commands let you change settings over SSH. Packages can add more features.
COULD THIS WORK FOR YOU?
Could this work in your setup?
If the Apple TV still uses Ethernet, what gives this setup placement freedom?
BUILD DETAILS
Build details & ideas to reuse
01The TV spot I wanted had no cable
Live Btv on Apple TV encountered wired and direct-modem connection conditions in my setup. Rather than run a long cable across the room, I separated the Ethernet link Apple TV needed from the path back to the network.
02Connect the short TV cable over Wi-Fi
I connected Apple TV directly to the Pi’s Ethernet port and joined the Pi to the AP over Wi-Fi. A VXLAN tunnel between the Pi and OpenWrt in my NAS VM carries the existing LAN’s address assignment and TV traffic. Apple TV sees an Ethernet connection.
The path is NAS OpenWrt → switch → AP ⇢ Wi-Fi/VXLAN ⇢ Raspberry Pi 3 → short Ethernet → Apple TV. OpenWrt handles router functions such as routing, address assignment and firewalling. I used an agent to configure and check the setup; the equipment carries the traffic.
03Try playback and watch the latency
I played Btv over the Raspberry Pi 3’s 2.4GHz Wi-Fi. Playback continued without interruption for 25 seconds at about 13.44–13.50Mbps, with no measured packet loss. Sampling every five seconds showed typical stabilized latency of 6–18ms, with a temporary increase during initial background synchronization.
This showed that I could play the broadcast without a long cable. The short test does not establish all-day stability or performance at different bitrates.
04Restore the connection after changing the AP
After changing the AP, I checked the Pi, tunnel and Apple TV in order to restore the link, including reachability, VXLAN and HomeKit announcements.
05Keep the wiring rule with the setup
I reserved the Pi’s Ethernet port for Apple TV. Connecting it back to the upstream switch while the bridge is active can create a loop, so I kept that restriction in the handover. Troubleshooting follows power and cables, Wi-Fi, bridge/tunnel state and the endpoint address.
06The next checks would be longer
For a repeat test I would separate reboot recovery, weaker signal, competing downloads and extended playback. Interruption counts, worst latency and recovery time would describe everyday TV use better than a single average speed.
Scope and things to consider
I describe my Pi 3/OpenWrt setup, playback check and recovery after an AP change. Performance figures come from a 25-second observation. The setup provided wired recognition and playback in my Btv environment without changing subscription or account permissions.