Feature Request: Update of Last.FM plugin protocol to version 1.2

[Alexander De Sousa]

The purpose of the request is to update the protocol used in the Last.FM audioscrobbler plugin to version 1.2 to add some functionality as the "Now playing" notification, the new authentication scheme or the updated "no skipping" rule.

More info about it can be found here: http://www.audioscrobbler.net/development/protocol/

[Adam Olsen (arolsen)]

Alright, I've committed the code needed for this. I'm sure it's not perfect yet, so try it out and let me know how it works.

[kindofabuzz (kindofabuzz)]

the new last.fm plugin won't even install in my 2.14. on startup it aked if i would like to upgrade the plugin. went to plugins, checked it, hit install, and it never loads but dissapears from list. so i shut it down and restarted, it's in the list again, check it, hit install, still does not load. how can i get the old one back now?!?

[Adam Olsen (arolsen)]

Yeah, you'll need to be running the latest bzr of Exaile for it to work.

[kindofabuzz (kindofabuzz)]

so no way to get the old plugin back?

[Adam Olsen (arolsen)]

http://synic.ath.cx/lastfmproxy.exz

[Alexander De Sousa (aphanic)]

I'm testing it right now, I've compiled and installed the 1630 revision of the main dev branch.

Did you code the skipping possibility? If you did it is faulty. I've tried this 3 cases, none of them were submitted:

1. Total track time: 220 seconds.
    Time skipped: 6 seconds.
2. Total track time: 205 seconds.
    Time skipped: 3 seconds.
3. Total track time: 257 seconds.
    Time skipped: 7 seconds.

The new skipping rule: as long as 50% of the song is played or 240 seconds are played the track can be submitted. Also the submission must be independent of the way the track stops, the user can stop the track manually (or by changing track i.e.: clicking next song button) and if any of the conditions are met track should be submitted. This is quite easy to code (I think), just a boolean would do the job. Checked when a track change happens; submitting in case it's true.

The "now playing" notification works flawlessly, but I still don't know any way to test the "non visible" changes rather than looking at the code, and right now I can't code in Python... So I'll assume they work (for example the new authentication scheme).

(While generating the locales I found a "proximity" mistake in the createpot.py script. In line 17 it says "our but tracker..." should by "our bug tracker...".)

[Alexander De Sousa (aphanic)]

:( I'm sad to say this, but the submission system is not working properly...

The music I'm listening to right now appears in Last.fm as listened 2 hours ago. The "Now playing" statement works perfectly, but at the time the songs are submitted the time says they were listened 2 hours ago.

I've been up all night working and listening to music with Exaile, but with no connectivity at all. This morning when I got access to the Internet hoping that everything would be submitted I found that only a few were (about 10 or so). Then I kept listening to music with full connectivity. Maybe this is a trigger for the timing problem...

Or maybe not, I'm in Spain and summer-time is active... This is UTC+2 I think (usually UTC+1 in winter-time). Does the submission system use UTC time instead of local one?

Closing Exaile, waiting a bit and reopening it doesn't solve the problem. Even restarting the system doesn't solve anything... what makes me believe that it's a bug in the submission system.

Also the cache should be reimplemented as it should deal with long periods (hours) of no connectivity or server problems.

[Adam Olsen (arolsen)]

Ok, I think I've fixed a few of the problems. Submission should work even if you skip around in the track. Submission times should be correct.

As for the submission cache, I'm not sure why it's not working correctly. It seems as though that part should be working fine.

[kindofabuzz (kindofabuzz)]

i did a bzr update today and updated the plugin also. nwo when i use
streamripper, the status says starting rip, but ten no sound at all. the
stream is still playing but no sound.

On Fri, May 23, 2008 at 4:39 PM, Adam Olsen <email address hidden> wrote:

> Ok, I think I've fixed a few of the problems. Submission should work
> even if you skip around in the track. Submission times should be
> correct.
>
> As for the submission cache, I'm not sure why it's not working
> correctly. It seems as though that part should be working fine.
>
> --
> Feature Request: Update of Last.FM plugin protocol to version 1.2
> https://bugs.launchpad.net/bugs/232483
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Alexander De Sousa (aphanic)]

Ok, I'm testing it all this days: everything that worked before keeps on working, the submission time is right now (so yes, the UTC was the problem) and the skipping thing works too (I still have some odd cases to prove but I think it will work).

In few hours I'll test 6 hours of no connectivity to test the cache system, in case poor connectivity or something wrong happened the other day. And tomorrow I'll test it again an again. I'll try to reproduce what may have caused the cache error the other night. I'll report whatever happens.

It's a pity that I don't have the log of that day.

[Alexander De Sousa (aphanic)]

Finally, most testing is done, everything worked but there is a case when the cache fails... (at least in my opinion): If your Internet connection is up when starting Exaile (and so you can log into Last.fm) the cache system does work if you lose connectivity (4 hours connection down was the test). But if you start Exaile with no connectivity at all the cache system will not retain any track... (tested with 5 hours of no-connectivity)

I haven't realized before but right now I'm pretty sure that this can't be done because of the handshake (as in order to submit a (valid?) session ID is needed), though maybe there is something to make it work (preserving the last session ID maybe? When submitting the response could be a BADSESSION line and so forcing the system to perform a new handshake (getting a new session ID), preserving the tracks in the queue).

I've looked through the code but I couldn't find the "hard failure" handling code, is it implemented? It's related to the process itself. According to the 1.2 version of the protocol 3 hard failures should take the client to the handshake stage, doubling the time between handshaking if hard failures take place in this stage. This is somewhat related to the submission of the queue...

Whoa, what seemed an easy thing (updating the protocol used) appears to be complex (or at least needs time).