Bug 77313

Summary:	some streams on live365 doesn't work
Product:	[Applications] amarok	Reporter:	Siu Chung (Clement) Cheung <clement.cc>
Component:	general	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Siu Chung (Clement) Cheung 2004-03-11 19:39:44 UTC

Version:           0.9, 0.9_beta2 (using KDE KDE 3.2.0)
Installed from:    Gentoo Packages
Compiler:          gcc 3.3.1 with glibc 2.3.2 
OS:          Linux

I tried some streams on streamtuner <http://www.nongnu.org/streamtuner/> the other day. (Sorry to not use the built-in radio tuner. They really have a lot more stations.) Quite many stations doesn't work. For example,  <http://www.live365.com/play/298863> will ask me to log in to live 365 first. Same behavior on many other radio stations. Stations like http://www.live365.com/stations/mcfnetwork1 consistently work. While stations like 298863 consistently fails. (I noticed that one is called pro broadcast while the other is premium broadcast on the live365 webpage. Could that be why?)

Curl reveals that it's an HTTP redirection with strange characters in the URL (I'm suspecting the &):
curl -D - http://www.live365.com/play/298863
HTTP/1.1 302 Found
Date: Thu, 11 Mar 2004 17:52:37 GMT
Server: Apache
Location: http://216.235.81.17:20020/play?membername=&session=cutenick:0
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="http://216.235.81.17:20020/play?membername=&amp;session=cutenick:0">here</A>.<P>
</BODY></HTML>

I'm not sure why they put &amp; inside the href. Anyway, if I follow the URL of the header and type it into mpg123, it works. If I type in the URL with &amp;, I sometimes get the ask you to login message. But for some reasons I'm not able to reproduce this after a while. It gives 404 file not found instead.

Same problem with: beep media player, kaboodle (by typing in the URL in "run")
Works with: xmms, embeded kparts player (by typing in the URL in konqueror)

The strange thing is that it works on some, but not all, players. The kparts player is most mysterious. Isn't it supposed to be kaboodle? It looks like kaboodle to me... I can verify my settings if you need. I'm just not sure which MIME type konqueror think that it is. And beep is supposed to be the same as xmms on the inside... This is so weird. Is it like newer = bad?

Bug appears in 0.9_beta2. Then I upgraded to 0.9 by a naive mv in gentoo portage. Same problem. Even worse: Now I get application/octec not recognized error on startup. I know I'm not supposed to mv it. Just to make sure it's not a fixed bug. I cannot confirm this. But I think I have seen it work on amarok before. I think I was using 0.8 at that time.

Comment 1 Siu Chung (Clement) Cheung 2004-08-06 18:46:45 UTC

Alright, I'm quite sure this has something to do with http redirects. It looks like xmms has an http redirect patch specific for live365 streams. There're 2 hurdles in listening to live365 streams that amarok need to overcome.

1. http 302 redirect
2. Invalid junk at the beginning of the stream. mpg123 gave warnings about lots of "junk at the beginning", "skipped RIFF header", etc. It looks like amarok 1.0.1 doesn't like those junk and just gave up after seeing them.

I just want to update the info with some new info. Here's what I get using the latest programs:

These are confirmed to occur on other stations too. Such as 44357. Oh and by the way, they're using mp3pro instead of normal mp3, in case that matters.

I'm using KDE 3.3 beta 2. Direct link means giving it the URL directly (requires the program to handle the http redirect). mp3 link means using curl to grab that URL. Then typing in the new URL that http redirect gives me.

amarok: 1.0.1
Direct link: Not work, can't even hear it telling me to login first. Gives error message:
amarok: WARNING: [ArtsEngine::connectTimeout()] Cannot initialize PlayObject! Skipping this track.
If GStreamer is used, gives this error message instead:
amarok: WARNING: TitleProxy error: Unable to connect to this stream server. Can't play the stream!
mp3 link: still not work, same error message. But amarok apparently plays other mp3 streams that I get from the amarok Internet radio list (works on both aRts and GStreamer). I guess it might be the second hurdle that I mentioned happening here.

beep media player: 0.9.7 cvs 20040708 snapshot
direct link: gives me the audio that ask me to login first.
mp3 link: works

xmms: gentoo ebuild 1.2.10-r5
direct link: works
mp3 link: works

mpg123: gentoo ebuild 0.59r-r2
direct link: gives me the audio that ask me to login first.
mp3 link: works

noatun: 2.4.1
Direct link: Gives me the audio that ask me to login first.
mp3 link: works and oh somehow they managed to skip the beginning of the stream. Live 365 channels has an ad audio that says "live 365" before they start giving you the actual stream. Perhaps they skipped a constant amount of the beginning of the stream to deal with the crap?

Kaboodle: 1.7
direct link: nothing, not even the please login thing.
mp3 link: works

After so many months I'm still stuck with xmms and its superugly fonts. :-( Is this going to be fixed?

Comment 2 Mark Kretschmann 2004-12-24 09:24:09 UTC

This is probably fixed in CVS. There was a bug in our http streaming client: It ignored the "query" part of the URL (that's the stuff behind the ?, e.g. the session ID). 

Please test!

Comment 3 Greg Meyer 2005-02-02 05:18:40 UTC

I'm closing as fixed since this was from .9 and Mark thinks it is fixed in CVS.  Please test in a newer version and reopen if it still exists.

Comment 4 Siu Chung (Clement) Cheung 2005-02-02 05:43:35 UTC

Yes, it is fixed, except that the problem persists if Xine is used as backend. Directly giving xine the URL on the command line verified that it's Xine's fault. Works beautifully in GStreamer.