inputstream.adaptive
inputstream.adaptive copied to clipboard
xbmc
[Bug] dash-stream: can't go past start point or back to live
Describe the problem
It is not possible to move to "live" or e.g. +15 min after start point of the stream without pressing "stop" and starting again. I'm using ISA (+ iptv-simple) together with some german dash-streams. (see below)
example below (How to reproduce): I want to move past 20:00 (actual time 21:30). this is not possible.
I started the dash stream, went back 30 min, let it play for 3,5 min and tried to went forward 30 min to "live". But the stream only went forward 26,5 min to the point, where I started the stream. Shouldn't it to to "live"? It is a (live)stream ...
So ISA should update the endpoint (live) in some way ... Thx
Here is the forum-post: (put it together for this bug-report): https://forum.kodi.tv/showthread.php?tid=378875&pid=3210333#pid3210333
Possible fix
No response
Steps to reproduce
In the stream, I can go back 2 hrs (from 20:00 to 18:00). streamtime 18:00 actual time 20:00
If I go back 2h and watch the stream e.g. 1h30 min (at 19:30) and move forward because of advertising or end of the show, it is not possible to move to actual "live". streamtime 19:30 actual time 21:30 I can only go to 20:00 streamtime and not past 20:00. Kodi only goes forward to the start point of the stream (1h30 min ago) (20:00), where I moved backwards.
Debug log
was too big for 1 part part 1: https://paste.kodi.tv/kavomuzeja.kodi part 2: https://paste.kodi.tv/oduzeyiqos.kodi part 3: https://paste.kodi.tv/avisohokek.kodi part 4: https://paste.kodi.tv/ujakayupim.kodi
Stream manifest file(s)
The free (and legal) stream is geoblocked (german) from here: https://github.com/jnk22/kodinerds-iptv --> dash Tested with ARD (Das Erste) and ZDF ARD: https://paste.kodi.tv/ayavecoqeq ZDF: https://paste.kodi.tv/azumucukaj
Additional info
No response
Operating system(s)
Android
Operating system version(s)
Android 11 on Philips TV
InputStream Adaptive version(s)
21.5.9
Kodi version(s)
21.1
did not attach manifest files i will have to find time to test it is possible that the "inacessible” minutes are too close to the live edge, at the moment i don't remember well anymore, it is possible that playing the stream too close to the live edge is not possible because cannot keep a fluent buffering
I added the manifests above
sometimes Kodi even goes back, when the stream was started, if it is not possible to go further forward (the point, the stream was started) In the example above the stream goes to 20:00, but "live" is at 21:30. Shouldn't ISA update the "live" manifest, so it knows how far you can go back and forth from "live"? e.g. every 10 s or 1 min?
Don't know if this is possible. Thx
Same issue here.
I use IPTV service which uses DASH and HLS (for non DRM channels).
HLS stream works just fine if the program on 20 minutes i can go back and even watch kodi info gets updated every 6 seconds so after watching for 5 minutes the info shows 0:05:00/0:25:00 and can seek past the 20 minute "barrier".
On DASH streams it behave exactly as described above, the "Length" of the stream stuck on 0:20:00 and only reopening the channel "updates" it.
adding manifest for reference (removed some urls that might be "private")
<org-url>?indexMode&startTime=762867900000
<?xml version="1.0"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:cenc="urn:mpeg:cenc:2013" xmlns:mspr="urn:microsoft:playready" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" profiles="urn:mpeg:dash:profile:isoff-live:2011" type="dynamic" minimumUpdatePeriod="PT16S" availabilityStartTime="2025-03-05T11:45:00.001Z" maxSegmentDuration="PT3S" minBufferTime="PT2S" publishTime="2025-03-05T12:51:40.000Z" presentationTimeOffset="762867900001">
<BaseURL><org-url></BaseURL>
<UTCTiming schemeIdUri="urn:mpeg:dash:utc:http-head:2014" value="https://<otherurl>/utc" />
<Period sequence="0" start="PT0S">
<AdaptationSet id="0" group="1" contentType="video" mimeType="video/mp4" segmentAlignment="true" bitstreamSwitching="true" maxWidth="1920" maxHeight="1080" startWithSAP="1">
<SegmentTemplate presentationTimeOffset="762867900001" startNumber="381433951" duration="2000" timescale="1000" media="?type=video&ft=1&id=$RepresentationID$&bitrate=$Bandwidth$&idx=$Number$" initialization="?type=video&ft=0&id=$RepresentationID$&bitrate=$Bandwidth$&startTime=762867901064" />
<Representation id="0" frameRate="50" codecs="hev1.1.2.L123.90" bandwidth="5500000" width="1920" height="1080" />
<Representation id="4" frameRate="50" codecs="hev1.1.2.L120.90" bandwidth="3000000" width="1280" height="720" />
<Representation id="8" frameRate="50" codecs="hev1.1.2.L93.90" bandwidth="1500000" width="960" height="540" />
<Representation id="12" frameRate="50" codecs="hev1.1.2.L93.90" bandwidth="800000" width="960" height="540" />
</AdaptationSet>
<AdaptationSet id="1" group="2" contentType="audio" mimeType="audio/mp4" segmentAlignment="true" bitstreamSwitching="true" lang="pol">
<SegmentTemplate presentationTimeOffset="762867900001" startNumber="381433951" duration="2000" timescale="1000" media="?type=audio&ft=1&id=$RepresentationID$&bitrate=$Bandwidth$&idx=$Number$" initialization="?type=audio&ft=0&id=$RepresentationID$&bitrate=$Bandwidth$&startTime=762867900001" />
<Representation id="1" codecs="mp4a.40.2" bandwidth="128000" audioSamplingRate="48000" />
</AdaptationSet>
</Period>
</MPD>
also image which shows duration not get updated (so kodi can seek only previous to show duration)
kodi log only show this lines when starting playing
AddOnLog: inputstream.adaptive: adaptive::CDashTree::ParseManifest: The <UTCTiming> tag element is not supported so playback problems may occur.
debug <general>: AddOnLog: inputstream.adaptive: adaptive::CDashTree::OnUpdateSegments: MPD update - No new segments (repr. id "8", period id "")
debug <general>: AddOnLog: inputstream.adaptive: adaptive::CDashTree::OnUpdateSegments: MPD update - No new segments (repr. id "1", period id "")
If any thing else is needed , let me know.
FWIW, It's very much the same with the live streams from the iplayer-www addon.
I would like to add that it's not necessary to first skip back to a point before the stream was started. It just seems impossible to seek forward to any time later than the moment the stream was originally started, regardless of the point one seeks from.
e.g.:
- start BBC one and watch 30sec.
- pause for 30 sec and then resume playing for 30 sec
- try to skip 10 sec forward - this will bring you back to the original starting point.
- start BBC one and watch a few minutes
- skip back 1 minute
- skip forward 30 sec - this this will bring you back to the original starting point.
Files from 2: Kodi log: https://paste.kodi.tv/anusenilip.kodi manifest: https://paste.kodi.tv/wodacijalu
Live steams from ITVX do not have this problem. One notable difference is that BBC manifest is requested only at the start of the stream, while ITVX manifests are request after each segment.
i made the fixes / improvements, but given the high number of code changes it will not be backported to older kodi versions
anyway if someone want to test it on kodi 22 and provide a feedback, here there is the link with some test builds: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1867/5/artifacts
I tested on win11 and iplayer www and can confirm the issue is fixed. Haven't noticed any negative effects on other live streams. Thanks a lot!!
Tested the 22.2.7 version using nightly build.
It seems the "go past beyond start position" is working great.
But at least on my case, kodi's playback time seems to somewhat glitchy.
For example , started playback on 1:31:25 of the show (out of 2 hours) , kodi shows 1:31:25 / 1:31:31 and every 1 or 2 seconds there is an update that draw the time back to 1:31:25 / 1:31:31 (after 1 second it shows 1:31:26 / 1:31:32 and then goes back one second). On HLS stream both counter progress normally and after 1 minute for example they would show "1:32:26 / 1:32:32".
Just to clarify, Seeking works just fine , and it was the main issue for me , just wonder if this behavior happens only on my use case or maybe it a bug needs to be polished on kodi side (after all its a nightly build)
Yes, it's the same with me, but to me my looks like exactly the right behaviour.
For example , started playback on 1:31:25 of the show (out of 2 hours) , kodi shows 1:31:25 / 1:31:31
For a live stream this means that your stream has a replay window of 1:31:31, i.e. you can seek back a max of 1,5 hrs from the live edge. Kodi indicates your current position relative to the start of the stream and the total length of the stream The 'start' of the live stream is the start of the replay window, the 'end' is the live edge. The lenght is the size of the replay window.
Unlike VOD, the live edge, and thus the whole replay window, of a live stream moves forward a second with each second played. So, if you play live at normal speed, your play postition remains the same. With 1:31:25 / 1:31:31 you are probably playing as close to the live edge as possible. If you would seek back 30sec in the live stream, kodi will show something like 1:01:25 / 1:31:31. And it will remain that way as long as you don't seek, or pause and play at normal speed.
I don't know why HLS is different. Maybe it's replay window expands while you play, or else it's just HLS that's wrong, and worth a new issue if you'd ask me. You could try and see how far you can seek back in the HLS stream.
For a live stream this means that your stream has a replay window of 1:31:31, i.e. you can seek back a max of 1,5 hrs from the live edge. Kodi indicates your current position relative to the start of the stream and the total length of the stream The 'start' of the live stream is the start of the replay window, the 'end' is the live edge. The lenght is the size of the replay window.
exactly, on kodi as time passes, the GUI will show a timing that seems to "go back" at each manifest update because it is like a fixed point, related to the TSB instead some other video players start from the TSB duration and extend it as time passes, which could be nicer to look at
HLS should not be different because at each update older segments are deleted
this current way can confuses users as they don't know what is the TSB, to better handle the TSB on GUI, exists some kind of TSB timing that could be implemented (see #154) but i have already tested this TSB GUI interface and currently seems broken and need to be revisited
Here at least HLS acts differently
Started the stream using HLS
After about 5 seconds
On DASH
on start
after about 5 seconds
On HLS the numbers are accumulated while on dash they get rested (HLS behavior is preferable of course and worked this way before the update)
regarding try to seek way back , it stops on 00:00:00 but i am not sure whether kodi blocks it or the dash stream itself.
i have some hls live streams but all them show the same behaviour of live dash can you attach your hls link? (if not geolocked) i would like to see the difference
Sorry , not possible it is geoblocked and requires authentication/session.
HLS unlike DASH does not have a manifest and i don't see any special implementation there.
I'll try to find a public HLS stream that shows the same behavior.
HLS unlike DASH does not have a manifest and i don't see any special implementation there.
hls on a stream can have multiple manifests, one for each a/v/s tracks, depends on service
After a quick search i found 2 streams so far, testing them in a .strm file they behaved differently.
#KODIPROP:inputstream=inputstream.adaptive
#KODIPROP:inputstream.adaptive.manifest_type=hls
https://skynewsau-live.akamaized.net/hls/live/2002689/skynewsau-extra1/master.m3u8?ref=developerinsider.co
While this is currently a still image stream it played on kodi like
Other stream i found behaved kinda like the DASH one on my setup
#KODIPROP:inputstream=inputstream.adaptive
#KODIPROP:inputstream.adaptive.manifest_type=hls
https://ireplay.tv/test/blender.m3u8
I'll post more if I'll find any other behaviors.
about hls "skynewsau-live.akamaized.net" if you wait some minuts of playback you can see that time go back like dash
the "left"time go beyond the "total time" because on the TSB total time, has been removed the live delay duration 40s (total TSB) - 16s delay = 24s this to disallow user to try seek on live delay video part that contains segments not fully available
more likely this happens because on HLS parser it do not remove expired segments, so the current time exceeds the total time i need to investigate better