I don't know whether the error I posted above (se previous post) is the same that spacefish and mil are having, but my player also says "conection times out" (while the error message abowe is from the phyton command line (or whatever it's called)). However, I solved my problem by replacing line 451 (lastfmproxy-1.0.3) in the following way:
In my case host[1]=83 before, and for some reason 80 works better. I have no idea why this works, and don't really know what these numbers means at all (could someone explain?), but it's perhaps worth a try to change it.
Quoth oding:
I don't know whether the error I posted above (se previous post) is the same that spacefish and mil are having, but my player also says "conection times out" (while the error message abowe is from the phyton command line (or whatever it's called)). However, I solved my problem by replacing line 451 (lastfmproxy-1.0.3) in the following way:
I'm running 1.1a5 myself and because it's integrated into Windows XP, I don't see any of the error messages, only what's reported to Winamp (5.2). In my case, "Timed Out".
I'm actually sort of dreading switching to the player itself since I have integrated the proxy. The directions for integration are great and I had no problems doing that but there are no directions to switch back to the player so I'll probably be struggling with that if vidarino doesn't get this fixed.
Oh, and the proxy's not working this morning either. I can run the player and skip, love, ban through the proxy window though. I guess that's doable for now. The sound sucks though because it doesn't play through Winamp. I guess I should upgrade the player now that have to use it. Maybe I can use the external player feature there.
My winamp also said "Timed out", and I was also able to run the player through the proxy window, so it absolutely seems like you have the same problem as I used to have.
And, after I changed the line, everything works perfectly. In 1.1a5 it should be line 475, and replace like this (and then restart main.py)
Hmmm... all of a sudden, the proxy stopped working mid-song. Winamp just stopped playing. The player works but the proxy doesn't now. Works most of the time is good but dang, I wish this was fixed once and for all. :/
Weird method: ['PROPFIND', '/last.mp3/', 'HTTP/1.1\r']
Weird method: ['HEAD', '/last.mp3', 'HTTP/1.1\r']
Weird method: ['HEAD', '/last.mp3', 'HTTP/1.1\r']
Exception in thread Thread-5:
Traceback (most recent call last):
File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "./main.py", line 475, in gotconnection
streamsock.connect((host[0], host[1]))
File "<string>", line 1, in connect
error: (111, 'Connection refused')
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "./main.py", line 61, in metadataloop
self.checkmetadata()
File "./main.py", line 43, in checkmetadata
if not self.lastfm.getmetadata():
File "/home/alexis/lastfmproxy-1.1alpha5/lastfm.py", line 60, in getmetadata
s.req(self.info["base_path"] + "/np.php?session=" + self.info["session"])
File "/home/alexis/lastfmproxy-1.1alpha5/httpclient.py", line 41, in req
s.connect((self.host, self.port))
File "<string>", line 1, in connect
gaierror: (-2, 'Name or service not known')
proxy seemed to be working fine last weekend, then when i went to work monday morning and fired up mpg123, nothing. same when i got back home and tried it in amarok and it crashes amarok when i try to connect.
I also got the "connection refused/connection time out" problem back yesterday, so I tried to edit host[0] in the same way as I did to host[1], so before it was
host[0]="streamer2.last.fm" and host[1]=83
And when I change to
host[0]="streamer1.last.fm" and host[1]=80
it works. So now I added the lines
host[0] = "streamer1.last.fm"
host[1] = 80
just before the line 'streamsock.connect((host[0], host[1]))' in line 475 or 451 depending on the version. But, of course I've no ide how long this will work either. It would have been nice if someone with some more insight in the program, perhaps vidarino, could try to explain why one have to to do this changes in the host[0] and host[1].
I tracked down the source of the port 83, and it's last.fm itself that is reporting that port. It's either a bug somewhere or a crashed streamer.
Not really sure how this applies. Anyone else having problems now?
This applies to the problem because we now know that the problem is not in the lastfmproxy, but in the data that last.fm returns to the client or in a service within last.fm. This means that there is no point in patching the client to get around this.
Quoth ressu: I tracked down the source of the port 83, and it's last.fm itself that is reporting that port. It's either a bug somewhere or a crashed streamer.
Not really sure how this applies. Anyone else having problems now?
This applies to the problem because we now know that the problem is not in the lastfmproxy, but in the data that last.fm returns to the client or in a service within last.fm. This means that there is no point in patching the client to get around this.
Oh, that sounds disappointing, since I doubt last.fm will do anything anything to accommodate us proxy users. I mean, the stream still plays in the player so what's there to fix? :(
Quoth spacefish:
Oh, that sounds disappointing, since I doubt last.fm will do anything anything to accommodate us proxy users. I mean, the stream still plays in the player so what's there to fix? :(
Well, since it appears that the player usually gets redirected to streamer1 anyway, it might be that there is a problem in streamer2. I'm not sure though.
I mentioned this in IRC and someone said that they were going to mention this to someone else.. Or something (i was in a hurry). I'll check back in IRC later today.
the official player requests the metadata from ws.audioscrobbler.com while the proxy defaults to wsdev.audioscrobbler.com, this is what is causing the breakage. apparently wsdev is currently returning some testing data.
So it turns out lastfmproxy was to blame after all, but so was last.fm ;)
EDIT: fixed the line number and a typo, never do anything in a hurry.
the official host requests the metadata from ws.audioscrobbler.com while the proxy defaults to wsdev.audioscrobbler.com, this is what is causing the breakage. apparently wsdev is currently returning some testing data.
So it turns out lastfmproxy was to blame after all, but so was last.fm ;)
Will test this this morning. Thanks mate !
Seems to be working although I'm getting a lot of buffering in the stream. Perhaps that's just a dodgy streaming server and not related to the proxy fix.
mll: Thanks (goes for both the message and the congratulations). :)
Great to see that the mystery has been solved! I'll fix and release a new version shortly. Since has been the only bug worth mentioning in quite some time, I'm going to dub it 1.1 final and we'll see how it goes. :)
Big thanks to the testers and investigators.
Vidar
Tune in to the last.fm radio with any player: LastFMProxy
the official host requests the metadata from ws.audioscrobbler.com while the proxy defaults to wsdev.audioscrobbler.com, this is what is causing the breakage. apparently wsdev is currently returning some testing data.
So it turns out lastfmproxy was to blame after all, but so was last.fm ;)
Will test this this morning. Thanks mate !
Have tested it for 3 hours, worked without a glitch. I personnaly consider the bug closed (and will gladly listen to some long-awaiting tag radios). Thanks a lot ressu !
Quoth vidarino:
Since has been the only bug worth mentioning in quite some time, I'm going to dub it 1.1 final and we'll see how it goes. :) There's still the bug that it doesn't display track information for the current track after you've loved a track…