slartibartfast wrote:
> Here is a cometd status log snippet.
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.
------------------------------------------------------------------------
cpd73's Profile: http://forums.slimdevices.com/member.php?userid=66686
View this thread: http://forums.slimdevices.com/showthread.php?t=109624
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
