Are you using icecast _and_ slimserver? i.e. slimserver streaming to icecast and then icecast to the player? If so, I would bet money the buffer causing you problems is on the input side of icecast.
> > So it's not a buffer misbehaviour, it's the server waiting from the > player acknowledgment to execute the command! :-) No, the server doesn't know (or care) what the client is doing. When you press play on the client it will disconnect and reconnect, that disconnection will flush any buffers between you and the source. > > when you kill the server process (either slimserver.pl or slim.exe) the > clients keep playing!!! > They're emptying their client side buffers, which can be quite large. When the server "goes away" the player assumes it's a network glitch and keeps playing, hoping the server will come back. After some time (after the buffer empties) it gives up. > Hence Slimstream does not stream files! It just streams the > synchronization and the commands to the players to get the proper > files! > (and this is why there's no 8 seconds problem with > SoftSqueeze/SqeezeBox). I don't know what slimstream is, but all data is streamed from slimserver for all player types, there is no direct file access at all. The reason there's no "8 second problem" with slim players is that they use a different, much more sophisticated streaming protocol with the ability for the server to directly control the player. HTTP streaming (icecast) offers no such control. -- radish ------------------------------------------------------------------------ radish's Profile: http://forums.slimdevices.com/member.php?userid=77 View this thread: http://forums.slimdevices.com/showthread.php?t=23623 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
