softsyst / qirx_issues

Issue tracker for QIRX
1 stars 1 forks source link

User selected and preferred recording paths #152

Closed Drehrumbum closed 6 months ago

Drehrumbum commented 8 months ago

Hi Clem!

Can you please introduce an option for user-selected and preferred storage locations for RAW and AUDIO recordings? If this storage locations are not accessible (more likely an external hard drive), QIRX should fallback to the normal paths. I can of course change the paths in the configure-file accordingly, but if I forget to connect the external drive before recording, I get an error message.

path-error

I occasionally do air-checks of all DAB multiplexes here, which means I record each multiplex for at least one hour each, sometimes more. This results in up to 100 GB of data, which is initially stored on the internal SSD. Over time, this wears the SSD much more than just “normal use”. Well, and at the end I still have to copy all the data to my external archive drive, which takes additional time.

TIA Heiko

softsyst commented 8 months ago

Hi Heiko,

I have some difficulties following your argument. Your use-case of monitoring whole muxes with raw files certainly requires enough disk space.

For me, your precaution of entering an external raw path in the config file is the right measure, and the reaction of the SW (your screenshot) is the proper one, reminding you to plug-in the external USB disk, also telling you the required path.

Creating different scenarios would be certainly possible, but "waterproof" disk and directory handling is always a challenge, and always a hassle for the programmer, prone to side-effects not having thought about when realizing it.

Two examples:

For now, I think I will leave it as is.

With the Audio files which you also mention, you will need a long time to fill a hard disk. You always can select AAC audio producing small files, the VLC player is an excellent choice for replay.

Clem

Drehrumbum commented 8 months ago

Hi Clem!

I’ll try again. First of all, I have enough free space on the internal SSD. Currently only 192 GB out of 952 GB are occupied. That’s good for an SSD (wear-leveling needs free space), not the problem, just as audio recordings are irrelevant. Actually I just want QIRX to write the RAW files directly to the external HDD if it is connected.

When the user presses the “RECORD” button, QIRX generates the file name (UTC, channel, sample frequency and receive frequency) and uses the base path (inside of the string “rawOutDir” according to ancient QIRX sources) extracted from the node:

<rawOut value="C:\Users\User\AppData\Local/qirx4/Raw/" maxSize="0" />

The file is created and recording begins. This will normally not fail since the path exists.

Now we assume there is a new node in the configuration file that is used first when pressing “RECORD”.

<rawOutPref value="e:\qirx\" maxSize="0" />

If the file could be created everything is fine, if not then the whole thing is repeated with the standard path. That’s actually all I want to suggest. It is also completely sufficient if this new node has to be inserted into the configuration file by hand.

BFN Heiko

Drehrumbum commented 6 months ago

Hello Clem,

can you please change QIRX (and possibly the last 3.xx version as well, if that's not too much effort) so that the program always looks at the configuration file (to read out the currently saved paths) when the user starts a new recording? At the moment (and I only tried the RAW path) QIRX reads the currently saved path only for writing the text file with the GPS data. In order for the path to also be used for the IQ files, the user must first restart the receiver.

However, the nice little GUI from the next release of viterbi.dll will look something like this, if enabled..

recpath

BTW: Maybe you can also omit writing the text file with the GPS data if no GPS mouse is connected.

THX Heiko

softsyst commented 6 months ago

Hi Heiko,

After returning from vacations, I had a look at your requests. If I get it right, there are no less than four requests now in this thread. It would be much easier to have only one request per thread, but I'll try to comment anyway.

Request No.4: Your "BTW", omitting the GPS text file without a GNSS sensor connected. This is a reasonable suggestion, and can be realized with not much effort. I will do this (as the only one of your requests). Useless files are certainly not a good thing.

Request No.3: The widget you are showing: I don't know if I got you right. Any control of your widget from within qirx will not happen. BTW, tinkering with thread prios is doubtful at least. There are quite a number of reasons to reject such an integration. But perhaps I understood you wrong.

Request No.2: The time looking at the config file for raws This could of course be done, but certainly not in the next release to come. It also would mean adapting existing interfaces (between Kernel and GUI), which I will not do currently.

Request No.1: Two selectable paths for raw recordings This also could be done, but the next release will not contain it. It also would mean to touch long existing and stable interfaces. I had a look at the effort, and currently I do not completely oversee the consequences or possible side effects. As I already pointed out, dealing in a "waterproof" way which such seemingly trivial things is from experience always more effort than expected, with almost certainly unwanted side effects.

Clem

Drehrumbum commented 6 months ago

Hi Clem!

To shorten my requests a bit:

It would be absolutely sufficient (for me) if QIRX always read the RAW path from the configuration file before a new RAW recording starts, Just like QIRX did it with the GPS text files in the past.

BFN Heiko

softsyst commented 6 months ago

Heiko,

as your "shortened" request has been realized in 4.2.2, I close this.

Clem