▲

[Xander]

...i don't know whether this is because of the 10 slot cache, or whether the cache is being cleared on every xmplay or system shutdown...

As Dotpitch said all non-submitted tracks remain in the cache file (when you listen to a track it goes to cache first before trying to submit it) and it remains there until done. The protocol specifies that plugins should try to submit 10 tracks at most, otherwise the tracks may not be submitted correctly; so if you have in cache more than 10 tracks they're submitted in batches of 10.

Don't worry about the 10 slot cache, that's the default one; if the cache is full it is resized before adding new files to it. If you have the debug logging enabled you'd see a message about it (e.g.: "[DEBUG] Resizing cache array, from 10 to 20 slots."). Check it this weekend if you want, all of the tracks should be submitted.

[eidam655]

okay, next weekend then.

but for now, when you look at my library http://www.last.fm/user/eidam655/library/recent?sortBy=date&sortOrder=desc&page=1 , last record from weekend (that i also have log of) is 'Blue Man Group – Rods And Cones' (9.5.2010, late evening in log).

next song is the Madagascar 2; but when looking at the log, it says http://openpaste.org/en/21388/

i am aware that some songs were not submitted according to the fetch delay. but i highlighted the lines of songs which are listed as submitted in the log, but do not show up in the library.

PS: the log covers the area from the blue man group until madagascar, that means 'from one song to next one' in the library.

[Dotpitch]

last record from weekend (that i also have log of) is 'Blue Man Group – Rods And Cones' (9.5.2010, late evening in log). next song is the Madagascar 2; but when looking at the log, it says http://openpaste.org/en/21388/ . i am aware that some songs were not submitted according to the fetch delay. but i highlighted the lines of songs which are listed as submitted in the log, but do not show up in the library.

If a track cannot be submitted, it'll explicitly tell you the track was saved to cache and it'll try submitting 2 (or more) tracks the next time. Trying it here, the cache does seem to function properly.
In your case, it appears as if xmp-scrobbler thought it did have an internet connection, so the track was scrobbled and there was no need to save it to the cache. As the tracks don't show up in your library, xmp-scrobbler was probably wrong about that, though I'm puzzled why. Did you do something with your internet connection just before it started submitting again?

[eidam655]

oh GOD i am so stupid.

1. the link on the last.fm i gave you in my last post was the 'Recently added to library' -> only newly played tracks. so screw the log i posted, since it's irrelevant (and all songs that are in the log i gave you are scrobbled). i just remembered that all of this happened on 9th in the evening, when i was already permanently connected at the dormitory. http://www.last.fm/user/eidam655/tracks?page=2

2. on the other hand, i remember clearly that on saturday (the 8th), i played few songs (through xmplay; i remember staring in awe at the 3D Spectrum visualisation). so more info will indeed be available next monday, as i already lost the saturday's log.

3. my only hope is that you are not starting to be angry with my complaints/reports i promise i will think twice next time i post something here.

[Xander]

I was puzzled too, if those submissions were not computed by Last.fm the problem would be on their side.

When you see the message "Submission succeded" the tracks are already sent and their server responded that everything is correct. If you're not connected to the Internet, either when you start XMPlay or before submitting the info, you'd see a message stating the problem in the debug log (e.g.: "Could not resolve host: post2.audioscrobbler.com; Host not found, try again." which I can't change, it's libcurl related).

I'll add a warning too to know that the submission could not take place (right now only a handshake failure has a warning, submission errors are shown in the debug log).

[eidam655]

hello there.

so, the weekend is here, and here are my test results so far.

after playing few (13) songs, i quit xmplay normally (by clicking the X button). file xmplay-scrobbler.cache grew from 0 to 14kB, so the songs were saved.

after running xmplay again, cached songs were loaded, and cache continued to grow (according to the log). however, when directly turning off the computer via start -> shutdown, the cache file grew nothing in size; that's why i assumed that the newly cached songs in ram weren't saved.

this assumption turned out to be correct, when playing another song this morning, and the cache state was found as in the previous case.

the .cache file is here.

that's why i have a suggestion  - wouldn't it be safer (even in case of computer/xmplay crashes) to save the cache file after every cache addition?

[eidam655]

moreover, when playing another two songs while connected to the internet - only first 9 of 14 songs in cache were submitted; others were omitted, and next submission was the two songs played as last.

[Dotpitch]

however, when directly turning off the computer via start -> shutdown, the cache file grew nothing in size; that's why i assumed that the newly cached songs in ram weren't saved.

To clarify, you closed Windows while XMPlay was still playing?

wouldn't it be safer (even in case of computer/xmplay crashes) to save the cache file after every cache addition?

That certainly sounds more fail-safe.

moreover, when playing another two songs while connected to the internet - only first 9 of 14 songs in cache were submitted; others were omitted, and next submission was the two songs played as last.

Did it say the cache was empty after that?

[eidam655]

To clarify, you closed Windows while XMPlay was still playing?

exactly.

to the cache thing - looking in the log, 10 songs were tried to be submitted. only 9 got through, but that's ok; they've been scheduled for the next batch submit (trying to submit 7 songs instead of 6). however, only the last two showed up on last.fm; this _could_ be last.fm's fault, but doesn't have to be. (bah, why do i repeat myself? here's the log.)

Code SelectExpand

2010-05-16 16:34:05 [INFO] The current track is "Eidolon Alpha" by Rishloo.
2010-05-16 16:34:05 [DEBUG] Caching for submission in 152 seconds.
2010-05-16 16:36:36 [DEBUG] Scheduling a new submission.
2010-05-16 16:36:36 [DEBUG] Adding track to cache: 16 tracks in cache, 24 slots.
2010-05-16 16:36:36 [INFO] Track added to cache for submission.
2010-05-16 16:36:36 [INFO] Preparing to submit 10 tracks from cache.
2010-05-16 16:36:36 [DEBUG] Submitting.
2010-05-16 16:36:37 [INFO] Submission succeeded.
2010-05-16 16:36:37 [DEBUG] Submission interval set to 1 second.
2010-05-16 16:38:42 [DEBUG] Audio output stopped.
2010-05-16 16:40:28 [DEBUG] The track has been closed.
2010-05-16 16:40:28 [DEBUG] A new track has been opened.
2010-05-16 16:40:28 [DEBUG] Audio info: 2 channels, 44100 Hz.
2010-05-16 16:40:31 [DEBUG] Fetching the track data.
2010-05-16 16:40:31 [INFO] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly.
2010-05-16 16:40:31 [DEBUG] Track data fetch ended.
2010-05-16 16:40:31 [DEUG] PlayTime: 3 Start: 02010-05-16 16:40:31 [DEBUG] Track length: 212 seconds, 3 already passed.
2010-05-16 16:40:31 [INFO] The current track is "Fly" by Metropolis.
2010-05-16 16:40:31 [DEBUG] Caching for submission in 103 seconds.
2010-05-16 16:42:14 [DEBUG] Scheduling a new submission.
2010-05-16 16:42:14 [DEBUG] Adding track to cache: 7 tracks in cache, 24 slots.
2010-05-16 16:42:14 [INFO] Track added to cache for submission.
2010-05-16 16:42:14 [INFO] Preparing to submit 7 tracks from cache.
2010-05-16 16:42:14 [DEBUG] Submitting.
2010-05-16 16:42:14 [INFO] Submission succeeded.
2010-05-16 16:42:14 [DEBUG] Submission interval set to 1 second.
2010-05-16 16:42:32 [DEBUG] Audio output stopped.
2010-05-16 16:42:32 [DEBUG] The track has been closed.
2010-05-16 16:42:32 [INFO] Shutting down...
2010-05-16 16:42:32 ----
...aaand yes, the cache seems to be empty at this point.

[Dotpitch]

moreover, when playing another two songs while connected to the internet - only first 9 of 14 songs in cache were submitted; others were omitted, and next submission was the two songs played as last.

Did it say the cache was empty after that?

to the cache thing - looking in the log, 10 songs were tried to be submitted. only 9 got through, but that's ok; they've been scheduled for the next batch submit (trying to submit 7 songs instead of 6). however, only the last two showed up on last.fm; this _could_ be last.fm's fault, but doesn't have to be. (bah, why do i repeat myself? here's the log.) ...aaand yes, the cache seems to be empty at this point.

This is quite different from your earlier post, clearly xmp-scrobbler did not omit the other tracks. Also, it submitted 10 tracks the first time, not 9 (second submission is after a new track is added to the cache). I'm not sure why the tracks don't show up on your recently played list, though. Could you test it again some time?

Xander, could you please change the MB-ID-warning from [INFO] to [DEBUG]?

Code SelectExpand

2010-05-16 16:40:31 [INFO] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly.

[eidam655]

you're right - i forgot to add the new one

however i still counted only 9 new tracks at the server (after this batch). i will have time to test it this week, starting by tomorrow. (and maybe we'll find out that i can't count that's also a possibility ) maybe it really was a temporal server failure.

till then,
bye.

[eidam655]

OK, cache submission works fine. must have been last.fm's fault i guess.

[peewack]

Hi all!

 I just downloaded the 0.9.6 version of the plugin, so far no crashes because a broken/empty cache in Windows 7 x32.

kind regards

[saga]

Hmm, I have some TFMX files by Chris Hülsbeck, the song author and title are set using the XMPlay library. Whenenver I play those tracks, the author is scrobbled as "Chris Hülsbec" (and no, there's no typo in my library). Could that be a problem with unicode or whatever? Strangely enough, I think this doesn't happen with the MP3s (with ID3 tags) of Hülsbeck that I have.

[Dotpitch]

Hmm, I have some TFMX files by Chris Hülsbeck, the song author and title are set using the XMPlay library. Whenenver I play those tracks, the author is scrobbled as "Chris Hülsbec" (and no, there's no typo in my library). Could that be a problem with unicode or whatever?

That sounds very similar to eidams problem. Do you have the latest version of the plugin? Could you post the contents of the Message tab of the Info window?

[saga]

I'm using version 0.9.6. Message tab says...

Library:
Title   Apidya Ingame 1
Artist   Chris Hülsbeck

Right-click for track info
 (if supported by plugin)

Log says...

2010-08-03 13:07:08   ----
2010-08-03 13:07:08   [INFO] Hello, this is xmp-scrobbler 0.9.6
2010-08-03 13:07:19   [INFO] Number of entries in the cache: 0
2010-08-03 13:07:22   [INFO] Handshake with Last.fm server successful!
2010-08-03 13:07:29   [WARNING] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly!
2010-08-03 13:07:29   [INFO] Current track: Chris Hülsbec - Apidya Ingame 1 ()
2010-08-03 13:07:29   [INFO] Submitting in 13 seconds...
2010-08-03 13:07:41   [INFO] Track added to the cache for submission
2010-08-03 13:07:41   [INFO] Preparing to submit 1 track(s) from the cache
2010-08-03 13:07:42   [INFO] Submission succeeded!

And that's how it appears on my last.fm profile :s

[saga]

ok... pre-0.9.7 seems to fix this...

[vind]

the plugin doesn't seem to submit anything, despite of what the log is indicating...

Code SelectExpand

2010-08-11 00:27:43 [INFO] Hello, this is xmp-scrobbler 0.9.3
2010-08-11 00:27:44 [INFO] Number of entries in the cache: 72
2010-08-11 00:27:44 [INFO] Handshake with Last.fm server successful!
2010-08-11 00:27:53 [WARNING] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly!
2010-08-11 00:27:53 [INFO] Current track: Sidewinder - Just Break'n Out ()
2010-08-11 00:27:53 [INFO] Submitting in 224 seconds...
2010-08-11 00:31:36 [INFO] Track added to the cache for submission
2010-08-11 00:31:36 [INFO] Preparing to submit 10 track(s) from the cache
2010-08-11 00:31:36 [INFO] Submission succeeded!
2010-08-11 00:43:38 [WARNING] No valid MusicBrainz ID found, consider using MusicBrainz taggers to tag this file properly!
2010-08-11 00:43:39 [INFO] Current track: Sidewinder - Just Break'n Out ()
2010-08-11 00:43:39 [INFO] Submitting in 224 seconds...

the last successful submission was apparently in March, according to earlier data in the log...

why hasn't it submitted anything since then, only to save up 72 new scrobbles which still - 25 minutes after logging an apparent successful submission - haven't appeared in my chart of recently listened tracks ?

[Dotpitch]

Only 10 tracks can be submitted at once, so it'll take some time to submit the complete cache. Could you switch on debug logging (in the plugin config)? Have the tracks still not showed up on your profile?

[raina]

You seem to be running a rather dated copy of xmp-scrobbler. I think you should update first and look for solutions second, if the problem persists. I recently had some problems with submitting titles from a cue file, with xmp-scrobbler 0.9.6. The pre-0.9.7 fixed that.