Closed matthuisman closed 2 weeks ago
as experiment, i proxied and set minimumUpdatePeriod="PT20S". I then got either 20s between or 40s between. So seems to be some kind of "double" issue or one in between actually getting skipped
tested on kodi 20 and thats around 5-7s between refreshes and works well. The above is the cause of way live stream dash seem less reliable on kodi 21 (my old ticket that i closed)
its possible that the problem is difficult to be solved, the update interval time is fixed as per: https://github.com/xbmc/inputstream.adaptive/blob/6ece29460374011f46ad7e6c1c9eacd88c30fb81/src/common/AdaptiveTree.cpp#L282-L283 so cannot be wrong
but we need to wait that other operations have finished before execute the update https://github.com/xbmc/inputstream.adaptive/blob/6ece29460374011f46ad7e6c1c9eacd88c30fb81/src/common/AdaptiveTree.cpp#L286-L287
this imo could be the cause of bad delay
unfurnately this is needed because is missing a middle interface that decouple the "tree" and a separate "streams" object we are using the "tree" objects everywhere and this is a old bad design
just for experiment you can delete the lock line from https://github.com/xbmc/inputstream.adaptive/blob/6ece29460374011f46ad7e6c1c9eacd88c30fb81/src/common/AdaptiveStream.cpp#L1261-L1267 that lock the updates
you can see if there is a timing improvement
Also of note that this is minimum time between updates. Which means a minimum 12s. But faster is ok. But should not be longer than 12s
Can we just ignore this manifest value and do what Kodi 20? Refresh when needed? But if we detect that's longer than 12s,then refresh as well?
i need to do some test as confirm...
but if the problem is the lock, the lock block the code execution and you cant do nothing the lock there is because if "tree" objects is used elsewhere "demuxer read" that are from different threads, you cant access to "tree" objects then no "tree" updates can be done without make a memory violation access crash
found the problem is due to spurious wakup of std::condition_variable it dont manage unexpected awakenings and so make wait_for method unreliable for our use cases... I did not read his behaviour well on c++ docs
@matthuisman please test builds on the fix PR and let me know but in my test seem that now the situation seem solved
Your the best. I will test tonight and report back
On Wed, 28 Aug 2024, 02:32 Stefano Gottardo, @.***> wrote:
@matthuisman https://github.com/matthuisman please test builds on the fix PR and let me know but in my test seem that now the situation seem solved
— Reply to this email directly, view it on GitHub https://github.com/xbmc/inputstream.adaptive/issues/1660#issuecomment-2312739175, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPQAKKONENRPUORJG4QDNLZTSEWXAVCNFSM6AAAAABNFZI7DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSG4ZTSMJXGU . You are receiving this because you were mentioned.Message ID: @.***>
tested same stream
times are all 12s :)
2024-08-28 20:28:42.623
2024-08-28 20:28:54.694
2024-08-28 20:29:06.760
2024-08-28 20:29:18.826
2024-08-28 20:29:30.892
Looks good! Thank you,
Describe the problem
This dash manifest has minimumUpdatePeriod of 12s, but its always hitting the end of the stream. I had a workaround to force the updateperiod down to 4s which helped, but that affected other things.
Seems sometimes its 12s between refreshes and others are double
manifest download times 2024-08-27 22:03:10.018 1st 2024-08-27 22:03:34.027 +24s 2024-08-27 22:03:58.094 +24s 2024-08-27 22:04:10.170 +12s 2024-08-27 22:04:34.234 +24s 2024-08-27 22:04:46.598 +12s 2024-08-27 22:04:58.668 +12s
Possible fix
No response
Steps to reproduce
No response
Debug log
duke.log.txt
Stream manifest file(s)
Additional info
No response
Operating system(s)
Windows
Operating system version(s)
No response
InputStream Adaptive version(s)
21.5.3
Kodi version(s)
21