intermittently functioning AAC stream

[ManChicken]

I have a Favorite to a local station's stream which is being served by Liquid Compass (who has about a bazillion other radio station streams.) The URL in question is http://c1.mp3.liquidcompass.net/KNUSAMAAC - In the last several weeks, I can only get this to play about 10% of the time. I hit the favorite (or if I was listening to it previously, just hit power on the Squeezebox which is set to pause/resume on power) and I get nothing. The panel will say 'Connecting' for a second, then 'Playing' and then before it buffers anything it will immediately go into Stopped. No other indication of what might have happened.

If I hit Play 30 times in a row when it gets in this mode, it will still never connect. Yet I can hit the URL from the server (with wget) Squeezebox Server is running on and get data from it, so it's not like the stream is dead.

But if I let it sit for 10 minutes or so, come back and hit it, sometimes I get lucky and it will work.

I'm wondering if maybe this is a problem parsing metadata.. When it does play, I'll get something like "710 KNUS~DENNIS~~~T~~~9000~~" for the title. It might explain the random nature of it, if they are in commercial or something at the time I try to play it and the data is changing perhaps.

Anyways, Squeezebox Server 7.5.0 - r30464 running perl 5.8.8

[bpa]

The same stream does not play for me on a PC using mplayer. It looks like a stream problem and not a SBS one.

Does the stream play regularly OK for you on your PC using a player such as mplayer or vlc not a browser ?

[ManChicken]

It seems to be coming up reliably in iTunes, but I'll have to keep an eye on it for a couple of days to see for sure.

[bpa]

You need to check what format is being played in iTunes - some streams may vary the format used according to the requesting player which is why I suggested using something like vlc.

Can you get iTunes to show the stream format and audio codec being played.

[ManChicken]

Of course not, iTunes is a pile of cr@p! Windows Media Player either, although I'm guessing it's getting the AAC version as it shows up as '31kbps' (more on this below.)

Interestingly this morning before I left for work I flipped it on the Squeezebox, and after kicking it a few dozen times, it finally played. I scrolled over to More Info and it did say the stream type was AAC. 32kbps.

Just a few minutes ago, I was playing it and went and looked again and this time it said MP3.. 48kpbs.

So it seems that yes, perhaps they are doing some (broken) detection and feeding different streams depending on whose knocking.. and I'm just having a lousy time locking into their AAC stream when it gives that. Or they have multiple servers and some are broken, some aren't.. and it just depends on which one I happen to get directed to (I only get one IP for the hostname, but something else might be going on behind their scenes.)

I did dig around their website and found an alternate URL for an MP3 stream, which so far seems to work reliably.

[ManChicken]

New problem: Now the MP3 stream in the last couple of days is skipping every couple of seconds. Yet the exact same URL plays fine in iTunes, Windows Media Player, and even Songbird (http://den-a.plr.liquidcompass.net/pls/KNUSAMMP3.pls)

I installed SoftSqueeze for fun and it's barfing there as well; on the Squeezebox proper I just get skips, but on Softsqueeze I get little MPEG blarps.

[bpa]

Softsqueeze uses a totally different MP3 decoder so that would imply the problem may be something is causing a few bytes to be lost before reaching the decoder. I would suspect there is something funny in the "icy" data which is text data (usually track info but this channel uses it for ads) that is inserted into a stream to be displayed.

The text is very strange so I wonder if there are odd chars in it. Examples

710 KNUS~SMOKE ASSASIN~~~T~~~59000~~
710 KNUS~KNUS CONTEST RULES~~~T~~~61000~~
710 KNUS~BOYLE promo THRU 05-15~~~T~~~29000~~
710 KNUS~HANNITY LINER 5~~~T~~~8000~~

You should create a bug report if you this to be sorted.

[bpa]

The problem is the handling of the ICY headers. The radio station is using "Icy-Metaint" header instead of "icy-metaint" so SBS doesn't recognise the metadata interval of 8192 and uses 0 which means expect no data but the data is then played which results in garbling.

[10-05-19 12:00:19.4168] Slim::Player::Squeezebox2::directHeaders (526) Calling Slim::Player::Protocols::HTTP ::parseDirectHeaders
[10-05-19 12:00:19.4173] Slim::Player::Protocols::HTTP::parseDirectHeaders (340) header-ds: Session-ID: 204116
[10-05-19 12:00:19.4177] Slim::Player::Protocols::HTTP::parseDirectHeaders (340) header-ds: Content-Type: audio/mpeg
[10-05-19 12:00:19.4181] Slim::Player::Protocols::HTTP::parseDirectHeaders (340) header-ds: Icy-Metaint: 8192
[10-05-19 12:00:19.4186] Slim::Player::Protocols::HTTP::parseDirectHeaders (340) header-ds: Icy-Name: KNUSAM
[10-05-19 12:00:19.4189] Slim::Player::Protocols::HTTP::parseDirectHeaders (340) header-ds: Owner: LC
[10-05-19 12:00:19.4192] Slim::Player::Protocols::HTTP::parseDirectHeaders (340) header-ds: Icy-Br: 48
[10-05-19 12:00:19.4199] Slim::Player::Squeezebox2::directHeaders (545) Setting new title for http://edgev1.den.echo.liquidcompass.net/KNUSAMMP3, KNUSAM
[10-05-19 12:00:19.4205] Slim::Player::Squeezebox2::directHeaders (588) Got a stream type: mp3 bitrate: 48000 title: KNUSAM
[10-05-19 12:00:19.4209] Slim::Player::Squeezebox2::directHeaders (636) Beginning direct stream!
[10-05-19 12:00:19.4212] Slim::Player::Squeezebox2::sendContCommand (672) Sending cont frame: metaint 0, loop 0

I'm not sure whether SBS or the station is in error. All it takes is a small change to a line in ParseDirectHeaders routine in Player/Protocols/HTTP.pm to make the "icy-metaint" comparison case insensitive.

If you want it fixed you should open a bug report and link to this post.

[andyg]

On May 19, 2010, at 8:09 AM, bpa wrote:

>
> The problem is the handling of the ICY headers. The radio station is
> using "Icy-Metaint" header instead of "icy-metaint" so SBS doesn't
> recognise the metadata interval of 8192 and uses 0 which means expect
> no data but the data is then played which results in garbling.

Yikes, don't know why this was never being checked as case-insensitive, I've fixed it. Thanks for the heads up.

[ManChicken]

Thanks everyone for the sleuthing, I tweaked the source on this end and that seems to have done the trick!