Feature requests: 2 new %variables?

Dana

New member
I have 2 small feature requests:

A new variable like the existing "%len". But for the real lenght, because if the gap killer is activated, the track is shorter than the original.
So, "%reallen" for example. Nearly every track is shorter than the original and I use the "%len" for a progress bar. See the screenshot of the DAB radio display. This progress ends often at 95% or 97%. Not really perfect. So, how is the effort? The gap killer should know in the first second the real track lenght. And if you send after the first second the broadcast title format, then the information is valid.
I use at the moment this config:
%artist;%title;%filename;%playcount;%len;%seconds~
The result is processed in the DAB Mux and a PNG is generated for the digital radio and the send every 6 seconds.

My second request is a new variable like %lastplayed. Typicall the lastplayed date is after the first second of a tile the actual date and time. Nice, but I need the real last played time, not the latest played. So another variable would be fine. So what do you think? The background is to check the RP rule and to display in a DAB trial also the information.
 

Attachments

  • Clipboard04.png
    Clipboard04.png
    11.7 KB · Views: 28

djsoft

Well-known member
Staff member
A new variable like the existing "%len". But for the real lenght, because if the gap killer is activated, the track is shorter than the original.
So, "%reallen" for example.
Good idea, should be added in one of the future versions.

Typicall the lastplayed date is after the first second of a tile the actual date and time. Nice, but I need the real last played time, not the latest played
Do you mean previously played date/time?
 

Dana

New member
The actual time (Red) is well known during playing the title and also displayed under the playcount. Does this really makes sense to show this here? Because it is better to see the real last / previous play. Stations often play titles several times a day, because a new moderator doesn't know the previous playout. Only in the database.

To answer your question: Thanks if there is an access to the previous time, marked here in Green.
 

Attachments

  • Clipboard07.png
    Clipboard07.png
    46 KB · Views: 23

Dana

New member
Regarding the active / real title play time, I'm not sure if this is the track time minus gap killer. What I mean is the blue field at the end of the track here, because gap killer sets itself to 0 for this title. So there is another feature who did a gap. See market
Clipboard02.png
parts.
 

djsoft

Well-known member
Staff member
The actual time (Red) is well known during playing the title and also displayed under the playcount. Does this really makes sense to show this here? Because it is better to see the real last / previous play. Stations often play titles several times a day, because a new moderator doesn't know the previous playout. Only in the database.
Yes, makes sense, I've added it for the upcoming RadioBOSS 6.2.

Regarding the active / real title play time, I'm not sure if this is the track time minus gap killer. What I mean is the blue field at the end of the track here, because gap killer sets itself to 0 for this title. So there is another feature who did a gap. See market
The actual playback time = total track duration - gap killer - mix point.
 

Dana

New member
I forgot the mix-point. It makes sence to get all 3 timings into account. Thanks for your quick response. I'll wait for the next release to check that new variable!
The the values are correct, I think, reading the file in advance (like for the auto amp) shloud be recommended. That you have the gap killer and the mix point timing available in the fiorst second. Because then the broadcast .txt happened and the content of the text file should be valid.
 

djsoft

Well-known member
Staff member
The the values are correct, I think, reading the file in advance (like for the auto amp) shloud be recommended. That you have the gap killer and the mix point timing available in the fiorst second. Because then the broadcast .txt happened and the content of the text file should be valid.
It has all the information about the playing track, but not for the next track - it's evaluated with the delay.
The next version should have all this improved.
 
Top