You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 22, 2018. It is now read-only.
Trying to resume from a saved location or seek ahead into a part that hasn't been downloaded yet breaks completely. The file is downloaded from the beginning, then after about a minute the loading dialogue closes. The stream is briefly shown with the "playing" icon in search results the browser, then it reverts to nothing. Similarly, seeking ahead freezes, then exits the playing screen and goes back to the results browser. Starting that stream again offers to resume from the position of the failed seek, which fails because resumes don't work.
Is it possible to make it download the appropriate parts of the file, rather than start from the beginning each time? Not sure how hacky it needs to be, since I dunno how XMBC APIs work, but ideally if the codecs' data access is fully virtualised, it wouldn't need to assume anything about the file format/structure and just let it request the appropriate byte ranges.
[Tested on OYUA XMBC 13]
Trying to resume from a saved location or seek ahead into a part that hasn't been downloaded yet breaks completely. The file is downloaded from the beginning, then after about a minute the loading dialogue closes. The stream is briefly shown with the "playing" icon in search results the browser, then it reverts to nothing. Similarly, seeking ahead freezes, then exits the playing screen and goes back to the results browser. Starting that stream again offers to resume from the position of the failed seek, which fails because resumes don't work.
Is it possible to make it download the appropriate parts of the file, rather than start from the beginning each time? Not sure how hacky it needs to be, since I dunno how XMBC APIs work, but ideally if the codecs' data access is fully virtualised, it wouldn't need to assume anything about the file format/structure and just let it request the appropriate byte ranges.