Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broken HLS AES-128 decryption and live audio buzzy #1132

Open
3 of 7 tasks
CrAcK75 opened this issue Feb 10, 2023 · 30 comments · Fixed by #1133 or #1246
Open
3 of 7 tasks

Broken HLS AES-128 decryption and live audio buzzy #1132

CrAcK75 opened this issue Feb 10, 2023 · 30 comments · Fixed by #1133 or #1246
Labels
Resolution: Partially fixed issue was resolved with a workaround in the code, which may require future changes for a full fix Triage: Confirmed issue has been reproduced by a team member

Comments

@CrAcK75
Copy link

CrAcK75 commented Feb 10, 2023

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:

image

Additional context or screenshots (if appropriate)

Here is some additional context or explanation that might help:

Your Environment

Used Operating system:

  • Android

  • iOS

  • tvOS

  • Linux

  • OSX

  • 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
Copy link
Contributor

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 3d6e4e1 it works but 06320be didn't. After finding this I couldn't access any longer to be able to debug.

@CrAcK75
Copy link
Author

CrAcK75 commented Feb 11, 2023

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

@CastagnaIT
Copy link
Collaborator

yes i will try check

@CastagnaIT CastagnaIT added the Triage: Confirmed issue has been reproduced by a team member label Feb 11, 2023
@CastagnaIT
Copy link
Collaborator

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
Copy link
Contributor

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

@enigma131
Copy link

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

@CrAcK75
Copy link
Author

CrAcK75 commented Feb 15, 2023

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
Copy link
Contributor

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

@glennguy glennguy reopened this Feb 16, 2023
@glennguy glennguy changed the title Latest version (20.3.3) broken audiotracks recognition on Kodi 20 Latest version (20.3.3) broken HLS AES-128 decryption Feb 16, 2023
@CrAcK75
Copy link
Author

CrAcK75 commented Feb 17, 2023

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
Copy link

On catchup tv and more , no option to go back

@glennguy
Copy link
Contributor

glennguy commented Feb 19, 2023

@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
Copy link
Contributor

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
Copy link
Author

CrAcK75 commented Feb 21, 2023

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
Copy link
Collaborator

CastagnaIT commented Feb 23, 2023

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

@CastagnaIT CastagnaIT changed the title Latest version (20.3.3) broken HLS AES-128 decryption Broken HLS AES-128 decryption and live audio buzzy Feb 23, 2023
@CrAcK75
Copy link
Author

CrAcK75 commented Mar 16, 2023

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
Copy link

yazyazoo commented Apr 22, 2023

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

@CrAcK75
Copy link
Author

CrAcK75 commented Apr 26, 2023

@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
Copy link

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
Copy link

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
Copy link

ciro97RM commented May 1, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link

ciro97RM commented May 1, 2023 via email

@campipaolo
Copy link

campipaolo commented May 1, 2023 via email

@CrAcK75
Copy link
Author

CrAcK75 commented May 1, 2023

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
Copy link
Collaborator

CastagnaIT commented May 6, 2023

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

@CastagnaIT CastagnaIT reopened this May 6, 2023
@CastagnaIT CastagnaIT added the Resolution: Partially fixed issue was resolved with a workaround in the code, which may require future changes for a full fix label May 6, 2023
@CrAcK75
Copy link
Author

CrAcK75 commented Jul 20, 2023

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

@CastagnaIT
Copy link
Collaborator

CastagnaIT commented Jul 22, 2023

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
Copy link
Author

CrAcK75 commented Jul 25, 2023

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
Copy link
Author

CrAcK75 commented Jul 26, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Partially fixed issue was resolved with a workaround in the code, which may require future changes for a full fix Triage: Confirmed issue has been reproduced by a team member
Projects
None yet
8 participants