Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#7626 closed defect (invalid)

Mytharchive fails to import/export recordedmarkup

Reported by: djdallas@… Owned by: paulh
Priority: minor Milestone: unknown
Component: Plugin - MythArchive Version: 0.22
Severity: medium Keywords: mytharchive nuvexport
Cc: Ticket locked: no

Description

I've noticed while trying to move recordings with mytharchive from myth 0.21 to 0.22, that the the cutlists and adverts were not being imported to the new version.

The log would terminate with the following error:

2009-11-21 12:03:54.058 Inserted recorded details into database
2009-11-21 12:03:54.060 DB Error (recordedmark insert):
Query was:
INSERT INTO recordedmarkup (chanid, starttime, mark, offset, type)VALUES(?,?,?,?,?);
Bindings were:
:CHANID=1003, :MARK=0, :OFFSET=, :STARTTIME=2009-09-20T20:00:00, :TYPE=-3
No error type from QSqlError?  Strange...
QSqlDatabasePrivate::removeDatabase: connection 'DBManager0' is still in use, all queries will cease to work.

I then made a new recording, ran mythcommflag and created a editing cutlist. Once done, I exproted the new recording, deleted the origional, and then imported it again. There were no advert or cut marks in the imported file.

Comparing the old (0.21) and new (0.22) .xml files, I noticed that the recordedmarkup table entries were not present in the exported files.

On checking the mysql database, I noticed that the columns in recordedmarkup tables are different between the two mythtv versions: specifically the "offset" column is now called "data" in the new version.

Here's an extract from the file which created the new database in myth 0.22:

DROP TABLE IF EXISTS `recordedmarkup`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `recordedmarkup` (
  `chanid` int(10) unsigned NOT NULL DEFAULT '0',
  `starttime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `mark` mediumint(8) unsigned NOT NULL DEFAULT '0',
  `type` tinyint(4) NOT NULL DEFAULT '0',
  `data` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`chanid`,`starttime`,`type`,`mark`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

The old version (0.21) was:

  `offset` varchar(32) default NULL,

Looks like a deliberate change to me...

Nuvexport .sql files will import the recordedmarkup data correctly ONLY IF the file is edited to change the "offset" entry to read "data" instead. (using: "mysql -u mythtv -p mythconverg < *.sql")

I could not get mytharchive to import recordedmarkups correctly, even after editing the .xml file.

My guess is that either the mapping in mytharchive doesn't take the changes into consideration, or that the new myth version 0.22 is creating the table incorrectly.

I'm an Ubuntu Karmic user, so I'm reporting this at launchpad as well.

Thanks David

Change History (2)

comment:1 Changed 10 years ago by sphery

Resolution: invalid
Status: newclosed

MythArchive?, and MythTV, in general, do not support importing data from previous DB schema versions. You must import MythArchive? native exports (and restore mythconverg backups) into the same DB schema version from which they were created. Therefore, exports from 0.21-fixes are not compatible with 0.22 fixes.

The proper procedure to make sure the exported programs were brought over after upgrade to 0.22-fixes would have been to import them into 0.21-fixes, then back up the database, then upgrade to 0.22-fixes and let MythTV's database upgrade convert the data. If you have questions on proper upgrade procedure, please ask for more information on the mythtv-users list.

There is hope to one day make a real export format that's not version specific, but at this point, it's just a feature request/item on some TODO lists.

comment:2 Changed 10 years ago by djdallas@…

Ah. I didn't realise that.

I found that temporarily changing the database column name to offset, and replacing offset="" entries in the mytharchive .xml files with offset="NULL", allowed me to import the recordings properly.

Thanks for the prompt reply and explanation. Keep up the good work,

David

Note: See TracTickets for help on using tickets.