Trunking Recorder v3.6.5899 released

[scannerbox]

Trunking Recorder v3.6.5899 has been released

The release can be found at Trunking Recorder - Recording audio from trunked radio systems monitored by Unitrunker, SDRTrunk, ProScan, and DSDPlus

The full list of changes since 3.5:

• Added support for importing DSDPlus MP3 recorded calls.
• Ability to set call purging per Talkgroup and per System overriding the global default number of days to save. To keep calls forever set the number of days to save to "0". Individual "private" calls will use the global days to save since they are not part of a Talkgroup. Patch calls will only get purged when all Talkgroups are ready to be purged.
• Ability to Edit the Call Text and Notes from web interface.
• Added automatic reloading the Web Server external SSL Certificate if it changes each night.
• Added a visual indicator on the web interface for when a call has been played.
• Added error detection to web interface PDF export button if it fails to load.
• Modified Print button to only export visible columns.
• Modified PDF export to remove odd new line characters in patch calls.
• Modified Excel formatting so Excel correctly display text values instead of treating them as numbers.
• Improved handling of Call imports (SDRTrunk and ProScan) when using a network drive (either mapped or full UNC path) hosted on a Linux machine.
• Added Call Import/Save option to "not import calls longer than". If a call is longer than the specified milliseconds the entire call will not be imported and the file will be deleted. Default value is "0" which will import all calls.
• Fixed the Favorite menu help text in Trunking Recorder not displaying.
• Fixed SDRTrunk import failing if the Trunking Recorder generated Call Filenames contained invalid characters.
• Fixed ProScan import where Frequency could contain slot number. Slot will be stored in LCN field.
• Fixed issue with SDRTrunk imports where coping multiple recording files at the same time would sometimes only import the first file until additional recordings were created.
• SDRTrunk recordings that are invalid and cannot ever be imported will be removed after 1 hour automatically (These are usually 0kB files that were created when SDRTrunk crashed during the middle of a call).
• Reduced Call Upload timeout settings for Broadcastify.
• Reduced the number of call upload retries.
• Removed the wait time between call uploads when "skew" is too long to help speed up the uploads.
• Increased the Azure Speech-to-text transcription Key length limit to 256 characters.
• Fixed purge issue if calls already existed in PurgeCalls table.
• Moved Sunday morning SQLite database optimization to run after recording purge process instead of midnight if call purge is enabled.
• Added better error handling of web server Public URL.
• Split the Admin No Call has been imported notification so SDRTrunk, ProScan, and DSDPlus each have their own settings.

 

[inthesmoke]

Saw this and noted the DSDPlus support, so thought I'd try it. I can't recall if it was Trunking Recorder or an alternative that I'd previously tried and it struggled with DSD.

Having tried it for less than 12 hours, but letting it import a few days of files, I'm stopping for 2 main reasons.
1. Insufficient handling of nested user aliases and what DSDPlus calls Talker Aliases
2. stripping of this detail in the filename from the import file to where TR saves
A little more on this below, it's a shame as otherwise it seems like quite a slick implementation and was rather efficent in processing 10s of thousands of files.

1. Insufficient handling of aliases
A quick diagram to explain. These are the files as created by DSD, before import to TR. TR handling of the below example is for the record with both a manually entered Alias in DSD, plus a decoded Talker Alias, the Talker alias is shown in TR as a Source TAG, and the Source Label is blank. For the record without a Talker Alias, the Manually entered alias is loaded to the Source Label field.
My expected behaviour is that both would show the manually entered alias (apologies for using a layman reference and not technical field name), would be shown for both examples as the Source Label. I would expected the Source Tag to show for those calls with that data, and if unknown for either/both then reported as blank/unknown/0.


2. File conversion / stripping of this data
Now I think I might be able to change this with the metadata settings in TR, but not sure.
Below are equivalent calls for the 2 UIDs, after TR import. Again, TR seems to ignore the manually entered alias for the call with a Talker alias and removes both the manual alias and talker alias from the filename, leaving just the UID. Whereas for the other example, it keeps the alias?? I'm guessing this is some way that the data is being handled by the database and stripped from the filename, but it means that I can't easily find relevant recordings unless I completely rely on TR. I don't like that lock in approach.




By no means take this as a complaint, as I appreciate all of the work that the coders and tinkerers do to give us all these tools, but trying to provide quality feedback to what I'm experiencing, as I know sometimes the feedback can be a little lacking in detail and ability to action.

 

[scannerbox]

Saw this and noted the DSDPlus support, so thought I'd try it. I can't recall if it was Trunking Recorder or an alternative that I'd previously tried and it struggled with DSD.

Having tried it for less than 12 hours, but letting it import a few days of files, I'm stopping for 2 main reasons.
1. Insufficient handling of nested user aliases and what DSDPlus calls Talker Aliases
2. stripping of this detail in the filename from the import file to where TR saves
A little more on this below, it's a shame as otherwise it seems like quite a slick implementation and was rather efficent in processing 10s of thousands of files.

1. Insufficient handling of aliases
A quick diagram to explain. These are the files as created by DSD, before import to TR. TR handling of the below example is for the record with both a manually entered Alias in DSD, plus a decoded Talker Alias, the Talker alias is shown in TR as a Source TAG, and the Source Label is blank. For the record without a Talker Alias, the Manually entered alias is loaded to the Source Label field.
My expected behaviour is that both would show the manually entered alias (apologies for using a layman reference and not technical field name), would be shown for both examples as the Source Label. I would expected the Source Tag to show for those calls with that data, and if unknown for either/both then reported as blank/unknown/0.

View attachment 177924
2. File conversion / stripping of this data
Now I think I might be able to change this with the metadata settings in TR, but not sure.
Below are equivalent calls for the 2 UIDs, after TR import. Again, TR seems to ignore the manually entered alias for the call with a Talker alias and removes both the manual alias and talker alias from the filename, leaving just the UID. Whereas for the other example, it keeps the alias?? I'm guessing this is some way that the data is being handled by the database and stripped from the filename, but it means that I can't easily find relevant recordings unless I completely rely on TR. I don't like that lock in approach.
View attachment 177925
View attachment 177926


By no means take this as a complaint, as I appreciate all of the work that the coders and tinkerers do to give us all these tools, but trying to provide quality feedback to what I'm experiencing, as I know sometimes the feedback can be a little lacking in detail and ability to action.

Thanks for the feedback,

The development work to add support for DSDPlus calls was done back in last summer which I believe is before DSDPlus really added support for OTA Talker Aliases. It looks like they changed the format of the audio filenames slightly to add this additional data so that's most likely causing the Trunking Recorder import process some trouble and why it's not showing up in the correct columns.

I would prefer to not need to read any call metadata from filenames for this specific reason, but unfortunately DSDPlus only includes some of the call metadata in tags within the audio file so I'm forced to scrape the rest from the filename. This makes it easily broken if the filename format changes. I reached out to the DSDPlus developers last year about getting more data added to the internal audio file tags but never heard back.

None of the systems local to me send OTA Aliases so would you be willing to send me a handful of your recordings so I can run them through my development machine to see about fixing the import processing? If you can zip them up and email them to support@scannerbox.us I can take a look at getting it fixed.

By default Trunking Recorder has it's own filename and folder structure for storing calls since it supports importing and recording from multiple programs at the same time. You can always customize the filename and folder structure Trunking Recorder uses using the "custome audio filename" option on the "recording" tab. It allows you to use any metadata field recorgnized by Trunking Recorder (so will miss the Talker Alias until I fix it). Just a reminder that certain versions of Windows have a 260 character filename\path character limit.

 

[inthesmoke]

Do you need the audio files themselves, or just a listing of the names? And how many would be useful?

Totally understand the last paragraph, and that's what I was thinking. Would still be a reason for me to not 'dabble' with TR, until I was willing to spend the time to set that up properly to my liking, but that's a personal preference thing, and we all have our quirks

 

[scannerbox]

Do you need the audio files themselves, or just a listing of the names? And how many would be useful?

Totally understand the last paragraph, and that's what I was thinking. Would still be a reason for me to not 'dabble' with TR, until I was willing to spend the time to set that up properly to my liking, but that's a personal preference thing, and we all have our quirks

Please send a dozen audio files spanning as many different groups and radio IDs if possible. This way I can verify that there is no other processing issue with the internal tags of the audio files created by DSDPlus.

True, but hopefully you will use the Trunking Recorder web interface enough for searching and playing back audio that you kind of forget about ever looking at the files manually again.

Thanks

 

[KC2GYU]

Is there any way to minimize Trunking Recorder to the Windows Tray? And a way to auto minimize it on program startup? I have proscan set to do this, but the Trunking Recorder is always taking up a spot on my taskbar.

 

[inthesmoke]

@scannerbox - those sample files are now emailed.

 

[SimplyTech]

Any chance we could customize the call notifications email?
Use case - I am sending calls off to push over email gateway and it leaves a bit to be desired with the way the data ends up being laid out.

 

[PDXh0b0]

This is awesome, thank you

 

[scannerbox]

Is there any way to minimize Trunking Recorder to the Windows Tray? And a way to auto minimize it on program startup? I have proscan set to do this, but the Trunking Recorder is always taking up a spot on my taskbar.

Currently it is not possible to minimize Trunking Recorder to the Windows Tray, I will add it to the enhancement list.

 

[scannerbox]

Any chance we could customize the call notifications email?
Use case - I am sending calls off to push over email gateway and it leaves a bit to be desired with the way the data ends up being laid out.

Yes, the notification emails use a template file that can manually be customized. They are stored in "C:\Program Files\Trunking Recorder\EmailTemplates\" The "CallNotification.cshtml" file would be the one you would be interested in. Trunking Recorder uses the Razor HTML template system to take the call information and generate the final HTML email.

If you look in the current template you will see various lines containing "@Model." these are the placeholder values that get replaced with the call information when the notification is sent (Example: "@Model.Call.TalkGroupInfo.sourceid" would get replaced with the Call SourceID value.
You should be able to create a simpler HTML email template that works better through Pushover.

After you make a change to the template you will need to restart Trunking Recorder for the changes to work.

 

[DanKATL]

@scannerbox how does the ProScan Call import function detect new files? Does it look for a trigger from ProScan, or does it monitor the configured ProScan recordings folder for changes in the same way that SDRTrunk import works?

I recently added ProScan Calls import and I currently have to stop/start recording before it will import new files. I have two ProScan instances that reside on remote systems, so the files are relocated to the Trunking Recorder computer for import via FTP. On Start Recording, files from both ProScan sub folders import with correct metadata. It will not import again until I stop/start recording.

I use the same process as described above for SDRTrunk call import and it's been working without issue for a long time.


Thank you

 

[scannerbox]

Trunking Recorder uses a Windows file system watcher to detect when files are changed in the ProScan and SDRTrunk import folder paths. It specifically looks for changes to the "Last Write" time of a file.
Looking for only a subset of file events is done to prevent creating a conflict with SDRTrunk or SDRtrunk since they could still be creating and writing to the call recording files and I don't want to try and import something in progress.

My guess is moving the files via FTP is causing Windows to treat this as a file move and doesn't create a change file system event so Trunking Recorder doesn't see the new files. (Doing a Stop/Start causes Trunking Recorder to manually sweep the folder for files on startup)

Not sure exactly why it's working for your SDRTrunk import, the only difference is the SDRTrunk import does do some add some extra file system events if it detects the path is a network drive (this was done to support some Linux machines that didn't send the standard windows events on file update).

Trunking Recorder does not scan the input folder every few seconds since this could cause a performance issues, can keeps the hard drive from spinning down, or can cause extra wear on SSD drives.

Nor sure if you are using a script to do the FTP process, but you could try modifying it to "touch" the files after it moves them to update the last modified time. This might trigger Windows into generating a system watcher which Trunking Recorder can detect and will import all the files.
If you are using PowerShell you could add something like "(Get-Item C:\Path\To\recording,mp3).LastWriteTime = (Get-Date)"

I should also be able to add the same network drive support to the ProScan import process if that would help but I'm not sure it would.

 

[DanKATL]

Trunking Recorder uses a Windows file system watcher to detect when files are changed in the ProScan and SDRTrunk import folder paths. It specifically looks for changes to the "Last Write" time of a file.
Looking for only a subset of file events is done to prevent creating a conflict with SDRTrunk or SDRtrunk since they could still be creating and writing to the call recording files and I don't want to try and import something in progress.

My guess is moving the files via FTP is causing Windows to treat this as a file move and doesn't create a change file system event so Trunking Recorder doesn't see the new files. (Doing a Stop/Start causes Trunking Recorder to manually sweep the folder for files on startup)

Not sure exactly why it's working for your SDRTrunk import, the only difference is the SDRTrunk import does do some add some extra file system events if it detects the path is a network drive (this was done to support some Linux machines that didn't send the standard windows events on file update).

Trunking Recorder does not scan the input folder every few seconds since this could cause a performance issues, can keeps the hard drive from spinning down, or can cause extra wear on SSD drives.

Nor sure if you are using a script to do the FTP process, but you could try modifying it to "touch" the files after it moves them to update the last modified time. This might trigger Windows into generating a system watcher which Trunking Recorder can detect and will import all the files.
If you are using PowerShell you could add something like "(Get-Item C:\Path\To\recording,mp3).LastWriteTime = (Get-Date)"

I should also be able to add the same network drive support to the ProScan import process if that would help but I'm not sure it would.

Thank you for the information, it confirms how I expected it to function. For more context, the FTP Server Service (FileZilla) resides on the Trunking Recorder system. The remote systems (both ProScan and SDRTrunk) are using a Second Copy (Centered Systems) FTP job to move the files to the FTP server (all are using the same 9.5.0 version of Second Copy).

Tonight, I was able to do bit of further testing and do have a functional work around. Manually moving them out and back into the Import folder allowed them to be detected without a stop/start consistently. The FTP server now drops the ProScan files into a temporary folder (D:\ProScan\FTP), then a simple robocopy script moves them into the ProScan Import folder (D:\ProScan\Recordings); where they're detected and imported as expected. It's an extra step/more complexity, but it's working.

The SDRTrunk imports are dropped directly into the SDRTrunk Import folder (D:\SDRTrunk\Recordings) by the same FTP server and continue to work.

Both import folders are located on the same local SSD (D:\SDRTrunk\Recordings and D:\ProScan\Recordings), so as you I'm not sure if the network drive support would help in my case. If SDRTrunk import process has it and the ProScan one doesn't, I'm willing to test if you add the support when you have some time.

Thanks Again!