IO errno 5.

[nukdokplex]

Describe the bug
IO errno 5.

To Reproduce
I don't know how to reproduce this. It's random. For example last error was in a moment when i quit a game.

Expected behavior
No IO error OR not static screen. Maybe this IO error we can just ignore and don't stop queue?

Screenshots / photos of the Turing screen
So this is error in logs:

And here is ls /dev/tty*

Environment:

• 1b444aa
• Manjaro latest
• Python 3.11
• MSI Z170A GAMING M5, Intel Core i7 6700K, AMD Radeon RX6700XT

Additional context
Increased update time to minimum 2 secs in theme. systemctl restart turing restarts screen successfully and it continues working.

[nneul]

Seeing this as well. I'd be fine if it would actually crash - but the way it's currently behaving, it just hangs and doesn't terminate with the exception. If it exited the service could at least restart.

[nukdokplex]

@nneul but exception doesn't repeating. I think thread is actually stopped and doesn't throw this exception again. So there is two possible explanations:

1. Thread is actually stopped.
2. Thread writes serial without any errors, but screen doesn't update.

I could test this if I could somehow turn off screen restart during script initialization. If the first statement is true, then the screen should continue to update, if not, then the second statement is true. Please check if my logic is correct?

[nneul]

Probably easy enough to add a bit of debugging to write out a plain text debug message every N passes through the thread that is doing the serial writes. I think your logic makes sense.

[nneul]

It actually looks like it's being fired off as a repeating invoked function, and not a looped thread. I've added some logging to my instance, and will see if there is anything useful in output.

[nukdokplex]

Ok, so, i think that i can reproduce this strange bug. I quit a videogame (Prey 2017 via lutris proton if necessary) and screen was stuck instantly. I really don't know htf this s is connected, but... it is! And i don't know is it specific problem of proton, of prey or lutris. If anyone have some guesses i will listen very carefuly. So... WTF???

[nneul]

Not familiar with the game - but - does it use a headset? Maybe there is some sort of USB bus reset or other operation that is making the turing 'stumble'?

No video games in my case.

Does it happen every time you exit the game?

[nukdokplex]

@nneul yes, every time. And i don't use usb headset - it's jack3.5.

[nneul]

Meaning of that output - I wrapped each invocation of the callback function in the queue with prints of < and > respectively. The thread is either terminating or hanging in the middle of invocation of the callback function.

[nneul]

Could potentially be handled by adding a try around the queue callback function, and then if it traps an IO error, set a global to get it to exit the entire app or reestablish the serial connection.

[nukdokplex]

@nneul i'm waiting for that commit

[nneul]

Not sure what you mean - I don't have any fix - I'm just another user of this -- not the developer. Above was just a possible suggestion on maybe how to address it - not something I'm directly working on.

[mathoudebine]

@nukdokplex and @nneul I tried to make a fix for the issue you are encountering: on I/O error the program will close and reopen the COM port before a retry.
Can you test the branch fix/269-io-errno-5 and tell me if the fix works for you? I cannot reproduce the issue on my side, so I can't tell if it would work or not. Thanks!

[nneul]

I've installed it, will see if it looks, but it's relatively infrequent on my system. If @nukdokplex can easily reproduce that's going to be best test case.

[nukdokplex]

@nneul @mathoudebine Unfortunately, this fix didn't work. The exception is still thrown, but the script does not exit.

[nukdokplex]

@nneul @mathoudebine upd: i'm sorry, didn't checkout right commit. Seems like it's working.

After SerialException it reopens and screen continues updating.

[AwekM]

Can confirm the test branch works for me as well.

[nneul]

FYI - there may be some timing or other issues, as I just got this:

<>06/27/23 12:36:57 [DEBUG] Queue_Handler pass
<06/27/23 12:36:58 [ERROR] SerialException: Failed to send serial data to device. Closing and reopening COM port before retrying once.
06/27/23 12:36:58 [ERROR] Cannot find COM port automatically, please run Configuration again and select COM port manually

However - it exited now - which was the real concern previously that it just hung.

[mathoudebine]

Maybe the COM port auto discovery isn't necessary in this case: the program should try to open the same serial port, if it fails then the program will stop because it means COM port has changed/screen is disconnected so it is a valid stop case.
I'll make the changes, maybe in your case it will work without program exiting

[mathoudebine]

@nneul I just updated the main branch to avoid COM port auto-discovery after SerialException. Now the program will try to reconnect the same COM port, and show an error message if it fails

[nneul]

I suspect in my case what may be going on is that the device is blipping and then coming back. Something does appear to be causing a USB reset on my system causing it to disconnect and reconnect, but not lose power.