Frozen Screen: TinyPilot requires a reboot after 36h of uptime (with v2.5.4) otherwise the screen appears as a screenshot
- @cghague
TLDR :: When this occurs after 36h of uptime since this new 2.5.4 clean install (didn't occur 2.5.2). My logs show : Persistent Device Timeout (unplugged)
Question 1 - As preface:
Are there any currently known issues with reverting to the old EDID of OS Ver 10 within OS Ver 11 (Bullseye). I did this, and not sure if it is causing the following issue I've been experiencing only since upgrading (and reverted to the EDID that 2.5.2 was using and operating fine with)
-- ISSUE --
Since Bullseye OS Ver 11 (v2.5.4) where I came from OS Ver 10 : v2.5.2 on my Voyager 2, I am getting an issue where after 36-48 hours of uptime, TinyPilot video is "frozen" / "locked" and appears as a deceiving screenshot of the screen, as verified with the clock time and no mouse movement (despite the Mouse and Keyboard actually showing as moving on the Physical monitor)
- This is after a complete freshly nuked / clean installed 2.5.4 with only an EDID modification (and a few other minor SSH tweaks for root access which never caused a problem before).
- This never happened before with v2.5.2 (OS Ver 10), on the same slave Windows PC
- Input still works (as mentioned), even though it cannot be "seen". Physically being present shows mouse movements and keyboard input operating fine
- 0 display changes are occurring on the slave Windows PC that it is plugged into.
-- Fix ATTEMPTS --
- 1 - Un-F11-ing isn't helping (unsure if it's is causing this, but I F11 for Browser-mode Full Screen to pseudo (no pun) Full Screen, without doing it via TinyPilot to not have TinyPilot's cursor misalignment bug occur, which has been in existence for many past versions). Never caused an issue before.
- 2 - Opening in different browsers doesn’t help, nor opening on other LAN PCs.
- 3 - As mentioned above, mouse and keyboard input are still processing just fine.
- 4 - Flipping modes back to MJPEG just shows no signal. Same for going back to H.264 (and mouse and keyboard input still work)
- Yellow exclamation mark next to the video type says:
“
TinyPilot failed to stream video output from your target device using H.264 compression.
See System > Logs for diagnostic details.
Refreshing the page or restarting your device may fix the issue.
“ - 5 - Doing an ssh command like so does not help: sudo systemctl restart ustreamer.service
- 6 - Log investigation (see snippet of that below) show a common error of: Persistent Device Timeout (unplugged)
-- Workaround (non-ideal) --
- System > Power > Reboot or being physically present and yanking the power cable and plugging back in. This is non-ideal because it is fooling me to having the screen show something different.
-- Things not YET tried --
- Unplugging the HDMI cable on the slave PC and back again
- Blindly sending Win + P a few types to cycle through display changing to have display mode changed on the slave PC
- If this occurs after some random time on another windows PC as of this new OS Ver 11 ; TP v2.5.4
- Different EDID (or unreverting back to the default one with OS Ver 11 ; TP v2.5.4 and manually patching the TinyPilot string ... if there is even impacting this (seems possible)
-- Logs --
[Attaching Logs]
[Attaching EDID change]
(The forum here isn't letting me attach .txt files, so pasting these items here)
0 - EDID Changes (reverted to v2.5.2).txt
https://justpaste.it/6cs6w
1 - Logs - Frozen screen, still displays as ghost or frozen screenshot-like issue.txt
https://justpaste.it/d8p30
2 - Logs - After swapping to MJPEG - now shows No Signal (no longer as screenshot).txt
https://justpaste.it/9how1
3 - Logs - Good video (H.264) - After System - Power - Reboot.txt
https://justpaste.it/c4twm
Important error snippet when screen is either Frozen, or No Video after swapping display types in an attempt to fix. In both cases it results in the logs showing as : " Persistent device timeout (unplugged) "
INFO [118432.874 stream] -- Device fd=10 opened
INFO [118432.874 stream] -- Using input channel: 0
ERROR [118432.894 stream] -- Requested resolution=640x480 is unavailable
INFO [118432.914 stream] -- Using resolution: 1920x1080
INFO [118432.914 stream] -- Using format: UYVY
INFO [118432.914 stream] -- Querying HW FPS changing is not supported
INFO [118432.914 stream] -- Using IO method: MMAP
INFO [118432.926 stream] -- Requested 5 device buffers, got 5
INFO [118432.933 stream] -- Capturing started
INFO [118432.933 stream] -- JPEG-0: Initializing encoder ...
INFO [118432.933 stream] -- JPEG-1: Initializing encoder ...
INFO [118432.933 stream] -- JPEG-2: Initializing encoder ...
INFO [118432.933 stream] -- Using JPEG quality: 80%
INFO [118432.933 stream] -- Creating pool JPEG with 3 workers ...
INFO [118432.933 stream] -- Capturing ...
ERROR [118433.933 stream] -- Persistent device timeout (unplugged)
-- Now what ? --
Where do I go from here?
- Re-nuke (Clean install) again as OS Ver 11 ; TP 2.5.4? I don't why this would be required
- Clean install to 2.5.4 by obtaining Ver 10 (last supported), and check to see if the prior TP OS is impacted (still would change the EDID to the prior Toshiba as well, if thats needed), and just stay there until this bug in uStreamer is worked out, if ever?
- Add a daily reboot cron job like I previously did - How to best schedule a weekly or nightly reboot for performance? #post-2
- Revert back to the old EDID and try to patch the "TinyPilot" part or use some other EDID ... testing this out currently
- Are there other ssh commands I can try to refresh the display other than rebooting ustreamer (no effect), as mentioned, which can help track down what or why this is occurring ?
I will email support to try to obtain the following 2 images:
2.5.2 - in case I need to revert back
2.5.4 as Ver 10 OS - to test if have to go down that route
Thank you for your time and help. This is a really nagging issue and is causing me some stress when not physically in the same room as TinyPilot, and thus "seeing a ghost" when it seems screenshotted.
Secondary related question:
Can I just hex edit patch the new EDID bytes, by keeping it as v2.5.4s but just Hex Edit where it says the ASCII of "TinyPilot" and make it something different, or will that not work due to some sort of MD5 in the hex bytes needing changed too ? I ask since maybe keeping the new EDID (despite the old one previously working), works better with uStreamer / Bullseye (OS Ver 11). I think I can edit the product name without issue, according to this, correct ? In Device Manager under "Audio Inputs & outputs" I see "TinyPilot (Intel(R) Display Audio)" #post-16
If so I can un-revert the EDID back to the new one, and change the ASCII string itself and see if this fixes anything.
EDIT: Did the patch of the hex alone, and video is operating. Will see what happens after 36h
- CCharles Hague @cghague2023-05-08 12:02:23.644Z
Hi @Alt0, thank you for reaching out. I'm sorry to hear you're having issues with the video freezing. It looks like you’ve posted this question in a few different threads. In the future, please keep your question to one place, as duplicate posts make it harder for us to get an answer to you quickly.
It sounds like you might have found a solution for this issue already. However, I've reviewed the details in your post, and examined the attached logs, just in case. The reason for the lack of video appears to be that no signal is being received. This is sometimes misleadingly represented by the
Persistent device timeout (unplugged)message.As rebooting and/or reconnecting the HDMI cable restores the video feed the most likely explanation is that the target computer is putting the screen to sleep and then not reinitialising it. This is particularly common on laptops, but we've also seen it happen on desktops. As part of a recent upgrade we changed the TinyPilot device identifier, so it's possible you may need to reconfigure your display settings.
-- Now what ? --
Where do I go from here?I'm optimistic that your current solution will work out, but, if not, the following steps will be a good starting point for a more detailed investigation:
-
Check that the energy saving, sleep, and screensaver settings are configured so the "TinyPilot" monitor remains on and awake at all times.
-
Try relaunching the entire TinyPilot system using this command:
sudo systemctl restart ustreamer janus tinypilot -
If you have access to the target computer using another method, check if the "TinyPilot" monitor is still detected when the screen is blank.
I've addressed your additional questions below:
Question 1 - As preface:
Are there any currently known issues with reverting to the old EDID of OS Ver 10 within OS Ver 11 (Bullseye). I did this, and not sure if it is causing the following issue I've been experiencing only since upgrading (and reverted to the EDID that 2.5.2 was using and operating fine with)Reverting to the older EDID should be fine, although it's not something we've tested. The newer EDID adds additional modes and should be compatible with more devices.
Secondary related question:
Can I just hex edit patch the new EDID bytes, by keeping it as v2.5.4s but just Hex Edit where it says the ASCII of "TinyPilot" and make it something different, or will that not work due to some sort of MD5 in the hex bytes needing changed too ? I ask since maybe keeping the new EDID (despite the old one previously working), works better with uStreamer / Bullseye (OS Ver 11). I think I can edit the product name without issue, according to this, correct ? In Device Manager under "Audio Inputs & outputs" I see "TinyPilot (Intel(R) Display Audio)" #post-16
If so I can un-revert the EDID back to the new one, and change the ASCII string itself and see if this fixes anything.The EDID format includes checksums which mean that editing it directly isn't recommended. We do parse the EDID in a way that means it might work, but I'd advise against it. The recommended way to edit the EDID is to use a tool such as AW EDID Editor.
-
- AIn reply toAlt0⬆:@Alt0
Thank you for taking the time to reply in detail. And noted regarding first point (didn’t mean to).
The reboot I wouldn’t call a solution, more so a required manual workaround every 36 hours that it was occurring. Not want I want to always do / remember to do when seeing ghosts :)
Possible solution …
OK so, I kept the new 2.5.4 EDID and just patched the bytes where it said TinyPilot to change to another string, and it’s now stable thus far for more than 48 hours. I will watch it and see.
So perhaps the problem is indeed reverting to the old EDID on the new OS Ver 11 (Bullseye) maybe?I’ve seen that AW EDID editor suggested around here, but I thought others experienced issues where the hex bytes had to be converted to some .bin, edited, and then converted back or other pain points with it.
So I guess there is some checksum hash in there that provide integrity for all of these bytes and patching anything in there without updating other hex values is basically, unsupported / unexpected…?
Somehow it’s working without any other updates to it. And I can tell more (modes?) are being supported still because unlike in 2.5.2 (OS Ver 10), the slave PC is now respecting Night Light- CCharles Hague @cghague2023-05-09 13:45:43.683Z
The reboot I wouldn’t call a solution, more so a required manual workaround every 36 hours that it was occurring. Not want I want to always do / remember to do when seeing ghosts :)
The solution I was referring to was the EDID edit mentioned in your first post. I completely agree that rebooting every 36 hours would be a workaround and not a solution. I apologise for any confusion.
So perhaps the problem is indeed reverting to the old EDID on the new OS Ver 11 (Bullseye) maybe?
This shouldn’t have any impact, but it’s plausible that your computer has cached settings related to the older EDID that work better or that became muddled when the newer EDID was installed.
I’ve seen that AW EDID editor suggested around here, but I thought others experienced issues where the hex bytes had to be converted to some .bin, edited, and then converted back or other pain points with it.
It does appear to require the binary format which can be a hassle. Fortunately, editing the EDID isn’t a regular occurrence. I’d still recommend using an editor for anything other than the most basic modifications.
So I guess there is some checksum hash in there that provide integrity for all of these bytes and patching anything in there without updating other hex values is basically, unsupported / unexpected…?
That’s correct. The EDID format contains checksums to ensure it hasn’t been corrupted.
Somehow it’s working without any other updates to it.
We parse the EDID in a forgiving fashion, so checksum errors alone won’t prevent it from working.