Blank recordings and duplicates uploaded to Broadcastify. SOX warning.

[gonzoblue]

During the normal running I will see something like this go by:

[2023-11-22 15:30:54.005379] (error) [SD700] 5C TG: 101 ( WES DISP 1) Freq: 769.756250 MHz No Transmissions were recorded! [2023-11-22 15:30:54.005437] (error) [SD700] 6C TG: 8192 ( SD Sanitation 2) Freq: 769.318750 MHz No Transmissions were recorded! [2023-11-22 15:30:56.018835] (error) [SD700] 14C TG: 323 ( ADMIN 7A) Freq: 771.068750 MHz Dropping 1440 samples - current_call is null Rec State: available Since close: 1 [2023-11-22 15:30:57.010825] (error) [SD700] 17C TG: 8192 ( SD Sanitation 2) Freq: 769.318750 MHz No Transmissions were recorded! [2023-11-22 15:31:05.009238] (error) [SD700] 59C TG: 1621 ( 6B SLJ) Freq: 769.818750 MHz No Transmissions were recorded! [2023-11-22 15:31:05.010745] (error) [SD700] 60C TG: 8192 ( SD Sanitation 2) Freq: 769.318750 MHz No Transmissions were recorded! [2023-11-22 15:31:08.005543] (error) [SD700] 68C TG: 407 ( CMD 7H) Freq: 771.268750 MHz No Transmissions were recorded! [2023-11-22 15:31:08.006323] (error) Somehow, /dev/shm/SD700/101-1700695867_770256250.wav doesn't exist, not attempting to provide it to sox sox: SoX v14.4.2 sox FAIL sox: Not enough input filenames specified

And then I get a lot of these messages, and when checking my recordings on Broadcastify they are all 0 seconds in length and basically contain nothing:

Broadcastify Upload Skipped: SKIPPED---ALREADY-RECEIVED-THIS-CALL

I have also seen a message about sox and fdkaac are required, but both are installed. This happens as of the latest git pull on 11/22/23. I have been running and older version without issue for a month or two. For now I have checked out the version from 40 days ago (I picked a slightly random number of days when I might have last updated). It is back to working just fine.

[taclane]

If you are able, please post your config (removing any API keys). There were some recent changes in how r-t reads in the config.json, and there are likely a few remaining issues to track down regarding the config variables.

[gonzoblue]

There were a few warnings at first startup about some config variables that before I either had quoted or not quoted that I had to fix, but this at least would launch and run and appear to be working, except for above:

"ver": 2,
    "sources": [{
        "center": 770400000.0,
        "rate": 3000000.0,
        "error": 1050,
        "squelch": -50,
        "ifGain": 10,
        "lnaGain": 12,
        "mixGain": 12,
        "gain": 15,
        "analogRecorders": 0,
        "digitalRecorders": 14,
        "driver": "osmosdr",
        "device": "airspy"
    }],
    "systems": [{
        "control_channels": [771481250, 769806250, 770306250, 770806250],
        "type": "p25",
        "shortName": "SD700",
        "callLog": false,
        "digitalLevels": 1,
        "modulation": "qpsk",
        "recordUnknown": true,
        "minDuration": 0,
        "maxDuration": 0,
        "talkgroupDisplayFormat": "id_tag",
        "hideEncrypted": true,
        "talkgroupsFile": "sd700tg.csv",
        "broadcastifyApiKey": "API-STRING",
        "broadcastifySystemId": ##,
        "audioArchive": false
    }],
"broadcastifyCallsServer": "https://api.broadcastify.com/call-upload",
"frequencyFormat": "mhz",
"softVocoder": false,
"controlWarnRate": 5,
"callTimeout": 0.75,
"logFile": false,
"logLevel": "info",
"defaultMode": "digital",
"captureDir": "/home/pi/trunk-build/"
}

[taclane]

I can almost bet it is this: "callTimeout": 0.75, Try setting it to a whole number for now: "callTimeout": 1,

callTimeout has been rounding down as an integer since the change. It's essentially setting "callTimeout": 0, which should be responsible for a fair bit of the mayhem you reported.

I don't think you are the first to bring this up, hopefully a fix can go out pretty soon.

EDIT: It didn't actually get read in as a decimal before, it's just that the present conversion appears to truncate more than round.

[gonzoblue]

Made that one change and it looks like it is running much better after a few minutes. That should be it, thanks! You can close or keep open until fixed, whatever works for your workflow.

[taclane]

Heh. It is actually a little weird because callTimeout has always been an integer, even before this update.

It's just that it's suddenly rounding down now, and that value being 0 can cause all sorts of unpredictable issues.