Toggling scrobbling only takes an effect on the next playlist item

[GoogleCodeExporter]

Here's a subtle bug: When toggling scrobbling, I expect that it won't scrobble 
the currently-playing track. But when I stop and restart the track, it's a new 
"play session" and should be scrobbled - but Cantata doesn't. It only scrobbles 
when the playlist moves on to the next track.

Original issue reported on code.google.com by newbies...@gmail.com on 24 Jul 2014 at 3:57

[GoogleCodeExporter]

This should be fixed in branches/1.4 now. Could you check out, and confirm?

svn checkout http://cantata.googlecode.com/svn/branches/1.4

Original comment by craig.p....@gmail.com on 24 Jul 2014 at 7:22

• Changed state: Started

[GoogleCodeExporter]

I tested the trunk branch rather than 1.4 because you seem to have merged the 
change to both and I was already on trunk. Works now!

Original comment by newbies...@gmail.com on 27 Jul 2014 at 8:26

[GoogleCodeExporter]

However, the *other* bug - it's scrobbling the same countless times while it's 
playing - still persists :)

Original comment by newbies...@gmail.com on 27 Jul 2014 at 8:32

[GoogleCodeExporter]

You state 'the other bug... still exists'  but this is the first time you have 
mentioned it!

Anyway, I don't see this. I need more info.

1. Is this a scrobble, or now-playing?
2. How long is the song?
3. How often does it scrobble? Every minute? 
4. What is in your play queue? 1 track?

Original comment by craig.p....@gmail.com on 28 Jul 2014 at 11:15

[GoogleCodeExporter]

> 1. Is this a scrobble, or now-playing?

I don't understand the difference - I mean what shows up as "Recently Listened 
Tracks" on my last.fm profile page, as "Scrobbled from Cantata".

> 2. How long is the song?

Usually 2-5 minutes.

> 3. How often does it scrobble? Every minute?

Possible - I just played a 1m22s long track and got two scrobbles.

> 4. What is in your play queue? 1 track?

Right now it's an 8-entry playlist, an artist's album on repeat. But I also saw 
behavior like this running a "random tracks from genre" dynamic playlist.

Original comment by newbies...@gmail.com on 28 Jul 2014 at 4:07

[GoogleCodeExporter]

You can see a log here btw: http://www.last.fm/user/NewbieSone/tracks

That allows you to compare track lengths to number of scrobbles.

Original comment by newbies...@gmail.com on 28 Jul 2014 at 4:08

[GoogleCodeExporter]

Odd. Can you re-run Cantata from the commandline as follows:

CANTATA_DEBUG=69632 cantata

Then after a duplicated scrobble (i.e. after Cnatata itself has sent two 
scrobbles for the one track), stop cantata. This should have caused cantata to 
log scrobbling and network access to ~/.cache/cantata/cantata.log Please attach 
the contents of this to this bug report.

Original comment by craig.p....@gmail.com on 28 Jul 2014 at 4:15

[GoogleCodeExporter]

I'm in the process of trying to acquire that log now, but I just noticed two 
other interesting things:

- When I closed Cantata scrobbling was enabled, when I started it again it was 
off. I toggle it from the status bar.

- I just started playing the same album again that starts with that 1m22s track 
that got scrobbled twice last time. This time it was scrobbled once, and then 
when Cantata moved on to the next track the first scrobble actually disappeared 
from last.fm.

Original comment by newbies...@gmail.com on 28 Jul 2014 at 4:55

[GoogleCodeExporter]

This log shows covers both events:

- "moon village" is the track the scrobble disappeared for.

- "rain goes up to the sky" got scrobbled twice.

Original comment by newbies...@gmail.com on 28 Jul 2014 at 4:57

Attachments:

• cantata.log

[GoogleCodeExporter]

Thanks. The log file was *very* useful. Can you please update, and try again? 
Should now be fixed.

Original comment by craig.p....@gmail.com on 29 Jul 2014 at 7:19

[GoogleCodeExporter]

Tried it, and it seems to work nicely now! Thanks!

(Minor polish note that's not really worth ticketing I think: The "Center on 
Current Track" action in the status bar should probably be disabled when there 
is no current track.)

Original comment by newbies...@gmail.com on 31 Jul 2014 at 7:05

[GoogleCodeExporter]

Hmm, there still might be minor problems with the scrobbling. I just had a song 
on pause for ~10m, and it seems that its scrobble got removed from lastfm 
again, and when I resumed it wasn't rescrobbled. It's a bit hard to nail down, 
but effectively this means my scrobble protocol misses a song I actually played 
in full (just with a long pause), and I don't remember such behavior from when 
I was still using mpdscribble.

Original comment by newbies...@gmail.com on 31 Jul 2014 at 8:19

[GoogleCodeExporter]

How can a scrobble client *remove* a scrobble from last.fm? There is, AFAIK, no 
API for this - so I see no method with which Cantata could have done this.

All I can suggest, is re-run Cantata with the logging (delete the old file 
first). This will tell you what Cantata sends to last.fm

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 9:48

[GoogleCodeExporter]

I've never written a last.fm client, but from what I remember overhearing, 
last.fm does somehow try to differenciate "this song was actually played" from 
"this song was just skimmed", and ignore the latter. How long a song was played 
for plays into that I guess, and good scrobblers seem to be those that manage 
to use the API in a way that balances low latency (i.e. scrobbling soon after 
play start) with not fucking that up. I don't know how this is expressed at the 
API level, but if Cantata isn't explicitly calling off the scrobble, it must be 
behaving in a way that causes last.fm to remove it. Considering this already 
happened earlier (see older descriptions) perhaps the existing log can offer a 
clue, too.

Original comment by newbies...@gmail.com on 31 Jul 2014 at 9:53

[GoogleCodeExporter]

Another thing I've just noticed that is in a similar ballpark: last.fm is 
capable of differenciating between "is currently listening to" and "last 
listened to" states. I'm in an IRC channel with a bot that can query the 
last.fm API for the status of a user and outputs an appropriate message, and 
when someone just asked the bot what I was listening to, the bot dumped "last 
listened to track A" when my playlist had already begun to play track B for a 
while. I.e. this is the latency thing. I know that with mpdscribble the data 
was always in sync with very low latency, though (from using the bot sometimes 
within 1-2 seconds of a track switch).

Original comment by newbies...@gmail.com on 31 Jul 2014 at 10:16

[GoogleCodeExporter]

No, the previous log does not contain any helpful info. Please re-run the 
latest version with logging.

Cantata sends the scrobble at either the 1/2 way point of after 4 mins - 
whichever comes first. If a track is paused, then the scrobble timer is also 
paused.

The 'now playing' should only be sent 5 seconds after the song starts.

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 10:39

[GoogleCodeExporter]

Just a thought, but can you try this:

1. Edit scrobbling/scrobbler.cpp and change line 133 from:

        data+=QUrl::toPercentEncoding(i.key())+'='+QUrl::toPercentEncoding(i.value());

to:

data+=i.key()+'='+QUrl::toPercentEncoding(i.value());

...does this help at all???

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 10:51

[GoogleCodeExporter]

^ That won't work because i.key() is a QByteArray which can't + with QString.

Original comment by newbies...@gmail.com on 31 Jul 2014 at 10:56

[GoogleCodeExporter]

Sorry, try:

data+=i.key().toLatin1()+'='+QUrl::toPercentEncoding(i.value());

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 10:58

[GoogleCodeExporter]

So here's what I did, with the above applied:

1. Start Cantata
2. Resume playback
3. Wait for it to advance to the next song
4. Let it play for about a minute, which is below the half-way mark
5. Pause
6. Check last.fm: Song is listed as now playing
7. Resume much later
8. Song is gone from last.fm
9. As the song goes over the half-way mark it's getting scrobbled

So this seems ok ... last time the song disappeared entirely from the played 
songs list. I don't know if I paused it past the half-way mark or not that time.

But maybe Cantata should always send a "now playing" after n seconds of 
playback of the same track if it hasn't scrobbled it yet? I.e. to handle the 
"it was paused and diseappeared from lastfm"? Of course without causing the 
repeated scrobbles thing again ...

Original comment by newbies...@gmail.com on 31 Jul 2014 at 12:07

[GoogleCodeExporter]

Must admit that I dont personally use last.fm. So, is this (re-sending now 
playing) what other clients do? I assume last.fm is removing the track after it 
thinks its finished (due to the duration)

Does this change fix the behaviour? alter scrobbling/scrobber.cpp and change 
about line 742 from:

        case MPDState_Playing:
            if (0==currentSong.timestamp) {
                currentSong.timestamp = time(NULL)-MPDStatus::self()->timeElapsed();
            }
            if (!scrobbledCurrent) {
                scrobbleTimer->start();
            }
            if (!nowPlayingSent) {
                nowPlayingTimer->start();
            }
            break;

to:

            currentSong.timestamp = time(NULL)-MPDStatus::self()->timeElapsed();
            if (!scrobbledCurrent) {
                scrobbleTimer->start();
                nowPlayingSent=false;
                nowPlayingTimer->start();
            } else if (!nowPlayingSent) {
                nowPlayingTimer->start();
            }
            break;

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 12:25

[GoogleCodeExporter]

> So, is this (re-sending now playing) what other clients do?

I would assume so. Basically, here's the use case: I'm in a channel with a bot 
that does things like this:

[12:42] <NewbieSone> .np
[12:42] <Claire> Last.fm | newbiesone is listening to "너 때문에 (2011 New 
Recordings)" by After School from album Virgin | 
http://www.last.fm/user/newbiesone/now

[14:33] <NewbieSone> .np uguuu 
[14:33] <Claire> Last.fm | llamadeus last listened to "Truth" by HA:TFELT from 
album Me? | http://www.last.fm/user/llamadeus/now

For that to work properly, last.fm has to ideally return "listening to foo" 
whenever I'm actually playing foo. Right now, when I pause for a while and 
resume, that won't be the case. I never had problems with mpdscribble or 
previously Amarok, though (and I pause often), so it's reasonable to conclude 
that they act in a way that maintains that continuity.

Will be trying the above code change now.

Original comment by newbies...@gmail.com on 31 Jul 2014 at 12:35

[GoogleCodeExporter]

Actually, just try the attached files. I made a couple of changes. The now 
playing should only get re-sent if it has been more than 5 seconds since it was 
last sent.

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 1:01

Attachments:

• scrobbler.cpp
• scrobbler.h

[GoogleCodeExporter]

So I'm running those files now, but I'm still seeing this:

1. Play song
2. Pops up on last.fm
3. Pause (before half-way point)
4. Wait for song to disappear from last.fm
5. Resume
6. Not popping up on last.fm again (until half-way point causes a scrobble, 
then it's "just listened")

So basically, the issue is that pause+resume doesn't resume "now playing".

Original comment by newbies...@gmail.com on 31 Jul 2014 at 2:49

[GoogleCodeExporter]

Again, use the debug logging - that way I can *see* what is happening.

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 3:23

[GoogleCodeExporter]

Don't bother - made silly mistake!

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 3:32

[GoogleCodeExporter]

Try now.

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 3:36

Attachments:

• scrobbler.cpp
• scrobbler.h

[GoogleCodeExporter]

I was just logging! :)

Trying the new files now.

Original comment by newbies...@gmail.com on 31 Jul 2014 at 3:41

[GoogleCodeExporter]

Hmm, tricky tricky ... at first I thought "it works!" because I got a "now 
playing" back on resume, but now I have two entries of the same song on the 
last.fm page again, one "n minutes ago" and one "now listening". Log needed I 
guess ...?

Original comment by newbies...@gmail.com on 31 Jul 2014 at 3:58

[GoogleCodeExporter]

Perhaps. But what would you expect? two "now playing" messages have been sent.

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 4:15

[GoogleCodeExporter]

Hmm yeah, maybe it's OK ... it seems to have resolved itself actually, once it 
moved on to the next song eventually there was only one entry left in the log 
on the lastfm profile page. I've never monitored the website that closely 
before *during* playback. I guess if there aren't any dupes ultimately and now 
the data is there for the bot to always show what's playing, things are 
resolved now.

Sorry for this long road.

Original comment by newbies...@gmail.com on 31 Jul 2014 at 4:20

[GoogleCodeExporter]

One question; what would you expect to happen if the song is on repeat? Would 
you expect now playing to be continuously sent? What about scrobbles? Should 
the track be scrobbled each time?

I've noticed that the current code will not resend now playing or scrobble if 
the track is repeated straight after it is finished (e.g. single track in 
playqueue, set to repeat)

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 4:43

[GoogleCodeExporter]

Hmm - for repeats I'd expect "now playing" to continuously reflect it, and each 
new play round to result in a new scrobble. last.fm has a "top tracks" listing 
that shows your most-listened songs with a play count, and people do 
occassionally binge on a new single or so, so I think it makes sense from a 
social POV ...

Original comment by newbies...@gmail.com on 31 Jul 2014 at 4:56

[GoogleCodeExporter]

Please update, and try now.

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 7:38

[GoogleCodeExporter]

...as in with a repeated track, that is :-)

Original comment by craig.p....@gmail.com on 31 Jul 2014 at 7:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hmm doesn't seem to work - I have a playlist with one track and repeat enabled 
in the status bar, and it's only scrobbled it once despite multiple repeats. 
There's also no "Now listening" while it's still playing.

Original comment by newbies...@gmail.com on 1 Aug 2014 at 2:34

[GoogleCodeExporter]

again, debug log please. I've just tried - with a 'fake' scrobbler, and it does 
go through the motions each time. But this is not a real scrobbler, so no 
actual message is sent.

Original comment by craig.p....@gmail.com on 1 Aug 2014 at 4:16

[GoogleCodeExporter]

Well crap, now I can't reproduce it anymore ... attaching the log here just in 
case, but it would presumably simply indicate correct behavior because this 
time it scrobbled multiple times as expected. The only difference I can think 
of is that last time I enabled repeat within the session before starting the 
song, and this time it was already enabled when starting Cantata.

(More interesting perhaps is that "Stop After Track" doesn't seem to work in 
repeat mode. I can understand why - it's not advancing to a different track - 
but I used it to mean "stop when this play finishes".)

Original comment by newbies...@gmail.com on 1 Aug 2014 at 4:35

Attachments:

• cantata.log

[GoogleCodeExporter]

Well I'm closing - as it works good enough for now. Still not convinced 
scrobbling belongs in a client - but whatever...

As to the stop-after. I get what you mean - and it /should/ work if you set the 
stop-after after playing the track. However, it is only a hack anyway - and 
this (as well as fade on stop) really belong within MPD.

Original comment by craig.p....@gmail.com on 1 Aug 2014 at 5:00

• Changed state: Fixed

[GoogleCodeExporter]

OK!

> Still not convinced scrobbling belongs in a client - but whatever...

It's a convenience basically -- mpdscribble worked well, but I accidentally 
deleted the systemd unit file I wrote to start it and noticed Cantata had added 
scrobbling in the meantime, so I tried it out. Thanks for adding it!

Original comment by newbies...@gmail.com on 1 Aug 2014 at 5:06