2013-08-20, 16:30
(2013-08-20, 15:24)MilhouseVH Wrote: Not sure if it's good news or not, but top of master is still in the "worse" state, testing with the following settings:Useful to know, rather than good/bad.
Quote:I may be interpreting this incorrectly, but my understanding is that "B 0%" represents how full (or empty) the buffer is, with aq and vq similarly representing the audio and video queues. I have no idea what the "vb:" number represents, it tends to be all over the place, anywhere between 0 and 9830400.
vb is space in the video fifo (to GPU). Small numbers are good, meaning it is full.
I think removing that (or replacing with a percentage) and changing aq/vq to report amount of data buffered by gpu in seconds would be more useful.
They are the values used to determine buffering. I'll tidy up the numbers reported.
Quote:However, if the movie is started from the beginning (and not resumed) I see quite different results - the buffer will begin to fill from the very beginning which doesn't happen when resuming:
Interesting, but nothing comes to mind why resuming would behaving differently than starting from beginning.
Does seeking forwards by 10 minutes result in the "resume" behaviour when file was initially started from beginning?
Does seeking to beginning result in the "beginning" behaviour if initially resumed from middle?
Quote:In the Jul 21 build, the buffer doesn't run dry and peaking of network traffic is evident (and with no stalling). I'll try and work back through master to see if I can narrow down the relevant commit(s) - it's gonna take a while...
Would be useful.
Currently I have no idea if this is an omxplayer issue, or if something has changed in generic xbmc code, or even something has changed in OpenELEC (like a library bump).
Finding the OpenELEC commit is the first step to identifying this. (git bisect may be helpful here).
