RadioBOSS 5.5 [beta]

[djsoft]

Yes, it's a question of priority. Currently file type color settings take precedence over "played track" and "playing track" emphasizing settings. The "selection" color is top priority. It's not right or wrong, it's how it works. During the beta "emphasizing" settings were priority over file type and we received lots of complaints, like "file type color settings become ignored after a track was played", that's why now it works with file type colors priority.

 

[box26609]

Yes, it's a question of priority. Currently file type color settings take precedence over "played track" and "playing track" emphasizing settings. The "selection" color is top priority. It's not right or wrong, it's how it works. During the beta "emphasizing" settings were priority over file type and we received lots of complaints, like "file type color settings become ignored after a track was played", that's why now it works with file type colors priority.

Oh, okay. Thank you for the clarification. I wonder then if there might be another way to distinguish between played songs and unplayed songs on the playlist that's not colour specific - let's say for example creating an optional "status" column that displays a check mark icon [?] for items that have been played and a dot mark icon ( ? ) for those that are pending. Would this be possible? This way the colours are preserved but we'd still have a way of knowing what has already played with a quick glance at the playlist. I've seen something like that in RCS Zetta (screenshot attached).

 

[djsoft]

It changes the icon - unplayed tracks are blue, and played are grey. Please see the screenshot attached. However, depending on what background color you use for playlist window, it may not be clearly visible. Thank you for the suggestion about status column, we'll consider it for the future updates.

 

[nelson c]

Sometimes I have this error. RadioCaster is located in another pc reading this file.
Another option may be the antivirus, but has marked RadioBOSS as exception

NowPlaying can not be updated: Cannot create file "M:\...\CurrentSong.txt". El proceso no tiene acceso al archivo porque est? siendo utilizado por otro proceso

 

[djsoft]

It could be that RadioCaster reads the file, and at the exact same moment RadioBOSS tries to write to it, and that produces the "File is being used by another process" message. We'll do something about it in the future updates - thank you for pointing out this issue.

 

[eddr]

Hello,

Having finally purchased RadioBOSS (Thanks Dmitry!) I have found a few issues and although we are not using the beta on our production machine, I think they are present in both the latest + latest beta (I have not tested on the machine where we have been using the trial version).

1) When turning off the visualization in the options (vu meter), whatever reading it is at gets stuck - the vu meter is not cleared down when it is turned off. Maybe it should even be dimmed to show it's not active?

2) If a network stream is added to the playlist, played and then immediately removed, the title does not get updated and gets stuck with a buffering title (See screenshot). You can reproduce this issue by using cURL for example:

curl "http://localhost:9000/?action=inserttrack&filename=http://127.0.0.1:8000/listen.pls?sid=1&pos=1"
curl "http://localhost:9000/?cmd=play 1"
curl "http://localhost:9000/?action=delete&pos=1

Also when using the "streamtitle=" option I see the same behaviour.

3) The sending of metadata to the shoutcast server only happens when a track is played. We have RadioBOSS setup to always send some static text as the song title but this does not happen until we play a track even though the setting is set to send updates 'periodically' (At the moment we are just using RadioBOSS to send Input 1 to the shoutcast server and not actually playing any tracks within RadioBOSS).

4) If the current track which is playing is deleted from the playlist and then RadioBOSS is restarted, it does not begin playing (It is set to 'Resume Playback' rather than 'Start Playlist'

Thanks!

 

[djsoft]

Thank you for letting us know about those issues. 1 and 2 should be fixed in the next update.

3 - RadioBOSS doesn't send the title every time, even if you have the "Periodical" setting if the title did not change (compared to when it was previously updated on the server). Maybe it's the case?

4 - Appears to be a bug, although I'm not sure how it should "Resume" if playing track was removed. Perhaps, it was made so intentionally, I'll check previous bug reports about this feature.

 

[eddr]

Great thanks!

Thank you for letting us know about those issues. 1 and 2 should be fixed in the next update.

3 - RadioBOSS doesn't send the title every time, even if you have the "Periodical" setting if the title did not change (compared to when it was previously updated on the server). Maybe it's the case?

4 - Appears to be a bug, although I'm not sure how it should "Resume" if playing track was removed. Perhaps, it was made so intentionally, I'll check previous bug reports about this feature.

3 - I see, so a track has to be played for the title to be updated. If you are overriding the metadata for track title (So you always want the track title to say the same text) but do not play a track and are simply using RadioBOSS to broadcast an input without playing any track, this means the title metadata will never be sent - this is how I spotted the issue. It can be easily reproduced by overriding the metadata and closing + opening RadioBOSS -> streams are connected -> no track title gets sent even though it is override in the metadata (radio boss is not playing a track at this time).

4 - I thought this may be by design (intentional) but wanted to check. I know the track no longer exists in the playlist, but then this means resuming + starting the playlist have the same effect in this case. For us, it would be useful to be able to decide the behavour.

Thanks in advance

 

[eddr]

Also, adding #999 for example does not seem to change the duration of a stream. I am using

curl "http://localhost:9000/?action=inserttrack&filename=http://127.0.0.1:8000/listen.pls?sid=1 #999 &pos=1"

But I have also tried:
"http://localhost:9000/?action=inserttrack&filename=http://127.0.0.1:8000/listen.pls?sid=1 #999&pos=1"

It just doesn't seem to work. Has the #N always been present? We are using 5.5.5.0

Thanks

 

[djsoft]

3 - I see, so a track has to be played for the title to be updated. If you are overriding the metadata for track title (So you always want the track title to say the same text) but do not play a track and are simply using RadioBOSS to broadcast an input without playing any track, this means the title metadata will never be sent

It doesn't require track to be played. It will sedt the title only once, when first connected to the server, and if the text is fixed, then it won't be sent again. It's possible that the server skips the initial title update, and RadioBOSS doesn't make further title updates due to repeat protection (it's already sent that title, no need to send it again).

4 - I thought this may be by design (intentional) but wanted to check. I know the track no longer exists in the playlist, but then this means resuming + starting the playlist have the same effect in this case. For us, it would be useful to be able to decide the behavour.

Yes, it is by design. I checked the bug tracker, and this feature used to work as "if a track can't be resumed, start playlist from the beginning" - we received multiple complaints about it. And now that's why if you delete playing track, or stop playback, "Resume playback" will not start playback.

Also, adding #999 for example does not seem to change the duration of a stream. I am using

curl "http://localhost:9000/?action=inserttrack&filename=http://127.0.0.1:8000/listen.pls?sid=1 #999 &pos=1"

But I have also tried:
"http://localhost:9000/?action=inserttrack&filename=http://127.0.0.1:8000/listen.pls?sid=1 #999&pos=1"

It just doesn't seem to work. Has the #N always been present? We are using 5.5.5.0

The problem here is that you have "?", "#" and space in your request string. You need to URL-encode those parameters, the request should look like this:

http://localhost:9000/?action=inserttrack&filename=http://127.0.0.1:8000/listen.pls%3Fsid=1%20%23999&pos=1

 

[eddr]

Excellent, thanks for this! Initially it didn't work as I was calling cURL from a batch file and to get literal % you have to use it twice, so if you are using cURL in a batch file it would be:

http://localhost:9000/?action=inserttrack&filename=http://127.0.0.1:8000/listen.pls%%3Fsid=1%%20%%23999&pos=1

Unfortunately, even with the duration now specified it is not having the desired effect - if I close down the SHOUTcast server (running on 127.0.0.1) RadioBOSS does not keep retrying to connect and moves on to the next track. The following error is displayed in the log:

Stream connection lost/unstable: reconnecting
Unable to play! Error code 41 (unsupported file format).

The same error happens (Unable to play! Error code 41 (unsupported file format).) if the SHOUTCast servers source is disconnected for a brief moment (which can happen sometimes) and this as well, causes RadioBOSS to go on to the next track which is not what we want!

With regards to point 3 (track title) - I don't think this is happening and I can easily reproduce it, here's how I can:
1) Stopped broadcasting in RadioBOSS and also stop playing any tracks. Ensured RadioBOSS will not start playing any tracks when it is re-started.
2) Restarted the SHOUTCast server to clear any metadata just in case
3) Opened RadioBOSS (No tracks playing). Started broadcasting - no track information is sent.
4) Waited a few minutes - still nothing (Periodic is set to 30 seconds).
5) Started playing a track in RadioBOSS - now the static text defined for metadata track title is sent.

Thanks for confirming the behaviour of point 4.

I have noticed that API commands next track and delete track don't get logged to the API output window but play does? Is it a bug that they are not logged?

Also a small feature request: There is no Date column for the output log - it's hard to keep track of what has happened when if scrolling through the log. Would it be possible to make it auto scroll as well?

Thanks

 

[djsoft]

The same error happens (Unable to play! Error code 41 (unsupported file format).) if the SHOUTCast servers source is disconnected for a brief moment (which can happen sometimes) and this as well, causes RadioBOSS to go on to the next track which is not what we want!

This is "by design". RadioBOSS tries to reconnect but if it sees an error again (internally it even does two attempts IIRC), it gives up and goes on to play the next track. This is to prevent long periods of silence on air.

With regards to point 3 (track title) - I don't think this is happening and I can easily reproduce it

Thanks for the details - if it's a bug, it'll be fixed in the next update.

I have noticed that API commands next track and delete track don't get logged to the API output window but play does? Is it a bug that they are not logged?

The next command is logged after it's executed, but delete is not logged. I'll see what can be done about it

Also a small feature request: There is no Date column for the output log - it's hard to keep track of what has happened when if scrolling through the log. Would it be possible to make it auto scroll as well?

The log will auto scroll automatically if you scroll it to the very bottom. When it's not at the bottom, it will keep the position (this allows to browse the log, because if auto scroll is always active, it will jump to the bottom on every new logged event). Date column will be added at some point in the future. Note that log keeps last 500 or so entries only, and this usually covers about 48 hours.

 

[eddr]

This is "by design". RadioBOSS tries to reconnect but if it sees an error again (internally it even does two attempts IIRC), it gives up and goes on to play the next track. This is to prevent long periods of silence on air.

I thought this was what the silence detector may have been for  It looks like this behaviour is not going to work for us, I don't want to pollute this thread so I'll open a new one to explain further why this is a major problem for us, maybe you have some ideas how to get around it.

Thanks for the details - if it's a bug, it'll be fixed in the next update.

Great!

The next command is logged after it's executed, but delete is not logged. I'll see what can be done about it

Great! You're right, next is logged sorry. The insertion of a track (inserttrack) is also not.

The log will auto scroll automatically if you scroll it to the very bottom. When it's not at the bottom, it will keep the position (this allows to browse the log, because if auto scroll is always active, it will jump to the bottom on every new logged event). Date column will be added at some point in the future. Note that log keeps last 500 or so entries only, and this usually covers about 48 hours.

The behaviour makes perfect sense - Thanks. Date column would be very useful.

 

[djsoft]

This is "by design". RadioBOSS tries to reconnect but if it sees an error again (internally it even does two attempts IIRC), it gives up and goes on to play the next track. This is to prevent long periods of silence on air.

I thought this was what the silence detector may have been for  It looks like this behaviour is not going to work for us, I don't want to pollute this thread so I'll open a new one to explain further why this is a major problem for us, maybe you have some ideas how to get around it.

If you have to make it retry and do not give up, you can enable the "Repeat track" option.

 

[eddr]

Thanks - replied on the new thread Sounds promising but hit another problem with it.

Is it possible to delete the current playing track through API without knowing its position in the playlist? I've tried with just 'delete' and no &pos= and I've also tried &pos=0 and &pos=-1 but these didn't work.

Thanks

 

[djsoft]

You can use the playbackinfo API command to find out the playing track pos

<Playback pos="263849" len="348483" state="play" playlistpos="51" />

 

[nelson c]

Hello Dmitry, There is a bug in the skin Dark of RadioBOSS.
When it is minimized and maximized program, you Log window returns to the position by default.

to when is expected be foresees the launch of the new beta of RB?

 

[djsoft]

Hello Dmitry, There is a bug in the skin Dark of RadioBOSS.
When it is minimized and maximized program, you Log window returns to the position by default.

Yes, it's a bug in the underlying style library - developers are notified, and it should be fixed at some point in the future.

to when is expected be foresees the launch of the new beta of RB?

It's curently under development. I think within a month, or more, it will be published.

 

[nelson c]

Great

I have a request for RadioCaster. Is possible in a future to select the source of audio for each encoder (DSP, or input of line without processing)
I need that the streaming that is sent to FM are not processed, but if for web page. I currently have two instances but a feature so it would be very nice

 

[djsoft]

If you want to broadcast different then you'll have to install multiple instances of RadioCaster. Doing all this in one instance will be cumbersome...