LiveTV - Audio lost for a long / unpredictable time

  • Hi,

    Another ways to check the stream coming from TVH server:

    1. Install the Kodi to another device (PC, Android), install the TVHeadend client addon and try if the same issue appear.

    2. Download the channel list as m3u playlist (browser: http://ip:9981/playlist - "TVH-IP" = IP of device where the Tvheadend server installed).

    Try to open the channel with another video player (ex: VLC).

    In the both case if the playback not perfect (interrupted sound or video), means the stream from TVHeadend server have errors (antenna signal quality?).

  • Just to confirm this annoying bug is still present in LE 12 Nightly ( nightly-20230527-557e821 (RPi4.aarch64) ).

    Also sometimes the audio stream (usually AAC) is not detected at all after switching Live TV channels, even though the signal quality is great.

  • I'm swatting flies but it works, in modern IPTV HLS streams with ads, in playlists for tvheadend, I pass the URL of each channel through streamlink+ffmpeg+cvlc using a personal tvhdecode.sh script... and it works .

    I sense that now many TV streams or other, include DRM codes that need specific hardware/software in which linux is excluded or license burned in of the SoC itself, and only work well in major browsers or android applications, or some certified devices.

    Now I'm testing with Jellyfin clients that receive streams from the server from the playlists generated by tvheadend and the tests are interesting, with Android you can use the processing with the internal player based on ExoPlayer!.

    I hope I didn't bore you!

    Edited once, last by elonesna (May 27, 2023 at 3:47 PM).

  • Also sometimes the audio stream (usually AAC) is not detected at all after switching Live TV channels, even though the signal quality is great.

    This stupid and very annoying issue is still here ( nightly-20230910-09641de (RPi4.aarch64) ) :(

    I wonder why this can happen.

  • I don't expect somebody of developers could have a look on it but there's a log of issue encountered.

    It's too big for pastebin so I have used the local sharing platform which can hold it for 30 days:

    https://www.uschovna.cz/en/download/MZIDD66ZDCVY2LBS-4F5/5693GL2MA6/

    The issue happened at about 9:19 when the short stream data corruption led to silenced audio.

    Then I rewound a bit using timeshift and enabled the debug output So the issue repeated again at about 9:31.

    I would expect the audio should be restored quickly but it stayed silent.

    I also have the stream data recorded (at the time of the issue) by tvheadend but due to format used it can't be easily played.

  • i can confirm this is happening to me as well for last couple of years. no matter tvheadend or kodi version. I have observed, that this happens also when recording a tv show, so this looks more like a tvheadend server bug. Also from what i see, it happens to ghtester in czech republic, which is the same location as mine, so it may be the connected with h.265 codec, which is used here for dvb-t2...

  • i can confirm this is happening to me as well for last couple of years. no matter tvheadend or kodi version. I have observed, that this happens also when recording a tv show, so this looks more like a tvheadend server bug. Also from what i see, it happens to ghtester in czech republic, which is the same location as mine, so it may be the connected with h.265 codec, which is used here for dvb-t2...

    Yes in the Czech rep. it's a bit specific situation due to h.265 codec so I understand that developers from other countries (where the h.264 is still in use) don't see any issues.

    I am recording the tv programs exceptionally so I did not encounter the audio issue in this case - but when tested the behavior with bad signal level, during play of the recorded file the audio could be recovered after a temporary loss but this did not happen during live TV play of the same interval of the same program (and the audio stayed muted).

    BTW. I see that tvheadend server has more troubles with channels using fast data stream (CT1, CT2 - h.265, 1080 HD), where especially the timeshift often fails after some time.


    It's probably related to AAC audio. See here.

    Thanks for the link, unfortunately it seems it can't be fixed...

    Edited 2 times, last by ghtester: Merged a post created by ghtester into this post. (May 4, 2024 at 9:18 AM).