Author Topic: XMPlay Last.fm/Audioscrobbler plugin (xmp-scrobbler) (Read 789419 times)

yagood · « **Reply #100 on:** 27 May '06 - 15:31 »

Quote from: lingenfr on 27 May '06 - 15:23

(...)
In between the "Track is too short" messages, I closed and reopened XMP. No difference. I rolled back to the previous version and it worked fine with the same files. I rolled forward again and got the same thing. Immediately upon launching the file, one "Track is too short" and then nothing. Let me know what I can do to help. I have time to do more testing.

It happenend to me too yesterday while I was developing version 0.3. Check if the plugin is enabled in the configuration window. Let me know if it was the reason.

lingenfr · « **Reply #101 on:** 27 May '06 - 15:46 »

Duh. That was it. I will check that myself next time. Thanks.

yagood · « **Reply #102 on:** 27 May '06 - 15:55 »

Quote from: lingenfr on 27 May '06 - 15:46

Duh. That was it. I will check that myself next time. Thanks.

I've just figured out why this happens - it's because I added new configuration entries (proxy server, user and password) and they are written over the "enabled" bit. Ehh, I should have put this bit on the beggining of configuration structure

Please check your settings after upgrading to version 0.3!

Zarggg · « **Reply #103 on:** 28 May '06 - 18:43 »

Well, I'm not sure what the problem was, but I was just able to submit a song with 0.3. I'll let you know if I run into any other problems.

raina · « **Reply #104 on:** 28 May '06 - 22:17 »

Hooray, the crashes are gone!

yagood · « **Reply #105 on:** 28 May '06 - 22:52 »

Quote from: raina on 28 May '06 - 22:17

Hooray, the crashes are gone!

Pfff, yeah, fingers still crossed, but I've been using 0.3 for last two days and no crash - with previous versions crashes were ocurring quite often so there's definitely an improvement. Thanks to Ian for some technical tips!

jammer · « **Reply #106 on:** 29 May '06 - 12:28 »

works perfectly so far

all tagged tunes appeared on last.fm

Y@nek® · « **Reply #107 on:** 29 May '06 - 14:10 »

Great news. Thank you

Zarggg · « **Reply #108 on:** 29 May '06 - 16:06 »

I've also noticed that if you set library tags for plugin-controlled files that don't have an explicit "album" tag, you can submit them as well. Hooray for video game tracks!

lingenfr · « **Reply #109 on:** 29 May '06 - 17:29 »

Quote from: Zarggg on 29 May '06 - 16:06

I've also noticed that if you set library tags for plugin-controlled files that don't have an explicit "album" tag, you can submit them as well. Hooray for video game tracks!

Hunh? How about an example.

lingenfr · « **Reply #110 on:** 29 May '06 - 17:52 »

First, a suggestion. Write the log file by appending to the beginning rather than the end. For those of us who are monitoring our log file, it is a time saver and reduces confusion. That would put the newest entry on top.

Second, I am still having a problem that once it puts out a track to short, it dies with no more sending. I was actually playing a custom radio station from last.fm using lastfmproxy. Once it hits the track to short, no more log entries until I close and reopen xmp. For what is is worth, the tracks were showing up in lastfmproxy "Last tracks played". And yes, I did check to make sure the plug-in was enabled.

yagood · « **Reply #111 on:** 29 May '06 - 20:20 »

Quote from: lingenfr on 29 May '06 - 17:52

First, a suggestion. Write the log file by appending to the beginning rather than the end. For those of us who are monitoring our log file, it is a time saver and reduces confusion. That would put the newest entry on top.

OK, I'll consider that.

Quote from: lingenfr on 29 May '06 - 17:52

Second, I am still having a problem that once it puts out a track to short, it dies with no more sending. I was actually playing a custom radio station from last.fm using lastfmproxy. Once it hits the track to short, no more log entries until I close and reopen xmp. For what is is worth, the tracks were showing up in lastfmproxy "Last tracks played". And yes, I did check to make sure the plug-in was enabled.

Could you paste here a few last lines from the log file after this happens to you?

Ian Paul Freely · « **Reply #112 on:** 30 May '06 - 06:27 »

First off I've been an XMPlay for well over a year or two and I must admit its a very damn good player. I'm so glad that you guys managed to finally get an Audioscrobbler plugin for it, I refuse to touch winamp or WMP.

Now, there is a major issue with it. I will note I have not read the thread entirely except for the obvious first post so I do not know if this has been reported before, but if it is I have to add to it. The issue is the plugin's hogging of bandwidth.

I first noticed this issue earlier today while playing Counter-Strike: Source. XMPlay was running in the background with the plugin enabled, but doing nothing. By then, the most issues I have had with the plugin is the occasional random crash, which I expect as this is a mostly alpha stage project, and I'm sure it was reported already. However, while playing Counter-Strike, a much more major issue would arise.

I run 3 mb/s DSL and my average latency ingame is 30-75. However, while playing, my latency (ping) would shoot up to 400. It would stay there for at least a minute then slowly crawl back down to normal. It would do this in about the same time interval the plugin for XMPlay submits data. I did not think about that before.

Now tonight, I was trying to play on servers that were close to me (They were located in Dallas, I live in East Texas), and my ping would be 300-500 and would refuse to go down. I could not figure out why. I also noticed that the server latency in the server list was unusually high as well. I tried restarting my router (twice), closing/opening different ports, restarting my comptuer, etc. And the high latency remained. I also noticed that my regular internet browsing was slower than usual. Then, probaly about 20 minutes ago, I had the idea that this alpha plugin may have had something to do with it. I close XMPlay and refresh the STEAM server list and open FireFox.

Surely enough, all the latencies in STEAM were normal again, and my web browsing was as fast as it was. Just to double check, I open XMPlay again, and refresh the server list. The latencies skyrocket again. I tried switching between version 0.2 and 0.3, and there is no difference. For some reason, the plugin is hogging unecisarrily high amounts of bandwidth randomly (or even all the time) and prevent any other programs from using it. I don't know if this has been reported before (I apologize for my laziness to read the rest of the thread) or if anybody else has this issue. I'll check this thread once in a while incase any of you need anything else from me.

--Freely

yagood · « **Reply #113 on:** 30 May '06 - 08:54 »

Quote from: Ian Paul Freely on 30 May '06 - 06:27

(...) By then, the most issues I have had with the plugin is the occasional random crash, which I expect as this is a mostly alpha stage project, and I'm sure it was reported already. However, while playing Counter-Strike, a much more major issue would arise. (...)

It seems that crashes are gone with version 0.3. However, your bandwidth problem looks quite strange, because XMPlay sends at most couple of hundreds bytes while submitting single track and it disconnects from Last.fm server... obviously data of this length shouldn't affect DSL connection at all. I don't know what could be causing this, hmm... maybe some router issues? Can you monitor XMPlay network activity? Maybe xmp-scrobbler is doing something unusual and it's a bug. Nobody has reported such bandwidth issue before, I'll try to review xmp-scrobbler network code.

Quote from: Ian Paul Freely on 30 May '06 - 06:27

(...) Just to double check, I open XMPlay again, and refresh the server list. The latencies skyrocket again. (...)

This is odd too, because xmp-scrobbler doesn't even connect to the server on XMPlay startup - it only connects when you play first track (that's simple handshake with the server) and then when it has to submit a track it sends track data. Maybe you could paste couple of lines from your log here when this problem happens?

jammer · « **Reply #114 on:** 30 May '06 - 10:18 »

hope that you also consider my suggestion - excluding or including certain directories to be submitted

piovrauz · « **Reply #115 on:** 30 May '06 - 10:41 »

First of all, I don't use this plugin. But maybe I have a hint about your latency problem: it's not the plugin itsef, but STEAM (+ the plugin).

In these days games are "protected", and these "protection" can generate strange beauvoir of PC (personal experience).

I don't intend to start a discussion about game protections and so on, but you can try to monitor only this plugin network activity. I'm pretty sure it's not its fault.

yagood · « **Reply #116 on:** 30 May '06 - 11:07 »

Quote from: jammer on 30 May '06 - 10:18

hope that you also consider my suggestion - excluding or including certain directories to be submitted

It's already been requested before and I remember about it, but thanks for letting me know you want this feature - at least I'm sure that someone will actually use it :-) Anyway, it's a next thing on my to-do list and it will be included in the next release which probably will be ready this week.

Ian Paul Freely · « **Reply #117 on:** 30 May '06 - 18:16 »

Quote from: piovrauz on 30 May '06 - 10:41

First of all, I don't use this plugin. But maybe I have a hint about your latency problem: it's not the plugin itsef, but STEAM (+ the plugin).

In these days games are "protected", and these "protection" can generate strange beauvoir of PC (personal experience).

I don't intend to start a discussion about game protections and so on, but you can try to monitor only this plugin network activity. I'm pretty sure it's not its fault.

You could be correct about that. Because of all the cheating that used to go on through steam in its older days I wouldn't be suprised if it would have issues with unusual things in memory from all the added protection. Maybe if I tried on a non VAC server?

Now by log I'm hoping you mean the plugin's log. I can't give exact times that it happens, but I can give you a recent version of the log: http://masterofdeath.vectec.net/xmp-scrobbler.txt

pupil · « **Reply #118 on:** 30 May '06 - 18:49 »

Hi there,

I got a bug I just found. It's definitely something with the Scrobbler Plugin as when I disable it, it doesn't happen.

Basically after about 30 seconds into the track (I guess once its submitting/submitted the song) if I try and open an explorer window via the start menu (ie open my C/D/E whatever drive) the explorer window won't appear until I either turn off XMPlay or stop the current track from playing, then the explorer window will spring up. Odd. I've recreated it each time, so its not a one off. I shut down XMPlay as soon as it did it last time, and here is what was written to my scrobbler log file in the last minute before it happened:

2006-05-30 18:41:22   [DEBUG] DSP_Process -- sec <= 0
2006-05-30 18:41:22   [DEBUG] XMP_SubmitProc (bProcessed = 0)
2006-05-30 18:41:22   [DEBUG] XMP_InitDde
2006-05-30 18:41:22   [DEBUG] XMP_InitDde -- after DdeInitialize (instID = 167776386)
2006-05-30 18:41:22   [DEBUG] XMP_SubmitProc -- after XMP_InitDDE
2006-05-30 18:41:22   [DEBUG] XMP_GetChannelData
2006-05-30 18:41:22   [DEBUG] XMP_GetChannelData -- after DdeCreateStringHandle (instID = 167776386, hszService = 49153)
2006-05-30 18:41:22   [DEBUG] XMP_GetChannelData -- after DdeCreateStringHandle (instID = 167776386, hszTopic = 49154)
2006-05-30 18:41:22   [DEBUG] XMP_GetChannelData -- before DdeConnect (instID = 167776386, hszService = 49153, hszTopic = 49154)
2006-05-30 18:41:22   [DEBUG] DdeCallback (uType == 33010, uFmt = 0)
2006-05-30 18:41:22   [DEBUG] XMP_GetChannelData -- after DdeConnect (hconv = 201332098)
2006-05-30 18:41:22   [DEBUG] XMP_GetChannelData (id = 167776386, ch = info1, hconv = 201332098, hdata = 251665154, hszService = 49153, hszTopic = 49154)
2006-05-30 18:41:22   [DEBUG] DdeCallback (uType == 33010, uFmt = 0)
2006-05-30 18:41:22   [DEBUG] XMP_SubmitProc -- after XMP_GetChannelData (size = 105)
2006-05-30 18:41:22   [DEBUG] XMP_SubmitProc -- after XMP_FreeDDE
2006-05-30 18:41:22   [DEBUG] XMP_ParseTrackTags
2006-05-30 18:41:22   [DEBUG] XMP_SubmitProc -- after XMP_ParseTrackTags
2006-05-30 18:41:22   Submitting track: Spank Rock - IMC (Yoyoyoyoyo)...
2006-05-30 18:41:22   Submitting cache...
2006-05-30 18:41:22   ...
2006-05-30 18:41:32   The server reported a processing error.
2006-05-30 18:41:32   HTTP/1.1 503 Service Unavailable

2006-05-30 18:41:38   [DEBUG] xmptd.rate = 0
2006-05-30 18:41:38   [DEBUG] xmptd.chans = 0
2006-05-30 18:41:38   [DEBUG] DSP_StopTrack
2006-05-30 18:41:39   [DEBUG] DSP_NewTrack (CLOSE)
2006-05-30 18:41:39   [DEBUG] DSP_Free()

Any idea what's happening, it's isn't something I'm doing wrong is it?

Dotpitch · « **Reply #119 on:** 30 May '06 - 19:11 »

Quote from: pupil on 30 May '06 - 18:49

Basically after about 30 seconds into the track (I guess once its submitting/submitted the song) if I try and open an explorer window via the start menu (ie open my C/D/E whatever drive) the explorer window won't appear until I either turn off XMPlay or stop the current track from playing, then the explorer window will spring up.

Well... I've got the same thing

. Win+E takes about 8~10 minutes to launch, in the meantime my desktop won't refresh (yes, annoying). Running explorer.exe does work immediately. I do not have the HTTP 503 error though.
For the rest, perfect plugin

.

pupil · « **Reply #120 on:** 30 May '06 - 19:19 »

I'm glad it isn't just me then

I was a little worried it may be to do wit hthe HTTP/1.1 503 Service Unavailable as well, so kept testing and it still did it when the track was successfully submitted. Observe:

2006-05-30 19:11:20   [DEBUG] DSP_Process -- sec <= 0
2006-05-30 19:11:20   [DEBUG] XMP_SubmitProc (bProcessed = 0)
2006-05-30 19:11:20   [DEBUG] XMP_InitDde
2006-05-30 19:11:20   [DEBUG] XMP_InitDde -- after DdeInitialize (instID = 603985028)
2006-05-30 19:11:20   [DEBUG] XMP_SubmitProc -- after XMP_InitDDE
2006-05-30 19:11:20   [DEBUG] XMP_GetChannelData
2006-05-30 19:11:20   [DEBUG] XMP_GetChannelData -- after DdeCreateStringHandle (instID = 603985028, hszService = 49153)
2006-05-30 19:11:20   [DEBUG] XMP_GetChannelData -- after DdeCreateStringHandle (instID = 603985028, hszTopic = 49154)
2006-05-30 19:11:20   [DEBUG] XMP_GetChannelData -- before DdeConnect (instID = 603985028, hszService = 49153, hszTopic = 49154)
2006-05-30 19:11:20   [DEBUG] DdeCallback (uType == 33010, uFmt = 0)
2006-05-30 19:11:20   [DEBUG] XMP_GetChannelData -- after DdeConnect (hconv = 637541764)
2006-05-30 19:11:20   [DEBUG] XMP_GetChannelData (id = 603985028, ch = info1, hconv = 637541764, hdata = 687874820, hszService = 49153, hszTopic = 49154)
2006-05-30 19:11:20   [DEBUG] DdeCallback (uType == 33010, uFmt = 0)
2006-05-30 19:11:20   [DEBUG] XMP_SubmitProc -- after XMP_GetChannelData (size = 836)
2006-05-30 19:11:20   [DEBUG] XMP_SubmitProc -- after XMP_FreeDDE
2006-05-30 19:11:20   [DEBUG] XMP_ParseTrackTags
2006-05-30 19:11:20   [DEBUG] XMP_SubmitProc -- after XMP_ParseTrackTags
2006-05-30 19:11:20   Submitting track: James Lavelle - Tribal Gathering '96 (Disc 3) (Tribal Gathering '96)...
2006-05-30 19:11:20   Submitting cache...
2006-05-30 19:11:20   ...
2006-05-30 19:11:21   Submission succeeded.
2006-05-30 19:11:21   Submit interval set to 1 second(s).

??!

pupil · « **Reply #121 on:** 30 May '06 - 19:26 »

Oh and here is something else (you can tell I've been off work and playing with this all day can't you!) I have a couple of mix sets ripped as single mp3's with cue sheets giving track details. Scrobbler submits the name of the MP3 ( ie "ARTIST=James Lavelle , TRACK=Tribal Gathering '96 (Disc 3)" but not the individual tracks/artists that the CUE sheet is displaying. Any chance of supporting this, it worked ok with the QCD Plugin, but the CUE QCD Plugin works very differently to XMPlay as far as I can make out.

yagood · « **Reply #122 on:** 30 May '06 - 20:30 »

I've just reproduced the issue with explorer.exe hang and it's a bug, right now I don't know exactly what's causing it, but thanks for reporting.

Quote from: pupil on 30 May '06 - 19:26

Oh and here is something else (you can tell I've been off work and playing with this all day can't you!) I have a couple of mix sets ripped as single mp3's with cue sheets giving track details. Scrobbler submits the name of the MP3 ( ie "ARTIST=James Lavelle , TRACK=Tribal Gathering '96 (Disc 3)" but not the individual tracks/artists that the CUE sheet is displaying. Any chance of supporting this, it worked ok with the QCD Plugin, but the CUE QCD Plugin works very differently to XMPlay as far as I can make out.

That depends on how XMPlay handles CUE sheets. I don't have one on my PC right now so I can't test it, but I'll put it on my to-do list, because it would be nice to have such feature. The thing always the same - if XMPlay fills "Message" window fields correctly with artist, title and (optionally) album name - xmp-scrobbler can submit it, so please check it first. Of course handling one big MP3 with many tracks in it would be more complicated, because xmp-scrobbler probably would have to check periodically for tag fields changes, but it can be done. However, there are few things with higher priority on my to-do list so be patient.

pupil · « **Reply #123 on:** 30 May '06 - 20:40 »

Quote from: yagood on 30 May '06 - 20:30

I've just reproduced the issue with explorer.exe hang and it's a bug, right now I don't know exactly what's causing it, but thanks for reporting.

cool, no worries, glad you could reproduce it.

Quote from: yagood on 30 May '06 - 20:30

That depends on how XMPlay handles CUE sheets. I don't have one on my PC right now so I can't test it, but I'll put it on my to-do list, because it would be nice to have such feature. The thing always the same - if XMPlay fills "Message" window fields correctly with artist, title and (optionally) album name - xmp-scrobbler can submit it, so please check it first. Of course handling one big MP3 with many tracks in it would be more complicated, because xmp-scrobbler probably would have to check periodically for tag fields changes, but it can be done. However, there are few things with higher priority on my to-do list so be patient.

Hmmmm, thinking about it, CUE files are treated in the same way that subsongs are in MOD/SID files etc, so you might not be able to do it. You'll have to play around with a CUE file, it does display the artist/track names in the message window, but seemingly not in a way that the Scrobbler plugin would recognise easily to submit. But anyways, just would be nice to have it implemented, not a high priority request from me, I only have a couple CUE sheet Mp3's, so its not something I use very much. In your own time

Thanks again.

hukka · « **Reply #124 on:** 30 May '06 - 21:18 »

Does this thing not support Ogg Vorbis or something? I'm getting both "Track is badly tagged (artist/title not available)" and "Track is too short to submit it (must be at least 30 seconds long)" on a 4-minute Ogg Vorbis file.

(EDIT: oddly, it first complained the same as above on another 4-minute Ogg but at around 3:20 in it actually did submit the song into Audioscrobbler. Something's weird here...)