Opened 3 months ago

Closed 4 weeks ago

Last modified 4 weeks ago

#13423 closed Bug Report - General (fixed)

MythTV stopped recording multiple channels from single DVB strream

Reported by: bib1963 Owned by: gigem
Priority: minor Milestone: 30.1
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

This used to work...

I have M configured to record up to 10 channels from a single DVB stream.

I also have it configured to start 5mins earlier.

What happens if 2 shows are scheduled to record from the same stream at the same time...

1 will start 5mins earlier, but not the second Once that 5mins is up at the clock is at the time when the program starts, the current recording stops, and the 2nd scheduled recording start.

If you look at the list of scheduled recordings, no conflicts are listed.

Attachments (3)

capturecard.dbtxt (1.5 KB) - added by bib1963 5 weeks ago.
mythbackend.20190420100515.24302.log.xz (26.6 KB) - added by bib1963 5 weeks ago.
mythbackend.20190420110952.26484.log.xz (21.9 KB) - added by bib1963 5 weeks ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 3 months ago by jpilk

I don't see this. If you stop mythbackend, go back into mythtv-setup, and look at 'interactions between tuners,' do you still see the max recordings set to 10? You may not have saved it properly.

comment:2 Changed 3 months ago by jpilk

FWIW, this is my current setup. It seems to work, although not tested in livetv mode and the ordering there looks a bit strange.

MariaDB [mythconverg]> select cardid, inputname, reclimit, schedorder, livetvorder from capturecard ;
+--------+-----------+----------+------------+-------------+
| cardid | inputname | reclimit | schedorder | livetvorder |
+--------+-----------+----------+------------+-------------+
|      1 | DVBInput  |        8 |          1 |           8 |
|      2 | DVBInput  |        5 |          9 |          13 |
|      3 | DVBInput  |        5 |         14 |          18 |
|      4 | DVBInput  |        8 |          0 |           8 |
|      5 | DVBInput  |        8 |          0 |           8 |
|      6 | DVBInput  |        8 |          0 |           8 |
|      7 | DVBInput  |        8 |          0 |           8 |
|      8 | DVBInput  |        8 |          0 |           8 |
|      9 | DVBInput  |        8 |          0 |           8 |
|     10 | DVBInput  |        8 |          0 |           8 |
|     11 | DVBInput  |        5 |          0 |          13 |
|     12 | DVBInput  |        5 |          0 |          13 |
|     13 | DVBInput  |        5 |          0 |          13 |
|     14 | DVBInput  |        5 |          0 |          18 |
|     15 | DVBInput  |        5 |          0 |          18 |
|     16 | DVBInput  |        5 |          0 |          18 |
|     17 | DVBInput  |        5 |          0 |          13 |
|     18 | DVBInput  |        5 |          0 |          18 |
+--------+-----------+----------+------------+-------------+
18 rows in set (0.00 sec)

MariaDB [mythconverg]> \q ;
Bye


comment:3 Changed 3 months ago by jpilk

I get a more useful listing after adding an 'optional display name' during setup and using

select cardid, videodevice, displayname, dvb_eitscan, sourceid, inputname, reclimit, schedorder, livetvorder from capturecard ;

This may not be relevant to the ticket, of course...

comment:4 Changed 3 months ago by Klaas de Waal

Status: newinfoneeded_new

Have tested this with the following configuration:

  • one DVB-C tuner configured for maximum 4 recordings
  • 2 programs scheduled to start at 20:00
  • "Time to record before start of show": 180 seconds

Detailed tuner configuration:

MariaDB [mythconverg]> select cardid, videodevice, displayname, dvb_eitscan, sourceid, inputname, reclimit, schedorder, livetvorder from capturecard;
+--------+-----------------------------+-------------+-------------+----------+-----------+----------+------------+-------------+
| cardid | videodevice                 | displayname | dvb_eitscan | sourceid | inputname | reclimit | schedorder | livetvorder |
+--------+-----------------------------+-------------+-------------+----------+-----------+----------+------------+-------------+
|      1 | /dev/dvb/adapter3/frontend0 | K0          |           1 |        2 | DVBInput  |        4 |          1 |           1 |
|      6 | /dev/dvb/adapter3/frontend0 | K0          |           1 |        2 | DVBInput  |        4 |          1 |           1 |
|      7 | /dev/dvb/adapter3/frontend0 | K0          |           1 |        2 | DVBInput  |        4 |          1 |           1 |
|      8 | /dev/dvb/adapter3/frontend0 | K0          |           1 |        2 | DVBInput  |        4 |          1 |           1 |
+--------+-----------------------------+-------------+-------------+----------+-----------+----------+------------+-------------+
4 rows in set (0.001 sec)

Both programs have been recorded correct; both recordings starting at 19:57 and continued until the scheduled end of the program.

Please update your MythTV with the latest master and check that the problem still exists.

If the problem still exists, please give:

  • the detailed tuner configuration
  • the output of mythbackend for the whole recording period with the following verbosity:
mythbackend -v general,channel,chanscan,record,eit,dvbcam

comment:5 Changed 2 months ago by bib1963

This is horrible....

Wiped the db and started with a fresh install with head on 20190313.

After configuring the system to record 10 channels from a single stream, I found...

The record past time setting does not matter.

If I set the prerecord time to 271 seconds, it works.

If I set the prerecord time to 272 seconds, it fails.

This is with just a single dvb card on /dev/dvb/adapter0, nothing else.

And that 272 seconds, for the mathematically challenged is 4 minutes & 32 seconds.

Last edited 2 months ago by bib1963 (previous) (diff)

comment:6 Changed 7 weeks ago by Klaas de Waal

Have tested this again with the following configuration:

  • one DVB-C tuner configured for 10 recordings
  • two programs scheduled to start at the same time
  • "Time to record before start of show:" 300 seconds

Both recordings are correct.

Second try, now with:

  • "Time to record before start of show:" 272 seconds

Both recordings are correct.

As already indicated in comment:4, more information is needed.

Changed 5 weeks ago by bib1963

Attachment: capturecard.dbtxt added

Changed 5 weeks ago by bib1963

Changed 5 weeks ago by bib1963

comment:7 Changed 5 weeks ago by bib1963

Here we go...

Updated to master on 20190420 and restarted with the record before set to 271 seconds. Scheduled 2 programs to record which started at the same time. Upcoming recordings showed no conflicts. It worked. The logs are attached.

I find when I change this setting, I have to restart the backend. No matter, it helps with separating out the logs.

Set the record before to 272 seconds. Scheduled 2 programs to record which started at the same time. Upcoming recordings showed no conflicts. It failed. One started at the time before as configured, but the 2nd one did not. At the time the program was scheduled to start, at the real time, the first recording stopped and the 2nd one began. The logs are attached.

I've also attached the capturecard table.

comment:8 Changed 4 weeks ago by Klaas de Waal

Thanks for your log files. They do confirm the problem you describe. With the information in the log files I have now been able to reproduce the problem on my system with the "record before" time set to 272 seconds.

The problem depends on the "Schedule as group" setting (in mythtv-setup / 5. Input connections / Interaction between inputs / Schedule as group).

My test setup:

  • one DVB-C tuner configured with "Max recordings" to 10.
  • "Time to record before start of show" set to 272 seconds
  • Two recordings, manual schedule, start at the same time

With the "Schedule as group" disabled the recordings are correct: both recordings start 272 seconds before the scheduled start time and both recordings run to the scheduled end time.

With the "Schedule as group" enabled the problem appears: one recording starts 272 seconds before the scheduled start time and ends at the scheduled start time. The other recording starts at the scheduled start time (so NOT 272 seconds before) and runs to the scheduled end time.

comment:9 Changed 4 weeks ago by bib1963

Grand!

I wonder though what is so special about 272 or even 271 seconds and how it's calculated to get that. 9 * 30 + 1 is the closest I can think of... where 9 is the sub, and the 1 is the main. Ho hum!

I am recording something at the moment, so I'll wait until tomorrow to see if turning off group schedule is able to to be expanded to at least 300, and all the way up to 600 seconds.

comment:10 Changed 4 weeks ago by gigem

Owner: set to gigem
Status: infoneeded_newassigned

I'll try to look into this soon.

comment:11 Changed 4 weeks ago by Klaas de Waal

Some more observations that might be useful in finding this:

  • Changing the "Max recordings" to 4 does not make any difference.
  • With three recordings, manually scheduled to start at the same time, the first starts at the "Time to record before start of show" time and ends at the scheduled start time; the second is not recorded at all and the third starts at the scheduled start time and ends at the scheduled end time.
  • With the "Time to record before start of show" changed to 271 seconds all three recordings are correct.

comment:12 Changed 4 weeks ago by jpilk

I have never used a satellite system, but 'cat yourlogs | grep LNB' shows more activity than I would naively expect if all your recordings are from the same transport.

comment:13 Changed 4 weeks ago by David Engel <dengel@…>

Resolution: fixed
Status: assignedclosed

In b71875f16c/mythtv:

Account for very, large pre-roll values in AssignGroupInput?.

Fixes #13423

comment:14 Changed 4 weeks ago by David Engel <dengel@…>

In 30a59af73f/mythtv:

Account for very, large pre-roll values in AssignGroupInput?.

Refs #13423

(cherry picked from commit b71875f16c156abeb347e6035c8b7bb72c457904)

comment:15 Changed 4 weeks ago by gigem

Milestone: needs_triage30.1
Note: See TracTickets for help on using tickets.