1.5.1 can refuse to download new fragments just because "complete"

[JibberJim]

Another seeking issue with 1.5.1 is due to the PlaybackTimeRule refusing to propose a time because there's a "complete" fragment there, So if you play to the end, seeking into un-cached area can fail. Not sure why it didn't always fail, but possibly due to other seeking bugs where pending ones can be left behind and they could be rescheduled (see #881)

[bwidtmann]

Hi Jim,

do you have concrete steps to reproduce all these seeking issues?

As we all already know, the scheduling logic (pending and rejected requests) is quite error prone - especially when seeking a lot. Therefore Dan and Mikael are taking a lot of work to simplify this logic.

Currently we changed the default buffer pruning configurations on our productive systems to achieve a quite stable seeking experience for our customers in dash.js 1.5.1:

BUFFER_TO_KEEP = 10
BUFFER_PRUNING_INTERVAL = 10
BUFFER_TIME_AT_TOP_QUALITY = 10

Maybe this helps to overcome the major seeking problems until dash.js 2.0 is ready

[JibberJim]

Mostly just seek a lot, particularly after playback complete for some of
them, but generally seeking when you have pending requests and after ABR's
(as they leave requests behind that confuse things). However, I have
proper code fixes for them, and actually changing the buffering amount will
likely increase the likelyhood of them, as it will lead to a couple of them
triggering more often - having it in the real source buffer helps as that
seek always work which updates the playback times more reliably which helps
one of the bugs in the playbackTimeRule.

My raw notes as I made the changes / debug'd our QA reports:
https://raw.githubusercontent.com/bbc/dash.js/smp-v1.5.1/src/abr_notes.txt
read combined with the commit log
https://github.com/bbc/dash.js/commits/smp-v1.5.1

Once we get this release out as we'll have more confidence we've not broken
other things, and we'll produce a PR (against master) with the changes we
think are needed to address all those issues.

Cheers,

Jim.

On Mon, Nov 16, 2015 at 7:23 AM, Bernhard Widtmann <notifications@github.com

wrote:

Hi Jim,

do you have concrete steps to reproduce all these seeking issues?

As we all already know, the scheduling logic (pending and rejected
requests) is quite error prone - especially when seeking a lot. Therefore
Dan and Mikael are taking a lot of work to simplify this logic.

Currently we changed the default buffer pruning configurations on our
productive systems to achieve a quite stable seeking experience for our
customers in dash.js 1.5.1:

BUFFER_TO_KEEP = 10
BUFFER_PRUNING_INTERVAL = 10
BUFFER_TIME_AT_TOP_QUALITY = 10

Maybe this helps to overcome the major seeking problems until dash.js 2.0
is ready

—
Reply to this email directly or view it on GitHub
#882 (comment)
.

[bwidtmann]

Ok. That makes sense. We already experienced strange behavior when the stream ends. Therefore we close the player 1 second before stream ends. Thats the reason why we do not run into the same seeking problems as you described.

Providing a PR against master/dev does not seem to be a good idea since dev branch is frozen und the complete scheduling logic is refactored at the moment.

Our (maxdome) strategy is to wait for a dash.js 2.0 version and pass it to our internal QA. If there are still issues on seeking, we apply our internal patches/workarounds on top of it and try to pull it back to dash.js.

[shiweige]

@bwidtmann hi, just wonder what is the unit of these variable like BUFFER_TO_KEEP?
I suppose it should be seconds, but from the comments in BufferLevel, it shows the level of the buffer is in milliseconds.

[bwidtmann]

@shiweige those 3 mentioned above are in seconds

[dsparacio]

can someone that is familiar with this from 1.6 check if this is still an issue in 2.0?

[LloydW93]

2.0 Removes the general concept of "complete" when dealing with whether to schedule - this can be closed.

[dsparacio]

👍