On 06/02/2008, John Stamp <[EMAIL PROTECTED]> wrote: > On Monday 04 February 2008, Eddy Petrișor wrote: > > Currently I am listening (trying to) to Lu_beck's Radio Station. I am > > 995 sure the songs can be identified from the log (snapshot made after > > listening one sone and a little from the second) ;-) . > > Thanks for the log file. That second song shows that it took a while (3 > seconds) for your buffer to initially fill up enough to play, then it > emptied a couple of times in the first 6 seconds. Wow. That does look > bad. > > > Ok, I went back to that version, then even further, now I have ended up > > using the ancient 1:1.1.3.0-1 which doesn't stop in an annoying fashion. > > It plays without interrupts. > > > > Maybe there was a protocol change recently? > > It is interesting that 1:1.1.3.0-1 works, because last.fm did indeed > change the protocol. The old protocol delivers all of a station's songs > as a single stream. The current protocol streams each song individually > (i.e. there is a new HTTP GET request for each song). It's not a recent > change though. That happened with 1:1.3.0.58-1 back in June 2007!
I must have changed the client around that date (I remember using last-exit for a while), then I came back to lastfm somewhere around November or maybe earlier, but I didn't have these issues. I have discovered and installed shellfm sometime around the end of Novemeber, but I remember having interruption issues with it. I *think* wasn't experiencing issues with lastfm while I was with shellfm (it resulted in some weird alsa errors - i thought shellfm was broken). > I think that last-exit also uses the old protocol, so that's probably > why it doesn't give you buffering problems: neither last-exit nor > 1.1.3.0 send a new request on each new song. > > Shell-fm in testing/unstable uses the new protocol. Do you have > buffering problems when you use that? (Check Last.fm's conf file for a I was, last time I checked. Maybe it takes too much to open a new connection? Maybe lastfm closes the stream after buffering, instead of keeping the connection open, so it takes time to reopen again the stream? Is there a way to preemptively start the buffering when the buffer reaches a certain threshold (maybe modify that somehow)? Is it possible to request the usage of the old protocol in the current version? > url to use.) If so, then I suspect a problem between your box and their > servers. Maybe wireshark could shed some light on this. If not, > then... I think it would be interesting to see if I can preemptively ask for buffering. > > I am confused... > > Me too. In spite of all things, if each song is in a different stream, wouldn't that mean, even in worse case scenario, that there shouldn't be any interruptions during one same song or, at worst, the buffer fill ratio would tend to reach 0, but would be filled back again immediately? Still confused. P.S.: I'll try to find out if I can detect/deduce the date when I installed shellfm (but I doubt it with the log rotation of aptitude and me using noatime). -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein
