Fórum » Development Discussion

Automated track submission for portable players

 
  • Automated track submission for portable players

    Hello,
    First of all - sorry if this is a re-post, but I couldn't find the answers I am looking for...

    I have a Creative MuVo portable mp3 player and I am thinking of writing an application to submit the tracks I have on the player.
    There are a few things, however, that I'd like to inderstand:

    How many tracks am I allowed to submit at a time? I mean - I know the protocol v1.1 can submit 10 tracks in a signle request, but can I repeat several such requests right one after another?

    Should I make up my own 'time' for when the track was supposed to be played? The MuVo player keeps no log about that. If I can do that - let's say a timestamp a few hours before submission occurs - is there a maximum 'age'? Are tracks that are supposed to be played not soon enough dropped?

    After a successful handshake - how many subsequent requests can I make, before a new handshake is required?

    Since the application would be generally intended for my personal use, should I get a client id or I can use the 'tst' one?

    At first I thought I'd better add some code to amaroK to do that for me, but now I think it'll be better to write the client myself...

    Blade hails you...
    • Damaged disse...
    • Usuário
    • Jun 19 2006, 3h53

    Re: Automated track submission for portable players

    Quoth bladealslayer:
    Hello,
    First of all - sorry if this is a re-post, but I couldn't find the answers I am looking for...

    I have a Creative MuVo portable mp3 player and I am thinking of writing an application to submit the tracks I have on the player.
    There are a few things, however, that I'd like to inderstand:

    How many tracks am I allowed to submit at a time? I mean - I know the protocol v1.1 can submit 10 tracks in a signle request, but can I repeat several such requests right one after another?


    Yes


    Should I make up my own 'time' for when the track was supposed to be played?


    Technically, you shouldn't submit the song at all then, but iSproggler does something similar to support the iShuffle (which has no timestamps either). What you should do is follow its method:

    1. Get all tracks and add their durations to give you the total play time of all tracks.
    2. Sort them how you'd like (by name would be the most common)
    3. Get the current time from the OS and subtract the total duration to get your submission epoch.
    4. Submit the first track with the epoch, then add it's duration to the epoch. Submit the 2nd track with the updated epoch, then add it's duration to the epoch, repeat for every track.


    The MuVo player keeps no log about that. If I can do that - let's say a timestamp a few hours before submission occurs - is there a maximum 'age'? Are tracks that are supposed to be played not soon enough dropped?


    Following the above scenario will allow you to make it through the server SPAM filters. There is no maximum age of a sub, except it can't be before your last submitted track or your sign up time (which ever is greater).


    After a successful handshake - how many subsequent requests can I make, before a new handshake is required?


    As many as you can until (or if) you get a FAILED reply. This is noted in the protocol.


    Since the application would be generally intended for my personal use, should I get a client id or I can use the 'tst' one?


    tst

  • Thanks!

    Blade hails you...
    • gerph disse...
    • Usuário
    • Jun 19 2006, 18h32

    Re: Re: Automated track submission for portable players

    Quoth Damaged:
    Quoth bladealslayer:
    After a successful handshake - how many subsequent requests can I make, before a new handshake is required?


    As many as you can until (or if) you get a FAILED reply. This is noted in the protocol.



    I'm pretty sure it doesn't say that. As I recall you should retry the request when you get a FAIL. Due to server/gateway problems the transaction may not have completed successfully and you may have got the 'not all variables set' response and you should not go back to handshake for that. You should retry 3 times and if that fails back off 30 minutes. See the http://www.audioscrobbler.net/wiki/Protocol1 document for details. In my re-write of the protocol, I believe I stated the same sort of thing; http://usenet.gerph.org/AudioScrobbler/ASProtocol.txt.

    This said, I believe the current recommended behaviour is to use an exponential backoff on the handshakes with a limit at 30 minutes, rather than just jumping immediately to 30 minutes.

    • Damaged disse...
    • Usuário
    • Jun 20 2006, 4h57
    The recommended behavior is to use an exponential back off with a limit of 2hrs. It's been that for over a year. As for FAILED, I suppose you can not re-handshake, but in my experience a FAILED will usually require a re-handshake on the next sub attempt anyway because the session cache was restarted, so I just re-handshake on every FAILED response. However if a transport error is returned (can't connect, timed out, etc), then I don't re-handshake.

    • gerph disse...
    • Usuário
    • Jun 20 2006, 12h08

    Re:

    (removed dupe post)

    Editado por gerph em Jun 20 2006, 12h10
    • gerph disse...
    • Usuário
    • Jun 20 2006, 12h10

    Re:

    Quoth Damaged:
    The recommended behavior is to use an exponential back off with a limit of 2hrs. It's been that for over a year. As for FAILED, I suppose you can not re-handshake, but in my experience a FAILED will usually require a re-handshake on the next sub attempt anyway because the session cache was restarted, so I just re-handshake on every FAILED response. However if a transport error is returned (can't connect, timed out, etc), then I don't re-handshake.


    If it's 2 hours then that's a significant change and probably ought to be in the Wiki. As for retrying on all FAILED; I personally feel that that's excessive. In my experience a FAILED is usually due to the server thinking that plugin variables have not been set, or a 'too busy' type response and can be retried without a re-handshake.

    • Damaged disse...
    • Usuário
    • Jun 20 2006, 23h59

    Re: Re:

    Quoth gerph:
    If it's 2 hours then that's a significant change and probably ought to be in the Wiki. As for retrying on all FAILED; I personally feel that that's excessive. In my experience a FAILED is usually due to the server thinking that plugin variables have not been set, or a 'too busy' type response and can be retried without a re-handshake.


    RE :2hrs - It was in the protocol spec for the 1.2 protocol, but I don't think that's available anymore. Russ has been and still is recommending the exponential back off up to 2hrs for all clients, but it is technically not part of the 1.1 protocol.

    As for FAILED behavior, I really don't think it matters either way as FAILED responses are fairly rare (even the spurious Plugin Bug response). So re-handshaking on a FAILED is not going to cause any undue stress on the server.

  • Re: Re: Automated track submission for portable players

    Quoth Damaged:
    Technically, you shouldn't submit the song at all then, but iSproggler does something similar to support the iShuffle (which has no timestamps either). What you should do is follow its method:

    1. Get all tracks and add their durations to give you the total play time of all tracks.
    2. Sort them how you'd like (by name would be the most common)
    3. Get the current time from the OS and subtract the total duration to get your submission epoch.
    4. Submit the first track with the epoch, then add it's duration to the epoch. Submit the 2nd track with the updated epoch, then add it's duration to the epoch, repeat for every track.


    I see this is kind of workaround. Whats the last.fm team's opinion on this? I mean, if it is not officially allowed in the protocol specs...

    Blade hails you...
Usuários anônimos não podem postar mensagens. É preciso fazer login ou criar uma conta para postar nos fóruns.