I have noticed for some years that a playing URL/track as understood by the web GUI is not necessarily the same as a playing URL/track as understood by a Squeezeplay/Jive based player.
Essentially, the web GUI seems to look at what I might call a 'resolved' url/track/playlist object, that is the underlying stream that an intermediate 'playlist' url/playlist object drives us down into. Whereas a Squeezeplay player (and I think ip3k) stays with that 'playlist' url/object. Under the hood, this probably reflects which particular track object is being looked at. In consequence, context menus, track info, and the like can give a different result in the web GUI as compared with a Squeezeplay player, because they look at different track objects. I've noticed this, in particular, in the context of the BBC iPlayer plugin, which I think has a number of 'fixes' worked in over the years to deal with some of these issues. Perhaps this behavioural difference is contributing. I've often thought that it might be, or might have been, a 'good idea' to have track objects carry with them a 'canonical' url, that retains its identity regardless of the particular underlying stream being played out. That might then have been used to unambiguously identify the identity of a stream. Probably too difficult to 'retro fit', even if it is seen as a 'good idea'. Or perhaps Squeezeplay/Jive has got it right, and the web GUI is simply looking at the 'wrong' object. ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=110714 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
