Rejected calls due to system not existing

[cpg178]

I have been having an intermittent issue where calls from SDRTrunk for a particular system would be rejected as it would try to send them to sysid 4 which did not exist. Normally they would route to sysid5. This got annoying so I decided to fully wipe my DB and start from scratch by setting up my 4 systems with the system name the exact same as SDRTrunk but now it is trying to send the calls to sysid 5 which does exist... any insight will be helpful as if I turn on the main auto populate option it makes a new system for each call that comes in, even if the TG is the same.

[cpg178]

(removed)

[cpg178]

User error, auto populate was not checked WITHIN the system

[cpg178]

So apparently enabling auto populate, does not fix the issue either. I tried changing the system ID to 5 as that was what rdio was trying to send the files to, but then the system starts trying to send it 4 which rejects it as 4 no longer exists.

[chuot]

Have you checked discussion #262 that you opened on the same topic. I gave you some hints in this regard.

[cpg178]

Yes, both are named ‘Luzerne’. I turned on auto populate to allow it create a new system yesterday afternoon, and seemed to stop the error from occurring on the new DB that I had created. I will continue to monitor to see if the intermittent errors occur like they did before, but am hopeful a DB wipe will fix it as my old DB the ids were not sequential for some reason.

On Tue, Sep 27, 2022 at 7:18 AM Chrystian Huot @.***> wrote:

Have you checked discussion #262 https://github.com/chuot/rdio-scanner/discussions/262 that you opened on the same topic. I gave you some hints in this regard.

— Reply to this email directly, view it on GitHub https://github.com/chuot/rdio-scanner/issues/266#issuecomment-1259352704, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCLRPRKON2VUEDVDKXROGDWALJWZANCNFSM6AAAAAAQWCGQQQ . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Sent from Gmail for iPhone

[chuot]

The SDRTrunk parser relies strictly on the MP3 tags generated by SDRTrunk. Unfortunately, there is no system id available there, only the system name that matches what is set at the Playlist Editor level.

So the parser code here searches for a matching system name. If it finds it, it uses the system ID to populate the call data. If it does not find it, it tries to find the next available system ID, which will then be refused if autopopulate is not enabled.

[cpg178]

Thanks for the insight with the code, it’s interesting as I have 2 other separate SDRTrunk systems that had no issues just this one. The other 2 are NBFM so not sure if SDRTrunk would name the audio files different from the trunked system. What was especially interesting was it would reject TGs that already had been ingested to rdio before, saying no system/tg existed, prior to me wiping the DB and starting over.

On Tue, Sep 27, 2022 at 8:49 AM Chrystian Huot @.***> wrote:

The SDRTrunk parser relies strictly on the MP3 tags generated by SDRTrunk. Unfortunately, there is no system id available there, only the system name that matches what is set at the Playlist Editor level.

So the parser code here https://github.com/chuot/rdio-scanner/blob/af41604322ba3be3e0843263472a0413a8badff7/server/parsers.go#L188-L193 searches for a matching system name. If it finds it, it uses the system ID to populate the call data. If it does not find it, it tries to find the next available system ID, which will then be refused if autopopulate is not enabled.

— Reply to this email directly, view it on GitHub https://github.com/chuot/rdio-scanner/issues/266#issuecomment-1259458941, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCLRPTT4C52MYXGZAG5XODWALUO3ANCNFSM6AAAAAAQWCGQQQ . You are receiving this because you modified the open/close state.Message ID: @.***>

-- Sent from Gmail for iPhone

[chuot]

Maybe something is wrong with the MP3 tags? Try to identify a file outputed by SDRTtrunk and check the MP3 tags for some hints. Beware that Rdio Scanner overwrite those MP3 tags if you turned on the audio conversion and if ffmpeg is installed along with Rdio Scanner. In that case, check the files from SDRTrunk directly, not from Rdio Scanner.

[cpg178]

WIll do, I tried to look for any settings to customize the file names like with ProScan yesterday but could not find any.

On Tue, Sep 27, 2022 at 9:13 AM Chrystian Huot @.***> wrote:

Maybe something is wrong with the MP3 tags? Try to identify a file outputed by SDRTtrunk and check the MP3 tags for some hints. Beware that Rdio Scanner overwrite those MP3 tags if you turned on the audio conversion and if ffmpeg is installed along with Rdio Scanner. In that case, check the files from SDRTrunk directly, not from Rdio Scanner.

— Reply to this email directly, view it on GitHub https://github.com/chuot/rdio-scanner/issues/266#issuecomment-1259488528, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCLRPQUOP2SH227L5WQXHDWALXHRANCNFSM6AAAAAAQWCGQQQ . You are receiving this because you modified the open/close state.Message ID: @.***>

[cpg178]

Here is a metadata extraction from a recording along with a screencap of my system info, coincidently it has just started to reject certain files now after working flawlessly for almost 24hrs.

[chuot]

Great, that will help in troubleshooting your issue. If possible, can you send me by email a Rdio Scanner config export of your instance.

[cpg178]

Just sent it to you

[chuot]

@cpg178 Please update the issue with your findings in regards to multi-site recording.

[cpg178]

The issue occurs due to 2 separate sites for my system. Even though the system name is the same, SDRTrunk outputs each site as a separate system causing confusion with RDIO. I fixed it having a seperate RDIO System for each site.