▲

[Dotpitch]

Due to the changes the internal data the plugin saves was changed, so if the plugin is just updated its configuration will be messed up (i.e. incomplete username, incorrect settings, ...). My recommendation is to remove the plugin from the plugins list, update it, and then add it again (and reconfigure it).

Yeah, I've had some trouble getting it running again, but it works now (like the rest of the day). Perhaps the 'bad authorization'-message should be a warning and not just debug information?

[Xander]

Yeah, I've had some trouble getting it running again, but it works now (like the rest of the day). Perhaps the 'bad authorization'-message should be a warning and not just debug information?

Sorry about that, new variables were needed to allow users change the delay, I hope the info message (bad authorization) gets people to the config. You're right, when there's a problem using the username and password provided a warning should be posted in the log to let the user know there's a problem in the login info so it's now added. I've updated the binary in the post.

Regarding the CUE related changes, I've made some more tests today and everything seems to be fine. I'll give a few days though until the update is notified to all users .

[amit]

I've modified the plugin and added a new checkbox to the plugin config dialog. By default there will be a 10 second delay before fetching the info on the track, you can increase this time, reduce it or use no delay at all (use this last option with care, the default setting is the best way to go in my opinion). If "Delay info fetch" is ticked the edit box next to it will ask you for a number of seconds to use (if left empty the delay will be 0, the same as not ticking this option). You may enter any number, but only the first 3 digits will be used (so in practice, the delay may be 0-999 seconds).

Thanks. It works great now. This new checkbox can also define the shortest track that will be sent. This can be used to stop short intro or intermediate tracks from being sent. Right?

Another but minor issue : when moving by tab between different input areas in the plugin options gui they switch randomly without any order. Is there a way to order them more logically?

[Xander]

This new checkbox can also define the shortest track that will be sent. This can be used to stop short intro or intermediate tracks from being sent. Right?

I'm afraid not, one of the points of the protocol 1.1 is: "Each song should be posted to the server when it is 50% or 240 seconds complete, whichever comes first."

That point is important for this matter, the plugin will get the tags of the current track once the delay is over (this only applies to the first track of a CUE sheet). At that time, a "submission timer" is set to either 50% of the song or 240 seconds and when that timer reaches 0 if the track is not dirty (by seeking for example) it will be submitted to the server.

XMPlay allows playback resuming, so you may be resuming the playback of a song already submitted. To prevent double submissions (among other things), I used the current position at the time of fetching the tags to identify whether the track should already been submitted or not. So, for example, if the fetching time is 64 seconds and the track lasts 2 minutes that track wont be submitted. The plugin will recognize that track as already submitted (half the time of the song would be 60 seconds, but the tags would be read 4 seconds after that time).

In the current version of the protocol the submission point was moved to the end of the track (or when another track begins to play) so this problem will not be present .

When moving by tab between different input areas in the plugin options gui they switch randomly without any order. Is there a way to order them more logically?

There should be a way, I'll look into it .

[Ian @ un4seen]

Xander's latest update (0.9.6) is now available in the 1st post.

[natschos]

Hi,
I'm a last.fm fan.
Since I prefer Xmplay for sound quality and full usability and sociability in last.fm.
Is it possible you could add a feature in this add-on which sends PLAYING NOW/LISTENING NOW info to last.fm?

There's a bug report: It says the current track should already have been submitted and REFUSES to scrobble the track I listen to, hideously. Is it not a bug? I'm using 0.96 and since I upgraded from 0.93 this BUG is here suddenly annoying the heck out of me.

I say it is a bug because should/shouldn't questions makes no sense here. Please let me scrobble the music in Xmplay without making me press the STOP and PLAY button for every track to avoid this BUG again and again!

[Dotpitch]

Is it possible you could add a feature in this add-on which sends playing now info to last.fm?

That was already Xanders intention.

I'm planning on writing a new version of the scrobbler plugin, compatible with the new protocol (e.g. "Now playing" notifications, seeking allowed, ...) using the sockets API directly instead of the cURL library; but it'll take some time.

Have some patience .

[natschos]

Is it possible you could add a feature in this add-on which sends playing now info to last.fm?

That was already Xanders intention.

I'm planning on writing a new version of the scrobbler plugin, compatible with the new protocol (e.g. "Now playing" notifications, seeking allowed, ...) using the sockets API directly instead of the cURL library; but it'll take some time.

Have some patience .

Well, thanks for answering me! I only try to help..

I had found a bug above, see. Nothing helps, since I upgraded from 0.93 to .96

Edit:
OM G, I had problem with handshake with it, and then I removed plugin and re-add, and now Xmplay crashed AGAIN! (using .93)

Edit:
Now it works (.93)

Edit:

OM G It added the track to CACHE instead of scrobbling? WHY o WHY?

2010-04-20 19:15:36   [INFO] Current track: Third Eye Blind - Wounded (Blue)
2010-04-20 19:15:36   [INFO] Submitting in 137 seconds...
2010-04-20 19:17:52   [INFO] Track added to the cache for submission
2010-04-20 19:17:52   [INFO] Preparing to submit 1 track(s) from the cache
2010-04-20 19:19:58   [DEBUG] DSP_SetFormat( 1, NULL )
2010-04-20 19:19:58   [DEBUG] DSP_StopTrack
2010-04-20 19:19:58   [DEBUG] DSP_NewTrack (CLOSE)
2010-04-20 19:19:58   [DEBUG] DSP_NewTrack (OPEN)
2010-04-20 19:19:58   [DEBUG] DSP_SetFormat( 1, 44100, 2 )
2010-04-20 19:20:06   [DEBUG] XMP_FetchInfo -- start
2010-04-20 19:20:06   [WARNING] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly!
2010-04-20 19:20:06   [DEBUG] XMP_FetchInfo -- end
2010-04-20 19:20:06   [DEBUG] len = 92, diff = 8
2010-04-20 19:20:06   [INFO] Current track: Third Eye Blind - 10 Days Late (Blue)
2010-04-20 19:20:06   [INFO] Submitting in 84 seconds...
2010-04-20 19:21:29   [DEBUG] DSP_Process -- sec <= 0
2010-04-20 19:21:29   [DEBUG] XMP_SubmitProc start
2010-04-20 19:21:29   [DEBUG] AddTrack (cache_size = 1, tracks_size = 10)
2010-04-20 19:21:29   [INFO] Track added to the cache for submission
2010-04-20 19:21:29   [INFO] Preparing to submit 2 track(s) from the cache
2010-04-20 19:21:29   [DEBUG] Submitting...
2010-04-20 19:21:30   [DEBUG] Submission succeeded.
2010-04-20 19:21:30   [INFO] Submission succeeded!
2010-04-20 19:21:30   [DEBUG] Submit interval set to 1 second(s).


Conclusion: I had to downgrade to .93 for it to work.

[Dotpitch]

I had found a bug above, see. Nothing helps, since I upgraded from 0.93 to .96

Don't edit your post after someone answers.

It says the current track should already have been submitted and REFUSES to scrobble the track I listen to, hideously. Is it not a bug?

That's probably not a bug. Try playing a different track and see whether it works.

I had problem with handshake with it, and then I removed plugin and re-add, and now Xmplay crashed AGAIN! (using .93) OM G It added the track to CACHE instead of scrobbling? WHY o WHY?

If the handshake fails, it usually means you've put the wrong username/password, or that Last.fm servers are too busy to handle your request. If the track can't be scrobbled, it'll be saved to the cache for later submission. As you can see in your own log, it's submitting 2 tracks: the current track and the cached one.

[Xander]

Is it possible you could add a feature in this add-on which sends PLAYING NOW/LISTENING NOW info to last.fm?

Unfortunately I can't add that to the current plugin (it follows the old specs of the protocol), but as Dotpitch said I intend to do a new version complying to the current one. I had to push it to the background though, I'll post it in the forums once it's ready (I've been busy in "real life", I have some obligations that must be addressed).

There's a bug report: It says the current track should already have been submitted and REFUSES to scrobble the track I listen to, hideously. Is it not a bug? I'm using 0.96 and since I upgraded from 0.93 this BUG is here suddenly annoying the heck out of me.

I'll try to throw some light on it: When you play a track, the plugin waits X seconds before it gets the tag info about that track (artists, title, ...) which by default are 10 seconds (you can verify it in the plugin options from 0.9.5 on).

Then, it retrieves the track info and calculates when to submit the track. Now, if the track lasts more than 480 seconds the submission time is 240 seconds, otherwise it is length / 2. Of course that is if the track is at least 30 seconds long, can't be submitted if it's shorter.

As XMPlay allows you to resume playing, I implemented a (weak) mechanism to avoid double submissions and problems when submitting CUE listings: when it calculates the submission time, if you're over it (e.g. you're resuming a song past the point of submission) the plugin will interpreter that as if the track was already submitted and won't submit it.

There should not be any problem with this part, but if you can reproduce the problem please let me know the details (track length, if you were resuming or just playing from the beginning, and plugin version and delay (if applies)) and I'll look into it. If you may, please upload a complete log file when this happens showing the behaviour.

OM G It added the track to CACHE instead of scrobbling? WHY o WHY?

That was a decission of the original developer. When the submission time is over, if the track is good to go it's added to the cache and then submitted when there's an Internet connection available. You don't have to worry about this, I'll work .

I upgraded from 0.93 to .96
...
OM G, I had problem with handshake with it, and then I removed plugin and re-add, and now Xmplay crashed AGAIN! (using .93)
...
I had to downgrade to .93 for it to work.

You may upgrade to 0.9.6 safely, but if you downgrade from 0.9.5+ you have to reconfigure the plugin.

Kind regards.

P.S.: You beat me to it Dotpitch, I was just answering .

[eidam]

hello,

sorry for not reading previous posts to search for a fix for this issue O:-)

my problem with the plugin is that it doesn't scrobble some tracks, and i don't know why. they are properly tagged; the only thing i found were  some warnings in the log, about a non-valid Musicbrainz ID. at first i presumed, since this is only a warning, that the tags should be read fine and scrobble without trouble. here is a part of the log:

Code SelectExpand

2010-05-02 08:56:43 [INFO] Preparing to submit 1 track(s) from the cache
2010-05-02 08:56:44 [INFO] Submission succeeded!
2010-05-02 09:00:11 [WARNING] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly!
2010-05-02 09:00:11 [INFO] The current track should already have been submitted, resuming playback.
2010-05-02 09:05:42 [WARNING] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly!
2010-05-02 09:05:42 [INFO] Current track: Movits - Fel del av garden ()
2010-05-02 09:05:42 [INFO] Submitting in 107 seconds...

oh well; i don't know where the problem could be i'm quite worried about the "The current track should already have been submitted..." line, as this seems to indicate the skipping.

i'll gladly be more helpful, if needed.

[Dotpitch]

my problem with the plugin is that it doesn't scrobble some tracks, and i don't know why. they are properly tagged; the only thing i found were  some warnings in the log, about a non-valid Musicbrainz ID. at first i presumed, since this is only a warning, that the tags should be read fine and scrobble without trouble. here is a part of the log ... oh well; i don't know where the problem could be. i'm quite worried about the "The current track should already have been submitted..." line, as this seems to indicate the skipping.

MusicBrainz tags make sure your files are tagged properly, but it won't stop xmp-scrobbler from scrobbling if they're not present. xmp-scrobbler submits tracks at half their length (e.g. a 3m34s track is scrobbled at 107 seconds). If the plugin finds itself started after that point (for example because you start XMPlay and resume a track from that point), it assumes the track was already scrobbled. This will only happen on the first track, and only if you're past the first half of the file. All the next tracks will be scrobbled as usual.

Now, on with your problem. First, go to the configuration and switch on debug logging. Play a dozen of tracks and take a look at the logfile. Do they all have 'Submission succeeded'? Check your Last.fm profile as well, do they show up there as well? If, for some reason, a track can't be scrobbled, it'll be saved to the cache so it can (and will) be submitted later. If this happens, either your username/password is wrong, or the Last.fm servers can't handle your request.

[eidam]

wow, that's a quick response

what you're saying makes sense. however, the 'track already scrobbled' appears often during regular playback. (and it were often these tracks that didn't show up on last.fm). also, my credentials are correctly typed in (as some tracks do indeed show up )

another sample of the old log:

http://openpaste.org/en/20898/

here goes the debug log:

http://openpaste.org/en/20899/

so far, it scrobbles the songs which were previously skipped it's the Murphy's law - when a mechanic is around to fix a problem, there is no problem )

the 'track already submitted' notes miraculously disappeared. i'll hunt some more for them

also, i see that from some song tags, the last character is being cut off so this way, i have in my music library artists like Gorilla, Morrisse, Koshee, A Perfect Circl... but maybe that's an XMplay issue?

[Dotpitch]

however, the 'track already scrobbled' appears often during regular playback. ... the 'track already submitted' notes miraculously disappeared. i'll hunt some more for them.

If that happens again, please report which tracks it occured with and post the contents of the logfile.

here goes the debug log: http://openpaste.org/en/20899/
also, i see that from some song tags, the last character is being cut off. so this way, i have in my music library artists like Gorilla, Morrisse, Koshee, A Perfect Circl... but maybe that's an XMPlay issue?

You seem to have some connection problems, but the cache makes sure all tracks are scrobbled properly. For those lost characters, does it happen with all tags, or just with the Artist tags? Could you post the content of the Message tab of the Info Window for a problematic track from 'A Perfect Circle'?

[eidam]

If that happens again, please report which tracks it occured with and post the contents of the logfile.

of course; you got it.

ontent of the Message tab of the Info Window

yes, it happens only with Artist tags; at the end of the second log you see the final character stripped (L154, L138...)

[Dotpitch]

Could you post the image for 'A Perfect Circle - Sleeping Beauty' as well? That one is scrobbled correctly, so it might give a hint as to what causes this problem.

[eidam]

no, it isn't;
check the line 154 in the log. also, it might seem as it is correct, but that's only due to last.fm's spelling correction (marked by the green star).

in the log, the last correctly spelled MP3 track is on line 7 - Kotov Syndrome by Rise Against. (songs from Mad Season are in m4a format; so i don't know whether its info would be very helpful)

[Xander]

Hello eidam,

The double submission prevention seems to be causing some trouble, but I don't seem to be able to replicate the problems in my side. If you happen to come across tracks being "already submitted" again, post the track length and the log please. If you could provide an screenshot of the plugin configuration dialog in that case it would be appreciated too.

I can't reproduce the problem of the missing last letter either, could you please upload a track from "A Perfect Circle" or any other file which artist is not complete somewhere? It may be something related to the tags of those files.

If you prefer a FTP server use this one:

Server: ftpwt.com
User: xmplay
Password: xmplay

EDIT: Could you tell me the version of the plugin you're using too?

[eidam]

for testing purposes only http://jaja.kn.vutbr.cz/~ambrus2/sklad/xmplay%20stuff/06%20-%20A%20Perfect%20Circle%20-%203%20Libras.mp3 yes, i agree it might have something to do with the tags; different encoding at write/read seems to be the most probable issue. but i'm not an expert

to the submission problem - i haven't been able to replicate it myself since then. i don't know what could have caused it.

[eidam]

ah, can't edit guest posts.

i use both latest stable releases, since i'm a fresh user; xmplay 3.5, and xmp scrobbler 0.9.6 i think it is.