On Wednesday 06 February 2008, Eddy Petrișor wrote:
> > 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?
Using the current protocol, whenever the client wants to play a new song
it requests it from play.last.fm. The host returns an HTTP 302 which
points to a stream server in a pool. The client then connects to the
stream server and starts playing. As you might then expect, you get a
different server for each song, and the server closes the connection
when the song is done. (If it makes a difference, the current
protocol's streamers reply with HTTP/1.1)
This is partly why I suspect the servers or network problems and why I
think that wireshark or some other traffic analyzer might help us
diagnose this.
> Is there a way to preemptively start the buffering when the buffer
> reaches a certain threshold (maybe modify that somehow)?
Would you mind explaining this a bit? I'm not quite sure what you mean.
Here's how it currently works: The stream server sends a burst of data
at the beginning to quickly fill the client's buffer and then sends a
steady 16.9KB/s stream. The client's auto-managed buffer starts at
16KB and gradually increases whenever it gets completely emptied. But
generally you only have a couple seconds of mp3 data buffered at time.
What change are you proposing? Buffering one song while it plays
another?
> Is it possible to request the usage of the old protocol in the
> current version?
As for the old protocol, I don't think there will be much luck
requesting it. I'm in the U.S., and I can't even get last-exit or
client version 1.1.3.0 to play anymore. Amarok streams last.fm stations
but it can't skip. Maybe support for the old protocol varies from
location to location? I really don't know. But see below...
> > 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?
Thus my confusion. I assume that you don't have other network problems,
so I don't know why it fails to deliver a mere 16.9KB/s stream.
> 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).
I'd personally be interested in whether or not wireshark shows anything
interesting. From all that you tell me it looks like whenever you use
the current protocol's servers, songs don't stream, they "dribble."
But if a traffic analyzer tells you nothing, then we still haven't ruled
out much. It is one of the frustrating things about streaming clients.
There are many places where things can go wrong. We really need to
isolate the problem if we can:
1. Are you getting a 16.9KB/s stream when the client has buffering
problems?
2. Does the client have problems on a different computer in the same
network?
3. Do you have fewer problems if your laptop streams lastfm on another
network: at work, at a café, at a friend's house, etc? What if you
commandeer your friend's computer and stream from that?
4. Do certain times of the day seem worse than others?
5. Do you see a pattern of bad behavior with particular servers?
6. Can you think of any other tests? ;-)
If after all that we're still confused, then I'll forward this upstream
with your requests. But the more we rule out now, the less likely it
becomes that upstream will just shrug their shoulders.
Cheers,
John
