Radar seems broken for last couple of updates?

[FloraMaeWolfe]

Not sure if this is an issue on my end, a hardware/software/radar site issue, or an issue with this app.

https://pastebin.com/raw/eDckfvYp

Version 0.3.0 and 0.3.1 has shown this issue. I have not tested other versions. Went to load the app, it loads fine from the looks of it but radar data never shows. I did a clean settings test (deleted old settings and started new) and nothing changed. I also tried a couple of other random radar sites and the console log was similar.

The paste is the whole log, I also noticed it seems the program hangs on close so had to ctrl+c it.

[dpaulat]

This is not expected behavior. KRAX works for me, so the issue should not be with the radar site. I see two things here, maybe or maybe not related.

Issue 1:

[2024-01-20 15:51:56.383] [222999] [debug] [scwx::qt::map::radar_product_layer] UpdateSweep()
[2024-01-20 15:51:56.384] [222999] [debug] [scwx::qt::map::radar_product_layer] Sweep locked, deferring update
[2024-01-20 15:51:56.398] [222999] [debug] [scwx::qt::map::radar_product_layer] UpdateSweep()
[2024-01-20 15:51:56.398] [222999] [debug] [scwx::qt::map::radar_product_layer] Sweep locked, deferring update

This appears to be an issue I need to solve with the application. Seeing a couple of these isn't a concern, but seeing it repeatedly is. I haven't seen this recently, after some updates I made last summer. I'll need to dig back into this.

Issue 2:

[2024-01-20 15:51:53.877] [223044] [debug] [scwx::provider::aws_nexrad_data_provider] ListObjects: RAX_N0B_1970_01_01_
...
[2024-01-20 15:52:30.440] [223044] [warning] [scwx::provider::aws_nexrad_data_provider] Could not list objects: curlCode: 28, Timeout was reached

I should probably filter out attempting to list objects back to 1970, but this should just come back with "no objects found", rather than timing out after ~40 seconds.

A couple of theories/questions...

• Is this in a virtual machine with a limited number of CPU cores?
  • If so, I'm wondering if increasing the number of cores available to the VM helps.
  • I could inadvertently be keeping something from running that keeps the radar data from loading.
• Anything unique about your internet connection?
• Do any warnings appear in the alert panel (turning off the active alert filter if necessary)?

I'm not sure if there are any settings that would help or hurt this behavior (except maybe a 1x1 grid). The program hanging on exit is likely due to the program trying to load radar data (unsuccessfully) in the background.

I'll try playing around with settings or artificially slow things down to see if I can reproduce.

Thanks for the report.

[FloraMaeWolfe]

Not a virtual machine. The network is wifi using cellular home internet (5G cellular). The results seem to not change if I enable VPN or use regular plain internet.

I also just tried viewing archived radar data and see this error
[2024-01-20 17:13:58.544] [257068] [info] [scwx::qt::manager::timeline_manager] No volume scan found for 2024-01-20 21:51:00

I see nothing in the alert panel.

Some system info:
Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz

                      total        used        free      shared  buff/cache   available
Mem:           7.6Gi       6.1Gi       677Mi       297Mi       1.5Gi       1.6Gi
Swap:          8.8Gi       497Mi       8.3Gi

Kernel driver in use: i915 (graphics)

[dpaulat]

Thanks for the info. I was able to reproduce the issue in a virtual machine by artificially increasing my latency, and confirm the issue 1 and 2 noted above are related. It doesn't appear to take much, and I would expect the VPN to produce worse results. I expect not just 5G home internet, but anyone using on a mobile connection to potentially experience this issue (on Linux, not sure about Windows).

You can check your latency to AWS regions here:
https://clients.amazonworkspaces.com/Health.html
It appears a round-trip time to US East somewhere in the neighborhood of 250ms or higher causes an issue.

The "Update Sweep / Sweep Locked" messages are printing while waiting for AWS to respond. This message appearing shouldn't be an issue in this circumstance.

The issue doesn't appear to have anything to do with system specs (at least not the hardware you're using). Your CPU (with the Intel HD Graphics 4000) should be more than sufficient to run.

I'm going to play around with the AWS SDK library, and see what I can do to reconfigure it in order to not timeout in this manner (250ms latency shouldn't lead to a no response).

[FloraMaeWolfe]

Using that test, with plain internet, the range is 150ms to 280ms with one check being over 4000ms?
With VPN it ranges from 222ms to about 500ms. The highest seen with VPN was around 2000ms. So, seems for me and my connection, anywhere from 200ms to 5000ms.

[dpaulat]

Thanks for the results. In my environment, I've been running with a latency of about 725ms. I increased the default AWS connection timeout from 1 second to 10 seconds, and things seem to now work with higher latencies. I expect alerts may take a few extra seconds to load.

Could you try the artifacts from the following build?
https://github.com/dpaulat/supercell-wx/actions/runs/7606481219

[FloraMaeWolfe]

I can confirm the appimage at that link does load radar data :) thank you.

[dpaulat]

Excellent! Thanks for reporting back!

I think there's some still some things to improve upon for lower latency connections, or recovering if the applications starts while offline. For now, I suspect this will work for the vast majority of use cases, and I'll open a separate issue for that.