kill_processes.sh and reset_bluetooth_connections.sh not working as expected.

[ekobres]

When I install on a Pi4B with fresh 64-bit full Bullseye image, things "sort of" work - but HTOP shows all 4 cores at 100% and there are multiple "unkillable" instances of pyparty. (They always restart immediately)

I can actually pair a couple of controllers and play a game. Trying to pair additional controllers causes problems.

Even after stopping joustmania in supervisorctl the pyparty processes keep popping up.

The result is it's impossible to develop and impossible to reset bluetooth because the system is spamming pyparty processes realtime.

Also, the tests script seems hardcoded to python3.6 and the installer installs python3.9 - updating the tests script to the correct version still fails all tests.

Any ideas?

[ekobres]

Update - if I image with Buster (Legacy) then the above problems do not occur. Seems to be an issue with either 64-bit or with Bullseye. Will test more.

[adangert]

Hi @ekobres I just updated the kill_processes.sh script that may be working now, I've also found that reset_bluetooth_connections.sh does work, but it may take a couple of times running (and rebooting) before the connections are reset, please let us know if it's working for you

also you can test if the reset_bluetooth_connections.sh worked if the folder /var/lib/bluetooth/ is empty.

[ekobres]

Thanks for the tip on /val/lib/bluetooth.

I may try Bullseye again if you think it will work.

Question on the CPU load: Is this high CPU utilization indicating a problem somewhere? My load averages are 4.57 470 4.37 - basically system 100% CPU and all processors with stuff in the queue.

Normally unblocked polling or whatever is happening to use so much compute is not an optimum situation. Is there maybe somewhere in the main loop of the game where a wait interval or callback would be able to be used instead? It could help everything run better if all the cores weren't 100% soaked.

Even input processing of time-sensitive accelerometer data could benefit from a smoother sample of interval polling rather than all-out polling.

[adangert]

Yeah this is definitely something that would help, right now each of the controllers has it's own while loop that looks for new data, the sound processing also eats up a bunch of compute

[ekobres]

Looking at the psmove project it seems a relatively easy measure would be to sleep about 6ms on the else of every if(move.poll())

Letting poll() run unblocked to consume the buffer until it returns false means it should be at least 6.66 ms before another event happens.

Disclaimer I know bupkis about Python - but I’ve done a lot of C++ embedded multithreaded stuff with hardware devices - so I understand the hardware and OS part way better than I understand what’s possible in Python.

[DrDecagon]

Can confirm, kill_processes fix works well.

[adangert]

Closing, the kill_processes.sh issue should now be fixed, the higher CPU rate we can try to tackle in a separate issue