Mailing List Archive

On Thu, 21 Jul 2016 18:35:02 +1200, you wrote:

>> On 21/07/2016, at 5:37 PM, Robert Fisher <robert@fisher.net.nz> wrote:
>>
>> No I do not think that is what I need.
>> The old recordings are still in the location where the new ones are going.
>> MythTV and MythWeb only show the new recordings so I was wondering if there is a way for MythTV to recognise the old ones.
>>
>
>That will identify the files that are not in your recordings list. Useful as part of the cleanup.
>
>I believe the recommended process is to add these orphaned files to MythVideo. You won’t have any metadata or the ability to delete them once watched, but you will be able to watch them.
>
>You could restore the database from one of the backups? I know I have mysql backups of mythconverg in one of my recordings storage groups, so maybe you do too and they survived your upgrade.
>
> - Wade

If you still have a backup database with all the old recordings in it,
it is possible to get that data exported to the new system. What you
have to do is install a virtual machine somewhere that is running the
same MythTV version as the old backup database. Then you restore the
old database on that virtual machine, and upgrade the version of
MythTV to match the version on your real MythTV system. Then you
install mythexport and use its On The Go web page to mark all the old
recordings in the database that you still have the files for to be
exported. When it starts an export job, mythexport first stores a
.sql file to the export directory that contains all the data for the
recordings being exported. Then it copies all the recording files to
that directory. But I believe that if the recording files do not
exist (as they will not on the virtual machine), it will still create
the .sql file correctly. So once it has done that, copy the .sql file
to the real MythTV system, and install the mythimport package there,
and then run mythimport on it. All the data in the .sql file will be
imported into your database, and will then automatically match up with
the old recording files.

If your old database does not quite match all the old recording files
you have, you can still do this process, and then manually deal with
the mismatched files. There will be some files still without matching
database entries - find_orphans.py will tell you what the files are.
Those files will need to be moved to a videos directory. Then you
have to manually play each file, and rename it to whatever programme
it contains. For database entries that have no matching file,
find_orphans.py will automatically delete the database entries for you
if you tell it to.

When doing such a large mythimport run, it is possible to have a
problem with the import process, so it can stop in the middle with an
error such as one recording that is in the old database is somehow
matching one already in the new database. If that happens, you can go
back to mythexport and not mark that recording to be exported and try
again. But for that to work, you need all the recordings in the new
database that have already been imported by mythimport to be removed.
The only safe way I know of to do that is to backup the new database
before starting the mythimport run, and doing the mythimport run at a
time when there will be no recordings on the box for long enough for
mythimport to complete successfully, or for it to fail and then for
you to restore the backup database before the next recording.

Having backed up and restored databases many times, I can tell you
that if you follow the instructions, that process is very reliable so
there is no worry about having to do it should there be a problem with
importing the old database. I have also used mythexport and
mythimport extensively, but only so far on MythTV up to 0.27 - I have
not tried it on 0.28 yet.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

> If you still have a backup database with all the old recordings in it,
> it is possible to get that data exported to the new system. What you
> have to do is install a virtual machine somewhere that is running the
> same MythTV version as the old backup database. Then you restore the
> old database on that virtual machine, and upgrade the version of
> MythTV to match the version on your real MythTV system. Then you
> install mythexport and use its On The Go web page to mark all the old
> recordings in the database that you still have the files for to be
> exported. When it starts an export job, mythexport first stores a
> .sql file to the export directory that contains all the data for the
> recordings being exported. Then it copies all the recording files to
> that directory. But I believe that if the recording files do not
> exist (as they will not on the virtual machine), it will still create
> the .sql file correctly. So once it has done that, copy the .sql file
> to the real MythTV system, and install the mythimport package there,
> and then run mythimport on it. All the data in the .sql file will be
> imported into your database, and will then automatically match up with
> the old recording files.
>
> If your old database does not quite match all the old recording files
> you have, you can still do this process, and then manually deal with
> the mismatched files. There will be some files still without matching
> database entries - find_orphans.py will tell you what the files are.
> Those files will need to be moved to a videos directory. Then you
> have to manually play each file, and rename it to whatever programme
> it contains. For database entries that have no matching file,
> find_orphans.py will automatically delete the database entries for you
> if you tell it to.
>
> When doing such a large mythimport run, it is possible to have a
> problem with the import process, so it can stop in the middle with an
> error such as one recording that is in the old database is somehow
> matching one already in the new database. If that happens, you can go
> back to mythexport and not mark that recording to be exported and try
> again. But for that to work, you need all the recordings in the new
> database that have already been imported by mythimport to be removed.
> The only safe way I know of to do that is to backup the new database
> before starting the mythimport run, and doing the mythimport run at a
> time when there will be no recordings on the box for long enough for
> mythimport to complete successfully, or for it to fail and then for
> you to restore the backup database before the next recording.
>
> Having backed up and restored databases many times, I can tell you
> that if you follow the instructions, that process is very reliable so
> there is no worry about having to do it should there be a problem with
> importing the old database. I have also used mythexport and
> mythimport extensively, but only so far on MythTV up to 0.27 - I have
> not tried it on 0.28 yet.
>
I have a quick question: are database backups from 0.27 compatible with
0.28?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Fri, 22 Jul 2016 08:21:02 +1200, you wrote:

>
>> If you still have a backup database with all the old recordings in it,
>> it is possible to get that data exported to the new system. What you
>> have to do is install a virtual machine somewhere that is running the
>> same MythTV version as the old backup database. Then you restore the
>> old database on that virtual machine, and upgrade the version of
>> MythTV to match the version on your real MythTV system. Then you
>> install mythexport and use its On The Go web page to mark all the old
>> recordings in the database that you still have the files for to be
>> exported. When it starts an export job, mythexport first stores a
>> .sql file to the export directory that contains all the data for the
>> recordings being exported. Then it copies all the recording files to
>> that directory. But I believe that if the recording files do not
>> exist (as they will not on the virtual machine), it will still create
>> the .sql file correctly. So once it has done that, copy the .sql file
>> to the real MythTV system, and install the mythimport package there,
>> and then run mythimport on it. All the data in the .sql file will be
>> imported into your database, and will then automatically match up with
>> the old recording files.
>>
>> If your old database does not quite match all the old recording files
>> you have, you can still do this process, and then manually deal with
>> the mismatched files. There will be some files still without matching
>> database entries - find_orphans.py will tell you what the files are.
>> Those files will need to be moved to a videos directory. Then you
>> have to manually play each file, and rename it to whatever programme
>> it contains. For database entries that have no matching file,
>> find_orphans.py will automatically delete the database entries for you
>> if you tell it to.
>>
>> When doing such a large mythimport run, it is possible to have a
>> problem with the import process, so it can stop in the middle with an
>> error such as one recording that is in the old database is somehow
>> matching one already in the new database. If that happens, you can go
>> back to mythexport and not mark that recording to be exported and try
>> again. But for that to work, you need all the recordings in the new
>> database that have already been imported by mythimport to be removed.
>> The only safe way I know of to do that is to backup the new database
>> before starting the mythimport run, and doing the mythimport run at a
>> time when there will be no recordings on the box for long enough for
>> mythimport to complete successfully, or for it to fail and then for
>> you to restore the backup database before the next recording.
>>
>> Having backed up and restored databases many times, I can tell you
>> that if you follow the instructions, that process is very reliable so
>> there is no worry about having to do it should there be a problem with
>> importing the old database. I have also used mythexport and
>> mythimport extensively, but only so far on MythTV up to 0.27 - I have
>> not tried it on 0.28 yet.
>>
>I have a quick question: are database backups from 0.27 compatible with
>0.28?

That depends on what you mean by compatible. There are quite
significant changes in the database schema between 0.27 and 0.28, such
as the addition of a recordedid field as the primary index for the
recorded table. So the individual tables and rows from tables where
there are changes like that are incompatible. Hence the output of
mythexport from 0.27 will not work with mythimport in 0.28. But if
you do a full restore of a 0.27 database into a 0.28 system, that will
be detected when mythtv-setup or mythbackend is run, and the 0.27
database will be automatically upgraded to a 0.28 one.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

>> I have a quick question: are database backups from 0.27 compatible with
>> 0.28?
>
> That depends on what you mean by compatible. There are quite
> significant changes in the database schema between 0.27 and 0.28, such
> as the addition of a recordedid field as the primary index for the
> recorded table. So the individual tables and rows from tables where
> there are changes like that are incompatible. Hence the output of
> mythexport from 0.27 will not work with mythimport in 0.28. But if
> you do a full restore of a 0.27 database into a 0.28 system, that will
> be detected when mythtv-setup or mythbackend is run, and the 0.27
> database will be automatically upgraded to a 0.28 one.
>
> _______________________________________________

Would the correct procedure for a newly installed Mythbuntu 16.04 be to do
a full DB restore before or after manually setting up the various settings
on Myth backend and myth frontend?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Fri, 22 Jul 2016 15:59:21 +1200, you wrote:

>
>
>>> I have a quick question: are database backups from 0.27 compatible with
>>> 0.28?
>>
>> That depends on what you mean by compatible. There are quite
>> significant changes in the database schema between 0.27 and 0.28, such
>> as the addition of a recordedid field as the primary index for the
>> recorded table. So the individual tables and rows from tables where
>> there are changes like that are incompatible. Hence the output of
>> mythexport from 0.27 will not work with mythimport in 0.28. But if
>> you do a full restore of a 0.27 database into a 0.28 system, that will
>> be detected when mythtv-setup or mythbackend is run, and the 0.27
>> database will be automatically upgraded to a 0.28 one.
>>
>> _______________________________________________
>
>Would the correct procedure for a newly installed Mythbuntu 16.04 be to do
>a full DB restore before or after manually setting up the various settings
>on Myth backend and myth frontend?

Restore the database before you adjust any settings that are stored in
the database, as restoring the database will overwrite anything you
already have in the existing database on the new system with what is
in the restored database. A restore of the database is a complete
restore - it literally deletes the existing database and installs a
full database from the backup copy. If the backup copy says it is an
older database schema, the first program to read the database and
discover that will automatically update it to the current schema.
However, mythfrontend can not do that - only mythtv-setup and
mythbackend can. So the best option after restoring a database with
an older schema is to run mythtv-setup as it has more control about
schema updates - it asks if it is to go ahead and do it. Running
mythbackend works, but just does the update automatically without
telling you about it. And if your database is large (like mine), do
not worry if the first run of mythtv-setup or mythbackend takes ages
before it is ready, because it will be taking that time doing the
schema update. You can keep track of what is happening by doing a
"tail -f" command on the relevant log file in /var/log/mythtv
(mythtv-setup.log or mythbackend.log).

If necessary, you may need to set up the settings outside the database
before doing a restore of an older database, such as the mysql
settings to allow access outside the PC and the config.xml file(s).
This is especially necessary if you are using a backend that does not
also have a frontend on it to allow you access.

And the users and permissions for access to the mythcoverg database
are not stored in the mythconverg database - they are stored in the
mysql database, so they do not get backed up and restored. So you may
need to set them up also to allow access from other than the local PC.
The MythTV manual has how to do that:

https://www.mythtv.org/wiki/Build_from_Source

See the "MythTV Database Setup" section.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

>
> Restore the database before you adjust any settings that are stored in
> the database, as restoring the database will overwrite anything you
> already have in the existing database on the new system with what is
> in the restored database. A restore of the database is a complete
> restore - it literally deletes the existing database and installs a
> full database from the backup copy. If the backup copy says it is an
> older database schema, the first program to read the database and
> discover that will automatically update it to the current schema.
> However, mythfrontend can not do that - only mythtv-setup and
> mythbackend can. So the best option after restoring a database with
> an older schema is to run mythtv-setup as it has more control about
> schema updates - it asks if it is to go ahead and do it. Running
> mythbackend works, but just does the update automatically without
> telling you about it. And if your database is large (like mine), do
> not worry if the first run of mythtv-setup or mythbackend takes ages
> before it is ready, because it will be taking that time doing the
> schema update. You can keep track of what is happening by doing a
> "tail -f" command on the relevant log file in /var/log/mythtv
> (mythtv-setup.log or mythbackend.log).
>
> If necessary, you may need to set up the settings outside the database
> before doing a restore of an older database, such as the mysql
> settings to allow access outside the PC and the config.xml file(s).
> This is especially necessary if you are using a backend that does not
> also have a frontend on it to allow you access.
>
> And the users and permissions for access to the mythcoverg database
> are not stored in the mythconverg database - they are stored in the
> mysql database, so they do not get backed up and restored. So you may
> need to set them up also to allow access from other than the local PC.
> The MythTV manual has how to do that:
>
> https://www.mythtv.org/wiki/Build_from_Source
>
> See the "MythTV Database Setup" section.
>

The mythtv-setup you refer to is the utlity in the menus:
System->Administration->MythTV Backend Setup correct?
Not a script?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Sat, 23 Jul 2016 07:47:21 +1200, you wrote:

>
>>
>> Restore the database before you adjust any settings that are stored in
>> the database, as restoring the database will overwrite anything you
>> already have in the existing database on the new system with what is
>> in the restored database. A restore of the database is a complete
>> restore - it literally deletes the existing database and installs a
>> full database from the backup copy. If the backup copy says it is an
>> older database schema, the first program to read the database and
>> discover that will automatically update it to the current schema.
>> However, mythfrontend can not do that - only mythtv-setup and
>> mythbackend can. So the best option after restoring a database with
>> an older schema is to run mythtv-setup as it has more control about
>> schema updates - it asks if it is to go ahead and do it. Running
>> mythbackend works, but just does the update automatically without
>> telling you about it. And if your database is large (like mine), do
>> not worry if the first run of mythtv-setup or mythbackend takes ages
>> before it is ready, because it will be taking that time doing the
>> schema update. You can keep track of what is happening by doing a
>> "tail -f" command on the relevant log file in /var/log/mythtv
>> (mythtv-setup.log or mythbackend.log).
>>
>> If necessary, you may need to set up the settings outside the database
>> before doing a restore of an older database, such as the mysql
>> settings to allow access outside the PC and the config.xml file(s).
>> This is especially necessary if you are using a backend that does not
>> also have a frontend on it to allow you access.
>>
>> And the users and permissions for access to the mythcoverg database
>> are not stored in the mythconverg database - they are stored in the
>> mysql database, so they do not get backed up and restored. So you may
>> need to set them up also to allow access from other than the local PC.
>> The MythTV manual has how to do that:
>>
>> https://www.mythtv.org/wiki/Build_from_Source
>>
>> See the "MythTV Database Setup" section.
>>
>
>The mythtv-setup you refer to is the utlity in the menus:
>System->Administration->MythTV Backend Setup correct?
>Not a script?

Yes and no. On Mythbuntu, mythtv-setup is a script
(/usr/bin/mythtv-setup) that is run from that menu entry. The script
calls the real mythtv-setup program which has the filename
/usr/bin/mythtv-setup.real. The script shuts down mytbackend before
running mythtv-setup.real, and restarts it afterwards. It also checks
to see if mythtv-setup is being run from an appropriate user account
(one in the mythtv group). If you just want to use the channel editor
in mythtv-setup, then you do not actually need to shut down
mythbackend, so quite a few people run mythtv-setup.real from the
mythtv user (not root) command line in order to do that.

So when someone says "mythtv-setup", they may mean the real
mythtv-setup program (which is all that exists on some distros). But
since the script runs the program, it does not matter most of the
time. The usual intention is that you run the program mythtv-setup,
however that is done on your distro.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

> Yes and no. On Mythbuntu, mythtv-setup is a script
> (/usr/bin/mythtv-setup) that is run from that menu entry. The script
> calls the real mythtv-setup program which has the filename
> /usr/bin/mythtv-setup.real. The script shuts down mytbackend before
> running mythtv-setup.real, and restarts it afterwards. It also checks
> to see if mythtv-setup is being run from an appropriate user account
> (one in the mythtv group). If you just want to use the channel editor
> in mythtv-setup, then you do not actually need to shut down
> mythbackend, so quite a few people run mythtv-setup.real from the
> mythtv user (not root) command line in order to do that.
>
> So when someone says "mythtv-setup", they may mean the real
> mythtv-setup program (which is all that exists on some distros). But
> since the script runs the program, it does not matter most of the
> time. The usual intention is that you run the program mythtv-setup,
> however that is done on your distro.
>

I'm trying to do a database restore for this new install but I've run into
a bit of a problem.I can't seem to run mythconverg_restore.pl.
I've tried "mythconverg_restore.pl" "sudo mythconverg_restore.pl" and both
from the directory the file is in and from the home directory.
On my 12.04 installation I have the same problem but Thunar has an execute
option in the right click menu.In 16.04 Thunar does not have this option.I
would prefer to run this from the terminal if I could.

So what am I missing here?

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Thu, 28 Jul 2016 12:15:54 +1200, Paulgir <paulgir@gmail.com> wrote:

>
>
>> Yes and no. On Mythbuntu, mythtv-setup is a script
>> (/usr/bin/mythtv-setup) that is run from that menu entry. The script
>> calls the real mythtv-setup program which has the filename
>> /usr/bin/mythtv-setup.real. The script shuts down mytbackend before
>> running mythtv-setup.real, and restarts it afterwards. It also checks
>> to see if mythtv-setup is being run from an appropriate user account
>> (one in the mythtv group). If you just want to use the channel editor
>> in mythtv-setup, then you do not actually need to shut down
>> mythbackend, so quite a few people run mythtv-setup.real from the
>> mythtv user (not root) command line in order to do that.
>>
>> So when someone says "mythtv-setup", they may mean the real
>> mythtv-setup program (which is all that exists on some distros). But
>> since the script runs the program, it does not matter most of the
>> time. The usual intention is that you run the program mythtv-setup,
>> however that is done on your distro.
>>
>
> I'm trying to do a database restore for this new install but I've run
> into a bit of a problem.I can't seem to run mythconverg_restore.pl.
> I've tried "mythconverg_restore.pl" "sudo mythconverg_restore.pl" and
> both from the directory the file is in and from the home directory.
> On my 12.04 installation I have the same problem but Thunar has an
> execute option in the right click menu.In 16.04 Thunar does not have
> this option.I would prefer to run this from the terminal if I could.
>
> So what am I missing here?

PS the massage I get is "command not found"

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

On Thu, 28 Jul 2016 12:19:14 +1200, Paulgir <paulgir@gmail.com> wrote:

> On Thu, 28 Jul 2016 12:15:54 +1200, Paulgir <paulgir@gmail.com> wrote:
>
>>
>>
>>> Yes and no. On Mythbuntu, mythtv-setup is a script
>>> (/usr/bin/mythtv-setup) that is run from that menu entry. The script
>>> calls the real mythtv-setup program which has the filename
>>> /usr/bin/mythtv-setup.real. The script shuts down mytbackend before
>>> running mythtv-setup.real, and restarts it afterwards. It also checks
>>> to see if mythtv-setup is being run from an appropriate user account
>>> (one in the mythtv group). If you just want to use the channel editor
>>> in mythtv-setup, then you do not actually need to shut down
>>> mythbackend, so quite a few people run mythtv-setup.real from the
>>> mythtv user (not root) command line in order to do that.
>>>
>>> So when someone says "mythtv-setup", they may mean the real
>>> mythtv-setup program (which is all that exists on some distros). But
>>> since the script runs the program, it does not matter most of the
>>> time. The usual intention is that you run the program mythtv-setup,
>>> however that is done on your distro.
>>>
>>
>> I'm trying to do a database restore for this new install but I've run
>> into a bit of a problem.I can't seem to run mythconverg_restore.pl.
>> I've tried "mythconverg_restore.pl" "sudo mythconverg_restore.pl" and
>> both from the directory the file is in and from the home directory.
>> On my 12.04 installation I have the same problem but Thunar has an
>> execute option in the right click menu.In 16.04 Thunar does not have
>> this option.I would prefer to run this from the terminal if I could.
>>
>> So what am I missing here?
>
> PS the massage I get is "command not found"
Ok. I've found the correct command /usr/share/mythtv$
./mythconverg_restore.pl

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.linuxnut.co.nz
http://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/