LinHES Forums

Upgrade path R5A30.2 to LinHES
Page 1 of 2

Author:  Ralph [ Sun Jun 07, 2015 3:19 am ]
Post subject:  Upgrade path R5A30.2 to LinHES

I'm still running KnoppMyth R5A30.2 which is MythTV 0.18 (on a Pentium 4 with 2GB RAM and a small IDE drive with combined front/backend, all recordings are stored on a network drive) and would like to know if there is an upgrade path to LinHES?

Have looked through (R5F27 >> LH) and (R5D1 >> LH) but I suspect things may get even trickier when starting from a version as old as mine?

It would be important to retain access to my existing library of .nuv recordings - otherwise I would probably just do a clean install - though I would also like to retain my current database's tables of Previously Recorded, Custom Recordings etc.

I don't mind doing incremental upgrades if that's the most straightforward way and hopefully avoid messing around with manually editing the database, which I'm not confident with.

Advice please?

Author:  graysky [ Sun Jun 07, 2015 3:56 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

That is pretty old if I'm not mistaken... dunno if it's supported to update. Let someone with more knowledge answer.

Author:  Ralph [ Sun Jun 07, 2015 5:07 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

graysky wrote:
That is pretty old if I'm not mistaken... dunno if it's supported to update. Let someone with more knowledge answer.

It sure is! It's Debian-based and doesn't recognise SATA drives. The kernel is
There is an upgrade guide here but it presupposes you're starting from R5.5 - so I suspect that I first may need to upgrade to that version of KM before I can go any further?

Author:  mattbatt [ Sun Jun 07, 2015 8:41 pm ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

this is a qusetion that Cecil or Britney might have to answer Jeez. To simplify I'd say the things you need to move to LinHES 8.3 are your database and the recordings. so just trying to do a partial upgrade to the database might be your best bet instead of trying to move your whole install forward. BUT I am not qualified to answer this question.
This might help. ... _KnoppMyth
If you do have to do a stair stepped upgrade using multiple ISO files may I suggest that you do it in a virtual machine. You could install each version of KnoppMyth and LinHES as separate VMs first then back up and restore each version maybe? I know there were minor upgrades to MythTV and some Major upgrades.
How in the heck is this install still running?

Author:  Ralph [ Sun Jun 07, 2015 9:03 pm ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

Thanks Mattbatt, yes I've seen that upgrade guide but it presupposes you're starting from R5.5, and R5A30.2 is several big steps prior to that version.

I don't mind the stair-stepped method as you suggest, but it would need to be done on the old box (or an old box) rather than a VM, as those older versions won't even install on hardware with SATA drives. But that's not a problem, since my old box is working fine (for the moment) even though the hardware is ageing - and apart from the ever-increasing potential for hardware failure there's no reason why it shouldn't be, as KM is very stable. And of course it's mainly for the ageing hardware reason that I wanted to do this upgrade, 1) get LinHES running on the old hardware, then 2) move the installation to new hardware when I get the chance to build it.

But following your suggestion and after some similar discussion with others, it seems that it may be a better approach to do it the other way around, ie. 1) build a new box and install the latest version, then 2) upgrade the database using this as a guide?

Question: if I proceed that way, will LinHES be able to recognise and play all my existing .nuv files from R5A?

Author:  mattbatt [ Mon Jun 08, 2015 10:55 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

I believe in most VMs you can specify that the virtual "drives" are IDE, SATA, or even SCSI. here is how to do it in Virtualbox.

The best part of using a vm to test upgrading is that it doesn't take your main machine offline and can be done with any computer or OS as the vm host.

I believe you can still play nuv files. I don't have any to test with. There is a way to convert them.

You have avoided the pain of upgrading for so long and now I don't see an easy way to do this its going to be a long painful process.

Author:  mattbatt [ Mon Jun 08, 2015 7:00 pm ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

I was incorrect I do have some nuv recordings and they do still work just fine.

Author:  Ralph [ Mon Jun 08, 2015 11:56 pm ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

mattbatt wrote:
I believe in most VMs you can specify that the virtual "drives" are IDE, SATA, or even SCSI. here is how to do it in Virtualbox.

That is indeed interesting - I didn't realise one could specify that - I shall investigate!
Thanks also for confirming about LinHES being able to recognise the .nuv files that were recorded 'way back when' - that's good news.

Author:  mattbatt [ Tue Jun 09, 2015 4:36 pm ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

yeah I forgot that I still had some kids videos recorded on my pvr150 from back when I still had cable.

Author:  Ralph [ Mon Jun 29, 2015 1:35 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

Summary: my database won't upgrade successfully

The Details:
OK so I have been having 'fun' with the VMs, testing out upgrades and new installs of various versions. Just for the moment, I have been attempting the stepped upgrade method, so initially this is simply an attempt to upgrade from KnoppMyth R5A30.2 to the subsequent R5B7, rather than to any LinHES version.

I've followed (Some Hints for upgrading to R5B7) specifically about removing the ivtv entry in /etc/modules but this didn't help - my current modules doesn't contain an ivtv entry anyway.

I believe I have narrowed down my issue to my current working mythconverg. There must be something odd about it because:

1) If I install a brand NEW R5A30.2, its original database will upgrade/restore successfully into the next version, R5B7. (This at least proves that I've got the basics right!)

2) But - although my current WORKING database works just fine in R5A30.2 (both on my live box and in the VM) it will NOT upgrade/restore successfully into R5B7 (or into subsequent versions) even after running myisamchk -r (though no errors were found before or afterwards)

This is what happens every time, either following an upgrade install, or a new install followed by mythrestore: neither the R5B7 frontend or backend start. I'm stuck at the KnoppMyth splash screen. I can get into mythtv-setup from there using Alt+S, but it won't let me add a capture card.

THEN... after experimentation, here's what I found...

If I replace the settings table in my 'upgraded' mythconverg with an original table from a basic working R5B7 installation, I can then start the backend and frontend. But in mythtv-setup I still can't add a capture card.

Then... if I replace the capturecard table in the same way, voila, I can add a capture card too!

But with this mishmash of new and improperly-upgraded tables, R5B7 still won't work right, specifically:
* In 'Watch Recordings' I can see the Playback Groups (something R5A didn't have) containing all my existing recordings, but selecting any group returns 'Sorry, No Recordings Available'
* Can't schedule any recordings - they do get added to the record table in the database, but nothing shows up in 'Upcoming Recordings' list
* Can't add any new Playback Groups
* Can't watch live TV

The following points may or may not be relevant, but I also noticed:

During some mythrestore operations (not all, but a significant number) they stall because hda1 fills up, which I think is due to the excessive size of /var/log/mysql/mysql.log which can get up around 2GB, no doubt because there are some huge tables. I have to cancel the restore, delete the log and do the mythrestore again.

In the R5A30.2 settings table, DBSchemaVer is 1083
In the R5B7 settings table, DBSchemaVer is 1123
But in my poorly-upgraded settings table (the one that won't allow R5B7 to start) it's 1084 - I wonder if that's even a valid schema version.

My conclusion (which may of course be wrong!) is there must be something strange about my database that the upgrade script doesn't like. But where to from here - eg. other than myisamchk, is there another way to find out where the issue lies?

Author:  bgrant3406 [ Mon Jun 29, 2015 6:41 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

Have you reached out to Britney to see if any upgrade guide/notes exist for those old versions? They may have been flushed, but you never know.

An alternate thought (and a ton of work) might be to see if there is another version, like mythbuntu, that you could use to migrate your DB to, get the DB up to a version that LH can work with and migrate back to LH and continue the upgrade path with LH. Like I said, a ton of work, but maybe a way forward if no upgrade guides/notes exist.

Another thought, depending on your MySQL skills would be to identify the tables you really want/need, review the MYTHTV DB table changes and see if there is a way to convert those tables manually. It's pretty easy to export the tables and import them into fresh DB, I had to do something similar when I migrated over from Mythdora, granted I didn't have to manually modify tables. Also I was in the 0.24 range, so I was able to let LH do a lot of the heavy lifting. Take a look. There may be an idea that you can use, the list of table I exported may help you narrow the focus if you choose that path.

Author:  Ralph [ Mon Jun 29, 2015 8:04 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

Thanks, no I haven't reached out yet other than this post, but I'm fairly sure that other than the link for 'Some Hints for upgrading to R5B7' there is no specific guide as such.

Your second suggestion does sound like a ton of work as you say, but your third suggestion may indeed end up being what I have to do - thanks for the link - and is in fact something I had to do >10 years ago when I converted my original mandrake-based MythTV box to run KM instead. I ended up converting table schemas manually using Windows Notepad... anyway it was very time consuming but eventually I got it to work. I'd really like to avoid having to do that all over again though.

I just had another thought - what do you think of this idea:
1) Do a new install of R5A on one VM
2) Do a new install of R5B on another VM
3) Replace half the tables in the R5A database with those from my working mythconverg
4) Ensure it still boots up and runs (important!)
5) Assuming it does, make a backup
6) Restore that backup into R5B
7) Does R5B still work afterwards?
* If No, we can assume that one of the tables I just replaced is the culprit - narrow the replaced tables down by half by restoring some of the original R5B tables, and repeat from step 6) till it fails
* If Yes, we are yet to find the bad table - repeat from step 3) but this time using the remaining half of the tables

If a bad table is found, it could be inspected more closely to try to understand what its issue is.
With this method things could end up getting very tricky though if there is more than one table at fault.

Author:  bgrant3406 [ Mon Jun 29, 2015 9:34 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

Good idea, the main change I would make in your plan is to identify which tables actually have info in them, the others I would ignore. Build your 50/50 list from those with data, focusing on the important tables first (record, recorded, oldrecorded, oldprogram, recordedprogram, recordedrating etc.). Other than commercial detection and seek tables, this is all that I migrated from Mythdora over to LH. I rebuilt all of my Mythsetup items using LH and then merged these tables into the LH DataBase and continued the upgrade from there. The Mythtv page is a great source for what the table does:

Another way to force rank the first batch of tables is to think about which tables the upgraded system can rebuild for you. For example, my seek tables got screwed up somewhere in the migration, so I had to create a job to rebuild them. Somewhat of a PITA and pretty processor intensive to rebuild the ~350 recordings I had, but you can add the recordings to a playlist and then run the job against the playlist. Looks like recordedmarkup could be rebuilt via commercial detection. That could minimize the first batch of tables to try. In that vein, the following upgrades getting you to R8 have less data to potentially go wrong with. Once you've upgraded and created a backup to use for the next level of upgrade, you can try to rebuild any tables along the way to verify that it worked in a certain version. I would wait until I get all the way to R8 latest to do all of the rebuilding, but I think you get the gist of what I'm suggesting.

So much of this is really related to how you use your system (features) and what is most critical to get across to the upgraded system and what can you rebuild.

The huge plus is that once you get up to R8 the upgrades are generally mindlessly simple, hit the upgrade menu, do the upgrade, reboot, done.

Author:  Ralph [ Tue Jun 30, 2015 4:03 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

OK so I should start with the biggest 50% of the tables first.

One important question: obviously when one does an 'upgrade installation' the installation process upgrades the backed-up database's schema. But does a regular mythrestore do that as well? If not, then this method won't work at all.

Also I think where this method might fall down is if there is more than one bad table - on a failed run, I could easily end up swapping one bad table out, while keeping another bad table in for the next test run... and I already know from my previous experimentation that there is something about the upgrade process wrt both the settings table and the capturecard table that stops R5B7 from starting.

So maybe in the first instance I should run with that knowledge, and try to do a manual schema upgrade of those two tables?

Author:  bgrant3406 [ Tue Jun 30, 2015 8:54 am ]
Post subject:  Re: Upgrade path R5A30.2 to LinHES

Rather than trying to migrate the two known bad files, would it be easier to re-enter the data?

Basically take the newer version of Knoppmyth and go through the mythtv setup to redefine your capture cards and redo the settings (save a "gold" backup of the empty database with the new settings/capture card info). Once you have that, then import the other tables into the DB and test. If you find that something is messed up, revert to the "gold" backup and re-import what ever tables you see fit. One word of caution, the channel id info is based off of Videosource and other info, if this get's out of whack, your migrated recorded programs will not show the channel info, just a 4 digit number string, doesn't seem to affect anything and new recordings will show the correct info going forward.

On the database upgrade, I think (at least on the newer versions) when you go into myth setup (or when you exit, I can't recall) the DB is updated to the latest schema for that version. Thats seems to be one of the reasons it's a linear upgrade path, so that the changes to the schema are made with each upgrade step.

If I were going through what you are, I would probably do the following:
I would rebuild a VM with the next version of Knoppmyth, I would use myth setup to create a working system and migrate only the minimum number of tables I need (as outlined in the previous response). One benefit will be, for the tables not migrated, any trash that may have crept in over the years will be gone. Once I've verified that the system works, I would then continue my upgrades to the next version and so on until I've reached the latest version. I would intentionally be abandoning the old tables (other than the ones I require), biggest benefit to me would be that those tables should have no corruption and should not impact a future upgrade.

Honestly, I think you are going to be fighting a lot harder to migrate All of the old tables, rather than the minimum you really need. With the VM's you are running, you can jump back and forth between instances to review and modify settings. May be a little tedious, but at least you will be moving forward rather than dealing with the frustration of the DB issues of known (and yet to find) bad tables.

Page 1 of 2 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group