1 (edited by davidconrad10 2008-03-08 10:24:03)

Topic: Minor confusions with net radio display

Not sure how the display of Shoutcast stations is formatted, so not sure what can be done. But some stations give their names on the Shoutcast web site like this example: "New York City\'s non-commercial ..." using a backslash in front of the apostrophe. (Presumably that has something to do with escaping the apostrophe for JavaScript or some similar purpose.) But in any event, when such a station shows up on the Chumby, it appears like this:
New York City[ampersand pound-sign 92 semicolon]'s non-commercial ..." etc.

To an HTML programmer, that's no big deal. But for non-techhie Chumby users, that might be off-putting or even intimidating; perhaps there might be some way to filter such obscure symbols out?

Re: Minor confusions with net radio display

Well, the problem here is that SHOUTcast is double-escaping certain entities in their XML, and the chumby is doing the "right thing" according to the XML specification.

We're working on a server-side change to clean up the XML coming from them.

We also see this a lot where people stick HTML entities in RSS feeds - many of our widgets do feed-specific cleanup.

Re: Minor confusions with net radio display

It's irritating when you have to depart from standards because somebody else has departed from standards.

Thanks for considering doing it anyway. :-)

Re: Minor confusions with net radio display

The most annoying thing we run into is people sticking ISO-8859 encoded text in XML without setting the encoding in the XML header node, since by default the encoding of XML is UTF-8. I've even seen XML with both UTF-8 and ISO-8859 encodings in the same document - they've simply appended text fragments.

It was hoped that XML wouldn't suffer the same fate as HTML with tons of crappy out-of-spec documents, but I guess one shouldn't underestimate the ability of folks to screw up even the simplest things.

We sometimes run into folks that have even manage to screw up the HTTP protocol - one major tech site (which shall remain nameless) separates their HTTP headers with \n alone, when the RFC is *very clear* that it should be \r\n.  What's even more bizarre is that the server is Apache - somebody had to go *out of their way* to mess it up.