Closed exelix11 closed 1 year ago
Also, this means that TYPE_MODE_SWITCHING should not be reported anymore since if mode switching got stuck the IPC thread would be stuck as well.
Hopefully the bugs that caused hangs during mode switching are fixed for good this time.
The macro definitions are still in the header file cause I was unsure about keeping this change (saves about 8K of memory for the switching thread resources) but I think I'll keep it and will remove the unused defines from the code in the next commits.
Thx for the info, I will update and test the overlay accordingly when I get the time for it.
Ok, did some testing, and since the call for the mode change is happening in the ui thread anyway, it waits for a return, and is blocking during that, so afterwards no wait should be required. That's not perfect, but using other threads would require bigger changes, so for now I will set the overlay ui to switching, and then do the blocking request for the mode change. There also not much the user can do during the change in the overlay anyway, so unless the system module hangs and never returns, there should not be a problem with this.
Hi, a few days ago i released V 5.5 with protocol version 11, commands are the same however mode switching is not async anymore since the issue that required that mechanism is finally solved.
This means that the IPC thread will now handle the mode switching as soon as the client disconnects, causing it to become unresponsive to new requests while it waits for the streaming threads to terminate and start again, this causes connection requests to hang.
In practice this means you shouldn't reconnect to sysdvr immediately after mode switching here but wait at least 5 seconds before letting the user open the overlay again.
The settings app now waits 2 seconds on exit after closing the service, considering the hbmenu loading afterwards it should total to about 5 seconds.