Lessons learned from my use case
TinyPilot is awesome. We need it. But there are some shortcomings that will, I hope, be resolved eventually.
- Use case - I have 2 kids and I have to do things as a dad, yet I have to work. Tinypilot allows me to access my work computers from my Microsoft Surface tablet and so I don't have to lug around all the laptops to which I need access.
Problem: Tinypilot is not a streaming box. This means that even with Tailscale set up, the lag is unbearable. The remote screens appear but the mouse lag is what kills me. I can't click on anything without having to wait a while,a and so you can't really do anything useful.
Workaround - I enabled Windows RDP on one of my windows pro laptops. That protocol handles lags very well. So I can RDP into my Windows Pro laptop, and then get to TinyPilot and then it's usable, no issues at all.
Usecase: I have to login to one of my PCs (to which I don't have admin access) and initiate a Teams call. I try to connect on my phone via Tailscale.
Problem: It connects but the above mentioned lag issue exists. Also TinyPilot is not optimized for phone use.
Workaround: I have Google Remote Desktop setup on my Window Pro PC. Even without TailScale, I can connect to it via my phone, and then interact with TinyPilot in order to get the calls started.
Just thought I'd share this experience.
- CCharles Hague @cghague2023-02-06 22:18:05.588Z
Hi Santosh, thanks for providing this detailed feedback!
Remote Desktop software usually runs on the target system and captures the screen directly in software. This is good for latency but requires the target system to be online and running. TinyPilot is an IP-KVM (Internet Protocol Keyboard Video Mouse) which runs independently to the target system and captures the screen by “recording” the actual output from the target system. This takes a little while to process but has the advantage of removing the dependency on the target system. This means you can use a TinyPilot device even if the target system has no network connection, isn’t fully booted (e.g. displaying the BIOS) and so on.
We have been working to reduce latency and recently rolled out H.264 video support. H.264 is a very efficient video format and can drastically reduce latency - you can see some examples of how much difference it can make in our recent blog post. Can you please try turning on H.264 mode and checking if that makes a difference?
- ZIn reply toZantosh⬆:Santosh Krishnan @Zantosh
Hi there,
I have and it does reduce latency. But it crashes. So when it does crash, it falls back to the other option and there's some issue with this step, I haven't yet "debugged" the user experience yet. But in my use case, if I'm away for a while, like a week off skiing, I can't head home to reset things.
For example, last week, in my testing, something crashed with the new protocol. On my local computer, the windows pro, I managed to connect and change the setting, but from remote on an LTE connection, it was not possible. I didn't didn't too much time to figure it out because the quality is nice but the ability to reliably connect is what I need so I stopped using the new protocol.
Also, on a side note, if I don't close by browser for days, it appears to be connected but actually I'm seeing a cached version of the desktop. Today, I fired up my tablet and I thought I was connected to my laptop via tinypilot but when I did the RDP, through that computer the screens were totally different. I closed my tablet browser and reopened it and then it got the correct screens. Minor browser caching issue.
- CCharles Hague @cghague2023-02-07 10:51:39.255Z
Thanks for the detailed notes. I'm sorry to hear that you've had issues using H.264 mode.
I have and it does reduce latency. But it crashes. So when it does crash, it falls back to the other option and there's some issue with this step, I haven't yet "debugged" the user experience yet. But in my use case, if I'm away for a while, like a week off skiing, I can't head home to reset things.
For example, last week, in my testing, something crashed with the new protocol. On my local computer, the windows pro, I managed to connect and change the setting, but from remote on an LTE connection, it was not possible. I didn't didn't too much time to figure it out because the quality is nice but the ability to reliably connect is what I need so I stopped using the new protocol.
It should be possible for H.264 to be used constantly so it'd be great if we could investigate this and find out why it is crashing. Would you be able to send me a link to your debug logs the next time it happens? You can do this by going to System, then Logs and then clicking on Get Sharable URL.
Also, on a side note, if I don't close by browser for days, it appears to be connected but actually I'm seeing a cached version of the desktop. Today, I fired up my tablet and I thought I was connected to my laptop via tinypilot but when I did the RDP, through that computer the screens were totally different. I closed my tablet browser and reopened it and then it got the correct screens. Minor browser caching issue.
The majority of mobile devices use quite aggressive power saving techniques to maximise battery life and this can include suspending inactive browser tabs. I suspect this is what is happening here. The browser usually resumes the tab automatically when you interact with it, but if it doesn't you can normally press the refresh button to restart the tab.
- ZSantosh Krishnan @Zantosh
Just a follow up to this old case. I have been using H.264 successfully and the issue I reported is there, but if I close my browser and then re-open it, then it eventually works. What seems to happen is that if the browser has put the tab to sleep, then on reconnection, it defaults to MPEG and the H.264 doesn't show any image. But after clicking on the black rectangle and being patient, it seems to restart and connect.