Opened 9 years ago

Closed 4 years ago

#12392 closed Bug Report - General (Works for me)

Trunk: DVB recordings fail to start randomly

Reported by: tomi.orava@… Owned by: Klaas de Waal
Priority: minor Milestone: 32.0
Component: MythTV - DVB Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

Using the Trunk version (commit 7f68683be1f043a77ac5adbc813afd1cafd7a1f3), most of the DVB-T recordings are failing to start, unless the "Wait for the SEQ start header" option has been selected for every DVB card. (The previously used checkout from Dec 31 worked just fine with the same HW).

The host system is running kernel org 3.18.5 kernel and the system has been working just fine with the older GIT checkout version.

I've now had the above mentioned option set for all three DVB cards for 2 days and haven't got a single recording failure as of now.

The setup consists of two Nanostick 290e's and one Cinergy 1200 DVB-T card.

Bus 003 Device 004: ID 2013:024f PCTV Systems nanoStick T2 290e 05:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)

The below error was reported continuosly in the logs:

E [940/10016] DVBRead recorders/dtvrecorder.cpp:1319 (HandleSingleProgramPAT) - DTVRec[3]: HandleSingleProgramPAT(NULL)

Change History (6)

comment:1 Changed 9 years ago by J.Pilk@…

My test box, running the ppa pre-2682 build from ubuntu trusty (one commit before yours), and a single 290-e tuner, has two HD recordings (BBC2 and itv) marked as 'failed' although they seem faultless; startup overran the 3000 ms timeout, which I have now increased to 5000 ms. Tuning delay was 200 ms; wait for SEQ start; active scan. The same system has made 2 other HD recordings that didn't 'fail.'

I don't recollect seeing this sort of thing earlier, but I haven't used HD much.

comment:2 Changed 9 years ago by tomi.orava@…

At least here the problem is not directly related to HD recordings. I have the timeout set to 5000ms and even that didn't help the situation at all.

I just checked again and I still haven't got the previously mentioned error log line or failed recordings, after I enabled the "Wait for the SEQ start header" option for every card.

comment:3 Changed 9 years ago by J.Pilk@…

Recordings made overnight were ok, but a few minutes after the last one finished:

E PIDInfo(/dev/dvb/adapter0/frontend0): Failed to set TS filter (pid 0x0)
E TVRec[1]: TuningSignalCheck?: SignalMonitor? timed out
E TVRec[1]: TuningSignalCheck?: SignalMonitor? timed out

I'm still seeing the timeout every few minutes. This is a part-time channel (BBC FOUR HD) and the recording was the last scheduled programme.

Just tried starting another recording, which failed; still failing after killing/restarting backend. Bye!

comment:4 Changed 9 years ago by J.Pilk@…

Recording again after quitting frontend, killall backend, unplug/replug usb stick, mythbackend, mythfrontend.

comment:5 Changed 4 years ago by Klaas de Waal

Milestone: unknown32.0
Owner: set to Klaas de Waal
Status: newassigned

I always run with the "Wait for SEQ start header" selected but it should also run with this option not selected. This should be easy to check.

comment:6 Changed 4 years ago by Klaas de Waal

Resolution: Works for me
Status: assignedclosed

I have, with today's master, made a few DVB-T2 and DVB-C recordings with the "Wait for SEQ start header" unchecked. All recordings are good, so the problem cannot be reproduced here.

In the ticket it is indicated that with the "Wait for SEQ start header" option checked the problem is solved. This option is checked by default because the recordings then start at a key frame (GOP boundary).

As the problem cannot be reproduced and the problem is solved by setting the "Wait for SEQ start header" option correct there is nothing that can be fixed and hence this ticket is now closed.

Note: See TracTickets for help on using tickets.