Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeout ? #71

Open
AR2000AR opened this issue Apr 5, 2024 · 5 comments
Open

Timeout ? #71

AR2000AR opened this issue Apr 5, 2024 · 5 comments

Comments

@AR2000AR
Copy link

AR2000AR commented Apr 5, 2024

When not using actively the open connexion, the next read/write operation (e.g set_color()) will failed as disconnected, however regularly calling update() will fix the issue.

The Client class may need a kind of keepalive mechanic

@AR2000AR
Copy link
Author

AR2000AR commented Apr 6, 2024

Repo with my source code : https://gitea.ar2000.me/AR2000/ed_led_sync

@jath03
Copy link
Owner

jath03 commented Apr 6, 2024

Interesting. This is probably an issue with how the FileSystemEventHandler runtime works. It probably puts the process to sleep until something changes in the file, which apparently closes the socket or something. That's my guess at least. I haven't looked far enough into the docs to know for sure.

If you have something that works, great! I would probably just put the first operation you do after a break in a try block. Something like this will probably work:

def on_modified(self, event):
    try:
        cli.update()
    except OpenRGBDisconnected:
        cli.connect()
    ...

That way you'd just reconnect as needed instead of constantly sending data.

@jath03
Copy link
Owner

jath03 commented Apr 6, 2024

You mentioned that it also happened in the interpreter. Were you using watchdog there as well?

@AR2000AR
Copy link
Author

AR2000AR commented Apr 7, 2024

No I'm not. In the interpret I have nothing else loaded. Only the client. But if I forget ot for a while, when comming back to it it crashes (openrgb crashes too)

@AR2000AR
Copy link
Author

AR2000AR commented Apr 7, 2024

Interesting. This is probably an issue with how the FileSystemEventHandler runtime works. It probably puts the process to sleep until something changes in the file, which apparently closes the socket or something. That's my guess at least. I haven't looked far enough into the docs to know for sure.

Since it happen also in the interpreter it cannot be that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants