cpd73 wrote: > OK, waitingToPlay is not the issue. If Material detects this, it will > manually ask for a status update 1 second later - to see if the stream > has started playing. This should happen every second whilst > waitingToPlay. Looking at the log I see: > > > > > - [12:47:08] "Eric Clapton" track waitingToPlay, and its current > posiiton set to 0 (-"time":0-) Because this track is waitingtoPlay, > Material schedules a status update for 1 second later - [12:47:09] 1 second timer has fired, and a forced status update > is requested. (You can see -[forced]-). Now the track has changed to > "Sorten Muld". Again this is waitingToPlay, with its current > position 0 (so at start of track). Meterial schedules another status > update - [12:47:22] Now the second forced update is processed. > > > > > So, something is a bit odd. A 1 second timer took 13 seconds to fire. > Now I know Javascript timer resolution is deliberately bad - but not > that bad. Unfortunately the timestamps are when the status is > received, not when asked for - so it could be that LMS took 12 seconds > to process the status update request. > > Is your LMS configured to locally resize images, or is mysquezebox > being used? Can you look at your browser's Network tab (in developer > tools), and see if there is a long running network request whilst this > is happening.
Anything here? Using mysqueezebox resizing. 27523 +-------------------------------------------------------------------+ |Filename: Capture.JPG | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=27523| +-------------------------------------------------------------------+ ------------------------------------------------------------------------ slartibartfast's Profile: http://forums.slimdevices.com/member.php?userid=35609 View this thread: http://forums.slimdevices.com/showthread.php?t=109624 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
