I see unexpected |progress| events after a seek is triggered... EG, loading http://tinyvid.tv/show/t5v1inpguy9t, I initially get: ... videoctl: Got progress media event videoctl: +++ load, 28163892 of 28826786 videoctl: Got progress media event videoctl: +++ load, 28475212 of 28826786 videoctl: Got progress media event videoctl: +++ load, 28721372 of 28826786 videoctl: Got progress media event videoctl: +++ load, 28826786 of 28826786 If I then click to invoke a seek, the video starts downloading again (in part due to bug 473107 et al). I first get a few dozen repeated 100% events. This is not expected: videoctl: Got progress media event videoctl: +++ load, 28826786 of 28826786 videoctl: Got progress media event videoctl: +++ load, 28826786 of 28826786 videoctl: Got progress media event videoctl: +++ load, 28826786 of 28826786 videoctl: Got progress media event videoctl: +++ load, 28826786 of 28826786 ... Eventually it jumps back down to a sensible value, a |timeupdate| event is fired, and then a normal sequence of |progress| events as the download finishes: ... videoctl: Got progress media event videoctl: +++ load, 28826786 of 28826786 videoctl: Got progress media event videoctl: +++ load, 3245916 of 28826786 videoctl: Got timeupdate media event videoctl: time update @ 31370ms of 312875ms videoctl: Got progress media event videoctl: +++ load, 3315420 of 28826786 videoctl: Got progress media event videoctl: +++ load, 3843940 of 28826786 videoctl: Got progress media event videoctl: +++ load, 4715636 of 28826786 ...

The 100% events are the result of seeking to find the duration, which seeks to the end of the file. The events are supposed to be suppressed during this time but it appears to not be happening.

Bug 455654 changes that, so let's see if it fixes it.

Nope, same thing happens.

Fixed now?

Well... I don't see 100% progress events now. But seeking forward into a section of a video that hasn't been buffered yet does result in duplicate progress events being fired, in a similar fashion: videoctl: Got media event ----> progress videoctl: +++ load, 8450048 of 35154877 videoctl: +++ seeking to 278.36 videoctl: Got media event ----> seeking videoctl: Delaying status fade-in... videoctl: Got media event ----> progress videoctl: +++ load, 10678272 of 35154877 videoctl: Got media event ----> progress videoctl: +++ load, 10743808 of 35154877 videoctl: Delated start timer fired. videoctl: Fading status in videoctl: Got media event ----> progress videoctl: +++ load, 10743808 of 35154877 videoctl: Got media event ----> progress videoctl: +++ load, 10743808 of 35154877 videoctl: Got media event ----> progress videoctl: +++ load, 10743808 of 35154877 videoctl: Got media event ----> progress videoctl: +++ load, 10743808 of 35154877 videoctl: Got media event ----> progress videoctl: +++ load, 10743808 of 35154877

OK. I think this isn't really a bug. With the media cache, we can have arbitrary regions of data cached, and the "progress amount" is just a synthetic number we calculate --- it's just the amount of data we have cached starting at the current stream reader position. So it's perfectly possible to read data into the cache and have that number not change. So I'll take the liberty of resolving this as INVALID.

As far as out controls go, I guess that's fine. The duplicates don't hurt anything. But I think it is technically a spec violation, which says progress events should be fired "every 350ms (±200ms) or for every byte received, whichever is least frequent".

We're receiving bytes, they're just not adding to the progress total. I agree this is somewhat bogus, but trying to expose a "N out of N" progress count when we're doing all kinds of random access is inherently bogus.