Mailing List Archive

Fwd: backend (?) crash
sending this again with shorter logs. Restarting the backend was
successful, but I'd be curious to know if there's something i can do to
avoid it crashing again in future.
---------- Forwarded message ---------
From: Mary Strimel <mary.strimel@gmail.com>
Date: Thu, Feb 18, 2021 at 11:47 AM
Subject: backend (?) crash
To: Mythtv Mailing List <mythtv-users@mythtv.org>


I woke up this morning and my frontends would not connect. There are lots
of errors in the log, but I'm not sure which ones are the problem, versus
symptoms of the problem.
From mythbackend.log:

Feb 18 08:28:59 mythbox mythbackend: mythbackend[1177]: I Scheduler
scheduler.cpp:2427 (HandleReschedule) Scheduled 396 items in 0.2 = 0.02
match + 0.00 check + 0.20 place
Feb 18 08:29:30 mythbox mythbackend: mythbackend[1177]: I CoreContext
mainserver.cpp:3236 (HandleAddChildInput) MainServer: HandleAddChildInput:
Handling input 5
Feb 18 08:29:30 mythbox mythbackend: mythbackend[1177]: E CoreContext
cardutil.cpp:1548 (AddChildInput) CardUtil: Failed to add child input to
parent 5
Feb 18 08:29:30 mythbox mythbackend: mythbackend[1177]: E CoreContext
mainserver.cpp:3247 (HandleAddChildInput) MainServer: HandleAddChildInput:
Failed to add child to input 5


From mythfrontend.log:
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
cache directory: /home/mary/.mythtv/cache/remotecache
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 57
files, deleted 0 files, stat error on 0 files
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
cache directory: /home/mary/.mythtv/cache/thumbnails
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 661
files, deleted 0 files, stat error on 0 files
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
SendMessage mythcorecontext.cpp:469 (ConnectCommandSocket)
MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
192.168.1.253:6543 (try 1 of 1)
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: E
CoreContext devices/mythcecadapter.cpp:173 (Open) CECAdapter: Failed to
load libcec.
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: E
CoreContext AirPlay/mythraopdevice.cpp:30 (Create) RAOP Device: Aborting
startup - no key found.
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext AirPlay/mythairplayserver.cpp:387 (Create) AirPlay: Created
airplay objects.
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
thread_unknown serverpool.cpp:418 (listen) Listening on TCP 0.0.0.0:5100
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
thread_unknown serverpool.cpp:418 (listen) Listening on TCP [::]:5100
Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext schemawizard.cpp:117 (Compare) Current MythTV Schema Version
(DBSchemaVer): 1361
Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext decoders/mythvdpauhelper.cpp:71 (HaveVDPAU) VDPAUHelp:
Supported/available VDPAU decoders:
Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext decoders/mythvdpauhelper.cpp:103 (ProfileCheck) VDPAUHelp:
Driver does not report support for H264 Baseline
Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext decoders/mythvdpauhelper.cpp:114 (ProfileCheck) VDPAUHelp: ...
but assuming available as H264 Main is supported
Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext decoders/mythvdpauhelper.cpp:103 (ProfileCheck) VDPAUHelp:
Driver does not report support for H264 Constrained Baseline
Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
CoreContext decoders/mythvdpauhelper.cpp:114 (ProfileCheck) VDPAUHelp: ...
but assuming available as H264 Main is supported

Feb 18 11:25:04 mythbox mythfrontend.real: mythfrontend[11395]: E
MythSocketThread(-1) mythsocket.cpp:815 (ReadStringListReal)
MythSocket(7f815801ea30:60): ReadStringList: Error, timed out after 7000 ms.
Feb 18 11:25:04 mythbox mythfrontend.real: mythfrontend[11395]: C
SendMessage mythcorecontext.cpp:1662 (CheckProtoVersion) Protocol version
check failure.#012#011#011#011The response to MYTH_PROTO_VERSION was
empty.#012#011#011#011This happens when the backend is too busy to
respond,#012#011#011#011or has deadlocked due to bugs or hardware failure.
Feb 18 11:25:04 mythbox mythfrontend.real: mythfrontend[11395]: I
SendMessage mythcorecontext.cpp:469 (ConnectCommandSocket)
MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
192.168.1.253:6543 (try 1 of 1)
Feb 18 11:25:11 mythbox mythfrontend.real: mythfrontend[11395]: E
MythSocketThread(-1) mythsocket.cpp:815 (ReadStringListReal)
MythSocket(7f815800ea30:59): ReadStringList: Error, timed out after 7000 ms.
Feb 18 11:25:11 mythbox mythfrontend.real: mythfrontend[11395]: C
SendMessage mythcorecontext.cpp:1662 (CheckProtoVersion) Protocol version
check failure.#012#011#011#011The response to MYTH_PROTO_VERSION was
empty.#012#011#011#011This happens when the backend is too busy to
respond,#012#011#011#011or has deadlocked due to bugs or hardware failure.
Feb 18 11:25:11 mythbox mythfrontend.real: mythfrontend[11395]: I
SendMessage
Re: Fwd: backend (?) crash [ In reply to ]
Your frontend log shows that it cannot connect to the backend, otherwise it
is OK.
Your backend log fragment shows that it wants to create a new virtual tuner
for a multirec recording but that this fails. This should not happen.
To get to the bottom of this a lot more information would be needed, such a
complete backend log and a dump of some database tables.
You can create a Github issue and then you can attach bigger log files than
you can with the mailing list.

For the time being I suggest to:
- check that your database is correct by running optimize_mythdb.pl
- run the latest updated version, e.g. v31/fixes

You can also with mythtv-setup:
- delete all capture cards
- create new capture cards
- connect them to the video source
Reason is that your backend issue could be caused by a corrupt capturecard
table.

Klaas.





On Fri, 19 Feb 2021 at 23:20, Mary Strimel <mary.strimel@gmail.com> wrote:

> sending this again with shorter logs. Restarting the backend was
> successful, but I'd be curious to know if there's something i can do to
> avoid it crashing again in future.
> ---------- Forwarded message ---------
> From: Mary Strimel <mary.strimel@gmail.com>
> Date: Thu, Feb 18, 2021 at 11:47 AM
> Subject: backend (?) crash
> To: Mythtv Mailing List <mythtv-users@mythtv.org>
>
>
> I woke up this morning and my frontends would not connect. There are lots
> of errors in the log, but I'm not sure which ones are the problem, versus
> symptoms of the problem.
> From mythbackend.log:
>
> Feb 18 08:28:59 mythbox mythbackend: mythbackend[1177]: I Scheduler
> scheduler.cpp:2427 (HandleReschedule) Scheduled 396 items in 0.2 = 0.02
> match + 0.00 check + 0.20 place
> Feb 18 08:29:30 mythbox mythbackend: mythbackend[1177]: I CoreContext
> mainserver.cpp:3236 (HandleAddChildInput) MainServer: HandleAddChildInput:
> Handling input 5
> Feb 18 08:29:30 mythbox mythbackend: mythbackend[1177]: E CoreContext
> cardutil.cpp:1548 (AddChildInput) CardUtil: Failed to add child input to
> parent 5
> Feb 18 08:29:30 mythbox mythbackend: mythbackend[1177]: E CoreContext
> mainserver.cpp:3247 (HandleAddChildInput) MainServer: HandleAddChildInput:
> Failed to add child to input 5
>
>
> From mythfrontend.log:
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
> cache directory: /home/mary/.mythtv/cache/remotecache
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 57
> files, deleted 0 files, stat error on 0 files
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
> cache directory: /home/mary/.mythtv/cache/thumbnails
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 661
> files, deleted 0 files, stat error on 0 files
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> SendMessage mythcorecontext.cpp:469 (ConnectCommandSocket)
> MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
> 192.168.1.253:6543 (try 1 of 1)
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: E
> CoreContext devices/mythcecadapter.cpp:173 (Open) CECAdapter: Failed to
> load libcec.
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: E
> CoreContext AirPlay/mythraopdevice.cpp:30 (Create) RAOP Device: Aborting
> startup - no key found.
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext AirPlay/mythairplayserver.cpp:387 (Create) AirPlay: Created
> airplay objects.
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> thread_unknown serverpool.cpp:418 (listen) Listening on TCP 0.0.0.0:5100
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> thread_unknown serverpool.cpp:418 (listen) Listening on TCP [::]:5100
> Feb 18 11:24:57 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext schemawizard.cpp:117 (Compare) Current MythTV Schema Version
> (DBSchemaVer): 1361
> Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext decoders/mythvdpauhelper.cpp:71 (HaveVDPAU) VDPAUHelp:
> Supported/available VDPAU decoders:
> Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext decoders/mythvdpauhelper.cpp:103 (ProfileCheck) VDPAUHelp:
> Driver does not report support for H264 Baseline
> Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext decoders/mythvdpauhelper.cpp:114 (ProfileCheck) VDPAUHelp: ...
> but assuming available as H264 Main is supported
> Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext decoders/mythvdpauhelper.cpp:103 (ProfileCheck) VDPAUHelp:
> Driver does not report support for H264 Constrained Baseline
> Feb 18 11:24:58 mythbox mythfrontend.real: mythfrontend[11395]: I
> CoreContext decoders/mythvdpauhelper.cpp:114 (ProfileCheck) VDPAUHelp: ...
> but assuming available as H264 Main is supported
>
> Feb 18 11:25:04 mythbox mythfrontend.real: mythfrontend[11395]: E
> MythSocketThread(-1) mythsocket.cpp:815 (ReadStringListReal)
> MythSocket(7f815801ea30:60): ReadStringList: Error, timed out after 7000 ms.
> Feb 18 11:25:04 mythbox mythfrontend.real: mythfrontend[11395]: C
> SendMessage mythcorecontext.cpp:1662 (CheckProtoVersion) Protocol version
> check failure.#012#011#011#011The response to MYTH_PROTO_VERSION was
> empty.#012#011#011#011This happens when the backend is too busy to
> respond,#012#011#011#011or has deadlocked due to bugs or hardware failure.
> Feb 18 11:25:04 mythbox mythfrontend.real: mythfrontend[11395]: I
> SendMessage mythcorecontext.cpp:469 (ConnectCommandSocket)
> MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
> 192.168.1.253:6543 (try 1 of 1)
> Feb 18 11:25:11 mythbox mythfrontend.real: mythfrontend[11395]: E
> MythSocketThread(-1) mythsocket.cpp:815 (ReadStringListReal)
> MythSocket(7f815800ea30:59): ReadStringList: Error, timed out after 7000 ms.
> Feb 18 11:25:11 mythbox mythfrontend.real: mythfrontend[11395]: C
> SendMessage mythcorecontext.cpp:1662 (CheckProtoVersion) Protocol version
> check failure.#012#011#011#011The response to MYTH_PROTO_VERSION was
> empty.#012#011#011#011This happens when the backend is too busy to
> respond,#012#011#011#011or has deadlocked due to bugs or hardware failure.
> Feb 18 11:25:11 mythbox mythfrontend.real: mythfrontend[11395]: I
> SendMessage
>
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: Fwd: backend (?) crash [ In reply to ]
On Sat, 20 Feb 2021 at 00:08, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

> Your frontend log shows that it cannot connect to the backend, otherwise
> it is OK.
> Your backend log fragment shows that it wants to create a new virtual
> tuner for a multirec recording but that this fails. This should not happen.
> To get to the bottom of this a lot more information would be needed, such
> a complete backend log and a dump of some database tables.
> You can create a Github issue and then you can attach bigger log files
> than you can with the mailing list.
>
> For the time being I suggest to:
> - check that your database is correct by running optimize_mythdb.pl
> - run the latest updated version, e.g. v31/fixes
>
> You can also with mythtv-setup:
> - delete all capture cards
> - create new capture cards
> - connect them to the video source
>
Reason is that your backend issue could be caused by a corrupt capturecard
> table.
>

If the error is related to a capture card that does convert external video
signals such as a HD-PVR then it can be a configuration issue.
In mythtv-setup look at page Input Connections / Interaction between Inputs
For a HD-PVR the "Max Recordings" should be 1 and the "Schedule as Group"
should be unchecked.

When the "Schedule as Group" is checked then additional virtual tuners are
created when needed, but this can only work when the complete transport
stream is available such as with capture cards that have a tuner.

Klaas.
Re: Fwd: backend (?) crash [ In reply to ]
On 2/20/21 4:13 AM, Klaas de Waal wrote:
>
>
> On Sat, 20 Feb 2021 at 00:08, Klaas de Waal <klaas.de.waal@gmail.com
> <mailto:klaas.de.waal@gmail.com>> wrote:
>
> Your frontend log shows that it cannot connect to the backend,
> otherwise it is OK.
> Your backend log fragment shows that it wants to create a new
> virtual tuner for a multirec recording but that this fails. This
> should not happen.
> To get to the bottom of this a lot more information would be
> needed, such a complete backend log and a dump of some database
> tables.
> You can create a Github issue and then you can attach bigger log
> files than you can with the mailing list.
>
From the description it sounds a lot like a bug I had found and fixed
about a year ago. It was related to updating recording metadata on the
frontend. That would cause the backend to stop accepting connections,
although it still continued running and making recordings. Were you
updating metadata at any time before?

https://code.mythtv.org/trac/ticket/13479

It was fixed in v30 and v31.

Make sure you have a v30 or v31 build later than Feb 2020, or avoid the
recording metadata update screen.

Peter
Re: Fwd: backend (?) crash [ In reply to ]
On Sat, 20 Feb 2021 at 10:13, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

>
>
> On Sat, 20 Feb 2021 at 00:08, Klaas de Waal <klaas.de.waal@gmail.com>
> wrote:
>
>> Your frontend log shows that it cannot connect to the backend, otherwise
>> it is OK.
>> Your backend log fragment shows that it wants to create a new virtual
>> tuner for a multirec recording but that this fails. This should not happen.
>> To get to the bottom of this a lot more information would be needed, such
>> a complete backend log and a dump of some database tables.
>> You can create a Github issue and then you can attach bigger log files
>> than you can with the mailing list.
>>
>> For the time being I suggest to:
>> - check that your database is correct by running optimize_mythdb.pl
>> - run the latest updated version, e.g. v31/fixes
>>
>> You can also with mythtv-setup:
>> - delete all capture cards
>> - create new capture cards
>> - connect them to the video source
>>
> Reason is that your backend issue could be caused by a corrupt capturecard
>> table.
>>
>
> If the error is related to a capture card that does convert external video
> signals such as a HD-PVR then it can be a configuration issue.
> In mythtv-setup look at page Input Connections / Interaction between
> Inputs
> For a HD-PVR the "Max Recordings" should be 1 and the "Schedule as Group"
> should be unchecked.
>

It looks like that for the HD-PVR the "Max Recordings" and "Schedule as
Group" configuration items are missing.
The default values are not correct for the HD-PVR. This is a bug.
Until this is fixed changing the configured values in the database needs
some SQL.

If my analysis is correct then your backend will fail when you have
scheduled two (or more) simultaneous recordings from the same multiplex;
the recordings are then scheduled on the same HD-PVR.
Can you please try this?

Thanks,
Klaas.
Re: Fwd: backend (?) crash [ In reply to ]
Thanks for responding. Yesterday was a busy day with family members
recording and watching, but today I was able to break in and try your
suggestions:

On Sat, Feb 20, 2021 at 4:15 AM Klaas de Waal <klaas.de.waal@gmail.com>
wrote:

>
>> For the time being I suggest to:
>> - check that your database is correct by running optimize_mythdb.pl
>>
> Done, seemed to run fine.

- run the latest updated version, e.g. v31/fixes
>>
> I think I am:



*mythtv@mythbox:/home/mary$ mythbackend --versionPlease attach all output
as a file in bug reports.MythTV Version :
v31.0+fixes.202102081459.ba4036099f~ubuntu20.04.1MythTV Branch : fixes/31*

>
> If the error is related to a capture card that does convert external video
> signals such as a HD-PVR then it can be a configuration issue.
> In mythtv-setup look at page Input Connections / Interaction between
> Inputs
> For a HD-PVR the "Max Recordings" should be 1 and the "Schedule as Group"
> should be unchecked.
>

This sounds like it could be my problem as I have a HDPVR that I installed
a few weeks ago. However, I do not see a "Max Recordings" or "Schedule as
Group" setting under "Interactions between inputs." How can this be?

>
> When the "Schedule as Group" is checked then additional virtual tuners
> are created when needed, but this can only work when the complete transport
> stream is available such as with capture cards that have a tuner.
>
> Klaas.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: Fwd: backend (?) crash [ In reply to ]
From the description it sounds a lot like a bug I had found and fixed about
> a year ago. It was related to updating recording metadata on the frontend.
> That would cause the backend to stop accepting connections, although it
> still continued running and making recordings. Were you updating metadata
> at any time before?
>
> https://code.mythtv.org/trac/ticket/13479
>
> It was fixed in v30 and v31.
>
I don't believe I was updating metadata, although I was deleting many
channels (or trying to, they never seem to stay deleted).

> Make sure you have a v30 or v31 build later than Feb 2020, or avoid the
> recording metadata update screen.
>
I am running 31/fixes as supplied in package form by Linux MInt.

> Peter
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: Fwd: backend (?) crash [ In reply to ]
>
>
>> If the error is related to a capture card that does convert external
>> video signals such as a HD-PVR then it can be a configuration issue.
>> In mythtv-setup look at page Input Connections / Interaction between
>> Inputs
>> For a HD-PVR the "Max Recordings" should be 1 and the "Schedule as
>> Group" should be unchecked.
>>
>
> This sounds like it could be my problem as I have a HDPVR that I installed
> a few weeks ago. However, I do not see a "Max Recordings" or "Schedule as
> Group" setting under "Interactions between inputs." How can this be?
>
>>
>>
>> This is a bug. Somewhere in the past, the system defaults were correct
for the HDVPR so there was no need to make it configurable. Later on the
defaults have been changed but the HDPVR was forgotten. This bug was not
noticed because most of the time people do an upgrade and not a clean
install. If you do an upgrade the existing database settings are preserved,
so if you had a correct HDPVR configuration it stayed correct. Only new
installs (or those who create new capture cards entries....) will encounter
this.
I plan to fix this one way or another, either by adding the configuration
options or by changing the defaults for the HDPVR.
In the meantime, if you are comfortable with the command line you can fix
it with the following SQL:

[klaas@modu ~]$ mysql -u mythtv -pmythtv mythconverg
> MariaDB [mythconverg]> update capturecard set reclimit=1,schedgroup=0
> where cardtype="HDPVR" limit 1;
> Query OK, 1 row affected (0.003 sec)
> Rows matched: 1 Changed: 1 Warnings: 0


This is from my system, how I tested the command. On the first line, use
your own password after the -p (mine is mythtv).
The "limit 1" at the end limits the changes to max one record. This reduces
the effects of mistakes, but if you have two HDPVR devices you need then to
do it again.
To view the final result you can use this command:

> MariaDB [mythconverg]> select
> cardid,parentid,videodevice,cardtype,inputname,sourceid,reclimit,schedgroup
> from capturecard;
>
> +--------+----------+---------------------------------------------------+-----------+-----------+----------+----------+------------+
> | cardid | parentid | videodevice |
> cardtype | inputname | sourceid | reclimit | schedgroup |
>
> +--------+----------+---------------------------------------------------+-----------+-----------+----------+----------+------------+
> | 28 | 0 | /dev/dvb/adapter0/frontend0 |
> HDPVR | None | 17 | 1 | 0 |
>
> +--------+----------+---------------------------------------------------+-----------+-----------+----------+----------+------------+
> 27 rows in set (0.001 sec)


And then you see something like the above.
N.B. Have left here only the HDPVR entry.
N.B. Your videodevice is probably different, I do not have a HDPVR and have
just used another video device.

Hope this helps,
Klaas.
Re: Fwd: backend (?) crash [ In reply to ]
On Mon, 22 Feb 2021 at 21:15, Klaas de Waal <klaas.de.waal@gmail.com> wrote:

>
> On Mon, 22 Feb 2021 at 20:03, Mary Strimel <mary.strimel@gmail.com> wrote:
>
>> Thank you very much for the explanation and info.
>>
>>
>>> [klaas@modu ~]$ mysql -u mythtv -pmythtv mythconvergYes
>>>
>>> MariaDB [mythconverg]> update capturecard set reclimit=1,schedgroup=0
>>>> where cardtype="HDPVR" limit 1;
>>>> Query OK, 1 row affected (0.003 sec)
>>>> Rows matched: 1 Changed: 1 Warnings: 0
>>>
>>>
>> Will this work if I have mysql and not MariaDB?
>> I don't claim expertise in mysql but I've been able to run various
>> commands as needed for mythtv, so I think I could do it.
>>
>>>
> Yes this will work, there is no difference in mysql and MariaDB for this.
>
> Yesterday I fixed this in master (pre-v32) and v31/fixes. It will probably
take some time before the packages are updated.
When you have installed the latest you can then:
- delete the HDPVR capturecard
- create a new one
- create the Input Connection to the video source
and then it should be OK.
You can use the SQL command given before to verify if the database is
correct:

> MariaDB [mythconverg]> select
> cardid,parentid,videodevice,cardtype,inputname,sourceid,reclimit,schedgroup
> from capturecard;


Klaas.