I'm not sure if these are bugs or feature requests, if the latter these should probably go here.

I have developed an AJAX PHP File Index with multimedia support, and a new feature I wanted to add was generating m3u files from directory contents with the media files in them. These do return the required headers:

HTTP/1.1 200 OK
Date: Thu, 02 Dec 2010 15:15:17 GMT
Server: Apache/2.x.xx (Linux)
X-Powered-By: PHP/5.x.x
Content-Disposition: filename="generatedPlayList.m3u"
Content-Type: audio/x-mpegurl

These M3Us have URLs instead of file paths, and the file names instead of Track Names, and I've written functions to get length of the files in seconds.

#EXTINF:405,01 - My Track.mp3
http://www.site.com/mediaServer.php?download=9999

However for the first issue, none of this information comes across to AmaroK2. The second issue is, once played, the track name is populated but the length is not, and is thus not seekable.


I believe the behavior someone can reasonably expect is, the Track name is populated with the m3u information (instead of just 'Stream'). The real Track name (and audio length) should probably be determined from the stream itself once played.

The third and most annoying problem though is that Amarok2 will by default stop after playing one stream, rather than going through the playlist. Even if I 'queue' the remaining tracks, Amarok2 will simply stop rather than continuing. This could be related to problem #2, maybe by not knowing the length, AmaroK2 never 'finishes' playing the track and thus does not move on to the next one. Incidentally, clicking the next track button will make Amarok2 continue to the next track.

My homegrown web-based (Flash, working on an HTML5 one) media player has support for playlists, can get the track length and name from the stream, so I would reasonably expect just about any media player with streaming to support this eventually.

If a developer would like to look at this behavior I can send them a link to one of the generated playlists, so the behavior should be extremely easy to reproduce. Also, all of my code from the ground up is home grown, so if my implementation is bad I can do the necessary modifications to correct it.

Thanks!

I swear I opened this under Usability, why did this show up in 'Development'? Apologies, please move this.
Edit: It looks like this was moved here from Usability.

Okay, this is getting a little interesting. I found a small bug in my PHP which would not close the connection after reading the full file buffer:

(3442) Reading : 1048576 bytes, 0 already read out of 13022378
(3442) Reading : 1048576 bytes, 0 already read out of 13022378
(3442) Reading : 1048576 bytes, 0 already read out of 13022378
(3442) Reading : 1048576 bytes, 0 already read out of 13022378

Which is now Patched:

(3446) Reading : 1048576 bytes, 1048576 already read out of 17552231
(3446) Reading : 1048576 bytes, 2097152 already read out of 17552231
(3446) Reading : 1048576 bytes, 3145728 already read out of 17552231
(3446) Reading : 1048576 bytes, 4194304 already read out of 17552231
(3446) Reading : 1048576 bytes, 5242880 already read out of 17552231
(3446) Reading : 1048576 bytes, 6291456 already read out of 17552231
(3446) Reading : 1048576 bytes, 7340032 already read out of 17552231
(3446) Reading : 1048576 bytes, 8388608 already read out of 17552231
(3446) Reading : 1048576 bytes, 9437184 already read out of 17552231
(3446) Reading : 1048576 bytes, 10485760 already read out of 17552231
(3446) Reading : 1048576 bytes, 11534336 already read out of 17552231
(3446) Reading : 1048576 bytes, 12582912 already read out of 17552231
(3446) Reading : 1048576 bytes, 13631488 already read out of 17552231
(3446) Reading : 1048576 bytes, 14680064 already read out of 17552231
(3446) Reading : 1048576 bytes, 15728640 already read out of 17552231
(3446) Reading : 1048576 bytes, 16777216 already read out of 17552231
(3446) Reading : 775015 bytes, 17552231 already read out of 17552231
(3446) Finished.

At the 'Finished', the PHP would close the connection. However this isn't necessary usually, as the client will close the connection once the value from the Content-Length header is hit:

HTTP/1.1 200 OK
Date: Thu, 02 Dec 2010 16:35:06 GMT
Server: Apache/2.x.x (Linux)
X-Powered-By: PHP/5.x.x
Last-Modified: Thu, 18 Feb 2010 23:21:36 GMT
Content-Length: 17552231
Etag: "40660-10bd367-47fe83a69e000"
Expires: Sat, 01 Jan 2011 16:35:06 GMT
Content-Disposition: filename="07 - I Remember.mp3"
Accept-Ranges: bytes
Content-Type: audio/mp3

Regardless, with the patched server side behavior Amarok still has the same behavior. I do notice that Amarok is still showing the track as currently playing long after the connection has closed (bottom right status bar):

More testing...

I started thinking this could be more of a Phonon thing than an AmaroK2 issue. Looking at Amarok 1.4's behavior using the Xine engine (Xine was also used on Phonon):

In 1.4, the Title is making it through from the m3u data. I've set the seconds to 0 in the m3u across the board, as I did for AmaroK2. On play, the actual information populates, minus the seconds. Seek is impossible in AmaroK 1.4 as well.


However, 1.4 does 'know' when it has hit the end of a stream, and continues to play the next stream.