troffasky wrote: > I am checking the state of the connection between LMS and whatever the > stream is coming from. This was in response to Redrum's supposition that > the issue is caused by this leg of the connection timing out.
I think LMS notes the "last position" by the info coming back from slimproto as a player may have a huge internal buffer (or a highly compressed very low bit rate MP3 stream) and yet have only played a fraction of it - it is the duration of the fraction played that should be recorded as the "last position" and not the amount received and so the state of the audio connection may not be relevant if all audio data has been downloaded into the player. I think to be certain, you need to validate by enabling LMS logs. I think if a stream is paused and it is not a "live" stream (i.e. a known limited duration) - LMS will hold data buffer but the source may close the TCP connection if data does not move within a time period. If connection is closed LMS will hold the "last position". Depending on the source (i.e. HTTP server with an ability to start at a Byte offset) - the stream may be resumed at the byte offset. *Not all sources can do this.* IIRC Podcast mechanism depends on being able to request a byte offset from a HTTP server. Phillippes build on this with caches in memory or on disk but it may be reliant on HTTP server capabilties. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=115999 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
