(2012-05-11, 03:53)Bstrdsmkr Wrote: The percentage displayed isn't percentage of cache filled. It's the percentage of X where X is the amount needed to play all the way through without having to stop and buffer again, at the current average download speed. If the average speed drops, X gets bigger, thus the amount buffered is a smaller percentage of X so the displayed number gets smaller.
Thank you for that description but if that's the case, the skinning wiki makes things confusing when:
- Player.CacheLevel - Players current cache fill percentage (if supported by the player)
- Player.ProgressCache - Shows how much of the file is cached above current play percentage
Your description of the process of determining the current buffer percentage seems, to me at least, really convoluted and counter-intuitive when taking into account common experiences outside of XBMC where buffering video streams are concerned. Player.ProgressCache seems to imply that from the point the user is currently in the video to the end, 100% of the video stream should be completely download and available. Likewise, Player.CacheLevel completely contradicts what you said regarding percentage of cache filled.
I guess this brings me back to the point I made in my last post regarding Buffered vs Loaded. Does one prefer to know how much of the
total stream has been downloaded and therefore available; or, know how long until the video can be watched until buffering needs to occur? Which one offers more information to the user? Which one is going to offer the maximum benefit with the less amount of confusion?
Using my wife as an example, which I tend to do when it comes to programming for the common user, I would venture to say the displaying the percentage of the total filesize is the best solution. As you will see on just about every video streaming site, the percentage filled is always the total amount of the video download. To my knowledge, this is the current recognized behaviour when the user interacts with the seekbar.