Remote TV Debugging.
I’ve been working in the Smart TV and media streaming space for nearly ten years now and wanted to talk about remote TV debugging.
One thing every TV developer runs into at some point is an issue that only happens on a specific TV model.
For instance, let’s start with the fun ones:
LG 2017–2018
Samsung 2018 or 2016 (if you’re mad or brave enough)
TV development is a fun space. It’s a bit like working with Internet Explorer back in the day finding bugs and issue that make zero sense, I talk about one below.
But working with these older Chromium based browsers can quickly become an uphill battle, especially when you’re trying to be an industry leader and shave 500ms off a VST (Video Start Time).
Before I go off track, let’s focus on developing across different TV models and devices.
Most companies have a development suite where you can log in and control TVs remotely. On paper, this sounds great. In reality, when multiple developers are fighting for the same devices (like the ones above), it becomes a long and frustrating process.
You’ll often hear:
“Hey, can I have the LG 2018 for an hour?”
“Yeah, sure, let me know when you’re done.”
Then you open it up, and the camera is already being used by another TV, or it’s not pointing at the right one, or someone’s standing in front of it. Oh, and you can’t get the debug logs, so you’ll need to build a custom debug UI to capture the console output.
Here’s something I’ve been using:
https://gist.github.com/samueleastdev/e85fe1d07f757c31d7875a28ff1f85ee
It lets you view logs over the TV UIand send them to a custom endpoint.
Recently, when working with teams across the world, I’ve noticed another issue. You might be trying to reduce VST time by 500ms from the UK over a VPN. In the office, they’re seeing sub 3 second VSTs, but from your home connection, you’re getting 5–6 seconds due to network latency. This difference has to be accounted for.
Get Samuel East’s stories in your inbox
Join Medium for free to get updates from this writer.
This is where the TVProbe LG Smart TV Remote Debugging Tool comes in:
https://github.com/samueleastdev/TVProbe-LG-Smart-TV-Remote-Debugging-Tool
With this tool, anyone can download and run it on their own machine and allow it to be controlled remotely over the internet. This helps eliminate wild theories about where time is being lost in the workflow. It also means I can directly check the telemetry data for VST from a remote connection in another country and control everything through the UI. All they need to do is point a webcam at the TV.
Most Smart TV developers have a few devices around, usually the buggy ones listed earlier. With this tool, you can share your TV with other developers, helping to avoid the common issues seen in corporate test suites. You can easily collaborate with another developer over Teams, or, if you’re brave, pair-debug together in real time.
Everything runs over ZeroTier, so once it’s running on your machine, as long as the other person has joined the same network and you’ve activated them, you can both use the devices.
Recently, I’ve been having fun with LG devices. For some reason, the playtime is inconsistent between models due to differences in their native player implementations.
- LG 2018: playtime is off and it doesn’t handle multi-period manifests
- LG 2019: fixed
- LG 2023: broken again
Ah, the joys of TV development.
Using the TVProbe tool, I can access LG 2018 and LG 2023 devices remotely and debug over ZeroTier, which is incredibly helpful.
Another thing many people miss when debugging older LG TVs is that you need to use specific Chromium versions listed in their documentation:
https://webostv.developer.lge.com/develop/getting-started/app-debugging
A fun fact (or painful one) is that these older Chromium versions don’t work on a Mac M4. So after buying a shiny new Mac, you might discover you need a Raspberry Pi with remote access just to debug with the correct version.
Feel free to contribute to the tool. It’s often better to have full control and speed up development, especially when working across different countries. Unfortunately, I think no one will make it through their TV development career without needing remote access to at least one troublesome TV.
