'trackschanged' event not fired correctly for multi-Period content #680
Assignees
Labels
status: archived
Archived and locked; will not be updated
type: bug
Something isn't working correctly
Milestone
Comments
shaka-bot
pushed a commit
that referenced
this issue
Feb 6, 2017
Before, we would fire a 'trackschanged' event when StreamingEngine asked us to select streams for a new Period. However, this is not when the tracks change, they change when the playhead moves into a different Period. This adds code to Playhead to track where the current Period is and raise an event when it changes. This also reduces any extra events so a 'trackschanged' event is only fired when the tracks actually change. Issue #680 Change-Id: I85aedaed737f9324d5871201d952066886ea290c
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The
trackschangedevent from the Player doesn't fire at the correct time WRTplayer.getTracks(). Currently, it fires when StreamingEngine handles a Period transition and starts buffering content from that Period. However,player.getTrackswill return tracks based on the current playhead position. This means that when the event fires, the tracks returned haven't actually changed and will change once the playhead moves. This also means that if you seek backwards into a different buffered Period, the event will not fire.Another side effect of this is that while the playhead is in the old Period and StreamingEngine is buffering from the new Period, the
tracks.activefield is not correct. Theactivefield is determined from the current streams in StreamingEngine; this means that while the playhead is in a different Period, there will be noactivetracks. The demo app currently throws errors because of this.The text was updated successfully, but these errors were encountered: