SamY wrote: > Here is the log file with 2.1.12.1. Not using "underrun". I decided to > let the whole album play this time. As you will see, the read errors all > occur within a few seconds of 2 minutes (not 3) after the beginning of a > new track and are completely and predictably repeatable, i.e. if I play > the same album again, the track skips will occur at the same place in > each track. Also note that the skips don't begin happening until the > second track, then happen on four straight tracks, then take a break, > etc. As I said, completely repeatable. Did you read the link I sent > earlier about CC connections timing out after 2 minutes? Is it perhaps > related? Let me know what else I can do to help. As noted by @bwaldron, > the skips don't occur when using "underrun". > > EDIT: Here is the link I was referring to: > https://community.openhab.org/t/chromecast-binding-connection-times-out-every-2-minutes/121751
Thanks. Its is not a timeout that comes from the bridge to CC connection, but from the bridge to LMS and that also happens with UPNP devices. The CC timeout is a different thing and in fact you need a specific keep-alive (ping) for CC exactly for that reason and I have implemented it. I will re-read the logs, but AFAIR it was a 3 mins timeout. These are difficult to read due to the way the data pipeline works, Ill edit one log to show it. The fact that it does not happens on first track is also fully consistent with that hypothesis as well as the fact that underrun solves it. Underrun does the following: it waits until the CC/UPnP device reports track had stopped before querying LMS for the next track. This way, you always have a continuous flow of stream once a device starts playing a given track. The bridge gets the data from LMS, puts it in a multi-level pipeline and then forwards it to the CC/UPnP device when asked to. Bridge get as much as it can from LMS, fills its buffer and waits for player to consume data. As soon as a player pulls a bit from the pipeline, it is refilled by pulling some from LMS. In normal mode, the bridge queries LMS for track N+1 as soon as the track N as been entirely stored in internal buffers, and that includes what the CC has gobbled up. So, depending on format uses, you have a burst of data download from LMS of track N+1 pretty early while playing track N to fill up the pipeline, but the player will only query track N+1 after it has ended track N ((for CC and some UPnP) so you have a long period during which the streaming of track N+1 between LMS and the bridge stops. Then it resumes when the players queries N+1 and starts emptying the pipeline. The issue happens during that pause. Now, if the track N+1 is small enough, that does not happen as it is entirely in the pipeline during the initial data download burst. If you use flac, it does not happen because streaming track N takes much more time and there is no case where the CC has all the data it needs for an extended period of time. What Im totally failing to figure out is why, in some cases and only on Windows such idle period causes it to shut off the connection. I know that underrun solves that problem for CC but it is a disaster for UPnP when you need gapless and even in CC it might fairly increases the gap between tracks. Ill setup a dedicated Win10 machine, can you share your tracks? LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=104614
_______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
