Missing scrobbles

  1. anonymous

    As I'm not entirely sure if this is Synergy or last.fm acting up I'm posting here instead of filing a bug report, but I'm noticing that since I've upgraded to version 4.4 I'm missing scrobbles.. Nothing shows up in console though, so I'm not sure what's causing this..

  2. Greg Hurrell

    Take a look at this page.

    It tells you how to turn on logging for the AudioScrobbler feature; specifically you execute the following in the Terminal when Synergy is not running: 

    defaults write org.wincent.Synergy LogAudioscrobblerEvents -bool yes

    And you can then view the log using the Console application (in /Applications/Utilities/) and see if any error information appears.

    I myself haven't had any problems scrobbling lately but I'm going to see if I can reproduce any problem here.

  3. anonymous Created , edited

    Hmm.. I think I figured out what the problem in this case is, although I'm finding it hard to reproduce it.. The missing scrobbles seem to occur when I'm viewing song lyrics (through command + I).. When canceling that dialog (by pressing escape) I get the following error: 

    9/5/10 23:55:22 	Synergy[217]	Audioscrobbler: Submission timer fired; will double-check that current track position matches expected value
9/5/10 23:56:11 	Synergy[217]	Audioscrobbler: Position does not match (user must have skipped); will not submit to Audioscrobbler

    I've seen this behaviour at least twice (looking up lyrics causing failed scrobbles) but as I said, I'm finding it hard to reproduce...

  4. Greg Hurrell

    Interesting. Thanks for the details.

    An issue which has come up a number of times over the years is that iTunes "blocks" when it has one of its "modal" windows up front. This was always one of the ways in which it differentiated itself from "pure Cocoa" applications like Mail.app. I have no idea how much of iTunes is still that old-fashioned style Carbon core, and how much of it is "modernised", but it seems that things like the preferences window and other "panes" like the song lyrics info are still definitely running as they always have (ie. in a blocking fashion).

    What this means is that when one of these windows is upfront iTunes effectively shuts its eyes and ears to all external communication, and will only reply to requests from other programs (or any process requesting information via Apple Events or AppleScript) after those windows have been dismissed. And this is why submission fails: because before submitting, Synergy must check how far iTunes is into the track in order to filter out tracks in which the use has skipped rather than listened to the required portion of the track (the Audioscrobbler protocol requires this, at least at the time of writing, although they are talking about releasing a new version of the protocol which drops this requirement).

    So, Synergy asks iTunes for the track position, iTunes doesn't respond, and later, when the window has been dismissed, iTunes decides to respond, but by then it's too late and the track position has moved forward and so Synergy deduces that the user has skipped forward.

    There are 3 possible fixes for this, then, I guess:

    • Apple removes this annoying blocking behavior (seems unlikely; I've been wishing they would for nearly a decade now...)
    • Synergy stops checking (ie. disregards the Audioscrobbler protocol; not too keen on this option myself)
    • Synergy compares the track position not against the time the request was made, but against the time the request was answered

    The latter option sounds doable, at least in principle, so I'll add a ticket to the issue tracker for this so as not to lose track of it. See ticket #1552.

Reply

This topic is now closed.

topic index