mherger wrote: > > From further experiments the artwork falls a track behind after the > > first Spotify track in a playlist which is long enough to allow the > HDD > > to sleep. If another long Spotify track appears later in the playlist > > then the artwork does not fall further behind but remains a single > track > > behind. > > That might explain why I've never seen it on my dev system: it's all > SSD. But it wouldn't explain why I saw it on my main system (with the > "ghost" track), as that's a busy NAS which never puts disks to sleep. > That said I've seen slow response times when it's really busy. > > The other system OTOH is an old NAS connected to pCP. That one would go > to sleep. I'll give that a try for more reproducible results. > > -- > > MichaelBefore the HDD sleep theory was mentioned I was doing some testing on a Windows 10 server with local music on the internal HDD and couldn't trigger the issue by adding Spotify tracks which makes sense as the HDD wouldn't be sleeping. On the Pi I can see the HDD waking up before the end of the Spotify track. Obviously in normal use if I start a new playlist when the HDD is sleeping the artwork and track info of the first track is correct so why is that situation different to this one?
Sent from my Pixel 3a using Tapatalk ------------------------------------------------------------------------ slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=112623 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
