I've got Centova Cast 3.2.0 running on a Debian 7 x64 Server with a ShoutCast DNAS v2.4.7.256 and a Liquidsoap AutoDJ.

I am facing a problem with the title updates.
The server doesn't allow some of the titles that the Liquidsoap or any other source sends to it.
This is what the error log shows when this happens:

INFO   [ADMINCGI sid=1] XML title update [<?xml version="1.0" encoding="UTF-8" ?><metadata><TIT2>&amp;I - Into the Green</TIT2></metadata>]
WARN [ADMINCGI sid=1] Title update rejected - value not allowed

Here some infos from the source log: http://pastebin.com/8MUUsyd8

Is this a bug or do I have to configure something to get it working correctly?

titles beginning with an & (and a lot of other punctuation) are rejected by the DNAS. so that's why you're seeing what you are.

Is there any (logical) reason why an '&' character at the beginning will be rejected but if you have something like 'xyz & abc' it ist not?
We have a few artists in our playlists that have names that start with such characters and when songs of them play no one sees the title of the song.
This titles won't be logged for our song history which is a big problem for us because we need a list with all this titles for licensing with GEMA & GVL.

its intentionally blocked to prevent listeners and the listing details being populated with bad data. as all of the cases of such titles beginning with punctuation that were seen from the information the DNAS provides to the SHOUTcast platform were not of any use, especially as it's generally expected to see an 'artist - title' style of title and not a lot of the abused title updates that have been seen in the system which all begin with random punctuation characters.

so apologies if it's affecting a few legitimate cases (which will need to be re-worded if needed) but the data that was looked at indicated it was worth doing it vs the small possible side-effects for legitimate cases.

Even though it is to protect the listeners and listing details from bad data it would really help to have some kind of whitelist to allow certain characters so that people who really need and rely on them could still use them.
I really appreciate it that there is a protection from bad data but I think it would be a really good addition to have the possibility of a whitelist even if there are not that much cases in which this would be needed.

a user-configurable white-list (as I think you're asking for) will not be provided as it defeats the point of filtering out things (as anyone could then just add back in things that aren't wanted).

I don't really see why it would be a problem if people could exclude certain characters and symbols from the filter. Why would this defeat the point of filtering if there is the possibility to exclude things from the filter?
If it would defeat the point of a filter if you could configure it to exclude some things then (as an example) a firewall that has the ability to be configured to have some of the filtered ports open would defeat its own purpose...

You say that "... anyone could then just add back things that aren't wanted." but think about that:
Who is the one who says what is "wanted" and what not? If someone who is running a webradio WANTS to have these characters then why would they not be "wanted"? Because the developer of the software says that these people are wrong because he says so?

There are so many applications that have a filter and still have the ability to configure the filter without destroying its purpose.

i get your point but it doesn't go with what SHOUTcast wants and a custom filter of any sort would defeat that point. as what's the point of filtering out things to then give someone the option to re-enable what isn't wanted ? under such a suggestion, it'd just be easier to not have the filter in there at all (which is not what is going to be done).

we don't want crappy titles and if that means blocking some legitimate ones vs all of the other bad ones that otherwise appear, then that was deemed acceptable (especially as in this case, & at the front of a title only ever showed up in the test data as being due to poorly done scripts / source handling).

as such, the benefit and handling for how we want the platform to be far out-weighs the possible side-effects to a few (as you unfortunately fall under with that stile of title update). if we didn't see so much bad data (especially so from 1.x based setups) then we wouldn't need to have to do such things but that reality is that far too many people couldn't care less about having decent titles (and other associated metadata) and due to that, something had to be done and that's what has been going on for a while with the 2.x DNAS and it's gradual refinement of it's title filtering.

The point of having a filter that is activated and fully working on standard installation and having a custom filter is that those people to whom you refer as people who don't care about the titles are "protected" from their own laziness and that people who care about the title can still work with it.
Instead of having a brick wall that blocks everything that is not pre-sanitized enough.

I understand that you (as the developer) want to protect the people of crappy titles but let's be honest and realistic how many people who run a ShoutCast server and don't sanitize their ID3 tags are gonna be all like "Hmm lets just write all characters we can make with a keyboard in our whitelist, yolo!" and then would later go on with "Why are our titles showing all this crap?"
I doubt that there would be more than 10 people world wide who fall into this category of people.
If someone doesn't care about the metadata of their songs then this person surely won't even lift a finger to fiddle with some settings to format/filter their metadata.

Do you really think that people would just turn everything off just because it is possible?

If you want to protect the people from bad things then why don't you just turn off the ability of ShoutCast to stream on low bitrate? Crappy stream quality is bad for the people right?
NO! Because there are people who need certain features even if there could be theoretically people who might misuse them and get poor results. If you want to protect stupid people from doing stupid or risky things you put a warning label on it and give them an explanation on what they are about to do.

We fixed our issues with ShoutCast by switching to IceCast.
Our Tags are now showing up as intended.

Thank you for responding to our problem even though you couldn't really help us fixing it.

not that it'll likely matter now but we've made some adjustments to the title filter list which would allow your '&' title to work again when the next 2.x DNAS is released.