search

xbmc / inputstream.adaptive

kodi inputstream addon for several manifest types
Other
453 stars 242 forks source link

Aborting playback in the event of commercial breaks or X-discontinuity with the inputstream.adaptive addon #1507

Closed werimail closed 5 months ago

werimail commented 7 months ago

Bug report

Describe the bug

Here is a clear and concise description of what the problem is: Hi @CastagnaIT I noticed that the stream from DAZN Darts x PlutoTV simply stops after a certain time and you end up back in the Kodi main menu. It doesn't matter which Kodi version is used. According to the responsible developer @matthuisman , this is due to the lack of full support for ad breaks or X-discontinuity in the inputstream.adaptive addon. (https://github.com/matthuisman/slyguy.addons/issues/673#issuecomment-1987384548) For the same stream: https://pluto.tv/de/live-tv/64b67f0424ade50008a3be17, playback via browser works without any problems.

Expected Behavior

Here is a clear and concise description of what was expected to happen: The stream should run through without stopping after a certain time.

Actual Behavior

The stream from DAZN Darts x PlutoTV simply stops and ends up back in the Kodi main menu.

Possible Fix

To Reproduce

Steps to reproduce the behavior:

  1. Start Kodi
  2. Play Stream: https://r.mjh.nz/PlutoTV/64b67f0424ade50008a3be17-alt.m3u8 with IPTV Simple Client (with activated option to use HLS streams via the inputstream.adaptive Addon under "Advanced")

Debuglog

The debuglog can be found here: https://github.com/matthuisman/slyguy.addons/files/14551853/kodi.log

MPD/M3U8s/ISM

An example or copy of a manifest (or manifests for HLS - master and variants) can be found here: https://r.mjh.nz/PlutoTV/64b67f0424ade50008a3be17-alt.m3u8

Screenshots

Here are some links or screenshots to help explain the problem:

Additional context or screenshots (if appropriate)

Here is some additional context or explanation that might help:

Your Environment

Used Operating system:

note: Once the issue is made we require you to update it with new information should that be required. Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.

CastagnaIT commented 7 months ago

as specified on wiki "WIP" page ADS support is not well supported atm im working to improve MPD live manifest support that in theory should allow also a better ADS support

but atm i have no plan to improve HLS atm good to have a free stream that can be used in future for test

werimail commented 7 months ago

as specified on wiki "WIP" page ADS support is not well supported atm im working to improve MPD live manifest support that in theory should allow also a better ADS support

but atm i have no plan to improve HLS atm good to have a free stream that can be used in future for test

Ok @CastagnaIT there is currently no short-term solution to the problem in the event of commercial breaks or X-discontinuity (ADS-streams). However, I also noticed that the stream stops pretty quickly without warning, even outside of the commercial break. Maybe there is also a general error in the HLS component?

Greetings Weri

mtr81 commented 7 months ago

I had the same problem in one of my addons. Solution is using proxy (HTTP server) and removing X-discontinuity tags from manifest.

CastagnaIT commented 7 months ago

However, I also noticed that the stream stops pretty quickly without warning, even outside of the commercial break. Maybe there is also a general error in the HLS component?

looks like that sometime the provider send an empty child manifest update like the following:

#EXTM3U
#EXT-X-TARGETDURATION:5
#EXT-X-VERSION:3
#EXT-X-ENDLIST
#PLUTO-VERSION:2.75.2-production-stitcher-green

no segments and EXT-X-ENDLIST signalled, this seem to be the cause that stop the playback

on Kodi 21 you should read the log error adaptive::CHLSTree::ParseChildManifest: No segments parsed.

EDIT: usually EXT-X-ENDLIST is used to signal the end of the stream

werimail commented 7 months ago

However, I also noticed that the stream stops pretty quickly without warning, even outside of the commercial break. Maybe there is also a general error in the HLS component?

looks like that sometime the provider send an empty child manifest update like the following:

#EXTM3U
#EXT-X-TARGETDURATION:5
#EXT-X-VERSION:3
#EXT-X-ENDLIST
#PLUTO-VERSION:2.75.2-production-stitcher-green

no segments and EXT-X-ENDLIST signalled, this seem to be the cause that stop the playback

on Kodi 21 you should read the log error adaptive::CHLSTree::ParseChildManifest: No segments parsed.

EDIT: usually EXT-X-ENDLIST is used to signal the end of the stream

Ok @CastagnaIT that sounds plausible to me. Is there a way to work around the problem in Kodi so that the stream continues running even though there is a signal to stop?

Greetings Weri

CastagnaIT commented 7 months ago

by reading specs seem that our parser forgot to check EVENT value to playlist type immagine since EXT-X-PLAYLIST-TYPE tag is missing on manifest data above we should as i have understood ignore EXT-X-ENDLIST so imo its possible make an attempt

EDIT: Ok then if VOD or EVENT with EXT-X-ENDLIST: not fetch update manifests == no live

but if EXT-X-ENDLIST is signalled its not so clear to me if its right or not ignore it on live streams, if ignored could cause the stream to never end? @glennguy

im not so expert but for now sound like a provider encoder bug

werimail commented 7 months ago

EDIT: Ok then if VOD or EVENT with EXT-X-ENDLIST: not fetch update manifests == no live

but if EXT-X-ENDLIST is signalled its not so clear to me if its right or not ignore it on live streams, if ignored could > cause the stream to never end? @glennguy

@CastagnaIT , @glennguy For me it wouldn't be bad if a live stream never ended. In my opinion, it even makes sense that I consciously stop a live stream if I no longer want to watch it.

Greetings Weri

CastagnaIT commented 7 months ago

not all live shows are like "TV" so endless stream, there are streams that end when the live is finished i would like to avoid stall in a perpetual buffering the video player

werimail commented 7 months ago

not all live shows are like "TV" so endless stream, there are streams that end when the live is finished i would like to avoid stall in a perpetual buffering the video player

Well @CastagnaIT I understand. Maybe it makes sense to initially limit the workaround to the provider “Pluto.TV”. If necessary, this could then be expanded to include additional providers if an encoder bug also exists there.

Would it be possible to provide a temporary fix for testing purposes? I could then test the behavior during live streams with different providers.

Greetings Weri

matthuisman commented 7 months ago

I can proxy Pluto add-on to make any changes we think are needed

On Wed, 13 Mar 2024, 21:32 werimail, @.***> wrote:

not all live shows are like "TV" so endless stream, there are streams that end when the live is finished i would like to avoid stall in a perpetual buffering the video player

Well @CastagnaIT https://github.com/CastagnaIT I understand. Maybe it makes sense to initially limit the workaround to the provider “Pluto.TV”. If necessary, this could then be expanded to include additional providers if an encoder bug also exists there.

Would it be possible to provide a temporary fix for testing purposes? I could then test the behavior during live streams with different providers.

Greetings Weri

— Reply to this email directly, view it on GitHub https://github.com/xbmc/inputstream.adaptive/issues/1507#issuecomment-1993815082, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPQAKLXRPM55PSMMZ2ODUTYYAFILAVCNFSM6AAAAABEQBC44CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTHAYTKMBYGI . You are receiving this because you were mentioned.Message ID: @.***>

werimail commented 7 months ago

I can proxy Pluto add-on to make any changes we think are needed

That doesn't sound bad @matthuisman I'm happy to make myself available for testing purposes.

Greetings Weri

CastagnaIT commented 7 months ago

i would wait @glennguy answer that he could know better HLS

maybe a kind of workaround could be, if no segments and EXT-X-ENDLIST signalled, then, ignore EXT-X-ENDLIST, perhaps this way there is less chance to broken regularly finished live streams, but i cant confirm

glennguy commented 7 months ago

Sorry for the delay in getting involved

I think that the playlist refresh shown above is some sort of error and not a valid playlist... don't know if it's technically invalid according to RFC but it still makes no sense.

if no segments and EXT-X-ENDLIST signalled, then, ignore EXT-X-ENDLIST,

This could certainly work around this situation but it's a very specific hack of sorts. Maybe something more generic like a playlist property to ignore the endlist tag? The problem then becomes if a live playlist actually ends we are stuck forever. Not a problem with Pluto most likely, but for example with Matt's Kayo Sports add-on it would be. Then do we add a further condition to check if there has been X amount of refreshes or Y time passed with no segment updates to abort playback? Is this good or bad design?

I'm not tied to anything in particular. If we can somewhat agree on a solution that resolves the issue in some way and isn't too hard to maintain then I'm all good :)

CastagnaIT commented 7 months ago

considering the maintenance aspect a property to ignore endlist tag is much easier to implement, otherwise you need to save at least one or more states between representation and manifest updates code thats seem quite chaotic

however, there is a consideration of stopping updates (and playback) if we don't receive more segments after some updates it is still necessary to implement an additional check to stop updates (so playback) if no more segments are received after a number of updates (more likely after 2 updates, not to make you wait too long due to interval time update)

for the new prop probably the best thing is add a generic "manifest_config" where contains a json dict value, so that can be extensible for other use cases, more likely this is a good place where move also live delay prop

but before doing this is necessary the merge of the PR rework also make a release because there are really too much changes

werimail commented 6 months ago

Hi @CastagnaIT maybe it's also a bit offtopic... but I had to notice that after the release of the rework with ISA version 21.4.4 the fix #1459 no longer "works". I used now Kodi 21RC2. The subtitles on the German broadcasters ARD and ZDF are displayed within the HLS streams no longer output. Did something “slip out” here (see also #1109 ) ??? With ISA version 21.4.3 this still works as usual! Greetings Weri

CastagnaIT commented 6 months ago

I expected some regression big changes and too much to test... i will try take a look

CastagnaIT commented 6 months ago

however not depends from PR https://github.com/xbmc/inputstream.adaptive/pull/1459 at least not directly because reverting that PR subs dont works anyway...

something dont work with pts, the following code https://github.com/xbmc/inputstream.adaptive/blob/a9debfa5b7ac8727bf43c44e548f5075f57e0fcf/src/Session.cpp#L1056-L1058 compare DTSorPTS from the sub reader and on the other side of < the audio/video readers, and so on

but sub pts value come from manifest and pts from a/v come from a/v packet itself that have another kind of value these two diffferent pts's cant be compared as want to do the above code

happen for example 1711890077000 < 16107247155 1711890077000 is the sub pts and will be never lower than the others so the sub packet will be never sent to kodi ofc hacking it to be lower subs works

atm i have i dont remember how was working before, i need to find the last working commit and place some debug lines

CastagnaIT commented 6 months ago

compiled previous release 21.4.3 and subtitle "works", i can notice following pts

2024-03-31 16:20:22.311 T:18844   debug <general>: AddOnLog: inputstream.adaptive: COMPARE: 10788000000 < 20835247155
2024-03-31 16:20:22.313 T:18844   debug <general>: AddOnLog: inputstream.adaptive: COMPARE: 20837327155 < 20835247155

the 10788000000 pts is from subtitles reader, this means that this problem was already present from old ISA versions, but hiddened, basically takes all the packets without taking pts into account, the comparator is useless is not consistent in this case

10788000000 and 20837327155 pts's arent comparable the situation is similar to the current 21.4.4, but since i have introduced EXT-X-PROGRAM-DATE-TIME to read the pts, has shown the problem because the pts is higher than pts of video reader...

@glennguy seem i found another old ISA bug

werimail commented 6 months ago

compiled previous release 21.4.3 and subtitle "works", i can notice following pts

2024-03-31 16:20:22.311 T:18844   debug <general>: AddOnLog: inputstream.adaptive: COMPARE: 10788000000 < 20835247155
2024-03-31 16:20:22.313 T:18844   debug <general>: AddOnLog: inputstream.adaptive: COMPARE: 20837327155 < 20835247155

the 10788000000 pts is from subtitles reader, this means that this problem was already present from old ISA versions, but hiddened, basically takes all the packets without taking pts into account, the comparator is useless is not consistent in this case

10788000000 and 20837327155 pts's arent comparable the situation is similar to the current 21.4.4, but since i have introduced EXT-X-PROGRAM-DATE-TIME to read the pts, has shown the problem because the pts is higher than pts of video reader...

@glennguy seem i found another old ISA bug

Hi @CastagnaIT , that sounds to me like there is a solution to the problem of subtitles not being displayed for the current ISA version?! Is a separate issue required for this or is it fixed straight away? Greetings Weri

CastagnaIT commented 6 months ago

i have two ideas to solve the "new-old" problem

1) replace streamReader->DTSorPTS from code above linked by using only manifest pts values. since it is just a packet selector based on the older pts, in theory (since there are to check what happens with multiple periods) should not make any difference, except that it would have consistent comparison pts. As i can see .ts package files, have stand-alone pts that seem not to correlate with periods/chapters. But for this change needs closer inspection, so before do something like this, i would like before a feedback from @glennguy. 2) a middle step before a possible point 1 solution. Consist in to remove period start pts from subtitle segment pts, this in theory should restore the previous situation where the pts are always lower than video pts. Not a solution but again a workaround.

Is the initial problem about ad breaks or X-discontinuity abort playback still present?

werimail commented 6 months ago

Is the initial problem about ad breaks or X-discontinuity abort playback still present?

Do you mean the current ISA version 21.4.4? Have you changed anything about this in the new version?

EDIT: I just tested with the current ISA version 21.4.4 and Kodi 21RC2. Unfortunately, the initial problem about ad breaks or X-discontinuity abort playback still occurs there.

Greetings Weri

CastagnaIT commented 6 months ago

i was testing more the original issue problem but i found new stream weirdness not only the EXT-X-ENDLIST is signalled in the middle of the live stream but noticed weird buffering behaviour because some segments are skipped

Problem 1: EXT-X-PROGRAM-DATE-TIME sometime is not precise, so incosistent, the same segment with X pts, after a manifest update dont keep the same X pts Problem 2: By "disabling" the uses of EXT-X-PROGRAM-DATE-TIME as segment startPTS, i have found that still skip segments, this time caused by inconsistent EXT-X-MEDIA-SEQUENCE values between manifest updates

i have attached some manifest updates to show the problems: manifests.zip

on the first manifest "manifest_1712578185_child-video.txt" the EXT-X-MEDIA-SEQUENCE is "6" on next files the value increase as it should, but, on file "manifest_1712578212_child-video.txt" become inconsistent, is "1", why not "11" ??

on next file from "manifest_1712578212_child-video.txt" become "2", then on next "manifest_1712578231_child-video.txt" there is the weird EXT-X-ENDLIST signal and on next last manifest the EXT-X-MEDIA-SEQUENCE have again an inconsistent value of "1"

i am pretty confused... this dont seem to be a regular HLS

werimail commented 6 months ago

i was testing more the original issue problem but i found new stream weirdness not only the EXT-X-ENDLIST is signalled in the middle of the live stream but noticed weird buffering behaviour because some segments are skipped

Problem 1: EXT-X-PROGRAM-DATE-TIME sometime is not precise, so incosistent, the same segment with X pts, after a manifest update dont keep the same X pts Problem 2: By "disabling" the uses of EXT-X-PROGRAM-DATE-TIME as segment startPTS, i have found that still skip segments, this time caused by inconsistent EXT-X-MEDIA-SEQUENCE values between manifest updates

i have attached some manifest updates to show the problems: manifests.zip

on the first manifest "manifest_1712578185_child-video.txt" the EXT-X-MEDIA-SEQUENCE is "6" on next files the value increase as it should, but, on file "manifest_1712578212_child-video.txt" become inconsistent, is "1", why not "11" ??

on next file from "manifest_1712578212_child-video.txt" become "2", then on next "manifest_1712578231_child-video.txt" there is the weird EXT-X-ENDLIST signal and on next last manifest the EXT-X-MEDIA-SEQUENCE have again an inconsistent value of "1"

i am pretty confused... this dont seem to be a regular HLS

O @CastagnaIT that doesn't look good at all...in my opinion, the example stream is also officially offered by Pluto.TV.

By the way...have you made any progress with the problem regarding the missing subtitles in the current ISA version 21.4.4? Has @glennguy commented on this before?

Greetings Weri

CastagnaIT commented 6 months ago

By the way...have you made any progress with the problem regarding the missing subtitles in the current ISA version 21.4.4? Has @glennguy commented on this before?

i opened a new PR to "add back" again the old workaround since a complete fix solution needs more time unfurnately glennguy seem not available on these days so all PR are still awaiting approval

werimail commented 6 months ago

By the way...have you made any progress with the problem regarding the missing subtitles in the current ISA version 21.4.4? Has @glennguy commented on this before?

i opened a new PR to "add back" again the old workaround since a complete fix solution needs more time unfurnately glennguy seem not available on these days so all PR are still awaiting approval

Ah ok, I must have missed @CastagnaIT , sorry... the first tests with PR #1522 are also positive, the subtitles are now displayed correctly again! Thanks for the dismantling and greetings Weri

glennguy commented 6 months ago

Apologies for my delays. I did start typing up a big reply to this thread on the weekend and forgot to finish it :/

werimail commented 6 months ago

By the way...have you made any progress with the problem regarding the missing subtitles in the current ISA version 21.4.4? Has @glennguy commented on this before?

i opened a new PR to "add back" again the old workaround since a complete fix solution needs more time unfurnately glennguy seem not available on these days so all PR are still awaiting approval

Ah ok, I must have missed @CastagnaIT , sorry... the first tests with PR #1522 are also positive, the subtitles are now displayed correctly again! Thanks for the dismantling and greetings Weri

Hi @CastagnaIT Unfortunately, another tests have shown that the subtitles are only displayed for a short period of time (a few seconds) and then disappear again. Is this also related to the problem here: #24777?

EDIT: further testing has shown that this only applies to HLS streams like https://mcdn.daserste.de/daserste/de/master.m3u8. DASH streams (http://mcdn.daserste.de/daserste/dash2/manifest.mpd) are not affected by this phenomenon. As a basis I used the current stable Kodi version 21.0 with the current ISA version from here: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1522/1/artifacts

EDIT2: another note... with ISA version 21.4.3 and fix #1496 and Kodi version 21.0, the subtitle display also works permanently with the HLS streams?!

Greetings Weri

CastagnaIT commented 6 months ago

this is a side effect of two problems 1) the problem already mentioned above, about wrong comparison DTSorPTS, that cause to fire the subtitle reader without control 2) an oversight on "if/else" conditions from a my recent PR that i forgot to fix

fix on #1526

PS. CI builds for android are broken, due to recent changes on xbmc repo

werimail commented 6 months ago

PS. CI builds for android are broken, due to recent changes on xbmc repo

@CastagnaIT So no test versions for android with Fix #1526 can be made available in the short term? Is this issue already known to the xbmc repo team?

Greetings Weri

CastagnaIT commented 6 months ago

no idea when team fix CI builds, if you have a pc you can test the Windows build

werimail commented 6 months ago

no idea when team fix CI builds, if you have a pc you can test the Windows build

No @CastagnaIT , unfortunately I don't have any Windows environments running. But I saw that the versions were built for iOS/OSX. I could test with those... but don't I need a combination of fixes #1522 and #1526 so that the subtitles are displayed with the current ISA version 21.4.4?

Greetings Weri

CastagnaIT commented 6 months ago

if you look at 1522 that pr is already "merged" so its already included

werimail commented 6 months ago

if you look at 1522 that pr is already "merged" so its already included

Thanks for this hint. I will try...

werimail commented 6 months ago

@CastagnaIT With fix #1526 for iOS, the subtitles work correctly again and are displayed permanently. However, when testing various DASH streams, I found that this one: http://mdrtvsndash.akamaized.net/dash/live/2094117/mdrtvsn/dash.mpd does not start (loading circuit) and Kodi returns to the selection? kodidebug_iOS.log.zip

Greetings Weri

glennguy commented 6 months ago

Looks like maybe an issue calculating the correct segment number - loops on downloading this with 404: Download failed, HTTP error 404: http://mdrtvsndash.akamaized.net/dash/live/2094117/mdrtvsn/dash960x540p50-130641.mp4 Not related to the issue in this thread but if you wanted to help us debug please post in a new issue the log plus a copy of the mpd.

werimail commented 6 months ago

Looks like maybe an issue calculating the correct segment number - loops on downloading this with 404: Download failed, HTTP error 404: http://mdrtvsndash.akamaized.net/dash/live/2094117/mdrtvsn/dash960x540p50-130641.mp4 Not related to the issue in this thread but if you wanted to help us debug please post in a new issue the log plus a copy of the mpd.

Yes @glennguy , that's right...that's more offtopic. I'm creating a separate isue for this EDIT: Done...see https://github.com/xbmc/inputstream.adaptive/issues/1527

Greetings Weri

werimail commented 6 months ago

Apologies for my delays. I did start typing up a big reply to this thread on the weekend and forgot to finish it :/

Hello @glennguy Will there be another detailed reply from you on the original issue (Aborting playback in the event of commercial breaks or X-discontinuity with the inputstream.adaptive addon)so that a possible fix can be made?

Thanks and greetings Weri

CastagnaIT commented 6 months ago

i tried again I think there are two ways to solve

1) fix the malformed EXT-X-MEDIA-SEQUENCE value to do this you need to find the right segment on the manifest update, and the only reference that can be used is EXT-X-PROGRAM-DATE-TIME

2) keep the wrong EXT-X-MEDIA-SEQUENCE that will be ignored because we sync "current" segment by using EXT-X-PROGRAM-DATE-TIME start pts

i roughly tested the 2° because more easy to implement, and i was able to get stable playback (discontinuities not tested yet)

EDIT: I forgot, the inappropriate use of EXT-X-ENDLIST of which randomly the service make use, is cause of buffering problems because the malformed manifest update is lacking of segments, so we exceed the time limit to provide segments, I tried to mitigate the problem by halving the update time interval temporarily

another problem found is that the provider, at playback start, can send the first manifest with EXT-X-ENDLIST, this is shitty thing... therefore its needed to implement a way to request the first manifest more times to get segments

it would be appropriate for PlutoTv to fixes its broken services... i will try in the next week the 1st approach if feasible without too much changes

CastagnaIT commented 6 months ago

ok i was able to implement method 1 without too much effort test builds here: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1532/1/artifacts

and for the faulty live streams you need to enable the workarounds as follow: add inputstream.adaptive.manifest_config with {"hls_ignore_endlist":true,"hls_fix_mediasequence":true}

werimail commented 6 months ago

Thanks @CastagnaIT with the implemented solution from PR #1532, streaming of this Pluto.TV channel has worked without any problems for me so far. The stream runs without major interruptions, even with advertisements. I'll keep watching...

Greetings Weri

werimail commented 6 months ago

Hi @CastagnaIT , further tests have shown that the stream freezes after a longer runtime. This usually always occurs just before a commercial break. Otherwise the stream runs without any major dropouts.

kodi.log manifest_1713266865_master.txt

Greetings Weri

CastagnaIT commented 6 months ago

i noticed that on ads or chapter switching there are doubled segments or however wrong things i suspect there is another ISA HLS parser bug something wrong with period selection for discontinuities i need to investigate better

CastagnaIT commented 6 months ago

new test build: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1532/2/artifacts let me know

CastagnaIT commented 6 months ago

doesnt matter test new build, found a new problem video freeze after ads discontinuities seem to happens when there is a broken manifest with EXT-X-ENDLIST between two updates

manifest_1713347449_child-video.txt manifest_1713347452_child-video.txt manifest_1713347454_child-video.txt

if try compare manifest_1713347449_child-video.txt with last manifest_1713347454_child-video.txt seem there are no correlations between segments/disconts

It seems as if EXT-X-ENDLIST is used to do a global "reset" of the HLS decoder state I will have to do a further test

werimail commented 6 months ago

Ok @CastagnaIT I'll wait for another fix before testing again...

Greetings Weri

CastagnaIT commented 6 months ago

i have collected a bit of manifests and maybe im wrong but to me when ads happens playlists most of time have unclear behaviours BadPlaylists.zip sometimes they change endpoints, sometimes the PTSs are out of whack, sometimes EXT-X-DISCONTINUITY-SEQUENCE is broken or with unclear values i would like to know how website manage this mess im trying to find a solution but its really a big mess...

EDIT: i found one of problems, its on the EXT-X-MEDIA-SEQUENCE fix that works not so good with discontinuities, more reworks needed

glennguy commented 6 months ago

It seems as if EXT-X-ENDLIST is used to do a global "reset" of the HLS decoder state

Yeah I would agree. This looks like abuse of that tag like they have a hack on their side for the HLS packaging with a corresponding hack in their player. IMO after EXT-X-ENDLIST appears for a playlist that stream should either become VOD (where the playlist has all segments from beginning of broadcast) or in this case should become 404 once enough time has passed for the timeshift buffer to expire. What they're doing makes no sense.

matthuisman commented 6 months ago

Im happy to add in proxy mods for Pluto if they arn't keeping to the standard. However, that wont help users using the proxy streams directly or the other pluto addons

ksooo commented 6 months ago

Yes, this would not help pvr.plutotv and other addons. It would be good to have all the „fixes“ at a central place, like IA.

CastagnaIT commented 6 months ago

Im happy to add in proxy mods for Pluto if they arn't keeping to the standard.

it won't be easy even with a proxy

in my investigations i found these weird behaviours:

I will try to see if i can improve the fix for EXT-X-MEDIA-SEQUENCE where in the current fix PR seems not to cover all use cases