Media time not updated in Cast Receiver

[cdongieux]

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
The version from the Demo app page: https://shaka-player-demo.appspot.com/ (v2.5.7)

Can you reproduce the issue with our latest release version?
v2.5.7 is the latest release version

Can you reproduce the issue with the latest code from master?
Yes

Are you using the demo app or your own custom app?
Demo app

If custom app, can you reproduce the issue using our demo app?
N/A

What browser and OS are you using?
79.0.3945.88 (Build officiel) (64 bits) (cohort: 79_Win_88)
Windows 10 OS Version 1909 (Build 18363.535)
NVIDIA SHIELD as Cast Device

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?
I use the Demo app videos (Big Buck Bunny, Angel One, Sintel)

What did you do?

• open https://shaka-player-demo.appspot.com/
• click PLAY on one of the videos (Big Buck Bunny, Angel One, Sintel) => video starts
• click on the "3 dots" button on the player UI
• select "Cast..."
• select the device => video pauses in the browser, video playback starts on the selected device, progressbar / play-pause button / media time UI are displayed on the Receiver

What did you expect to happen?
Media time UI on the Receiver should grow like it does on the Sender

What actually happened?
Media time UI is displayed on the Receiver but stays at "0:00"

[theodab]

Hm, you're right. When we added the UI, it broke a lot of stuff in the Chromecast receiver. This must be a problem we missed.
Thanks for the report!

[theodab]

Actually, on further inspection, it looks like this has been fixed already. I'm not entirely sure what commit is responsible, but trying out a version of the cast receiver synched up to master, this problem is no longer present.
At the moment, the only publicly hosted version of the cast receiver is still running a v2.5.7 build, where this bug was still present. But when we release a version with whatever CL fixed this problem, the public cast receiver build will be fixed.
So, if this issue is a problem for you, you can just host your own cast receiver in the meantime. I mean, I presume you want to anyway, so that it doesn't have Shaka Player branding all over it.

[joeyparrish]

Until we can identify the change and cherry pick it to the v2.5.x release branch, this issue should remain open.

[joeyparrish]

It's difficult to git bisect the cast receiver, since it has to be deployed to appspot to test. Our deployment tools work well with tags, though, so I'll start by testing all the -master tags for each release, back to the v2.5.x branch point. That should narrow down where the fix occurred.

[joeyparrish]

In these tests, I deployed a copy of both sender and receiver to appspot, with the receiver app ID set to load from this particular appspot URL. I had the expiration time turned down to 1s to make sure I wasn't getting the wrong version due to caching, and I further modified the receiver app with a high-z-index div showing the deployed version number. So I'm sure that I was testing what I intended to test. :-)

Release tags:

• v2.5.0 - working as expected
• v2.5.1 - can't cast at all
• v2.5.2 - can't cast at all
• v2.5.3 - can't cast at all
• v2.5.4 - receiver UI timestamp and seek bar do not update
• v2.5.5 - not tested
• v2.5.6 - not tested
• v2.5.7 - receiver UI timestamp and seek bar do not update

Corresponding master branch tags:

• v2.5.0-master - no such tag (v2.5.0 released from master)
• v2.5.1-master - can't cast at all
• v2.5.2-master - receiver UI timestamp and seek bar do not update
• v2.5.3-master - receiver UI timestamp and seek bar do not update
• v2.5.4-master - receiver UI timestamp and seek bar do not update
• v2.5.5-master - receiver UI timestamp and seek bar do not update
• v2.5.6-master - receiver UI does not show up at all
• v2.5.7-master - receiver UI does not show up at all
• 17473d5 (latest in today's master branch) - working as expected

[joeyparrish]

So it seems that we broke something between v2.5.0 and v2.5.1, both in the master branch and the release branch. We then broke something else (no receiver UI at all) in the master branch between v2.5.5-master and v2.5.6-master. We fixed that second bug (no receiver UI) between v2.5.7-master and now, and the first bug (this issue) was fixed between v2.5.5-master and now.

That's 160 commits, about 82 of which haven't already been cherry-picked to the master branch. Of those 82, only 27 affect the folders that could influence the cast receiver UI (lib/cast/, demo/cast_receiver/, and ui/).

Here are the shell commands I used to figure out which commits are interesting:

git log v2.5.5-master..master --oneline > master.log
git log v2.5.5..v2.5.7 --oneline > release.log
wc -l master.log

cat master.log | while read sha msg; do
  grep -q "$msg" release.log || echo "$sha $msg"
done > maybe.log
wc -l maybe.log

cat maybe.log | while read sha msg; do
  # If the git log for those folders starts with the same commit hash,
  # then that commit affected those folders.
  git log --oneline -n 1 "$sha" -- lib/cast/ demo/cast_receiver/ ui/ \
    | grep -q "^$sha" && echo "$sha $msg"
done > affecting-cast.log
wc -l affecting-cast.log

[joeyparrish]

The second bug (missing receiver UI) was fixed this week in the trio of commits: a43f52c 08a36e8 a6b159f. With those cherry-picked and merge conflicts fixed manually, these are the results:

v2.5.6-master + cherry-picks - working as expected
v2.5.7-master + cherry-picks - working as expected

So the first bug (this issue) was fixed in master between v2.5.5-master and v2.5.6-master.

Applying the same shell scripts above to that range, I wind up with a list of 12 commits that might have fixed it, 11 of which are about ads:

0f6e973 Play/pause the current ad on video container click.
d47362a Integrate play button icon change with ads and fix fade out.
8fff915 Toggle ad's fullscreen mode when document.fullscreen changes.
688d888 Change controls behavior when an ad is playing.
8d45673 Change ad controls CSS according to designer's feedback.
02847e3 Show ad controls and update ad counter when ad starts.
04cf013 Add ad messages to the localization strings.
7afac89 Restructure AdManager to be owned by Player, not UI.
2628359 Make sure ad UI stays visible when other controls fade out.
f485772 Add ad elements to the UI layout.
c2105a3 Lay the ground for the Ad Insertion work.
1e746e6 Keep a mapping of compiled to extern player method names in cast proxy.

[joeyparrish]

I was starting to think 1e746e6 ("Keep a mapping of compiled to extern player method names in cast proxy") would turn out to be the fix, since it was the only non-ad-related commit in the list. But when I tested just the commits that fixed the second bug (no receiver UI at all), I found that those alone were enough to fix this issue when applied to v2.5.5-master and v2.5.7 (release).

• v2.5.5-master - receiver UI timestamp and seek bar do not update

• v2.5.6-master - receiver UI does not show up at all

• v2.5.7 (release) - receiver UI timestamp and seek bar do not update

• v2.5.5-master + a43f52c + 08a36e8 + a6b159f - working as expected

• v2.5.6-master + a43f52c + 08a36e8 + a6b159f - working as expected

• v2.5.7 (release) + a43f52c + 08a36e8 + a6b159f - working as expected

This seems to be because of this code in the UI:

  this.timeAndSeekRangeTimer_ = new shaka.util.Timer(() => {
    // Suppress timer-based updates if the controls are hidden.
    if (this.isOpaque_()) {
      this.updateTimeAndSeekRange_();
    }
  });

These recent changes made the UI controls always opaque in our cast receiver, so the time will always be updated. This seems to be a bit broken, though.

With these new changes, the receiver UI is actually hidden at the app level, without the knowledge of the library. This defeats the purpose of only updating the UI when it's shown. Every update causes the browser to recalculate the layout, which can be expensive on low-powered devices like the Chromecast or battery powered mobile devices.

Also, the "fix" is actually the new noFade option, which is applied at the app level. The UI library itself isn't fixed, we've just disabled the broken part of the code in our specific demo app. So we haven't fixed anyone else's receiver app by doing this.

[joeyparrish]

We will revert the recent changes, including the noFade option, and make new changes to the hide/show logic in the UI that will fix this issue. We will then cherry-pick them to the release branch to be part of v2.5.8.

[joeyparrish]

The fix has been merged and cherry-picked to the release branch. It will be part of v2.5.8. I don't have a release date yet, but you can always deploy code from the stable v2.5.x branch ahead of a release if you need to.

[cdongieux]

Thanks a lot for fixing this!

Best regards,
Christophe

[joeyparrish]

Happy to help! We're working on releasing v2.5.8, which hopefully will be out this week.