unending SerialExceptions 😲 after ~30 minutes of sending commands to screen —— having to power cycle 😥

[ClaireCJS]

Describe the bug

First off, i LOVE this project. I was so happy to see that i could do something ELSE with my turing model "A" screen. They are going for only $13 on aliexpress right now.

Anyway —— Is this a bug, or do I just need to throttle my commands at a slower rate?

To Reproduce
Steps to reproduce the behavior:

1. Run my current winamp_dashboard.py program, which isn't yet published yet
2. Watch it fail over unending SerialExceptions after 30 minutes or so
3. Power cycle the frame because it will never ever reset eve again after this

I spent so long getting this thing to work, and once it worked. The frame conks out in 30 minutes.

Expected behavior
The library would not cause serialexceptions simply due to using it, or would return a more meaningful error code explaining what is going wrong and how to prevent that

Screenshots / photos of the Turing screen
Add screenshots or photos of the rendering on the smart screen to help explain your problem. You can drag and drop photos here to add them to the description.

DEBUG]     lcd_comm_rev_a: DisplayPILImage. is being run on an image of dimensions 800x40
DEBUG]     lcd_comm_rev_a: DisplayPILImage. [2] image_width/h=0x0,actual=800x40
DEBUG] DDDDDDDDDDDDrawing: DisplayPILImage: [4] x=0,y=0,x0=0,y0=0,x1=799,y1=39,image.size[0]=800,image.size[1]=40
DEBUG] DDDDDDDDDDDDrawing: DisplayPILImage: [5] self.SendCommand(Command.DISPLAY_BITMAP, x0=0, y0=0, x1=799, y1=39)
ERROR] SerialException: Failed to send serial data to device. Infinitely retrying.
DEBUG] Static COM port: COM4
ERROR] Cannot open COM port COM4: could not open port 'COM4': FileNotFoundError(2, 'The system cannot find the file specified.', None, 2)

Environment:

• Turing A [the one that uses lcd_command_rev_a.py]
• Version of your project? 2024/08/21 (I pulled it 3 days ago, so probably the latest?)
• WIndows 11
• 3.10.9
• AMD Ryzen9 5950X 16core 3.4/4.9GHz CPU+Gigabyte Aorus Ultra mobo+64G 4400Hz G.Skill RGB RAM+RTX3060 12G video+1TB WD PCIe4.0 NVMe M.2 SSD+18TB WD HD+liquid cool(w/RGB cpu light)+6 RGB fans+Phanteks case

Additional context
I can totally publish the product if you want to look at it, but I assume you probably do not. It's just one .py script (winamp.py) and one library (claire_winamp.py, i always put my first name into my own libraries so i don't forget it was me who wrote them 😂). Heck i could even email them if you want to look at them (but you probably don't).

[ClaireCJS]

p.s. when this happens, the screen is hung with whatever is on it, forever, until power cycled.

I soooooooooooooo wish there was a way to power cycle via usb signal.

I bet they probably never imagined we'd be tinkering with their toy so much! 😂

[ClaireCJS]

Here's another screenshot. It literally crashed in the middle of updating the progress bar (you can see how the column of pink-ish pixels wasn't completely drawn).

But i have no idea why this is happening. I can run it through the same song that crashes it another time and have it not crash it. It's intermittent. 😭

[ClaireCJS]

Tried slowing the port down from 115200 to 9600.

Tried throttling most screen updates with a 2 second pause.

Just won't last.

[ClaireCJS]

Running init() on the screen again just doesn't work. It stays hung forever unless you power cycle the screen, which seems impossible with software:

[mathoudebine]

Hello, I've never encountered this issue but here the issue may be with your screen since the library cannot communicate with it to send data frames until it is unplugged.

What is your screen size? Is it a 3.5" or a 5"?

Anyway, here are some things you could try:

• use the default software provided with the screen for 30min to see if the problem happens as well
• try to add a small delay between each frame you send to the display (maybe that's what you did with the 2s pause?) I don't know if you send frames to the display in loop or just periodically. If you do it in loop, try to add a small delay like 150ms
• if you have a 3.5" screen: try to disable the call to lcd_comm.Reset(), it should work without it

[ClaireCJS]

Thanks for the help!!!

1) Yup, that's the one. The one that comes with UsbPcMon. "Model A"

2) I used it for a few days actually. It was fine

3) Indeed, I've done sooo much delay and throttling. It would hold up with 0.25s / 250ms progress bar updates for an hour or so. I have a good 2s between most updates now. I can't go slow enough.

4) Oooooh I will try disabling that! I actually was calling it MORE to try to fix things, so this is a really helpful tip.

5) Given that lcd_comm.reset() can and should be skipped, I have to also ask about lcd_comm.InitializeComm() ... Am I still keeping those?

6) I lowered the baud rate f6om 115200 to 9600. (Insert UART chip joke here.) just in case going slower would help. but in theory that could make it worse by lowering the available bandwidth. Any guess on that one?

[ClaireCJS]

Got my winamp_dashbard project to run for 6 hours last night, I think definitely because of your tips! Thank you!

I also adjusted back up from 9600 to 115200 on the port, maybe i was squeezing it too hard in an attempt to throttle the crashes.

It only crashed this time after 6 hrs due to not liking a specific album art (Ramones song — I Wanna Live), which crashes DisplayPILImage consistently.

At that point, it is no longer being able to open the com port. At which point LcdCommRevA has no object 'reset' and it can't be reset.

I'm a bit lost on this, but i think the image data itself is somehow out of spec enough to crash the com port, except the image works everywhere else (minilyrics plugin, winamp info) so the image is definitely good enough for other things to render.

But not for DisplayPILImage?

For what it's worth, here's a copy of the image, though I don't know if Github blesses/changes it somehow upon upload. I'm about to go on vacation so i may not get to return to this for a bit.

[ClaireCJS]

[That image consistently crashes DisplayPILImage right before the top of the red shoes, at which point purple 'noise' spills out. i've seen a couple like this. my input set is 45,000 songs with differently sourced album art, so it's actually a wonderful testdata set. A bit too wonderful lol. It would take a year to play them all for testing.]

[ClaireCJS]

I actually hardened the code so that it autoconnects again if you power cycle it.

I was looking into USB libraries to automatically power cycle it when it detects a crash, but i hit a dead in in not being able to discern the screen and needing to decide if i want to power off ALL my usb ports at once, which... Would be annoying [i have sound effects, and i sleep!] so i didn't want to do it.

I'm not sure, but i think this is the line it actually crashes at:

                self.SendLine(rgb565le[start:end])

And when i say 'crash', i mean the screen. The code is still running and complaining. Good code! Bad screen! lol

[ClaireCJS]

p.s. Unrelated: I've added some code to my copy of your libraries that basically allows for transparent text over an image. Seen here with the WinAmp song title being overlayed over the album art.

Basically, it creates 1 image with the text, but with alpha transparency over everything except the rendered font (i think... it was a late night... i tend to not go to sleep when i get like this). A 2nd image with the art. They are then combined into 1 image. So I ended up having to add a 'bgalign' attribute because i tried both center and left/right alignments for the background. Perhaps that is something i could.. pull request into your side of things as a contribution? I've never done that before.