Mailing List Archive

On Mon, Jan 24, 2022 at 4:59 PM John Pilkington <johnpilk222@gmail.com> wrote:

> Database error was:
> Specified key was too long; max key length is 767 bytes
>
> 2022-01-24 15:58:50.844369 E Database schema upgrade failed.
> 2022-01-24 15:58:50.844695 E Couldn't upgrade database to new schema.

It is likely that your default storage engine
is innodb (that could be the default for your
version of the database, or you could be
explicitly specifying it), *and* you do not
have innodb_large_prefix set (typically
the default) along with the dynamic row
format (again, typically the default) that
one would get by specifying barracuda
as the innodb_file_format.

That said, the create table statement
for these sports extensions *should*
have explicitly set the engine to be
MYISAM(*), as the other create tables
do, in order to avoid the random issues
one otherwise can encounter with
different configurations.

I would suggest you open a github
issue against the failure to upgrade
(and the commit).






(*) MYISAM is problematic for
other reasons, but it is the MythTV
default default because it is well
known.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 24, 2022 at 5:22 PM Gary Buhrmaster
<gary.buhrmaster@gmail.com> wrote:

> That said, the create table statement
> for these sports extensions *should*
> have explicitly set the engine to be
> MYISAM(*), as the other create tables
> do, in order to avoid the random issues
> one otherwise can encounter with
> different configurations.
>
> I would suggest you open a github
> issue against the failure to upgrade
> (and the commit).

I just noticed another issue. The sportslisting
table uses a foreign key. And MYISAM does
not support foreign keys.

TTBOMK, the MythTV project as historically
avoided using foreign keys (preferring to
implement the business logic in the code,
and any cleanups, including inconsistencies,
to be in the housekeeping codes) in order
to be database independent.

So, with MYISAM not supporting foreign
keys, and INNODB needing to be configured
specifically to support such large key lengths,
one would seem to have additional issues
to consider and decide upon.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, 2022-01-24 at 17:38 +0000, Gary Buhrmaster wrote:
> On Mon, Jan 24, 2022 at 5:22 PM Gary Buhrmaster
> <gary.buhrmaster@gmail.com> wrote:
> I just noticed another issue.  The sportslisting
> table uses a foreign key.  And MYISAM does
> not support foreign keys.
>
> TTBOMK, the MythTV project as historically
> avoided using foreign keys (preferring to
> implement the business logic in the code,
> and any cleanups, including inconsistencies,
> to be in the housekeeping codes) in order
> to be database independent.

I think I can just drop the FOREIGN_KEY statement, as the code already
contains the following constraint in the select statement(1):

"INNER JOIN sportsapi api ON sl.api = api.id"

I only have a passing familiarity with sql, so I'd love to hear from
anyone with more experience if this is a correct solution.

Thanks.

David

1) From programs/mythbackend/recordingextender.cpp:1153.

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 24/01/2022 17:56, David Hampton via mythtv-dev wrote:
> On Mon, 2022-01-24 at 17:38 +0000, Gary Buhrmaster wrote:
>> On Mon, Jan 24, 2022 at 5:22 PM Gary Buhrmaster
>> <gary.buhrmaster@gmail.com> wrote:
>> I just noticed another issue.  The sportslisting
>> table uses a foreign key.  And MYISAM does
>> not support foreign keys.
>>
>> TTBOMK, the MythTV project as historically
>> avoided using foreign keys (preferring to
>> implement the business logic in the code,
>> and any cleanups, including inconsistencies,
>> to be in the housekeeping codes) in order
>> to be database independent.
>
> I think I can just drop the FOREIGN_KEY statement, as the code already
> contains the following constraint in the select statement(1):
>
> "INNER JOIN sportsapi api ON sl.api = api.id"
>
> I only have a passing familiarity with sql, so I'd love to hear from
> anyone with more experience if this is a correct solution.
>
> Thanks.
>
> David
>
> 1) From programs/mythbackend/recordingextender.cpp:1153.
>
I can't comment on that; but after a fairly protracted session with yum
erase --nodeps, yum install and myththconverg_restore.pl I appear to be
back to a working system - I hope :-)

I still have the new rpms; good to know that they will build and are
installable.

John

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 24/01/2022 17:56, David Hampton via mythtv-dev wrote:
> On Mon, 2022-01-24 at 17:38 +0000, Gary Buhrmaster wrote:
>> On Mon, Jan 24, 2022 at 5:22 PM Gary Buhrmaster
>> <gary.buhrmaster@gmail.com> wrote:
>> I just noticed another issue.  The sportslisting
>> table uses a foreign key.  And MYISAM does
>> not support foreign keys.
>>
>> TTBOMK, the MythTV project as historically
>> avoided using foreign keys (preferring to
>> implement the business logic in the code,
>> and any cleanups, including inconsistencies,
>> to be in the housekeeping codes) in order
>> to be database independent.
>
> I think I can just drop the FOREIGN_KEY statement, as the code already
> contains the following constraint in the select statement(1):
>
> "INNER JOIN sportsapi api ON sl.api = api.id"
>
> I only have a passing familiarity with sql, so I'd love to hear from
> anyone with more experience if this is a correct solution.
>
> Thanks.
>
> David
>
> 1) From programs/mythbackend/recordingextender.cpp:1153.

I just tried again, but no luck:
{{{
2022-01-30 09:53:18.551453 C mythtv-setup version: HEAD
[v32-Pre-fd4b8e3487] www.mythtv.org
2022-01-30 09:53:18.551459 C Qt version: compile: 5.9.7, runtime: 5.9.7
2022-01-30 09:53:18.562244 I Scientific Linux 7.9 (Nitrogen) (x86_64)


2022-01-30 09:54:20.094519 C Upgrading to MythTV schema version 1371
2022-01-30 09:54:20.095828 E DB Error (Performing MythtTV database
upgrade):
Query was: CREATE TABLE sportsapi (
id INT UNSIGNED PRIMARY KEY,
provider TINYINT UNSIGNED DEFAULT 0,
name VARCHAR(128) NOT NULL,
key1 VARCHAR(256) NOT NULL,
key2 VARCHAR(256) NOT NULL,
UNIQUE(provider,key1,key2)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
Error was: Driver error was [2/1071]:
QMYSQL: Unable to execute query
Database error was:
Specified key was too long; max key length is 1000 bytes
}}}

John
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, 2022-01-30 at 10:01 +0000, John Pilkington wrote:
> On 24/01/2022 17:56, David Hampton via mythtv-dev wrote:
> > On Mon, 2022-01-24 at 17:38 +0000, Gary Buhrmaster wrote:
> > > On Mon, Jan 24, 2022 at 5:22 PM Gary Buhrmaster
> > > <gary.buhrmaster@gmail.com> wrote:
> > > I just noticed another issue.  The sportslisting
> > > table uses a foreign key.  And MYISAM does
> > > not support foreign keys.
> > >
> > > TTBOMK, the MythTV project as historically
> > > avoided using foreign keys (preferring to
> > > implement the business logic in the code,
> > > and any cleanups, including inconsistencies,
> > > to be in the housekeeping codes) in order
> > > to be database independent.
> >
> > I think I can just drop the FOREIGN_KEY statement, as the code
> > already
> > contains the following constraint in the select statement(1):
> >
> >      "INNER JOIN sportsapi api ON sl.api = api.id"
> >
> > I only have a passing familiarity with sql, so I'd love to hear
> > from
> > anyone with more experience if this is a correct solution.
> >
> > Thanks.
> >
> > David
> >
> > 1) From programs/mythbackend/recordingextender.cpp:1153.
>
> I just tried again, but no luck:
> {{{
> 2022-01-30 09:53:18.551453 C  mythtv-setup version: HEAD
> [v32-Pre-fd4b8e3487] www.mythtv.org
> 2022-01-30 09:53:18.551459 C  Qt version: compile: 5.9.7, runtime:
> 5.9.7
> 2022-01-30 09:53:18.562244 I  Scientific Linux 7.9 (Nitrogen)
> (x86_64)
>
>
> 2022-01-30 09:54:20.094519 C  Upgrading to MythTV schema version 1371
> 2022-01-30 09:54:20.095828 E  DB Error (Performing MythtTV database
> upgrade):
> Query was: CREATE TABLE sportsapi (
>                id INT UNSIGNED PRIMARY KEY,
>                provider TINYINT UNSIGNED DEFAULT 0,
>                name VARCHAR(128) NOT NULL,
>                key1 VARCHAR(256) NOT NULL,
>                key2 VARCHAR(256) NOT NULL,
>                UNIQUE(provider,key1,key2)
>                ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
> Error was: Driver error was [2/1071]:
> QMYSQL: Unable to execute query
> Database error was:
> Specified key was too long; max key length is 1000 bytes
> }}}

Hi John,

Can you give the attached patch a try before I commit it? I've reduced
the size of the two keys, and pared down the index even further by
looking at the statistical lengths of the data. Thanks.

David

On 30/01/2022 15:14, David Hampton via mythtv-dev wrote:

>> I just tried again, but no luck:
>> {{{
>> 2022-01-30 09:53:18.551453 C  mythtv-setup version: HEAD
>> [v32-Pre-fd4b8e3487] www.mythtv.org
>> 2022-01-30 09:53:18.551459 C  Qt version: compile: 5.9.7, runtime:
>> 5.9.7
>> 2022-01-30 09:53:18.562244 I  Scientific Linux 7.9 (Nitrogen)
>> (x86_64)
>>
>>
>> 2022-01-30 09:54:20.094519 C  Upgrading to MythTV schema version 1371
>> 2022-01-30 09:54:20.095828 E  DB Error (Performing MythtTV database
>> upgrade):
>> Query was: CREATE TABLE sportsapi (
>>                id INT UNSIGNED PRIMARY KEY,
>>                provider TINYINT UNSIGNED DEFAULT 0,
>>                name VARCHAR(128) NOT NULL,
>>                key1 VARCHAR(256) NOT NULL,
>>                key2 VARCHAR(256) NOT NULL,
>>                UNIQUE(provider,key1,key2)
>>                ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
>> Error was: Driver error was [2/1071]:
>> QMYSQL: Unable to execute query
>> Database error was:
>> Specified key was too long; max key length is 1000 bytes
>> }}}
>
> Hi John,
>
> Can you give the attached patch a try before I commit it? I've reduced
> the size of the two keys, and pared down the index even further by
> looking at the statistical lengths of the data. Thanks.
>
> David

Hi David: I'll try, but there will be some delay. I haven't used
patches recently, and need to do other things. It's probably not a
widespread problem anyway... :-)

John
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 30/01/2022 16:08, John Pilkington wrote:
> On 30/01/2022 15:14, David Hampton via mythtv-dev wrote:

>>> I just tried again, but no luck:
LT CHARSET=utf8;
>>> Error was: Driver error was [2/1071]:
>>> QMYSQL: Unable to execute query
>>> Database error was:
>>> Specified key was too long; max key length is 1000 bytes
>>> }}}
>>
>> Hi John,
>>
>> Can you give the attached patch a try before I commit it?  I've reduced
>> the size of the two keys, and pared down the index even further by
>> looking at the statistical lengths of the data. Thanks.
>>
>> David
>
> Hi David:  I'll try, but there will be some delay.  I haven't used
> patches recently, and need to do other things.  It's probably not a
> widespread problem anyway... :-)
>
I suppose I ought to apply the patch within a git fork of myth, but I
don't want to put my normal builds at risk. Instead I tried it within
the build script. I guess the filesystems aren't quite lined up. At
least on this occasion it found the patch...and would have built
unpatched if I hadn't stopped it.

{{{
===========

TMPCLONEDIR=`mktemp -d`
pushd $TMPCLONEDIR >/dev/null
git clone $REPO mythtv

git apply /home/john/packaging/MythTV/rpm/SOURCES/dbcheck.patch

pushd mythtv >/dev/null
git checkout $GITCOMMITISH

========

diff --git a/mythtv/libs/libmythtv/dbcheck.cpp
b/mythtv/libs/libmythtv/dbcheck.cpp
index 7802c46146..e567f0742e 100644
--- a/mythtv/libs/libmythtv/dbcheck.cpp
+++ b/mythtv/libs/libmythtv/dbcheck.cpp

============

remote: Compressing objects: 100% (877/877), done.
remote: Total 462153 (delta 1106), reused 1781 (delta 1023), pack-reused
460233
Receiving objects: 100% (462153/462153), 409.40 MiB | 6.65 MiB/s, done.
Resolving deltas: 100% (373426/373426), done.
Updating files: 100% (18073/18073), done.
error: mythtv/libs/libmythtv/dbcheck.cpp: No such file or directory
Already on 'master'
Your branch is up to date with 'origin/master'.
----
Building mythtv version 32.Pre.3486.gfd4b8e3487 at commit
fd4b8e3487265a69058155eba78eac4c6ad39783
----
}}}

> John

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 30/01/2022 23:10, John Pilkington wrote:
> On 30/01/2022 16:08, John Pilkington wrote:
>> On 30/01/2022 15:14, David Hampton via mythtv-dev wrote:
<snip>
>>> Hi John,
>>>
>>> Can you give the attached patch a try before I commit it?  I've reduced
>>> the size of the two keys, and pared down the index even further by
>>> looking at the statistical lengths of the data. Thanks.
>>>
>
I now have the patch working, but the actual builds still use an
unpatched tarball. WIP, I hope.

John
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, 2022-01-31 at 09:19 +0000, John Pilkington wrote:
> On 30/01/2022 23:10, John Pilkington wrote:
> > On 30/01/2022 16:08, John Pilkington wrote:
> > > On 30/01/2022 15:14, David Hampton via mythtv-dev wrote:
> <snip>
> > > > Hi John,
> > > >
> > > > Can you give the attached patch a try before I commit it?  I've
> > > > reduced
> > > > the size of the two keys, and pared down the index even further
> > > > by
> > > > looking at the statistical lengths of the data. Thanks.
> > > >
> >
> I now have the patch working, but the actual builds still use an
> unpatched tarball.  WIP, I hope.

Thanks for testing on your system. I'll commit it today.

David

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 31/01/2022 16:02, David Hampton via mythtv-dev wrote:
> On Mon, 2022-01-31 at 09:19 +0000, John Pilkington wrote:
>> On 30/01/2022 23:10, John Pilkington wrote:
>>> On 30/01/2022 16:08, John Pilkington wrote:
>>>> On 30/01/2022 15:14, David Hampton via mythtv-dev wrote:
>> <snip>
>>>>> Hi John,
>>>>>
>>>>> Can you give the attached patch a try before I commit it?  I've
>>>>> reduced
>>>>> the size of the two keys, and pared down the index even further
>>>>> by
>>>>> looking at the statistical lengths of the data. Thanks.
>>>>>
>>>
>> I now have the patch working, but the actual builds still use an
>> unpatched tarball.  WIP, I hope.
>
> Thanks for testing on your system. I'll commit it today.
>
> David

Some confusion, I'm afraid. I was able to apply the patch but have not
yet been able to build rpms that include it. At present the builder
still uses the unmodified master, and I have not let it run to completion.

If you commit I should be able to build and test; if you don't, I hope
to get there eventually...

John

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Jan 24, 2022 at 5:56 PM David Hampton via mythtv-dev
<mythtv-dev@mythtv.org> wrote:

> I think I can just drop the FOREIGN_KEY statement, as the code already
> contains the following constraint in the select statement(1):
>
> "INNER JOIN sportsapi api ON sl.api = api.id"

I see where you changed the engine in the create
for the sports.... tables. Thanks.

However, from a cursory skim, there are now
some lingering issues.

For those that *have* already updated their DB
(and had a default engine of something other than
myisam so it will have worked), they still have
the foreign key for the sportslisting table and will
have the previous engine for all the sports.. tables.
Also, the columns will have the wrong lengths.
New upgraders will not.

That will lead to people having different
mythconverg schemas, which will, inevitably,
lead to issues at some future point.

The easiest easiest way forward, if one is
willing to lose existing data is another
db update that deletes the sports... tables
and recreates them as you wish (be sure
to note the api key issue below).

The 2nd easiest way for the tables other than
sportslisting is a simple database update
ALTERing the engine to myisam which will
preserve all the data (a long time ago I
seem to recall such a bulk ALTER to
change the engine). However, there
is (was?) no way to delete a foreign key
only if it exists, so that those that have already
created the sportslisting table will have
that foreign key, others will not. One solution,
if the sportslisting table can be easily recreated,
is just drop it, and recreate it without the
foreign key (this is, of course, just a subset
of the easiest easiest which does this for
all the sports.... tables). Note that one will
now not get an index on the api variable
(the foreign key auto generated one for you),
so joins may be sub-optimal, so you may
want to explicitly create such an index
(KEY api (api)) in the CREATE stmt
(whether the join will actually be sub-optimal
depends on other factors).

If the sportslisting table contents are
not easily recreated for existing users,
one will (probably) need to RENAME
the existing table, create sportslisting
as you wish, and then copy back the
data (as I recall that was done for
some other table for MythTV (db update
1310 is sort of like that)).



Hopefully that all makes a bit of sense.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 31/01/2022 17:33, John Pilkington wrote:
> On 31/01/2022 16:02, David Hampton via mythtv-dev wrote:
>> On Mon, 2022-01-31 at 09:19 +0000, John Pilkington wrote:
>>> On 30/01/2022 23:10, John Pilkington wrote:
>>>> On 30/01/2022 16:08, John Pilkington wrote:
>>>>> On 30/01/2022 15:14, David Hampton via mythtv-dev wrote:
>>> <snip>
>>>>>> Hi John,
>>>>>>
>>>>>> Can you give the attached patch a try before I commit it?  I've
>>>>>> reduced
>>>>>> the size of the two keys, and pared down the index even further
>>>>>> by
>>>>>> looking at the statistical lengths of the data. Thanks.
>>>>>>
>>>>
>>> I now have the patch working, but the actual builds still use an
>>> unpatched tarball.  WIP, I hope.
>>
>> Thanks for testing on your system. I'll commit it today.
>>
>> David
>
> Some confusion, I'm afraid.  I was able to apply the patch but have not
> yet been able to build rpms that include it.  At present the builder
> still uses the unmodified master, and I have not let it run to completion.
>
> If you commit I should be able to build and test;  if you don't, I hope
> to get there eventually...
>
> John
>
I'm afraid this is on a different level from Gary's concerns, but
Ihere's another update on my build problems.

I realised that the build script has, as its first line, the URL of the
MythTV GitHub page; and I already had a fork of that, unused for some
time. So I resynced that to master, successfully uploaded the patch,
and updated the URL in the script. The commit string had changed and
the build worked, but midway through I realised that the patch hadn't
been applied there either; the old code was still on the forked webpage.

Another build is now going ahead using the new code from the unforked
GitHub. The inactive patch has the comment "Add files via upload" - and
I suppose I should now delete it.

John
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, 2022-01-31 at 22:52 +0000, John Pilkington wrote:
> On 31/01/2022 17:33, John Pilkington wrote:
> > On 31/01/2022 16:02, David Hampton via mythtv-dev wrote:
> > > On Mon, 2022-01-31 at 09:19 +0000, John Pilkington wrote:
> > > > On 30/01/2022 23:10, John Pilkington wrote:
> > > > > On 30/01/2022 16:08, John Pilkington wrote:
> > > > > > On 30/01/2022 15:14, David Hampton via mythtv-dev wrote:
> > > > <snip>
> > > > > > > Hi John,
> > > > > > >
> > > > > > > Can you give the attached patch a try before I commit
> > > > > > > it?  I've
> > > > > > > reduced
> > > > > > > the size of the two keys, and pared down the index even
> > > > > > > further
> > > > > > > by
> > > > > > > looking at the statistical lengths of the data. Thanks.
> > > > > > >
> > > > >
> > > > I now have the patch working, but the actual builds still use
> > > > an
> > > > unpatched tarball.  WIP, I hope.
> > >
> > > Thanks for testing on your system. I'll commit it today.
> > >
> > > David
> >
> > Some confusion, I'm afraid.  I was able to apply the patch but have
> > not
> > yet been able to build rpms that include it.  At present the
> > builder
> > still uses the unmodified master, and I have not let it run to
> > completion.
> >
> > If you commit I should be able to build and test;  if you don't, I
> > hope
> > to get there eventually...
> >
> > John
> >
> I'm afraid this is on a different level from Gary's concerns, but
> Ihere's another update on my build problems.
>
> I realised that the build script has, as its first line, the URL of
> the
> MythTV GitHub page; and I already had a fork of that, unused for some
> time.  So I resynced that to master, successfully uploaded the patch,
> and updated the URL in the script.  The commit string had changed and
> the build worked, but midway through I realised that the patch hadn't
> been applied there either;  the old code was still on the forked
> webpage.
>
> Another build is now going ahead using the new code from the unforked
> GitHub.  The inactive patch has the comment "Add files via upload" -
> and
> I suppose I should now delete it.

I committed that change to git earlier today about noon EST. If you
pulled master since then you don't need to apply the patch.

David

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 01/02/2022 05:26, David Hampton via mythtv-dev wrote:
> On Mon, 2022-01-31 at 22:52 +0000, John Pilkington wrote:

>> I'm afraid this is on a different level from Gary's concerns, but
>> Ihere's another update on my build problems.
>>
>> I realised that the build script has, as its first line, the URL of
>> the
>> MythTV GitHub page; and I already had a fork of that, unused for some
>> time.  So I resynced that to master, successfully uploaded the patch,
>> and updated the URL in the script.  The commit string had changed and
>> the build worked, but midway through I realised that the patch hadn't
>> been applied there either;  the old code was still on the forked
>> webpage.
>>
>> Another build is now going ahead using the new code from the unforked
>> GitHub.  The inactive patch has the comment "Add files via upload" -
>> and
>> I suppose I should now delete it.
>
> I committed that change to git earlier today about noon EST. If you
> pulled master since then you don't need to apply the patch.
>
> David
>

{{{

[john@HP_Box ~]$ MYTHTV_NO_EGL=1 mythfrontend

2022-02-01 09:14:26.364577 C mythfrontend version: HEAD
[v32-Pre-84a2beeaef] www.mythtv.org
2022-02-01 09:14:26.364581 C Qt version: compile: 5.9.7, runtime: 5.9.7
2022-02-01 09:14:26.364608 I Scientific Linux 7.9 (Nitrogen) (x86_64)

[john@HP_Box ~]$ uname -r
5.4.175-1.el7.elrepo.x86_64

}}}

Thanks to all!

John P
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org