2.8.9: high CPU, file open never completes (get_threshold_divisor_histogram?)

[cpatulea]

Hello again :-) Sorry for the burst of issue reports in one day :-)

Expected Behavior

1. File > Open... > select file
2. some processing time (~minutes)
3. signal is shown in main window, with waveform

Actual Behavior

1. File > Open... > select "HackRF-20201101_162940-90MHz-20MSps-20MHz.complex16s"
   Here is some information about the file:

$ ls -l HackRF-20201101_162940-90MHz-20MSps-20MHz.complex16s
-rw-r--r--  1 catalinp  eng  132120576 Nov  1 16:29 HackRF-20201101_162940-90MHz-20MSps-20MHz.complex16s
>>> divmod(132120576, 8)
(16515072, 0)

(so it appears to contain a complete set of I/Q complex16s samples)

2. URH starts processing...

after 90 minutes, it is still processing:

$ ps u -p 90694
USER       PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
catalinp 90694 100.0 14.5  6204612 1215752   ??  R     4:33PM  90:31.97 /Applica

My machine is not the newest and greatest, but it is not that slow..

I used Mac OS "Activity Monitor" to get a profiling sample of URH during this time. Here is the full text for reference:
Sample of urh.txt

But here is the part that I think is most important:

    2653 call_function  (in libpython3.7m.dylib) + 364  [0x10b0427ec]
      2653 _PyMethodDef_RawFastCallKeywords  (in libpython3.7m.dylib) + 395  [0x10af0d98b]
        2653 __pyx_pw_3urh_9cythonext_19auto_interpretation_5get_threshold_divisor_histogram(_object*, _object*, _object*)  (in auto_interpretation.cpython-37m-darwin.so) + 4237,4254,...  [0x11707ee0d,0x11707ee1e,...]

seems it is spending a lot (all of..) the time in function "get_threshold_divisor_histogram".

I guess it is some preprocessing step before showing in UI, but I do not know enough about URH internals to go further.

Steps To Reproduce

1. Open file (I do not know what in particular there is about this file)
2. URH starts processing, never completes..

Screenshots

nothing interested in screenshots, main window is just not responsive

Platform Specifications

• OS: Mac OS 10.15.7
• URH version: 2.8.9
• Python version: 3.7
• Installed via release DMG

[jopohl]

The demodulation parameters such as bit length and center are found automatically by URH. Sometimes these heuristics can take some time and you just stumbled across a very extreme case. Quick Fix is to uncheck "Edit" -> "Auto detect signals on loading".

[cpatulea]

Thank you! "Auto detect signals on loading" unchecked, and I was able to load the file in around 2 seconds.

The file is a recording of the FM broadcast band (90 MHz), I can share it if it would be helpful to you.

[jopohl]

Sure I can have a look at the capture, that would be helpful!

[cpatulea]

Here it is: https://ufile.io/pexazw8k Hope it helps!