UI becomes unresponsive after entering new different discovery range

[tyalie]

As the title states

[Chleba]

Hi,
This may happen when you have a small amount of cores thanks to green tokio threads. You may try to wait a moment. The process of scanning is still running and after a while, the UI becomes responsive again.
I will address this issue in the near future.

[tyalie]

Hm. I was actually on a 12 core machine :/

[Chleba]

Hi,
Did you wait a while and then the UI became responsive again ?
I am thinking about a solution and will try a few things to fix this issue, but I would like to know if it freezes completely on Your PC or if it just lag for a moment.

[Stridsvagn69420]

I have a similar issue. What I noticed is that the Wi-Fi network lookup seems to be the most impactful. When I'm connected to my Raspberry Pi 4, a second TTY with btop freezes when netscanner also does, and I can replicate this behaviour when I run iw dev wlan0 scan manually.

I don't have this issue if I were to use nmcli dev wifi list, the command just takes a bit. Also, if I skip SSH and directly access a TTY, I can freely switch between netscanner on tty1 and btop on tty2. So the UI hangs and apparently also the network, but not the actual system.

Also, I noticed in btop that netscanner, when it's not frozen, only seems to be using a single core? But then it's the entire core, and shortly afterwards it hangs again.

Lastly, maybe unrelated, but MAC-Address and Hostname lookup seems to be way slower than if I were to manually arp-scan and look up hostnames. The current version I have installed is 0.6.3, but I have another Raspberry Pi 4 where I had version 0.5.3 installed directly via cargo and those two lookups were faster. Though the freeze issue was still present.