Forum » Development Discussion

request for suggestions for next version of submissions protocol

  • request for suggestions for next version of submissions protocol

    We are starting to gather ideas for a new version of the submissions protocol (as described here). We have our own ideas for some changes but would also like to incorporate suggestions from others, especially those of you who have developed your own scrobblers in the past. Can you think of anything about the current protocol that you would like changed? Some new features we could add? Features that would make development easier? Criticisms of the current protocol? Now is the time to let us know.

    Ideally we would like this to be an evolutionary change by adding optional features and keeping the basic structure the same so that upgrading existing scrobblers to a new version isn't too painful.

    Also, we won't be removing older versions of the protocol anytime soon and will continue to support protocols 1.2.x and 1.1 for some time.


    • [Gelöschter Benutzer] schrieb...
    • Benutzer
    • 8. Jan. 2009, 15:03


    I think a great addition would be an even easier way to fetch the album art for queried albums. For projects such as the one I head, which include a "Coverflow" style album art browser, the overhead of receiving all the data as opposed to just the image links makes all the difference in rendering times.

    Something along the lines of album.getArtwork or album.getImages would be mighty helpful indeed!

    Another addition that might be more troublesome to implement then helpful would be full support for JSON responses...that would make it a million times easier to implement a lightweight online module for Web 2.0 style hook-ins to desktop players. Think the web interface to uTorrent, but for a media player instead, which included features. It means we can avoid the overhead of AJAX calls to a PHP/ASP script which processes the XML response; instead, we can directly serialise the output into a Javascript object, and work from there. I guarantee this would make a very popular choice for widget authors...

    Can't really ask for much more at present! Hard to think of ways to extend one of the best API's already! Keep up the fantastic work! =]

  • Hey unfinitydesign - thanks for the suggestions. Perhaps I wasn't clear enough, but I was talking about the submissions protocol - i.e. only what is documented on this page:

    Your suggestions are for the more general web services API, which hopefully will be read and taken into account anyway, but I'd like to keep this thread focused on submissions only. Thanks.

    • fhen schrieb...
    • Benutzer
    • 8. Jan. 2009, 16:00
    Apart from the implementation of ratings at submission, which is on your todo list anyway I think, I can't think of any improvements to be honest.

    In fact, to me the protocol seems quite mature the way it is right now.
    I hope that praise is welcome as well :)

    • eartle schrieb...
    • Alumni
    • 8. Jan. 2009, 16:47

    It might be nice for mobile scrobblers, such as Mobbler, to be able to optionally scrobble GPS location.

    The server responses could be XML to be nicer to parse and more consistent with the Web Services API.

    Secure authentication with public and secret keys like the Web services API.

    Not really to do with the protocol, but it would be nice for people that write scrobbling apps to be able to stats on the usage of their scrobbler.

    My only criticism would be that the rating field doesn't really do anything (Love doesn't Love. Ban doesn't Ban. What does Skip do?).

    Was the Client Team - @eartle
    See also:
    Mobbler: the radio player and scrobbler for Nokia/Symbian.
    Setlist Scrobbler: scrobble the setlists for your attended events.
    • der_Karl schrieb...
    • Benutzer
    • 8. Jan. 2009, 17:01
    What would be nice would be a way to also submit the player software used - just like the official client does. I tried to emulate this behaviour in our Pocket Scrobbler but obviously the server only accepts this information when it's coming from the Scrobbler. ;)

    Would be really cool to see one's profile page display "Listening now using Pocket Scrobbler + TCPMP". (Just as a side note: When using Pocket Scrobbler this is still being displayed as " Mobile" - this name has been discontinued some time ago now. ;) )

    The only valid measurement for code quality: WTFs per minute.
  • As eartle said, a location field would be nice to have. But maybe make it general purpose and also allow things like "Home", "Work", "Laptop" etc..

    I'm pretty happy with the protocol right now.

    Please do not put XML in the server response. I don't want to put a xml parser in my application just to read the server response.

    I noticed that for some submitters, the "Listening now using xxx" becomes a link to the application. It doesn't do that for mine. Do you need a web services account for that?

    A stats page for all scrobbler submitters would be nice.

  • Thanks guys, this is great, keep it coming!

    gogglesguy and der_Karl - the display of the name of the scrobbler app with the link to its homepage is a relatively new feature. If you would like this changed then send an e-mail to (if possible from the account which you used to request the client id) with your client-id, the existing name/homepage, and what you would like changed.

  • Some more ideas

    Not sure how usefull the following might be:

    1) a status code to determine whether or not a submission was accepted or treated as garbage. clients may remember this and actually not submit the track anymore after this.

    2) possibly in combination with 1, returns a valid musicbrainz id as status. That way if the client doesn't have that id, it can use it next time during submission.

    3) Possibly submit tracks by musicbrainz id only. In which case 2 would be handy.

    • [Gelöschter Benutzer] schrieb...
    • Benutzer
    • 8. Jan. 2009, 22:56
    I think it would be great if a scrobbler was allowed by servers to scrobble large amounts of historical data (when songs were played in the past).

    This would make scrobbling a portable music device (such as an iPod) much easier, as the scrobbler would not have to delay scrobbling until the device was connected.

    Basically, the feature I would like is for the server to accept scrobbles of tracks played any time (past or present) and to insert those tracks into the user's profile as if they had been scrobbled when first played.

    • JJC1138 schrieb...
    • Benutzer
    • 9. Jan. 2009, 0:26
    My suggestion would be to do away with the handshake altogether. It adds a substantial amount of complexity (particularly to recovering from errors) for no obvious benefit. Also, the standard authentication token doesn't provide real security so I would get rid of that and just use HTTP Basic authentication on every submission and allow (and recommend) submissions over HTTPS.

    Some might complain about the overhead of HTTPS, so perhaps the authentication token could be retained as an optional alternative for extremely resource-constrained clients (I know I said the authentication token doesn't provide real security, but it does provide a measure of deterrent in that it requires a certain amount of time and effort to break). Either way the handshake is still unnecessary; the token could be recalculated on each submission.

    Also on the topic of authentication, supporting a scheme like OAuth would be nice so that users don't have to trust clients with their password.

    So to summarize, I would suggest:
    - Deprecating handshaking and publishing the submission URL as part of the protocol
    - Allowing per-submission authentication by HTTP Basic or the Standard Authentication Token (or session ID for legacy support)
    - Allowing and recommending HTTPS submissions
    - Thinking about OAuth (perhaps for the future)

    That would substantially reduce the effort required to develop a new client, while still supporting existing ones.

    • f1n4rf1n schrieb...
    • Benutzer
    • 9. Jan. 2009, 13:04

    Re: Some more ideas

    gogglesguy sagte:

    1) a status code to determine whether or not a submission was accepted or treated as garbage.

    2) return a valid musicbrainz id as status.

    That's what I would appreciate very much as well.

    The location concept sounds nice, too. It could be even extended with something you might already have discussed: "moods".

    Similar to S///'s Walkman concept (screenshot:
    Although I guess that it needs much work on your side to define usable mood values, incorporate it into the fingerprinting, etc.

    • trzywil schrieb...
    • Benutzer
    • 10. Jan. 2009, 0:58
    One thing I always wanted was ability to scrobble past songs.

    My script sends data from iPod to It's sent in bulk every now and then, not in real time, but desktop player might have been sending stuff too, causing some iPod song submissions to become invalid. Many users were confused by that, and I cannot really do much.

    Another thing - doesn't seem to report some errors. If song was rejected by spam filter due to timestamps or other information, script will not be told about that, so user cannot be informed, and confusion ensues.

    • [Gelöschter Benutzer] schrieb...
    • Benutzer
    • 11. Jan. 2009, 11:30
    My comments on that:

    - Remove the handshake process, do everything in one call (can only agree to JJC1138)

    - Allow https submissions

    - Maybe introduce oAuth so that we don't have to store the password

    - Allow submission of information as clean XML raw request (instead of a1 - ann etc URL parameters). Some overhead but much cleaner IMHO.

    • fhen schrieb...
    • Benutzer
    • 11. Jan. 2009, 17:06
    Client stats as mentioned by eartle would definitely be interesting.

    Apart from that, I would heavily dislike the idea of moving to XML for communication.

  • I agree with JJC1138, removing the handshake process would make submissions easier.

    Otherwise I can't think of any obvious problem in the current protocol, but if I come up with some idea I'll let you know.

    • lempsink schrieb...
    • Benutzer
    • 12. Jan. 2009, 6:53
    The main problem I ran into during development was the lack of errors. It's quite confusing if the protocol returns 'OK' while the submission was wrong.

    oAuth support could be nice, but is (in my experience) also at least as complex as the current handshaking. (Just look at the flowchart (section 6) of and you'll see the similarities using with web service authentication and oAuth.) I find it funny that the people suggesting to remove the handshake are also asking for oAuth support :)

  • finally getting the time to think about it and reply:
    - please, stay away from XML
    - ratings (like, 1 to 5 stars or similar, would make mapping information from portable devices easier)
    - https would be nice
    - meaningful errors would be nice
    - perhaps allow to specify play count (ipods don't store all play times, right now my ipod scrobbling app looks at gaps in the stream of play times and guesses where repeated plays would go)

    I don't mind the handshake, also wouldn't mind something like oAuth instead of it (to avoid password storage) :)

    • der_Karl schrieb...
    • Benutzer
    • 13. Jan. 2009, 17:46
    One thing that just came to my mind whilst I was listening to a track that I have on a compilation as well as on an album: It would be cool if one could also submit the album artist as an optional parameter. This would allow the user to better keep track of the albums he/she listened to.

    The only valid measurement for code quality: WTFs per minute.
  • playlist generator

    For my desktop client I'd like to have something like generate a playlist based on this song existing only of songs that are in this user's library. Something like that genius feature other music players have ;-)

    • Russ schrieb...
    • Alumni
    • 24. Jan. 2009, 11:38
    Just a note that we already support oAuth-style authentication if you use our web services auth - see section 1.3 of the submissions docs. In the new version of the protocol, this will be the only allowed auth method. We are pushing hard to reduce the number of applications which require users to enter their passwords.

    • tburny schrieb...
    • Forum Moderator
    • 27. Jan. 2009, 16:39
    @russ: sounds cool, this will include an update to the client, won't it?

    I agree with the other users about the error responses. But I think it would be good if the responses were in xml, as this would give the whole thing a clear structure. maybe line-based responses could be switched on by an optional param, but as the whole rest of the API is xml-based, and authentication too, you will need an xml parser to do the handshake and therefore the scrobbler responses should be in xml, too.
    It would be really cool if it was possible to submit love/ban ratings via the protocol OR web services, so you can rate the track via a scrobble OR a ws request and don't have to do both as specified in the protocol. 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 :)
    • Lisa1001 schrieb...
    • Benutzer
    • 12. Mär. 2009, 5:15


    Ideally we would like this to be an evolutionary change by adding optional features and keeping the basic structure the same so that upgrading existing scrobblers to a new version isn't too painful.

  • Map

    This may be a bit much, but I feel like the way the site is develloped is really great and that the search information could become a graphic interface.

    In my head it would look like a giant google map where you can start from all the various Tags of musical styles. The most common ones or more popular ones would be in bigger typo and then when you would zoom in you could read smaller groups.
    At a closer level you would start seeing images of the musical groups. The ones that are more similar would be closer to each other. and you could span towards the "musical direction" you would be most interested in (because you might already recognise some groups around.

    For example: I lik fiona apple, in the options it gives me I could span towards bat for lashes and away from alanis morriset. This would also be good when you search a lot with a style and feel like you're running in circles, a visual map would eliminate repition and let you heads further away than the top four.

    In general I think the data collected here is very important and could help to create better models of musical history. That and I'm a very visual person, this would be a pretty big task, but I really think it would be worth the effort.

    • [Gelöschter Benutzer] schrieb...
    • Benutzer
    • 31. Mär. 2009, 12:17
    i'd like mainly to see an updated look and feel. i expected this to come at the time of the new layout and then with boffin. i'm sure it's coming!

    as far as new features, though, i'd like to see more info within the application itself, like tour info. also, i've always found the fact that the "read more..." link takes you to a webpage rather than just showing the rest of the info within the app itself to be kind of annoying. also, the native client and boffin should probably become one.

Anonyme Benutzer dürfen keine Beiträge schreiben. Bitte log dich ein oder registriere dich, um Beiträge in den Foren schreiben zu können.