Occasional Failed Recordings

Have a MythTV related problem? Ask for help from other MythTV users here.

Moderator: Forum Moderators

Post Reply
richfeat
Newcomer
Posts: 4
Joined: Wed Sep 27, 2017 4:54 pm
Great Britain

Occasional Failed Recordings

Post by richfeat » Sun Jun 17, 2018 3:37 pm

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
Newcomer
Posts: 5
Joined: Sun Jun 24, 2018 6:26 am
Australia

Re: Occasional Failed Recordings

Post by Caysho » Wed Jun 27, 2018 11:50 am

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

wesnewell
Senior
Posts: 356
Joined: Mon Jun 23, 2014 6:54 pm
Location: Wylie TX, USA
United States of America

Re: Occasional Failed Recordings

Post by wesnewell » Wed Jun 27, 2018 5:17 pm

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.
Backend-GF8200A, AMD Phenom II B95, 6 atsc tuners. Frontends-GF8200's,,AMD Athlon II's. Mythtv user since 2005.

richfeat
Newcomer
Posts: 4
Joined: Wed Sep 27, 2017 4:54 pm
Great Britain

Re: Occasional Failed Recordings

Post by richfeat » Sat Jul 21, 2018 4:52 pm

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
Senior
Posts: 286
Joined: Mon Jul 25, 2016 4:16 pm
Great Britain

Re: Occasional Failed Recordings

Post by MikeB2013 » Sun Jul 22, 2018 8:21 am

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
Newcomer
Posts: 4
Joined: Wed Sep 27, 2017 4:54 pm
Great Britain

Re: Occasional Failed Recordings

Post by richfeat » Sun Jul 22, 2018 3:01 pm

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
Senior
Posts: 286
Joined: Mon Jul 25, 2016 4:16 pm
Great Britain

Re: Occasional Failed Recordings

Post by MikeB2013 » Sun Jul 22, 2018 3:37 pm

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
Newcomer
Posts: 4
Joined: Wed Sep 27, 2017 4:54 pm
Great Britain

Re: Occasional Failed Recordings

Post by richfeat » Mon Aug 06, 2018 3:45 pm

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.

Post Reply