id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	mlocked
13207	Failed recordings due to Active EIT Scanning on satellite adapters using DiSEqC	jmwislez@…	gigem	"This is a bug I have been facing since the transition from cardinput to capturecard in v0.28.  I have first  downgraded to v0.27 to get around it, but when I finally upgraded to v29 I have started investigating the problem.

As per release note instruction of v0.28 “Users of LNB/DiSEqC have created multiple DVB cards for the same adapter/frontend to keep LNB/DiSEqC working...” I now have a set-up as follows (only relevant adapter shown):

/dev/dvb/adapter0/frontend0 in capturecard:

cardid, parentid, dvb_diseqc_type, diseqcid, sourceid, displayname
1, 0, NULL, 1, 7, Astra 19.E
5, 0, NULL, 1, 3, Astra 28.2E
6, 0, NULL, 1, 4, Hotbird 13.0E
7, 1, 0, 1, 7, Astra 19.E
10, 5, 0, 1, 3, Astra 28.2E
11, 6, 0, 1, 4, Hotbird 13.0E

For all entries, Signal timeout is 7000, Tuning timeout is 10000, Wait for SEQ start header is active, Open DVB card on demand is active.

diseqc_config and diseqc_tree are correctly configured accordingly.

What I observe is that, when “Use DVB card for active EIT scan” is activated on /dev/dvb/adapter0/frontend0 sources, most recordings on /dev/dvb/adapter0/frontend0 fail.  The log of a failed recording is attached.

When disabling Active EIT Scan on /dev/dvb/adapter0/frontend0 sources, recordings are consistently successful.

Possibly, this bug only appears in conjunction with slow database access.  Since the upgrade from v0.27->v29, I noticed in mythweb that database use by mythtv is very slow.  I upgraded from mysql 5.7 to mariadb 10.2, which was an improvement, but it’s still slow.  A list with database table sizes is attached for information (I got many adapters and many channels).

I’m ready to support further analysis of this bug by running test cases."	Bug Report - General	closed	minor	29.2	MythTV - General	v29.0	medium	fixed	EIT,DiSEqC,recording		0