Broken HLS AES-128 decryption and live audio buzzy

[CrAcK75]

trafficstars

Bug report

Describe the bug

The latest versione of Inputstream 20.3.3 has broken something on Kodi 20 with this stream, now there is no audio: Rai1 => https://mediapolis.rai.it/relinker/relinkerServlet.htm?cont=2606803&output=7 If I downgrade to the previous 20.3.2 it works again

Expected Behavior

Here is a clear and concise description of what was expected to happen:

Actual Behavior

Audio not present

Possible Fix

No possible fix found, only if downgrade to the previous 20.3.2 it works again

To Reproduce

Steps to reproduce the behavior:

1. start the stream

Debuglog

The debuglog can be found here: this a portion of log when the channel starts: kodi.log

MPD/M3U8s/ISM

An example or copy of a manifest (or manifests for HLS - master and variants) can be found here: https://mediapolis.rai.it/relinker/relinkerServlet.htm?cont=2606803&output=7

this is the m3u8 that in this moment become from the url: playlist_ma.m3u8.txt

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:

• [X] Android

• [ ] iOS

• [ ] tvOS

• [X] Linux

• [ ] OSX

• [X] Windows

• [ ] Windows UWP

• Operating system version/name: Windows (10, 11) or AndroidTV (Box, Firestick)

• Kodi version: 20

• inputstream.adaptive version: 20.3.3

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.

[glennguy]

Thanks for the report @CrAcK75

I was able to have a brief look shortly after you posted this using the links in the log but now I get geoblocked.

@CastagnaIT since this stream is local to you are you able to investigate?

Going back to https://github.com/xbmc/inputstream.adaptive/commit/3d6e4e1c00c4df03b7a2a16a2822575238b3d34e it works but https://github.com/xbmc/inputstream.adaptive/commit/06320be036c03a20d0aa31c6cf20d41e6000c94d didn't. After finding this I couldn't access any longer to be able to debug.

[CrAcK75]

Yes @glennguy , unfortunatly is geobloked... the previous version works but often the audio is buzzy for streaming many of the RAI broadcaster channels

[CastagnaIT]

yes i will try check

[CastagnaIT]

Not sure but a possibility, about the audio corrupted for about 1sec every tot of seconds/minute @glennguy could be that the problem come from different EXT-X-MEDIA-SEQUENCE value between audio/video ?

here an example: audio.m3u8.txt video.m3u8.txt

[glennguy]

No the media sequence looks right, even lines up nicely with the segment numbers...

[enigma131]

With this version, I have no audio on some channels via catchup tv and more plugin. How to debug ?

[CrAcK75]

Not sure but a possibility, about the audio corrupted for about 1sec every tot of seconds/minute @glennguy could be that the problem come from different EXT-X-MEDIA-SEQUENCE value between audio/video ?

here an example: audio.m3u8.txt video.m3u8.txt

Any news about the corrupted audio?

[glennguy]

Do you have the same problem if you seek backwards 20 seconds and then continue watching from there?

[CrAcK75]

Do you have the same problem if you seek backwards 20 seconds and then continue watching from there?

Yes, I had some users carry out some tests and they all confirmed that going back about 20 seconds seems to solve the problem, the devices used were both PCs with Windows or Linux and devices with Android such as Firestick (before or last generation, or firestick 4k), MiboxS or Smartphone. In addition, in that case it seemed to me that the "large audio sync error" error does not appear in the Kodi log anymore.

[enigma131]

On catchup tv and more , no option to go back

[glennguy]

@CrAcK75 Thanks heaps for testing.

So for me this looks to be a service provider issue. @CastagnaIT provided some examples of downloaded manifests and it looks like a problem where stream segments on the live edge aren't being uploaded close enough together. The segments are 10 seconds long and IA by default (iirc) will try to start live streams in a segment that's 12-16 seconds away from the live edge.

Example:

• stream starts
• newest segment for audio/video is segment number 20, 10 seconds long each. This newest segment has just been added.
• Playback starts at 20 seconds from the live edge - segment 19.
• Kodi has 8 seconds internal buffer which it immediately consumes, and after two seconds starts reading segment 20
• IA refreshes the audio/video playlists after switching segment.
• At the 12 second point, Kodi would be needing to read into segment 21. By rights in this scenario, a new segment should have been added on the server at the 10 second mark.
• What we've observed in the logs, is that audio segment 21 has been added to the audio playlist at this point, but the video playlist is still at segment 20.

What I think happens next is that Kodi will receive some samples/packets from the audio stream before the video stream enters the 'waitforsegment' state, and it doesn't really like this so we get the buzzing until new video data is received and VideoPlayer can resync it.

Really, I think this problem would be solved if they didn't have such a giant segment size. 2-4 seconds is more typical and would prevent there being such a delay in publishing segments - in this case the video segments are 3-4MB!

@CastagnaIT what do you think about having a stream property that lets add-ons/m3u8 playlists set a minimum live edge buffer? When we call AdaptiveStream::start_stream it will start the stream no closer to the edge than this amount, and prevent seeking past this time as well. DASH streams will use the suggestedPresentationDelay attribute to set the existing live_delay_ member on the tree, we can just provide an override via the stream property to update this variable.

[glennguy]

One more thing to add - I would bet if you played the RAI stream on Kodi and the official web/mobile app at the same time, the Kodi stream would be a number of seconds ahead.

[CrAcK75]

One more thing to add - I would bet if you played the RAI stream on Kodi and the official web/mobile app at the same time, the Kodi stream would be a number of seconds ahead.

I'll check soon, my first check on Kodi Windwos vs Web is 20/25 secconds ahead

a little bit less between app mobile and kodi on firestick

other tests by some users had the same results, at least 20 seconds ahead

[CastagnaIT]

what do you think about having a stream property that lets add-ons/m3u8 playlists set a minimum live edge buffer?

now premise that i am not clear how all this works but this to me sound like a workaround i understand that RAI service is ugly (not new that italy government services suck) but at least testing RAI stream on some stream tester online (e.g. hls-js.netlify.app) there are no playback problem if the audio packages are ahead of the video why not stop and wait for video become ready? or at least a method of determining a delay change

from session we always force live_delay_ to 16 despite manifest settings

[CrAcK75]

what do you think about having a stream property that lets add-ons/m3u8 playlists set a minimum live edge buffer?

now premise that i am not clear how all this works but this to me sound like a workaround i understand that RAI service is ugly (not new that italy government services suck) but at least testing RAI stream on some stream tester online (e.g. hls-js.netlify.app) there are no playback problem if the audio packages are ahead of the video why not stop and wait for video become ready? or at least a method of determining a delay change

from session we always force live_delay_ to 16 despite manifest settings

Any news about this?

[yazyazoo]

I've the same issue: the audio corrupted for about 1sec every tot of seconds / minute. please fix it.

[CrAcK75]

@glennguy @CastagnaIT please, could you fix this? a lot of user that using my kodi addon are waiting a fix and they send me at lease 2 message per day... what could I answer them?

[JaneEyre76]

Hi, I've been experiencing the issue for several months already...since Kodi 20 was released. I've got Android TV boxes and sticks such as Xiaomi and Nokia. The problem with Rai channels comes up at every use and it is really absolutely frustrating. The buzz is quite often so unbearable so that it prevents from watching. Do, please, get a solution!

[campipaolo]

Hi guys, I'm running on Linux Mint 21 Xfce with Kodi 21.1 and right now buzz still persist, unfortunately. It's benn a long time since this ticket was open, hope you'll find a solution to make again Kodi perfectly with pvr experience! Thanks for support and great work in these past years

[ciro97RM]

Hi! I've been experiencing the issue too: the problem with Rai channels comes up at every use and it is really absolutely frustrating. I have an Android TV boxe and an two Amazon fire sticks. Please get a solution!

[CastagnaIT]

I understand your frustration about the audio buzzing problem but we are still investigating and we do not yet have a complete solution

for a full solution seem to require fixes also on Kodi core and will probably require the help of other team developers, to do this will take much longer time and i am talking of months not days, if so you will have to wait also a new Kodi release that include the patch, or use nightlies builds

what we can try to do now its the workaround as mentioned by glennguy above today i tested the workaround that consist in to add additional playback delay (default was 16secs) to 20 secs or more

so i tried set to 20 secs delay and played live video about 20 times and i get just 1 time buzz problem on 20 attempts this workaround quite good but not great, when buzz still happens you needed to stop and restart playback then should disappears, plus there is the disadvantage that sometimes there will be a very long delay of the audio at the beginning of playback (about 10secs)

i will prepare a test build with the workaround so you can give me a feedback

[CastagnaIT]

i have implemented the delay workaround it can be also customized by an addon by using following property (or also added to strm) listitem.setProperty('inputstream.adaptive.live_delay', 'xx') where xx stand for n seconds (must be >= 16)

in the following test builds the delay its already increased to 20secs (from default of 16), then no actions are required just install and play the live videos

test builds for some common operative systems here: Kodi 20: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1247/2/artifacts Kodi 21: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1246/1/artifacts

let me know

[ciro97RM]

I’m testing the fix right now and seems to work perfectly. Thanks a lot. Inviato da iPhoneIl giorno 1 mag 2023, alle ore 18:45, Stefano Gottardo @.***> ha scritto: i have implemented the delay workaround it can be also customized by an addon by using following property (or also added to strm) listitem.setProperty('inputstream.adaptive.live_delay', 'xx') where xx stand for n seconds (must be >= 16) in the following test builds the delay its already increased to 20secs (from default of 16), then no actions are required just install and play the live videos test builds for some common operative systems here: Kodi 20: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1247/2/artifacts Kodi 21: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1246/1/artifacts let me know

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[campipaolo]

Testing new IA on Xiaomi Stick Android 9 It seem works with new pvr version

Il lun 1 mag 2023, 19:40 ciro97RM @.***> ha scritto:

I’m testing the fix right now and seems to work perfectly. Thanks a lot. Inviato da iPhoneIl giorno 1 mag 2023, alle ore 18:45, Stefano Gottardo @.***> ha scritto: i have implemented the delay workaround it can be also customized by an addon by using following property (or also added to strm) listitem.setProperty('inputstream.adaptive.live_delay', 'xx') where xx stand for n seconds (must be >= 16) in the following test builds the delay its already increased to 20secs (from default of 16), then no actions are required just install and play the live videos test builds for some common operative systems here: Kodi 20: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1247/2/artifacts Kodi 21: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.adaptive/detail/PR-1246/1/artifacts let me know

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/xbmc/inputstream.adaptive/issues/1132#issuecomment-1529997303, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3YIRC2PC2KIABMEBPKIKJDXD7YSDANCNFSM6AAAAAAUYJFT5I . You are receiving this because you commented.Message ID: <xbmc/inputstream .@.***>

[CrAcK75]

I understand your frustration about the audio buzzing problem but we are still investigating and we do not yet have a complete solution

for a full solution seem to require fixes also on Kodi core and will probably require the help of other team developers, to do this will take much longer time and i am talking of months not days, if so you will have to wait also a new Kodi release that include the patch, or use nightlies builds

what we can try to do now its the workaround as mentioned by glennguy above today i tested the workaround that consist in to add additional playback delay (default was 16secs) to 20 secs or more

so i tried set to 20 secs delay and played live video about 20 times and i get just 1 time buzz problem on 20 attempts this workaround quite good but not great, when buzz still happens you needed to stop and restart playback then should disappears, plus there is the disadvantage that sometimes there will be a very long delay of the audio at the beginning of playback (about 10secs)

i will prepare a test build with the workaround so you can give me a feedback

I understand ALL friend... I think the 'inputstream.adaptive.live_delay' is the best solution for now, I'll modify my addon only for RAI channels to avoid the buzz, also I think that if the 20 seconds instead of 16 could influence negativelly other channels, probably is better to return at 16 sec .. but you known better the inputstream addon so, only you known what is really better. From my first tests, with 25 sec of delay, this works very well, if I leave the default now on 01/05/2023 23.10 on Rai3 it doesn't work

[CastagnaIT]

reopened to keep track of future fixes to do, the fix workaround for buzzing problem has been merged (https://github.com/xbmc/inputstream.adaptive/wiki/Integration#inputstreamadaptivelive_delay-) and will be available on next ISA release

[CrAcK75]

Hi @CastagnaIT , the audio buzz seems to be came back

[CastagnaIT]

the live delay its a workaround and not a real solution then can fail if you mean on kodi 21 only, its possible that depends on the internal buffering that has been recently limited to lower value so more likely you will need to increase the live delay to 3x the segment duration instead of 2x, so value 33

[CrAcK75]

the live delay its a workaround and not a real solution then can fail if you mean on kodi 21 only, its possible that depends on the internal buffering that has been recently limited to lower value so more likely you will need to increase the live delay to 3x the segment duration instead of 2x, so value 33

Our community users uses only the Kodi stable version, so kodi 20, a week ago all was ok. My delay valute was already set to 33 and the buzz Is present

[CrAcK75]

the live delay its a workaround and not a real solution then can fail if you mean on kodi 21 only, its possible that depends on the internal buffering that has been recently limited to lower value so more likely you will need to increase the live delay to 3x the segment duration instead of 2x, so value 33

really sorry ... probably it was my fault caused by a code typo or bug