LiveTV - Audio lost for a long / unpredictable time

    I am facing to this issue across several LE versions (from 9.2.6 to 11 Nightly) and more or less it's still the same or similar behavior.

    It usually happens when the DVB-T2 signal level / quality is not perfect but sometimes also right after switching the channel, even though the DVB-T2 signal is excellent. Then the Audio is lost (which means muted, it happens randomly, when the DVB-T2 signal drops for a moment or after switching to another channel and it takes an unpredictely long time to recover).

    When playing recording of the same stream, the audio is restored quickly but it does not happen with the live stream. Usually I need to switch to another channel (but then the TimeShift data is lost which is very annoying), sometimes it helps toggling audio stream (where there are more than one, which is not always).

    The current configuration is RPi 4B/2GB, LE 11 Nightly 20211108

    An example video recording:

    http://mysharegadget.com/729214965

    Debug log while LiveTV watching the same stream as the recording above (got back with TimeShift, activated Debug log before Audio was lost, deactivated Debug log when the Audio was back again):

    http://ix.io/3EsH

    The question is why there's a difference between LiveTV watching and recording play and if this can be improved (to recover audio quickly after stream corruption during LiveTV watching).

    BTW. as already reported in another thread, subtitles on this channel are not visible during LiveTV despite recorded properly and visible when playing recording ( this is an incompatibility of Kodi with Tvheadend 4.3 backend).

    Today encountered the audio issue on LE nightly 20211118 on Live TV channel (signal quality very good) with 2 audio AAC streams - the first one (2 channels 1/2) became silent and stayed silent during all Timeshift window (over 1 hour long).

    Manual switching to another available AAC stream (1 channels 2/2 ) was possible and audio was recovered. As soon as switched back to default AAC 2 channels 1/2 , audio was silent again. No matter of Timeshift positon.

    After switching to another Live TV channel and back, both audio streams started producing audio again.

    The same issue on LE 11 Nightly 20211215.

    Sometimes the Audio stream is not detected (Audio stream = None in Audio settings) after LE start (Play TV on startup is configured in Interface menu) or after a channel switch and the sound is silent (it does not matter if the Allow passthrough option is enabled or disabled in Audio settings).

    What are your video and audio codecs?

    Here it's hevc and aac.

    Even with a good signal quality, after switching to another TV channel, sometimes the audio is not detected properly. Very annoying and long lasting bug. Usually there are 2 options selectable in the audio stream settings:

    Czech - AAC - 2 channels (1/2)

    Czech - AAC - 1 channels (2/2)

    Where the first one is working option which is usually selected automatically. The second option (Czech - AAC - 1 channels (2/2)) is producing silent only.

    And sometimes after switching the channel, there's only the second (thus not working) option is there or there's even no audio stream option available.

    Switching to another channel and back usually fixes the issue .

    The same issue with LE 11 Nightly 20221015-6352186.

    Currently I see the issue most often after TV channel switch (even though the DVB-T signal is perfect) when some (working) audio streams are not detected at all.

    Hi,

    I don't think to be a Kodi or Libreelec issue. It's something with PVR backend-frontend.

    Please share some details about your device, TVHeadend(?) versions, if the server is on same RPi...

    I'm using 3 RPi3's in local network, LE11, TVHeadend server 4.3, 3 tuners (2x DVB-C, 1x DVB-T2) and don't experienced any similar issue.

    If you use the TVH server 4.3, maybe try the 4.2 to see if same issue produced. No need to uninstall the 4.3, only disable it in addon settings.

    To verify if a frontend or backend (server) issue, try to install the Kodi on another device (laptop, phone-android) and check it.

    Thanks for the feedback. Regarding to configuration - most info s in the post #1. There's Tvheadend server 4.3 running. Latest add-ons available installed.

    I think it could be related with AAC stream (used in our country and perhaps it's not widely used around the world so maybe that's the reason why nobody else encountered the same issue) which is not always detected properly by the layer responsible for LiveTV stream play.

    I don't plan to try testing with Tvheadend 4.2 as with this random issue it would be just time wasting.

    I don't think the issue ever happened with stream recording so the stream itself should be OK (need to say I use recording in rare cases).

    Why the hell the player can't sometimes detect the live audio stream properly?

    Quote from ghtester

    I don't plan to try testing with Tvheadend 4.2 as with this random issue it would be just time wasting.

    I don't think the issue ever happened with stream recording so the stream itself should be OK (need to say I use recording in rare cases).

    Why the hell the player can't sometimes detect the live audio stream properly?

    About trying the TVH 4.2... as you wish...

    The AAC stream not so exotic in case of DVB-T2, I have found it in my setup in a few channels (even if I watching very seldom that channels), and didn't noticed same issue.

    Also I checked your log, don't know if now is the same situation is present, but looks like you had the TVHeadend 4.2 and 4.3 too installed:

    2021-11-09 03:57:13.212 T:1449 INFO <general>: CAddonMgr::FindAddons: service.tvheadend42 v9.80.11.125 installed

    2021-11-09 03:57:13.212 T:1449 INFO <general>: CAddonMgr::FindAddons: service.tvheadend43 v10.80.2.102 installed

    and:

    Nov 09 04:26:20.700309 LE tvheadend[360]: TS: PRG-U/642MHz/Nova: AAC-LATM @ #274 Continuity counter error

    ....

    Nov 09 04:26:27.350300 LE tvheadend[360]: tsfix: transport stream AAC-LATM, DTS discontinuity. DTS = 22256813, last = 22068651

    ....

    You have a lot of transport stream AAC-LATM, DTS discontinuity and Continuity counter error, so trying with another version of TVH, another tuner, checking the antenna cable and connections... could be a good idea...

    Thanks again for your time & analysis.

    Yes I have both Tvheadend servers 4.2 and 4.3 installed, 4.2 disabled a long time ago and currently using 4.3 (despite the another issue with subtitles as reported long time ago in another thread). I supposed the 4.3 should be the release with active development progress (in opposite the 4.2 as developers usually stops development of older versions). Unfortunately my issues still persists.

    The old stream samples / logs really had the transport errors due to weak DVB-T2 signal. This is not the current problem, the issue with "missing" audio stream happen even though the signal is perfect, just after switching the DVB-T2 channel to another one. Looks like some timing issue or whatever similar... Don't know how the stream parameters are recognized but for sure it's done just one time after the play start (or maybe again when the stream is interrupted temporarily). And this one-time detection of audio sometimes fails (at least in my case).

    Yes if the signal is bad, the audio is sometimes lost during the LiveTV watching and sometimes can't be recovered for long time or ever (or until switched to another channel). But when the same (bad) stream is recorded, when I play the same recording, audio is recovered quickly (after the interruption point). The issue is with the live player (don't know / understand a difference between live and recordings play process). The same difference with subtitles that won't show on some channels during LiveTV watching using Tvh 4.3 but visible from recordings of the same channel (subtitles works on all live channels with Tvh 4.2).

    Edited 2 times, last by ghtester (October 17, 2022 at 5:37 PM).

    Quote from VLouis

    Nov 09 04:26:20.700309 LE tvheadend[360]: TS: PRG-U/642MHz/Nova: AAC-LATM @ #274 Continuity counter error

    ....

    Nov 09 04:26:27.350300 LE tvheadend[360]: tsfix: transport stream AAC-LATM, DTS discontinuity. DTS = 22256813, last = 22068651

    ....

    You have a lot of transport stream AAC-LATM, DTS discontinuity and Continuity counter error, so trying with another version of TVH, another tuner, checking the antenna cable and connections... could be a good idea...

    I have seen your log and it reminds me of the logs that occur during the IPTV broadcast of the free Pluto TV channels in tvheadend (I use version 4.3 of docker linuxserver/tvheadend for LE x86_64). Within this service I have installed, and absolutely updated, the ffmpeg, cvlc and streamlink players that I encapsulate through pipe for tvheadend. Well, with these players, the sound is often lost when discontinuities appear, that is, when ads are inserted or a new video clip starts in the stream (this does not happen when the stream is played from the VLC application on a PC ). Sound can be recovered by enabling and disabling the passthrough option within Kodi in LE, until the next discontinuity.

    The only solution I've found is to use the docker proxy dnsforge/xteve processing the output to tvheadend with xteve's internal ffmpeg, and pipe this output with cvlc, only then does everything work fine except the loss of a few seconds of image and sound frames in the discontinuities. This solution has a problem: it cannot be applied to the case of live television from a tuner.

    My suspicion is that it is a problem with tvheadend or Kodi's native player. The logs do not provide any clues.

    Edited once, last by elonesna (October 17, 2022 at 6:19 PM).

    Thanks for the comment / shared experience. It looks to me like the internal player tries starting play the stream too quickly, before detecting the live stream's parameters safely / properly (at least regarding to audio and subtitle tracks).

    I don't know if it really make sense from technical point of view but it looks to me it's like that. Because both described issues happen with live stream but not that bad with the same recorded stream.

    I have no idea if it's possible to try some configuration changes in Kodi / LE to improve that behavior or not...