Documentation for the Chrome API states that changes to the following
properties will trigger a listener registered against Media.addUpdateListener:
- currentTime
- volume
- metadata
- playbackRate
- playerState
- customData
Additionally, the docs state that:
"Instead of calling [getStatus], apps should prefer relying on the automatic
invocation of media update listeners."
However, listeners on addUpdateListener() get called sporadically at best, and
in some cases not at all. In many cases it seems that in order for the SDK to
even be aware of a state change, you *must* call getStatus() - essentially
manually invoking the status listener - and prod the SDK into realising
something has changed.
This does not make for a great development experience.
A simple reproduction of this is to register a listener against a Media object
containing an audio track, and play that track. Playing a track will change the
currentTime. Changes to currentTime are documented as invoking the listener.
The listener is not invoked.
Although currentTime is listed as deprecated, this illustrates the problem
perfectly (and at the very least currentTime should not be listed as a
trigger).
A more elaborate setup description is available here:
http://stackoverflow.com/questions/32223498/google-cast-detect-queueitems-that-f
ail-to-load - The setup is different but the problem is the same: the system
state is not synced until a call to getStatus.
This behaviour is observed running a cast sender app in Chrome on Debian,
Ubuntu and Windows 8.1.
The problem occurs both against a styled media receiver and when casting to
audio-only devices.
The problem has been present for at least the last 3 months and is still
present in the latest Cast Beta Extension (15.827.0.6).
Original issue reported on code.google.com by hims...@duncanhall.net on 8 Oct 2015 at 10:07
Original issue reported on code.google.com by
hims...@duncanhall.net
on 8 Oct 2015 at 10:07