Enhance temp directory names

[Why The]

Hi

This is an enhancement request.

Currently SparkSDR appears to create a temporary decode directory for each mode + receiver update and looks to assign random numbers to these tmp directories.

For users that are looking to aggregate and enrich the decode data with device / antenna information, it is impossible to know which Radio ID / RX ID created the directory, so attribution is not possible.

Would it be possible to enhance these temporary directories with useful metadata which includes a random number followed by a 2 digit Radio ID and a 2 digit RX ID. E.g. wsprdtmp_24624288_00_01. Even better would be to allow custom unique labels for each receiver + mode which are then used to name the directories (e.g. wsprdtmp_sdrplaymbv). This would likely only take effect after restarting SparkSDR with a profile though.

This way the Radios and RX id's could be programmatically mapped (best used in combination with SparkSDR's existing profiles feature).

Note whilst the websockets do include the rxid already, the output of the websockets does not include the same fields or field resolution compared with for example ALL_WSPR.TXT or fst4_decodes.dat files. So joining the websocket data to get the rxid is also not currently a feasible solution.

Cheers

[AndyZ K1RA]

I wonder if I could piggyback on this request and ask also if the temporary root folder name for writing WAV files might be user define in some settings or config file?  Even if by hand and not thru the UI.  I run CWSL_DIGI https://github.com/alexranaldi/CWSL_DIGI as a competing app against my SparkSDR and CWSL_DIGI app has the ability to set the temppath for digital mode WAV file recordings.  I point that at a RAMdisk (R:) created in memory, such as not to stress out my Windows C: SSD drive.

For Linux I'm writing a digital mode Skimmer app for KA9Q-Radio software for use with my RX-888 and there I'm using /dev/shm as my temp root folder for WAV files as not stress out that hard disk file system.

Thanks & 73

andyz - K1RA

[PE3ES / F4VTQ]

I second this request (third in fact) as I would like to de-dupe my decodes and need to find the right spots files per band in a more consistent location (WSPR and FST4W).

Of course individual software developers do not like examples from other colleagues (as it will restrict their own creativity in bringing solutions to non existing problems) so here an example

/dev/shm/spotfiles/wspr/receiver-1/40meter

/dev/shm/spotfiles/fst4w/receiver-2/20meter

or anything else STABLE !

Thank you.

Erwin

Op vrijdag 5 januari 2024 om 17:14:10 UTC+1 schreef AndyZ K1RA:

[ahop...@googlemail.com]

Hi All,

I need to give this some thought,  making the root for the files setable is not a problem but making the names constant could have a number of unintended consequences.  I often run run multiple copies of a decoder on the same band to do things like compare my own level 0 decoders with the wjstx versions, adding rx ids might work.

I'm currently spending what time I have on automating the build/test process now so many platforms are supported, once this is done I'll get back to adding features.

73 Alan M0NNB