Audioscrobbler with mp3 streams and title support?

  1. Eto

    Shouldn't Audioscrobbler be able to support live mp3 streams that are played in iTunes?

    Streams that provide title updates for each track played could (should?) we inserted into the last.fm database (methinks)

    Any chance we can get this supported?

    • **************************************************

    Notification received 2007-01-03 11:18:01 +0100:

       Name: com.apple.iTunes.playerInfo
   Info: {
   Genre = Various; 
   Location = "http://broadcast.infomaniak.ch/rsr-couleur3-high.mp3"; 
   Name = "Couleur 3"; 
   "Player State" = Playing; 
   "Store URL" = "itms://itunes.com/link?n=Couleur%203"; 
   "Stream Title" = "The Raconteurs - Together"; 
   "Stream URL" = "http://www.couleur3.ch";

    }

    • **************************************************

    Notification received 2007-01-03 11:21:42 +0100:

       Name: com.apple.iTunes.playerInfo
   Info: {
   Genre = Various; 
   Location = "http://broadcast.infomaniak.ch/rsr-couleur3-high.mp3"; 
   Name = "Couleur 3"; 
   "Player State" = Playing; 
   "Store URL" = "itms://itunes.com/link?n=Couleur%203"; 
   "Stream Title" = "2 bit pie - Here I come"; 
   "Stream URL" = "http://www.couleur3.ch";

    }

  2. Greg Hurrell

    Originally Posted By: EtoShouldn't Audioscrobbler be able to support live mp3 streams that are played in iTunes?

    As of right now, the answer is technically no (but that may change in the future; see below).

    The Audioscrobbler support in Synergy was written in compliance with version 1.1 of the Audioscrobbler protocol:

    Quote:If a user is playing a stream instead of a regular file, do not submit that stream/song.

    http://www.audioscrobbler.net/wiki/Protocol1.0_1.1

    However, version 1.2 of the protocol is up on the Audioscrobbler site. Here is a draft:

    http://www.audioscrobbler.net/development/protocol/protocol1.2.php

    And here is what looks like the final version:

    http://www.audioscrobbler.net/development/protocol/

    I've seen no official announcement that plug-ins may start using the new protocol yet, but I haven't looked yet and I only stumbled across these 1.2-related pages when preparing this response to your post.

    The new version of the protocol does not say anything about not submitting streams. The 1.2 draft explicitly mentions a new "source" parameter for which one possible value is "broadcast", but the (apparently) final version of the draft has a lot of this new stuff removed; there is no mention of the "source" parameter and in fact the list of changes from version 1.1 of the protocol is very small.

    So basically, until this is clarified, I think Synergy will have to continue using the same submission policies as before. If the Audioscrobbler folks can clarify the 1.2 protocol then I'll consider switching to it, but as it currently stands there are no advantages to switching protocols for me as a developer or for my users because the changes are just implementation details:

    The handshake now requires some authentication details.Handshake response BADUSER replaced with BADAUTHThe UPDATE response does not provide a URL.Song submission dates are now sent in unixtimestamp format, not YYYY-MM-DD HH:MM:SS.The INTERVAL response does not exist any more.

  3. Eto

    Thanks for the quick reply and the clarification.

Reply

This topic is now closed.

topic index