Topic: XMPlay Last.fm/Audioscrobbler plugin (xmp-scrobbler)

[Dotpitch]

the state is here http://openpaste.org/en/20970/ - i played few files that get misspelled, some files however are correct; however, i can't spot any pattern.

The failing files all have the Artist tag as the last ID3v2 entry, the others don't.

[Xander]

the advantage of a community this small and one-man-plugin-project is that i never got this intensive feedback from any developer yet

Well yes, the plugin is small really , collaboration between users and devs is easy under these characteristics. In bigger projects it's often complicated to get in touch with developers and expose issues and suggestions.

The failing files all have the Artist tag as the last ID3v2 entry, the others don't.

You're right, but the behaviour seems to be arbitrary, I can't get it to fail here with files that are failing there. The current plugin doesn't use the GetTag function XMPlay offers but instead gets the whole message block and parses it. From the state file I can see the message block is ok, the problem must be when parsing it.

Here there are 2 more binaries:
 - Debug 2: Changed the 2nd part of the state file, now shows 2 strings for the artist to let me know more about what's happening there. Use this one and paste the contents of the state file please.
 - Different: In this one I changed how the tag is extracted, should be equivalent really, but I made use of different functions. Check this one out and tell if there are still missing letters.

Let's see how that goes...

[eidam]

i just wonder - am i the only one with this problem?

state2 - http://openpaste.org/en/20999/ (the last two cranberries are different songs)

different - http://openpaste.org/en/21000/ (it's supposed to generate the state.txt too, isn't it?)

still cuts off the last letters :/

[Xander]

i just wonder - am i the only one with this problem?

At least no one else reported it... The problem with this is that it appears to be random, so maybe in other computers it's working correctly and nobody came across this behaviour.

I've made a change that may fix the issue and is harmless to anyone not experiencing it (if only I could reproduce it...). Use this binary and tell us if everything is correct, if it's not... we'll have to deal with it later, I might not be able to work on it until this weekend.

This one generates a state file too, I didn't change that part yet; when everything is right and stable the changes will be in 0.9.7.

[eidam]

yay all works fine now i'll let you know if not, but it should be okay now

thanks a lot. what was the issue?

[Xander]

I'm glad it works!

The message block of a track contains several tags (for example, ID3v1, ID3v2 and APEv2), the plugin retrieves the it and chops it in these categories for later processing. The only thing I did was expanding the lower limit 1 character so that if the artist is in the last position it will have always all of its characters.

Once I investigate it further and see if it doesn't break anything it'll be in the next stable version. You may use this one if you don't want the state file to be generated by now.

Thank you very much for all your testing work , kind regards.

[eidam]

hello, it's me again 

don't throw rocks at me, but the 'should already been submitted' bug has reappeared! i just finished listening an album with all of the tags complete, and XMplay gave me only two scrobbles and this http://openpaste.org/en/21350/

do you think you can look onto it? i'd be very thankful

[Xander]

I think I have an idea why could that happen (even though I can't get that behaviour here), the info fetch delay is low and might be related as sometimes the seconds are not strictly counted (I'll have to look at that too).

In 0.9.7 the lower limit of the delay will be lifted from 0 to 10 seconds to avoid these problems, in the meanwhile you may increase the delay yourself which should avoid those messages.

Use the attached version of the plugin too, some things were changed and other restructured. One important part is that the messages posted in the log were changed for better understanding and will help understand situations like this, so if the delay is not what it's causing this it'll give further information.

[eidam655]

of course; why the hell did i turn that thing off?!

works alright now x-) and i like the verbosity of the new debug output. it's so much more... human

good luck onwards

EDIT: oh, and while I'm at it  - do you think you could do something to the cache? the hing is, that on weekends i am 'internet-less,' but still listen to music i would like to have scrobbled. unfortunately, i guess none of the tracks i listened to got uploaded to last.fm.
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; but if i could request one feature, it would be this.

[Dotpitch]

do you think you could do something to the cache? the hing is, that on weekends i am 'internet-less,' but still listen to music i would like to have scrobbled. unfortunately, i guess none of the tracks i listened to got uploaded to last.fm. 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; but if i could request one feature, it would be this.

Are you sure the tracks are not submitted? All non-submitted tracks should be in xmp-scrobbler.cache (which is not cleared on closing XMPlay or Windows), and they should be submitted in batches of 10 tracks once the connection with Last.fm is available again.

[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: [Select]

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: [Select]

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?