Occasional Failed Recordings

[richfeat]

Hardware: Gigabyte GA-EG43M-S2H, Intel E8400, 4GB RAM, 750GB Samsung HD753LJ Hard Drive
2 x Hauppauge WinTV-Nova-T DVD-T Chip: Conexant CX22702
Software: Ubuntu MATE 16.04.4 64bit, Mythtv 2:29.1+fixes.20180610.675676b-0ubuntu0mythbuntu4
Machine is always on. It is only used for mythtv recording, so little else running.

Occasionally (weekly, say) I get failed recordings with the same pattern in the logs. EG:
syslog/kern.log
Jun 16 18:49:00 samuel kernel: [351812.887800] cx8802: cx8802_mpeg_irq: mpeg:general errors: 0x00000100

mythbackend.log
Jun 16 18:49:00 samuel mythbackend: mythbackend[1661]: I Scheduler scheduler.cpp:2923 (HandleRecordingStatusChange) Tuning recording: "Romancing the Stone": channel 9385 on cardid [1], sourceid 1
Jun 16 18:49:07 samuel mythbackend: mythbackend[1661]: E TVRecEvent tv_rec.cpp:3954 (TuningSignalCheck) TVRec[1]: TuningSignalCheck: Hit pre-fail timeout
Jun 16 18:49:10 samuel mythbackend: mythbackend[1661]: W TVRecEvent tv_rec.cpp:3985 (TuningSignalCheck) TVRec[1]: TuningSignalCheck: taking more than 10000 ms to get a lock. marking this recording as 'Failing'.
Jun 16 18:49:10 samuel mythbackend: mythbackend[1661]: W TVRecEvent tv_rec.cpp:3987 (TuningSignalCheck) TVRec[1]: See 'Tuning timeout' in mythtv-setup for this input
Jun 16 18:49:10 samuel mythbackend: mythbackend[1661]: I CoreContext scheduler.cpp:734 (UpdateRecStatus) Updating status for "Romancing the Stone" on cardid [1] (Tuning => Failing)

I had previously increased the tuner timeout from 6000 to 10000 ms, but the failure frequency is the same. I'd appreciate help in trying to fix this!

[Caysho]

If you have two tuners, is one in use when this happens ?
Is it always the same channel ?

[wesnewell]

I have this happen every now and then too and can verify it's something flakey with the tuner card (or driver) as other tuners work using live tv, and that one won't work in live tv. A shutdown and restart always fixes it. Doesn't happen often enough for me to worry about. Might try swapping tuner cards and see if it follows that card.

[richfeat]

Many thanks for your suggestions.
I have 2 tuner cards. Adaptor 0 has encoders 1,3 & 4, adaptor 1 has encoders 2,5 & 6
I went away for 2 weeks and had failed recordings on encoders 1,2,3 & 4 on various TV channels. Failures happen when just one or both adaptors are being used.
I have configured a cron job to restart the backend every day, but I got another failure today. Only 1 TV programme was being recorded. The previous (successful) recording was on the same encoder, some 6 hours before.
I noticed the failure about 1/2 hour into the programme. I restarted the backend, and then the rest of the programme recorded OK. The failure was on encoder 1 and the rest of the OK recording was on encoder 1. Restarting the backend allows the adaptor to tune in, but I can't work out what state the backend/adaptor is in when it fails to record. Still hunting!

[MikeB2013]

Are the failed recordings across all multiplexes or only on one multiplex?
You can monitor the signals on either of your adapters when recording or watching LiveTV using either femon (sudo apt install dvb-apps) or dvb-fe-tool (sudo apt install dvb-tools).

Here is an example of monitoring, the -a3 in your case should be either -a0 or -a1

Code: Select all

mike@myth-server-1:~$ femon -H -a3
FE: Silicon Labs Si2168 (DVBT)
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  51% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
^C
mike@myth-server-1:~$ dvb-fe-tool -m -a3
Lock   (0x1f) Signal= -49.00dBm C/N= 31.50dB UCB= 0 postBER= 0
Lock   (0x1f) Signal= -49.00dBm C/N= 31.75dB UCB= 0 postBER= 0
Lock   (0x1f) Signal= -48.00dBm C/N= 31.75dB UCB= 0 postBER= 0
Lock   (0x1f) Signal= -49.00dBm C/N= 31.50dB UCB= 0 postBER= 0
Lock   (0x1f) Signal= -48.00dBm C/N= 31.50dB UCB= 0 postBER= 0
Lock   (0x1f) Signal= -48.00dBm C/N= 31.50dB UCB= 0 postBER= 0

If you are using EIT for program data (EPG) it might be worthwhile checking that only one adapter is set to use EIT (mythtv-setup>Capture Card), you can have more than 1 but there is no real advantage to this.

[richfeat]

Thanks for your thoughts.
The failures happen on at least 3 multiplexes. Most recording are from these, so it is not significant that it is only those 3 in the last 3 months.

I was using EIT on both adaptors, so I have changed that today to only use Adaptor 0. Thanks for that.

The mythtv-setup>Capture Card option "Open DVB Card on demand?" looks suspicious? I have that UNSET on both cards.

I installed dvb-apps/femon as you suggested.
With no recordings active I get:
femon -H -a0
FE: Conexant CX22702 DVB-T (DVBT)
status SCVYL | signal 67% | snr 100% | ber 0 | unc 0 | FE_HAS_LOCK
femon -H -a1
FE: Conexant CX22702 DVB-T (DVBT)
status SCVYL | signal 68% | snr 100% | ber 0 | unc 0 | FE_HAS_LOCK

The snr looks high considering the adapters are not even recording. I notice you have 0%. May be a default output.

With live tv on a0 and a1 recording I get:
femon -H -a0
status SCVYL | signal 69% | snr 100% | ber 0 | unc 0 | FE_HAS_LOCK
femon -H -a1
status SCVYL | signal 70% | snr 100% | ber 0 | unc 0 | FE_HAS_LOCK

snr still 100%

I can't always catch a failed recording happening, so I don't know what output I would get then.

[MikeB2013]

Given the signal around 70% it does not look like a signal problem you have FE_LOCK so it should be fine.

The "snr 100%" may not mean anything - it just depends on the card driver implementation of statistics. There is a lot of history around statistics, basically the original standards were open to a lot of interpretation, so various drivers implemented differently, they are more standardized now, but many drivers have not been updated , you could try dvb-fe-tool to see if that gives something more sensible.

Prior to mythtv 0.29 the default for "Open DVB Card on demand" was not selected (so your setting of not selected is fine, it is what I use), I don't why it was changed in 0.29, the only side effect I have seen when it is selected is mythbackend startup takes longer.

[richfeat]

Well, 15 days have gone by since Jul 22, and no more failures yet. The only change I made was to turn off EIT on one adaptor as you suggested Mike.
I have been reluctant to report the lack of new failures because I feel I'm in the land of black magic, where writing this can only have one result ...
Time will tell. Meanwhile, another very cautious Thank You is it order.

[richfeat]

Another month and a half with no failed recordings. It appears to be fixed.
Unless the many mythtv updates recently have had anything to do with it, it seems that using EIT on one tuner only does the trick.
Many thanks Mike - is this setting well known?

[MikeB2013]

Possible but not likely that the recent mythtv 29 changes would have impacted recordings, a couple of changes were related to EIT scanning, but these were to do with resuming EIT scan after a timeout and only running EIT on visible channels.

I only set EIT on one tuner per Video Source as this minimizes processing overhead and in some case reduces power consumption (not by much but every little helps).

A bit of history:
There were problems some years ago with some dual tuners (DVB-T) both usb and pci/pcie which miss behaved after a period leading to failed recordings, and use of EIT on both tuners aggravated the situation, using EIT on a single tuner helped but did not always totally resolve the issue. Basically these dual tuners shared some circuitry and the associated drivers did not always perform sufficient checks to make sure that the shared circuitry was only accessed by one process (i.e. insufficient exclusive locking) and the situation was not helped by some firmware deficiencies. So setting EIT on one tuner only per Video Source became my default.

I run test systems checking out changed software and/or hardware before applying to my production mythtv system, in such cases I do set EIT on all possible tuners just in case there are issues. Recently I did have problems, now fully resolved, with a new DVB-T/T2 quad tuner card which locked up when under certain conditions, EIT scanning on all 4 tuners provoked the lockup more frequently but was not the root cause.

[Doppel-D]

Had also problems with a double tuner setup while retrieving EPG data over EIT, resulting in a constant high CPU load and some kind of card lockup (but still usable to record)

I disabled it on both tuners which fixed the above mentioned problems, but I am stll getting EPG data which surprises me. Anyone has a clue?

@MikeB2013 Ahhh...recognized to late that you already know about ;- )

[MikeB2013]

@Doppel-D

You may still get EIT data even with "Use DVB card for active EIT scan" not selected for all Capture Cards as mythtv has another EIT mode "passive" which will be used if the Video Source has EIT enabled and the individual channel has EIT allowed (useronairguide ticked in mythweb). The passive mode will pickup any EIT data in the channel that is tuned to.

Depending on the transmitter (varies by Country and delivery system DVB-S/S2, DVB-T/T2) , this channel EIT data if present maybe Now/Next, details for next few days for the channel or data for all channels (which could be for more than just the multiplex that the channel is tuned to).

In UK both Freeview (DVB-T/T2) and Freesat (DVB-S/S2) provide EIT data for the next 7 days

Mike

[Doppel-D]

Hello Mike,
thank you again for the background info! Here on german cable it states EPG for 22 days, but it gets sparse the closer you get to this date, but how can I complain....happy to have some data although it is not perfect.
kind regards