Closed t0mcat1337 closed 11 months ago
your considerations are right there are many DASH features not implemented in ISA addon this is one then cause mentioned problems
the weird thing is that despite other players have endNumber attribute support to SegmentTemplate im not able to find this specification on the dash docs, look like a separate revision of this protocol that im not able to find
i think that with this we should also take a look for related things mentioned on DASH 4.4.3.5. Last Segment Message
chapter
at least for the Supplemental Descriptor with schemeIdUri http://dashif.org/guidelines/last-segment-number
where we can also test with a sample stream:
http://dash.akamaized.net/dash264/TestCasesIOP41/LastSegmentNumber/1/manifest_last_segment_num.mpd
In the meantime, I've been looking into this issue a bit more, despite neither never really coded in C++ in general nor had seen ISA addons source code in special.
But even with my noob - knowledge at least I have managed: -> parsing endNumber Attribute from SegmentTemplate Tag in the dash XML -> Use it for not downloading segments beyond this endNumber, so the stream isn't hanging any more
I'm very sure especially the 2. point can be done much better with better knowledge of ISA code (and C++ ;) ), but I think it could at least be a start ;)
These changes actually are living in a branch of a forked ISA Repo from Omega branch in my GitHub Profile. Perhaps I could open a pull request?
BTW: I have tried "fixes" for Omega and Nexus Versions of ISA, which are very different because of the different ISA structures.
i havent had time to take a look in depth, your changes are a starting point but incomplete, we have to implement this in a more generic extensible way, because dash spec show more ways to signal last segment, your code is SegmentTemplate dependent, and so not correct and i also expect that with these changes to implement the Supplemental Descriptor
BTW: I have tried "fixes" for Omega and Nexus Versions of ISA, which are very different because of the different ISA structures.
true, many improvements has not been backported to Nexus due to heavy code changes but we treat this issue not as a bug, but an improvement, being it is an unsupported dash feature so in this case backport is not mandatory nor a priority, a partial backport may also be considered at later time
I'm completely with you that my code is far away from being complete, but nevertheless it is a quick (and yes, dirty) fix/workaround for the specific problem with those streams which actually affects quite a few users. (Compare this thread in Kodinerds forum: https://www.kodinerds.net/thread/57646-release-tvnow-rtl-watchbox-vox-ntv-nowus-rtl2-nitro/)
Of course the complete, more generic and extensible solution you mention is neccessary, but it sounds that this will take some amount of time, especially when it comes to be backported / available in Nexus (which actually is the productive version)
Do u see any chance for a quicker (perhaps not as perfect) fix for this issue, so those streams work again for the currently affected users?
Do u see any chance for a quicker (perhaps not as perfect) fix for this issue, so those streams work again for the currently affected users?
often people want "quick fixes" but many "quick" fixes were introduced in the past that messed up the source code a lot, as you can see from differences between Omega VS Nexus branch that has required tons of refactors to give manageability to the code
who want merge a quick fix doesn't always mean it was done with broader thinking in mind, who develop a fast fix may not bother to complete the changes made at later time, then some other people will have to study and solve this a second time, or worst it will be forgotten and today small problem become a future huge problem that require big code refactor and many hours to spend
i noticed that you are able to understand a bit C++ and you might understand that the amount of work here is huge we are 2 devs with little time, tons of Issue threads to be solved and improvements "under the hood" to do
Perhaps I could open a pull request?
about this, anyone can participate to the source code, and we are happy to accept new guests even casual, this will help lighten our tasks!
who wants to participate to the project must observe the development rules and requests from project maintainers in general Kodi team devs, on the Wiki page there is "Contributing and code guidelines" section that is a starting point that i suggest you to read if you would like to take an interest in this
however i will start take a look this week, atm i dont comment about backport as said in my previous message
can you test the PR #1422? you can find also some test builds here: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1422/1/artifacts
Just tested PR with a freshly built kodi omega from master and with this ISA the error is gone, streams are played without problems. Well done :)
since its small change i made backport for kodi 20 if you have chance to test builds: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1425/3/artifacts
Awesome...as I just found artifacts for ios, android, windows, osx and tvos in your jenkins - link but no linux one, I compiled your branch end_segment_nexus on my own and tested this. With this version, streams are playing without any problem in Nexus, too.
I'm afraid I have some bad news... I just tested the Nexus Backport in IAS Nexus Branch and this doesn't fix the issue... ISA still tries downloading SubTitles Segments beyond the endNumber...
OK, don't really know what I messed up during the test but this obviously was my mistake, big sorry for that. I debugged this in VSCode and found the buggy code in DASHTree.cpp lines 1279ff:
When EndNumer is set in Template: --> Correct countSegs from Templates EndNumber: 681
But right after, we enter the "else" branch because of wrong logical if ... else structure:
and then the countSegs is overwritten:
Working solution for me was simply inserting "else if...":
thanks to have find out my oversight!
Bug report
Describe the bug
(German-?) Streams played through inputstream.adaptive suddenly hang (as if they where paused) somewhen in the last few minutes. One can stop them, continue them at the hanging position, they continue a few seconds, then hang again.
Reproducable examples are the german SoapOpera "Gute Zeiten - schlechte Zeiten", which can be played through the tvnow - plugin from the kodinerds repository.
Expected Behavior
Streams should be played without hanging
Actual Behavior
Streams hang in the last few minutes.
Possible Fix
All "hanging" streams have in common, that they contain subtitles, read below.
Debuglog
When streams hang, such entries can be found in kodi.log
MPD/M3U8s/ISM
Now take a special look at this: In the AdaptationSet of the Subtitle (id="2", contentType="text"), there is the
<SegmentTemplate>
Tag with an AttributeendNumber="681"
I assume that this attribute is ignored by inputstream causing it trying to download a segment with number 682, which of course fails with 404 as can be seen in the log:
Download failed with error 404: https://vodnowusoawsdash.secure.footprint.net/p112/cves/sd/rtlplus/927829/2-1-1-1-2.ism/dash/2-1-1-1-2-textstream_eng=2000-682.m4s
At this moment the stream hangs.
Your Environment
Used Operating system:
[ ] Android
[ ] iOS
[ ] tvOS
[X] Linux
[ ] OSX
[ ] Windows
[ ] Windows UWP
Operating system version/name: Ubuntu 23.10
Kodi version: 20.2-Nexus
inputstream.adaptive version: 20.3.14