[mythtv-users] Failed database update 1327->1328

Gary Buhrmaster gary.buhrmaster at gmail.com
Sun Jun 22 17:49:31 UTC 2014


On Sun, Jun 22, 2014 at 5:04 PM, Mike Perkins
<mikep at randomtraveller.org.uk> wrote:
....
> It isn't the primary key. That's something different. This is just a
> collection of fields indexed to make scheduling or searching easier.

If this is the commit I remember it to be, making this a unique
key avoids a set of "issues" (i.e. bugs) that can be introduced
if more than one row is created that is a duplicate (which, as
stated, should not occur, but stuff happens, and if the right
stuff hits the rotating air mover, the result is even more stuff).
Existing databases with duplicate rows will fail the schema upgrade.

I would agree that that makes it important to improve the schema
upgrade logic, since existing stuff may also be in other
real world databases (although what one should do with the
duplicates will presumably require some additional logic).

It might be worthwhile to open a ticket so that the devs
are aware of the potential issue before 0.28 is released
(not all of them read the users list, so this could get lost).

Of course, running master is often a bit bumpy, so the
interim fix is probably to remove your duplicate record
rules manually until a more proper fix-up is introduced.

Those that want to do check to see if they are going to
have issues can try to run a sql query of the form (only
written, never actually run/tested, and not really efficient):
  select * from record as p1 where (select count(*) from record as p2
    where p1.chanid = p2.chanid and p1.starttime = p2.starttime and
    p1.startdate = p2.startdate and p1.title = p2.title and p1.type =
p2.type) > 1;


More information about the mythtv-users mailing list