I was able to reproduce this on Chrome Dev (51) and it got fixed when reloading. Do you see the same behaviour in Dev?

Just had this issue on M51 (Dev Channel) on another website while trying to debug an unrelated issue. The length of the file was "21:1314".

CC'ing other people given that dalecurtis@ might be away for a few days IIRC.

Yes, after reloading, the duration is correct.

Is the time reported by mediaElement.duration also wrong? Is it wrong all the way down, in WebMediaPlayerImpl and Pipeline?

+1 to what philipj asked, is it just a display issue?

soundcloud.com and watchcartoononline.com seems to suffer from exactly the same bug. I was debugging JWPlayer in the latter so I would be suprised if both sites share some code.

However, `.duration` seems fine. I will try to do some bisect.

The bisect was conclusive. It is a regression from v8:
https://chromium.googlesource.com/chromium/src/+/b05d0fd2eb6c4a63fc7516ce83dab545aef777d0  \o/

I believe this is the commit that broke everything:
https://codereview.chromium.org/1839763003

Assigning to slan@.
CC'ing reviewers of the CL.

A very simple STR is:
1. soundcloud.com
2. play the first song
3. scrub (ie. change time using gesture), you will notice that when you are after 1:00, it will start showing 1:60, then 2:120, etc.

Bouncing to v8 OWNERS, who have far more context on what might be happening.

I don't have a way to test either the chromecast nor the android version, so I'd propose to revert the CL and merge back.

adding back mlamouri@

FWIW, locally reverting the CL fixes the issue. It might be good if you guys could have a test on the v8 side to avoid this happening again though :)

working hard on adding support for GN, but as you probably can tell, it's currently not supported by V8.

This is not a complete solution for the Cast team. This fix is critical for playback on Chromecast devices - several of our most popular apps do not function without it - so we need to understand how to fix both Android and Chromecast cases.

jochen@: Do you have any insight on why this patch caused this behavior?

No, sorry

I continue to be surprised that it works at all

Merge before Monday 5 PM PT if you want to make the first beta cut.  Approved.

Re-opening since the fix is not merged to M51 yet.

"Fixed" means fixed on trunk usually.

And it's already merged since two days: https://chromium.googlesource.com/v8/v8/+/c12882a3a97f394f0beb5e716b62fef68db63b2f

Are there tests on the Chromium or internal bots that would've caught either the problem for Cast or the problem on Android? Did we miss this because something was still GYP instead of GN?

Were there tests on the v8 bots that would've caught this if they'd been on GN instead of GYP?

I haven't verified, but I would hope that a combination of V8 unit tests and layout tests would have caught that, but we don't run unit tests on V8/GN yet, and we don't run the majority of layout tests on chromium/android :-/

@jochen: 

"unit tests" => v8 unit tests, not chromium unit tests?

it would be interesting to see which layout tests might've caught this. You're right of course that we don't run most of them on android (we only run about 0.5% of them, in fact) but if there are some that are particularly platform-specific we should add them.