1 account is having a weird issue.  They do not use Centova Auto DJ, its by remote source only.  If you click play on the player, you can hear the music.  However, status shows that the station is offline, and doesn't show currently playing, and speaker icon shows a red x saying there's no audio, but yet, there is audio.

Have stopped and restarted the stream, which didn't work, and there's nothing in the logs showing any problems.  Had just recently updated this server with the most recent version of Centova

Centova cast 3.2.0
SHOUTcast V2.4.7.256

This usually means that the live broadcast is not sending any title updates, and without that Centova Cast is assuming that the station is offline.

If your client doesn't want to send constant title updates (or perhaps he isn't even broadcasting music) he could just enter a sentence or a character in his encoder and that would fix the problem.

I think we actually got this issue figure out.  It had to actually do with the Administrator password having a Symbol in it.   Once we removed the symbol, clicked update, stopped / restarted the stream, everything was back to normal.


Also I have noticed that, users can't change their passwords.   They put in the new password, click update, stop / restart the stream, it reverts back to the previous password, however, admins are able to change passwords with no problems.

I think we actually got this issue figure out.  It had to actually do with the Administrator password having a Symbol in it.   Once we removed the symbol, clicked update, stopped / restarted the stream, everything was back to normal.

This use to be a Shoutcast 1 only issue, and it's suppose to be fixed on Shoutcast 2, so is either a regression on Shoutcast 2 or the problem is with the source.

Would you mind sharing which special character was causing the problem ,and also which source software (and version) are you using?

Also I have noticed that, users can't change their passwords.   They put in the new password, click update, stop / restart the stream, it reverts back to the previous password, however, admins are able to change passwords with no problems.

I'm unable to reproduce this issue, however we have recently pushed a couple of hot fix builds, please run the update utility script (/usr/local/centovacast/sbin/update), and if that doesn't solve the problem, please open a ticket to our support department so that we can test the issue in place and fix it.


HTH

This use to be a Shoutcast 1 only issue, and it's suppose to be fixed on Shoutcast 2, so is either a regression on Shoutcast 2 or the problem is with the source.

Would you mind sharing which special character was causing the problem ,and also which source software (and version) are you using?

$ symbol and # symbol

SHOUTcast v2.4.7.256
Centova Cast 3.2.0

the symbol in password issue will be looked into (which I've just quickly tried and can replicate some failures). it's most likely a side-effect of all of the re-working of the password handling (admin and source) that had to be done with the 2.4.7 DNAS release to resolve a number of other issues whilst also allowing for the multiple-1.x source support to work.

the symbol in password issue will be looked into (which I've just quickly tried and can replicate some failures). it's most likely a side-effect of all of the re-working of the password handling (admin and source) that had to be done with the 2.4.7 DNAS release to resolve a number of other issues whilst also allowing for the multiple-1.x source support to work.

That would be a great fix, as we have many clients that use symbols in their passwords  (administrator and source), Which in turn is affecting some things in the Centova Cast panel and seems to also be affecting being listed in YP.  (It what it seems like anyways, but the YP thing could be something completely different)

the # symbol issue has been fixed for the next release (that was a side-effect of the multi-1.x source support), but i'm not seeing an issue when using the $ symbol, so if you have $ and # in at the same time, it would have been due to the # symbol.

One password had a #  a different client had a &, and another client had a !,
After removing them and replacing with something else, the accounts cleared up.
The account that had a ! was after I had posted.  so it was 3 different passwords, with the symbols.

(I'm just stating the symbols that were changed, and the after affects of changing them).