I have what might be a bug, but might be benign, and would like to
know if it's going to affect me going forward. (And if it's worth
working up a patch so it doesn't bite someone else.)
I've recently created a v31 myth backend on a new machine, starting
from v0.18 (yes, you read that right) on an old machine. I got there by
installing Ubuntu 10.10 on a different old machine[0], upgrading the v0.18
DB under v0.23 to schema 1254, and then using v31 on an Ubuntu 20.04 machine
to upgrade to schema 1360.
I have all the relevant database backups, and am probably going to
run this upgrade path once more in the near future as part of running
the new and old myths in parallel for a while before decomissioning
the old one, so I can refer to old DB's and perhaps even run a test
if someone thinks it'd be useful.
Along the way, I hit one issue which I fixed[1], and saw one warning
which may or may not be an issue but probably reflects a slight bug in
one of the upgrade schemas which may yet bite someone.
The warning looked like this:
> [ . . . ]
> 2021-07-26 23:08:52.121900 C Upgrading to MythTV schema version 1301
> 2021-07-26 23:08:52.759652 C Upgrading to MythTV schema version 1302
> 2021-07-26 23:08:52.769408 E DB Error (GetRecgroupString()):
> Query was:
> SELECT recgroup FROM recgroups WHERE recgroupid = 1
> Bindings were:
> :RECGROUPID=1
> Driver error was [2/1146]:
> QMYSQL: Unable to execute query
> Database error was:
> Table 'mythconverg.recgroups' doesn't exist
>
> 2021-07-26 23:08:52.769770 E DB Error (UPDATE/INSERT record):
> Query was:
> INSERT INTO record SET type = 11, search = 0, recpriority = 0, prefinput = 0, startoffset = 0, endoffset = 0, dupmethod = 6, dupin = 15, filter = 0, inactive = 0, profile = 'Default', recgroup = '', recgroupid = 1, storagegroup = 'Default\
> ', playgroup = 'Default', autoexpire = 0, maxepisodes = 0, maxnewest = 0, autocommflag = 1, autotranscode = 0, transcoder = 0, autouserjob1 = 0, autouserjob2 = 0, autouserjob3 = 0, autouserjob4 = 0, autometadata = 1, parentid = 0, title =\
> 'Default (Template)', subtitle = '', season = 0, episode = 0, description = '', category = 'Default', starttime = '03:08:52', startdate = '2021-07-27', endtime = '03:08:52', enddate = '2021-07-27', seriesid = '', programid = '', inetref \
> = '', chanid = 0, station = '', findday = 0, findtime = '00:00:00', findid = 738362, next_record = NULL, last_record = NULL, last_delete = NULL, avg_delay = 100 ;
> Bindings were:
> :AUTOCOMMFLAG=true, :AUTOEXPIRE=false, :AUTOMETADATA=true, :AUTOTRANSCODE=false,
> :AUTOUSERJOB1=false, :AUTOUSERJOB2=false, :AUTOUSERJOB3=false,
> :AUTOUSERJOB4=false, :AVGDELAY=100, :CATEGORY="Default", :CHANID=0,
> :DESCRIPTION="", :DUPIN=15, :DUPMETHOD=6, :ENDDATE=2021-07-27, :ENDOFFSET=0,
> :ENDTIME=03:08:52.759, :EPISODE=0, :FILTER=0, :FINDDAY=0, :FINDID=738362,
> :FINDTIME=00:00:00.000, :INACTIVE=false, :INETREF="", :INPUT=0, :LASTDELETE=NULL,
> :LASTREC=NULL, :MAXEPISODES=0, :MAXNEWEST=false, :NEXTREC=NULL, :PARENTID=0,
> :PLAYGROUP="Default", :PROGRAMID="", :RECGROUP="", :RECGROUPID=1, :RECPRIORITY=0,
> :RECPROFILE="Default", :SEARCHTYPE=0, :SEASON=0, :SERIESID="",
> :STARTDATE=2021-07-27, :STARTOFFSET=0, :STARTTIME=03:08:52.759, :STATION="",
> :STORAGEGROUP="Default", :SUBTITLE="", :TITLE="Default (Template)",
> :TRANSCODER=0, :TYPE=11
> Driver error was [2/1054]:
> QMYSQL: Unable to execute query
> Database error was:
> Unknown column 'recgroupid' in 'field list'
>
> 2021-07-26 23:08:52.770133 C Upgrading to MythTV schema version 1303
> 2021-07-26 23:09:01.867517 C Upgrading to MythTV schema version 1304
> 2021-07-26 23:09:06.450166 C Upgrading to MythTV schema version 1305
> [ . . . ]
This appears to be a complaint that the recgroups table didn't exist,
and it in fact does not appear to exist in pre-upgrade databases.
[.Presumably it would have existed if I'd done the relevant setup in some
intermediate version, but I didn't.] However, the upgrade continued,
and when it finished, the table did exist, and was populated with the
Default, LiveTV, and Deleted recgroups, which seems reasonable.
I wasn't easily able to find this in dbcheck.cpp, though---the relevant
stanza doesn't seem to mention this query at all, but I didn't check all
the functions it calls. So I'm not exactly sure what's going on here
or if there's some other problem this might cause later.
Opinions? Can someone explain what this was trying to do, and/or what
I should be looking for (or fixing) in my DB if it failed to do so?
[0] I got partway down the rabbit hole of trying to run 10.10 in a
schroot under 20.04, then realized that trying to get 10.10's mysql not
to fight with the 20.04 installation was going to be problematic, and
decided that using a flash drive to install 10.10 on a machine that had
been sitting around for years was going to be way faster than dealing
with spinning up a real VM. (Like, it took me half an hour, plus
spending 30 seconds replacing the BIOS battery.) After all, I don't
intend to run the 10.10 machine once the upgrade is complete.
[1] While upgrading to schema 1266, I got exactly the error described in
http://lists.mythtv.org/pipermail/mythtv-users/2012-April/331349.html,
and fixed it with the code from Mike which drops a bunch of video*
tables. (Thanks Mike!) Judging from the single line in one of the
tables, apparently I'd tried MythVideo precisely once (probably when
the original machine was days old), and then completely forgot about
it forever.
_______________________________________________
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
know if it's going to affect me going forward. (And if it's worth
working up a patch so it doesn't bite someone else.)
I've recently created a v31 myth backend on a new machine, starting
from v0.18 (yes, you read that right) on an old machine. I got there by
installing Ubuntu 10.10 on a different old machine[0], upgrading the v0.18
DB under v0.23 to schema 1254, and then using v31 on an Ubuntu 20.04 machine
to upgrade to schema 1360.
I have all the relevant database backups, and am probably going to
run this upgrade path once more in the near future as part of running
the new and old myths in parallel for a while before decomissioning
the old one, so I can refer to old DB's and perhaps even run a test
if someone thinks it'd be useful.
Along the way, I hit one issue which I fixed[1], and saw one warning
which may or may not be an issue but probably reflects a slight bug in
one of the upgrade schemas which may yet bite someone.
The warning looked like this:
> [ . . . ]
> 2021-07-26 23:08:52.121900 C Upgrading to MythTV schema version 1301
> 2021-07-26 23:08:52.759652 C Upgrading to MythTV schema version 1302
> 2021-07-26 23:08:52.769408 E DB Error (GetRecgroupString()):
> Query was:
> SELECT recgroup FROM recgroups WHERE recgroupid = 1
> Bindings were:
> :RECGROUPID=1
> Driver error was [2/1146]:
> QMYSQL: Unable to execute query
> Database error was:
> Table 'mythconverg.recgroups' doesn't exist
>
> 2021-07-26 23:08:52.769770 E DB Error (UPDATE/INSERT record):
> Query was:
> INSERT INTO record SET type = 11, search = 0, recpriority = 0, prefinput = 0, startoffset = 0, endoffset = 0, dupmethod = 6, dupin = 15, filter = 0, inactive = 0, profile = 'Default', recgroup = '', recgroupid = 1, storagegroup = 'Default\
> ', playgroup = 'Default', autoexpire = 0, maxepisodes = 0, maxnewest = 0, autocommflag = 1, autotranscode = 0, transcoder = 0, autouserjob1 = 0, autouserjob2 = 0, autouserjob3 = 0, autouserjob4 = 0, autometadata = 1, parentid = 0, title =\
> 'Default (Template)', subtitle = '', season = 0, episode = 0, description = '', category = 'Default', starttime = '03:08:52', startdate = '2021-07-27', endtime = '03:08:52', enddate = '2021-07-27', seriesid = '', programid = '', inetref \
> = '', chanid = 0, station = '', findday = 0, findtime = '00:00:00', findid = 738362, next_record = NULL, last_record = NULL, last_delete = NULL, avg_delay = 100 ;
> Bindings were:
> :AUTOCOMMFLAG=true, :AUTOEXPIRE=false, :AUTOMETADATA=true, :AUTOTRANSCODE=false,
> :AUTOUSERJOB1=false, :AUTOUSERJOB2=false, :AUTOUSERJOB3=false,
> :AUTOUSERJOB4=false, :AVGDELAY=100, :CATEGORY="Default", :CHANID=0,
> :DESCRIPTION="", :DUPIN=15, :DUPMETHOD=6, :ENDDATE=2021-07-27, :ENDOFFSET=0,
> :ENDTIME=03:08:52.759, :EPISODE=0, :FILTER=0, :FINDDAY=0, :FINDID=738362,
> :FINDTIME=00:00:00.000, :INACTIVE=false, :INETREF="", :INPUT=0, :LASTDELETE=NULL,
> :LASTREC=NULL, :MAXEPISODES=0, :MAXNEWEST=false, :NEXTREC=NULL, :PARENTID=0,
> :PLAYGROUP="Default", :PROGRAMID="", :RECGROUP="", :RECGROUPID=1, :RECPRIORITY=0,
> :RECPROFILE="Default", :SEARCHTYPE=0, :SEASON=0, :SERIESID="",
> :STARTDATE=2021-07-27, :STARTOFFSET=0, :STARTTIME=03:08:52.759, :STATION="",
> :STORAGEGROUP="Default", :SUBTITLE="", :TITLE="Default (Template)",
> :TRANSCODER=0, :TYPE=11
> Driver error was [2/1054]:
> QMYSQL: Unable to execute query
> Database error was:
> Unknown column 'recgroupid' in 'field list'
>
> 2021-07-26 23:08:52.770133 C Upgrading to MythTV schema version 1303
> 2021-07-26 23:09:01.867517 C Upgrading to MythTV schema version 1304
> 2021-07-26 23:09:06.450166 C Upgrading to MythTV schema version 1305
> [ . . . ]
This appears to be a complaint that the recgroups table didn't exist,
and it in fact does not appear to exist in pre-upgrade databases.
[.Presumably it would have existed if I'd done the relevant setup in some
intermediate version, but I didn't.] However, the upgrade continued,
and when it finished, the table did exist, and was populated with the
Default, LiveTV, and Deleted recgroups, which seems reasonable.
I wasn't easily able to find this in dbcheck.cpp, though---the relevant
stanza doesn't seem to mention this query at all, but I didn't check all
the functions it calls. So I'm not exactly sure what's going on here
or if there's some other problem this might cause later.
Opinions? Can someone explain what this was trying to do, and/or what
I should be looking for (or fixing) in my DB if it failed to do so?
[0] I got partway down the rabbit hole of trying to run 10.10 in a
schroot under 20.04, then realized that trying to get 10.10's mysql not
to fight with the 20.04 installation was going to be problematic, and
decided that using a flash drive to install 10.10 on a machine that had
been sitting around for years was going to be way faster than dealing
with spinning up a real VM. (Like, it took me half an hour, plus
spending 30 seconds replacing the BIOS battery.) After all, I don't
intend to run the 10.10 machine once the upgrade is complete.
[1] While upgrading to schema 1266, I got exactly the error described in
http://lists.mythtv.org/pipermail/mythtv-users/2012-April/331349.html,
and fixed it with the code from Mike which drops a bunch of video*
tables. (Thanks Mike!) Judging from the single line in one of the
tables, apparently I'd tried MythVideo precisely once (probably when
the original machine was days old), and then completely forgot about
it forever.
_______________________________________________
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