HTTP problem with the streaming servers

 
    • tburny a dit :...
    • Forum Moderator
    • 6 avr. 2012, 19h13m

    HTTP problem with the streaming servers

    Short version: Would it be possible to allow fetching the last 128 bytes of a stream file - independently of the number of open HTTP connections to a file - while the rest of the file is being streamed?

    Long version:
    As some of you might know, I am trying to create a flash-free, HTML 5 only last.fm player. It works in Firefox, but sadly not in Chrome and I think I figured out why.

    Description of the problem
    While prebuffering, Chrome tries to fetch the last 128 bytes of the MP3 file to get the IDv3 Version 1 Tag, so it can read its metadata. This behaviour cannot be suppressed, as far as I know.

    The requests are as follows
    1. Chrome makes a request to the stream Url from radio.getPlaylist
    2. While the HTTP connection of 1 is still open, it always requests the last 128 bytes. As it does this about a second after 1., I assume this step is done after pre-buffering the first second of the file.


    The last.fm streaming servers only seem allow one connection per file at a time, at least for the URL from radio.getPlaylist (e.g. URLs similar to http://play.last.fm/user/73241723423423478237823).
    As 1. and 2. are done in parellel, e.g. there are two connections, this causes both http connections to fail.
    It seems Chrome/Chromium is ignoring the preload="none" property of the audio tag. As far as I could find out the tag is only a recommendation to the browser, so they just ignore it.
    It seems last.fm is using the original urls as kind of one-time access token/access control filter, whereas the resolved stream url is valid for a while. (Can someone confirm that?)

    For the full HTTP headers (cookies censored, of course), see http://pastebin.com/rBAdL4X8. (Copied from Chromium element inspector).


    Expected behaviour
    Last.fm really should support HTML 5 audio on all browsers to get rid of the RAM sucking flash stuff.
    It is expected that the browser can always access the last 128 bytes of the file independently of the number of opened HTTP connections to the last.fm streaming servers. Obviously, noone can do any bad things with that.

    I think that this behaviour has been implemented to prevent stuff like broadcasting that file via stream url or that this is a relict from the older radio API's.

    Related Bugs on Chromium:
    http://code.google.com/p/chromium/issues/detail?id=102699
    http://code.google.com/p/chromium/issues/detail?id=94285

    However I think its quite useful for player widgets that last.fm supports reading the mp3 tag.

    Combo.fm: Combine your favourite radio stations! | My Blog | scala-lastfmapi | Cache2k - A high performance Java in-memory cache
    P.S.: Do not click here
    throw new PokemonException(); //Gotta catch 'em all
    My forum post reflects my personal opinion :)
    Modifié par tburny le 7 avr. 2012, 11h55m
    • snyde1 a dit :...
    • Abonné
    • 7 avr. 2012, 0h32m
    To me, this really sounds more like a Google bug than an issue for Last.fm. The browser shouldn't expect to be able to skip ahead in a stream feed. What happens in the case of a live feed?

    As the current scheme works in both Firefox and Opera, Chrome is showing itself to be out of step ...

    I agree with the comments on Flash and heartily support the HTML5 radio player.

    Improve your view of Last.fm - add some User Scripts.
    Did I hear that right? Mondegreens - for the misheard word. Like Odds? Can't get better than Even Odds!

    Speak your truth quietly and clearly; and listen to others, even to the dull and the ignorant; they too have their story.
    • tburny a dit :...
    • Forum Moderator
    • 7 avr. 2012, 1h05m
    I think Chrome's behaviour makes quite sense because Chrome is trying to make the metadata information available as fast as possible.
    Its a chrome bug, which seems to be fixed now.

    Combo.fm: Combine your favourite radio stations! | My Blog | scala-lastfmapi | Cache2k - A high performance Java in-memory cache
    P.S.: Do not click here
    throw new PokemonException(); //Gotta catch 'em all
    My forum post reflects my personal opinion :)
Les utilisateurs anonymes ne peuvent pas poster de messages. Merci de vous connecter ou de créer un compte pour pouvoir intervenir dans les forums.