Re-tune channels after errors - Mygica T230 DVB-T2 - Tvheadend

Re-tune channels after errors - Mygica T230 DVB-T2

Hello,

We have a Mygica T230 used for DVB-T2 live TV streams. It works fine most of the times, but sometimes (about 1 of every 10 tunings) there is no output or the screen is green with noise, and tvheadend generates a lot of errors. This seems to be a problem with the USB stick, as we had this problem with this stick in different versions of Linux, tvheadned, using transcoding or not using it, etc., also in Windows. When watching Live TV we can stop and restart or tune another channel and return to the original and it usually works Ok. However the issue is with recordings, as the recording will fail in these cases.

We tried changing some parameters in the adapter config, for example we changed the "# tune repeats" to 1, 2, 3.. but this is not helping as the isue is totally random.. so it could appear after the 2nd or 3rd tuning.

My question is: is there any way for tvheadend to detect that tuning of a channel is having errors, or detect that error number is big, and then stop and restart the tuning? For example, after 1000 errors stop and restart. This will really help us with the issues we have with recordings.

For reference, below there is part of the log output for one of these failed tunings. I also attached a screenshot of the tvheadend status output showing the amount of errors. Thanks!

2019-02-26 11:06:08.560 subscription: 007D: "192.168.15.136 [ remoto | Kodi Media Center ]" subscribing on channel "NTN 24", weight: 100, adapter: "Silicon Labs Si2168 #0 : DVB-T #0", network: "Col", mux: "479MHz", provider: "RCN TELEVISION", service: "NTN 24", profile="remoto", hostname="192.168.15.136", username="remoto", client="Kodi Media Center" 
2019-02-26 11:06:08.884 transcode: 0016: 01:H264: ==> Using profile remoto
2019-02-26 11:06:08.885 transcode: 0016: 02:MPEG2AUDIO: ==> Using profile webtv-aac
2019-02-26 11:06:09.636 TS: Col/479MHz/NTN 24: H264 @ #701 Continuity counter error (total 1)
2019-02-26 11:06:09.804 TS: Col/479MHz/NTN 24: MPEG2AUDIO @ #702 Continuity counter error (total 1)
2019-02-26 11:06:10.154 tbl-base: sdt: 479MHz in Col: invalid checksum (len 243, errors 1)
2019-02-26 11:06:10.322 TS: Col/479MHz/NTN 24: H264 @ #701 Corrupted PES header (errors 1)
2019-02-26 11:06:10.468 tbl-base: pat: 479MHz in Col: invalid checksum (len 44, errors 1)
2019-02-26 11:06:14.844 tbl-eit: eit: 479MHz in Col: invalid checksum (len 180, errors 1)
2019-02-26 11:06:17.872 tbl-base: pmt: 479MHz in Col: invalid checksum (len 76, errors 1)
2019-02-26 11:06:18.102 TS: Col/479MHz/NTN 24 Transport error indicator (total 1)
2019-02-26 11:06:18.749 tbl-base: cat: 479MHz in Col: invalid checksum (len 12, errors 1)
2019-02-26 11:06:19.599 TS: Col/479MHz/NTN 24: H264 @ #701 Continuity counter error (total 928)
2019-02-26 11:06:19.971 TS: Col/479MHz/NTN 24: MPEG2AUDIO @ #702 Continuity counter error (total 49)
2019-02-26 11:06:21.893 tbl-base: sdt: 479MHz in Col: invalid checksum (len 243, errors 5)
2019-02-26 11:06:22.093 tsfix: The timediff for MPEG2AUDIO is big (948160), using current dts
2019-02-26 11:06:22.102 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (16080 != 42000)
2019-02-26 11:06:22.104 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (49680 != 97200)
2019-02-26 11:06:22.113 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (127920 != 160320)
2019-02-26 11:06:22.116 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (168000 != 204720)
2019-02-26 11:06:22.120 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (218160 != 237600)
2019-02-26 11:06:22.123 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (249120 != 279360)
2019-02-26 11:06:22.127 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (290880 != 312480)
2019-02-26 11:06:22.130 tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = 583200, last = 321840
2019-02-26 11:06:22.130 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (324000 != 583200)
2019-02-26 11:06:22.133 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (592800 != 614400)
2019-02-26 11:06:22.139 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (635520 != 678720)
2019-02-26 11:06:22.145 tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = 918000, last = 699840
2019-02-26 11:06:22.146 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (701760 != 917760)
2019-02-26 11:06:22.153 libav: AVCodecContext: mmco: unref short failure
2019-02-26 11:06:22.153 libav: AVCodecContext: mmco: unref short failure
2019-02-26 11:06:22.153 libav: AVCodecContext: number of reference frames (0+4) exceeds max (3; probably corrupt input), discarding one
2019-02-26 11:06:22.159 libav: AVCodecContext: mmco: unref short failure
2019-02-26 11:06:22.206 libav: AVCodecContext: mmco: unref short failure
2019-02-26 11:06:22.206 libav: AVCodecContext: mmco: unref short failure
2019-02-26 11:06:22.206 libav: AVCodecContext: number of reference frames (0+4) exceeds max (3; probably corrupt input), discarding one
2019-02-26 11:06:22.207 libav: AVCodecContext: mmco: unref short failure
2019-02-26 11:06:22.315 libav: AVCodecContext: Increasing reorder buffer to 2
2019-02-26 11:06:22.316 libav: AVCodecContext: Found reference and non-reference fields in the same frame, which
2019-02-26 11:06:22.316 libav: AVCodecContext:  is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
2019-02-26 11:06:22.316 libav: AVCodecContext: If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. ([email protected])
2019-02-26 11:06:22.316 libav: AVCodecContext: decode_slice_header error
2019-02-26 11:06:22.316 libav: AVCodecContext: Failed to upload decode parameters: 18 (invalid parameter).
2019-02-26 11:06:22.316 libav: AVCodecContext: Failed to end picture decode after error: 18 (invalid parameter).
2019-02-26 11:06:22.316 libav: AVCodecContext: hardware accelerator failed to decode picture
2019-02-26 11:06:22.424 tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = 1144800, last = 937440
2019-02-26 11:06:22.424 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (938880 != 1144080)
2019-02-26 11:06:23.492 tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = 1252800, last = 1153440
2019-02-26 11:06:23.492 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1155600 != 1252800)
2019-02-26 11:06:24.373 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1283520 != 1292160)
2019-02-26 11:06:25.042 tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = 1393200, last = 1293840
2019-02-26 11:06:25.043 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1296000 != 1393200)
2019-02-26 11:06:25.148 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1400880 != 1403040)
2019-02-26 11:06:26.047 tbl-eit: eit: 479MHz in Col: invalid checksum (len 180, errors 5)
2019-02-26 11:06:26.915 tbl-base: pat: 479MHz in Col: invalid checksum (len 44, errors 4)
2019-02-26 11:06:27.047 TS: Col/479MHz/NTN 24: H264 @ #701 Corrupted PES header (errors 5)
2019-02-26 11:06:27.048 tsfix: transport stream MPEG2AUDIO, DTS discontinuity. DTS = 1566000, last = 1423440
2019-02-26 11:06:27.048 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1424160 != 1564560)
2019-02-26 11:06:27.601 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1576080 != 1608480)
2019-02-26 11:06:27.752 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1616160 != 1618320)
2019-02-26 11:06:28.593 tbl-base: pmt: 479MHz in Col: invalid checksum (len 76, errors 13)
2019-02-26 11:06:28.739 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1647120 != 1716240)
2019-02-26 11:06:29.014 transcode: 0016: 02:AAC: [mp2 => aac]: Detected framedrop in audio (1733520 != 1737840)
2019-02-26 11:06:29.350 TS: Col/479MHz/NTN 24 Transport error indicator (total 6)
2019-02-26 11:06:29.351 tbl-base: cat: 479MHz in Col: invalid checksum (len 12, errors 4)

Annotation 2019-02-26 110805.jpg (35.1 KB) Annotation 2019-02-26 110805.jpg

TVHeadend Status showing errors

Replies (10)

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by Mark Clarkstone over 5 years ago

This is actually quite common with Silicon-based tuners. I have yet to find a solution!

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by German Rincon over 5 years ago

I assume there is no solution to the random bad tuning in this stick, as it seems to be hw related. So my question is if there is any way to configure tvheadend to identify a bad tuning and restart the stream.. Or is this something that needs to be developed? I am not a developer, but I think this should be not difficult as tvheadend already knows the number of errors in the stream.. thanks!

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by Mark Clarkstone over 5 years ago

There's the DVR profile option "Try re-scheduling recording if more errors than", give that a go

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by German Rincon over 5 years ago

I have been trying to use the re-scheduling recording option, but it just creates a new recording schedule for the following day.. so the current recording continues with the big amount of errors.

Can someone with basic knowledge of the code point me to the section where this can be added? Let say after 1000 errors, stop the channel tuning automatically and restart it again. Thanks!

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by James Hutchinson over 5 years ago

I discovered the same issues reported here with my MyGica T230 DVB-T2 tuners, straight after recently upgrading from Debian Stretch (kernel 4.9.168) to Buster (kernel 4.19.37).

I've therefore been trying various kernel versions in-between and quickly found that the issue was introduced somewhere between 4.9->4.10.

I therefore performed a (lengthy) git bisect to find out which of the 14,248 commits during the v4.10 development cycle introduced this regression.

I have tracked this regression down to the following commit:
5fa8815: [media] dvb-usb-cxusb: Geniatech T230 - resync TS FIFO after lock

Indeed, if I apply the following patch ontop of 4.19.37 to fully revert that commit, I now have a stable MyGica T230 tuner once more


diff --git a/drivers/media/usb/dvb-usb/cxusb.c b/drivers/media/usb/dvb-usb/cxusb.c
index 9b8771eb31d4..243403081fa5 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -369,26 +369,6 @@ static int cxusb_aver_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
        return 0;
 }

-static int cxusb_read_status(struct dvb_frontend *fe,
-                                 enum fe_status *status)
-{
-       struct dvb_usb_adapter *adap = (struct dvb_usb_adapter *)fe->dvb->priv;
-       struct cxusb_state *state = (struct cxusb_state *)adap->dev->priv;
-       int ret;
-
-       ret = state->fe_read_status(fe, status);
-
-       /* it need resync slave fifo when signal change from unlock to lock.*/
-       if ((*status & FE_HAS_LOCK) && (!state->last_lock)) {
-               mutex_lock(&state->stream_mutex);
-               cxusb_streaming_ctrl(adap, 1);
-               mutex_unlock(&state->stream_mutex);
-       }
-
-       state->last_lock = (*status & FE_HAS_LOCK) ? 1 : 0;
-       return ret;
-}
-
 static void cxusb_d680_dmb_drain_message(struct dvb_usb_device *d)
 {
        int       ep = d->props.generic_bulk_ctrl_endpoint;
@@ -1392,12 +1372,6 @@ static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)

        st->i2c_client_tuner = client_tuner;

-       /* hook fe: need to resync the slave fifo when signal locks. */
-       mutex_init(&st->stream_mutex);
-       st->last_lock = 0;
-       st->fe_read_status = adap->fe_adap[0].fe->ops.read_status;
-       adap->fe_adap[0].fe->ops.read_status = cxusb_read_status;
-
        return 0;
 }

diff --git a/drivers/media/usb/dvb-usb/cxusb.h b/drivers/media/usb/dvb-usb/cxusb.h
index 66429d7f69b5..18acda19527a 100644
--- a/drivers/media/usb/dvb-usb/cxusb.h
+++ b/drivers/media/usb/dvb-usb/cxusb.h
@@ -37,11 +37,6 @@ struct cxusb_state {
        struct i2c_client *i2c_client_tuner;

        unsigned char data[MAX_XFER_SIZE];
-
-       struct mutex stream_mutex;
-       u8 last_lock;
-       int (*fe_read_status)(struct dvb_frontend *fe,
-               enum fe_status *status);
 };

 #endif

Looks like Crazy Cat was the author of commit 5fa8815: [media] dvb-usb-cxusb: Geniatech T230 - resync TS FIFO after lock

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by Anonymous over 5 years ago

Hi - Would it be possible for you to upload the .patch file ? - Using the diff fragment above introduces a lot of whitespace which the kernel builder stumbles on.

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by James Hutchinson over 5 years ago

Andreas Tsiotsias wrote:

Hi - Would it be possible for you to upload the .patch file ? - Using the diff fragment above introduces a lot of whitespace which the kernel builder stumbles on.

Find attached.

I also started a thread here: https://www.spinics.net/lists/linux-media/msg154356.html

linux-media-revert-cxusb-geniatech-t230-resync-ts-fifo-after-lock.patch (1.87 KB) linux-media-revert-cxusb-geniatech-t230-resync-ts-fifo-after-lock.patch

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by Anonymous over 5 years ago

James Hutchinson wrote:

Andreas Tsiotsias wrote:

Hi - Would it be possible for you to upload the .patch file ? - Using the diff fragment above introduces a lot of whitespace which the kernel builder stumbles on.

Find attached.

I also started a thread here: https://www.spinics.net/lists/linux-media/msg154356.html

Thank you ! - I'll post here my results after I rebuild the kernel

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by Anonymous about 5 years ago

It took a bit of time .... but I can say that the fix works very well.
No failed recordings since I rebuilt the kernel (11 days ago) with the supplied patch (even though building the kernel was a journey in itself).

So a great thank you ! for your kind help and work.

For anyone else who wants to do the same, it should be a straightforward process. However, I found that the Linux kernel source for Debian simply refused to build (fails with a lot of 'fuzzy' errors). So I had no choice but to go for a 'pristine' Linux kernel from kernel.org. I successfully built the kernel using the 4.19.67 and 5.2.9 tarballs with the patch (above). Both tested and both working with Debian Buster - I am now sitting on 5.2.9 plus 'fix' - very stable.
Another thing I noticed in the dmesg traces:
- without the 'fix' the adapter only loads one firmware file (the 'demux' one)
- with the 'fix' the adapter loads both firmware drivers ('demux' and 'tuner')

In any case, I'm delighted and have an exceptionally stable build - tvheadend rocks !

RE: Re-tune channels after errors - Mygica T230 DVB-T2 - Added by James Hutchinson about 5 years ago

The revert fixes the issue for certain generations of the t230 stick, but breaks others...

Further work went into this upstream, and the mygica t230 stick (all variations) should hopefully work out-of-the-box in kernel v5.4 onwards; where it's been moved from the cxusb to the dvbsky module; similar to the fate of the t230c which was moved to dvbsky some time ago for similar reasons.

https://www.spinics.net/lists/linux-media/msg155759.html

(1-10/10)

Project

General

Profile

Tvheadend