Able to reproduce the issue using #68.0.3403.0 on Android Samsung J7; 7.0.0 as per the steps mentioned in original comment. Observed Not Found.

Will update other info soon.

Thanks!!

@Reporter: Could you please update Chrome to latest Canary #68.0.3404.0 and check as issue is no longer seen in latest Canary?

Thanks!!

yes, it's still visible.

+liberato in case this is MCVD related.

doesn't appear to be related to MCVD.  i tried with / without @ ~ ToT and "file not found" in both cases.  didn't see anything in logcat of interest.

marcin@, does this bug still repro on present canary?

yes

any updates here?

Seems like a site specific issue, but +network folks in case I'm missing something. Video URLs are different on desktop than mobile:

Desktop:
https://img.joemonster.org/upload/rdz/1690094b4c0aa9dyt_1055477366.mp4

Mobile:
https://img.joemonster.org/upload/rdz/1690094b4c0aa9dyt_1055477366.mp4?fs=1&iv_load_policy=3&rel=0&autohide=1&modestbranding=0&showinfo=0

Changing iv_load_policy to any other value than 3 allows the mobile playback to work. I don't know what that does though, so it's probably wontfix from our side unless the network team sees us not responding to requests properly.

I think, that title of bug is self-descriptive: "File not found in Canary, everything OK in Stable"

I can confirm that even today, on stable 66 it's ok, on canary 68 not.

It still looks for me, that problem is because of changes in Chrome.

Yes, that doesn't necessarily mean it's a bug in Chrome though. It's more likely sure, but in this case (at least from the media side) it doesn't look like it.

> Yes, that doesn't necessarily mean it's a bug in Chrome though. 
> It's more likely sure, 
> but in this case (at least from the media side) it doesn't look like it.

Of course there is possibility that it's not Chrome bug, but... because I don't have such resources like you (mainly time) I'm reporting this issue from end user role and I kindly ask for making investigation. 

Of course as QA I know that in such case bug should be confirmed or rejected (and in first case suspected CL should be found)... and I also kindly ask for it too :)

Bug is annoying and to be honest I don't see any reason (such like Chrome setting) which could make difference, maybe it's not media side problem, maybe something else... Please investigate if possible.

I tried 66.0.3359.158 Stable on Android. If I use incognito mode, there is the "File not found" error. In a normal profile, the video loads.

This doesn't seem to be a Chrome problem. Please contact the site developer to check the params that you are sending to the server.

I think, we have misunderstanding here.

You (I mean you personally and your colleagues) confirm - on version X it works, in version X+1 it doesn't

And now you say - "This doesn't seem to be a Chrome problem"

Any more investigation? Can we find what X exactly it? What exactly change between these version?

Or if this is not media, could you reassign it correctly to your colleagues from team who could help here?

When the page fails, the URL of the frame with the video is "https://m.joemonster.org/upload/rdz/1690094b4c0aa9dyt_1055477366.mp4?fs=1&iv_load_policy=3&rel=0&autohide=1&modestbranding=0&showinfo=0", and when it succeeds, it is "https://img.joemonster.org/upload/rdz/1690094b4c0aa9dyt_1055477366.mp4?fs=1&iv_load_policy=3&rel=0&autohide=1&modestbranding=0&showinfo=0" (Note the img instead of m, at the front of the domain name).

There's actually a redirect from the correct URL to the incorrect one, which is cached.  Clearing the cache clears the bad redirect, and the page works from then on.  Even clearing the cache again, I'm unable to reproduce.  Bizarrely, I ran into the same behavior with incognito - even restarting Chrome and using a new incognito tab, it still works.

I managed to reproduce once more somehow, but then never again.  I wonder if the backend is remembering my IP, and behaving differently based on some internal timeout.  Even without that, though, it's not clear why it's sending us that cacheable redirect in the first place, or why it depends on Chrome version (Or even if it depends on Chrome version, and the reason why you're only seeing it on one version is because of the cache getting stuck with the bad redirect).  Also just tried again on Android, with a new Canary install, and couldn't repro at all (I did repro last night, on my first try).

It's unclear if there's a Chrome bug triggering the server sending us a bad redirect, but I don't think we have a path forward here.  We'd need to know what's going on at the server end of things.

I don't think there's anything we can do that's actionable here - even just catching us getting the bad redirect is difficult.

Can we ask Google QA team to check more deeply from which version it started happening?

It's unclear that this is a regression comment #17 mentions that the issue can reproduce in 66.0.3359.158.  Without help from the server side, or a consistent repro, I don't think we should be investing resources here.

We need a consistent repro.  I don't think we can proceed here without one.

66 without incognito - for me files were always loaded

68 without incognito - for me files were always not loaded

it's maybe not simple case, but my QA experience say, that it will be max. 0,5 - 1 h for one person.

To be more specific:

let's start from 66.0.3359.158 and 68.0.3403.0 and let's try few versions between to see, which CL could make this.

Typical small QA task.

> max. 0,5 - 1 h for one person. 

Network team has already taken a close look.

> let's start from 66.0.3359.158 and 68.0.3403.0 and let's try few versions between to see, which CL could make this.

See comment 21 for why this is not feasible. Please contact the site owner for follow up.