Mailing List Archive

I had problems with the ubuntu vanilla flavor of 16.04. Keeping on 15.10
until it gets ironed out. Mainly to do with driver support and init.
Otherwise than that I managed to got it working and it was a lot faster but
felt buggy.will make the move on 16.10 I think...

On 18/07/2016 13:08, "Paulgir" <paulgir@gmail.com> wrote:

> Hi All
>
> Those who have already updated to Mythbuntu 16.04,how is it going?I noted
> that people where experiencing problems,initially.
> I'm thinking of upgrading when 16.04.1 comes out shortly.
>
> -Paul
>
> _______________________________________________
> 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 Mon, 18 Jul 2016 13:07:59 +1200, you wrote:

>Hi All
>
>Those who have already updated to Mythbuntu 16.04,how is it going?I noted
>that people where experiencing problems,initially.
>I'm thinking of upgrading when 16.04.1 comes out shortly.
>
>-Paul

If you have not already upgraded to MythTV 0.28, it would be sensible
to do that first on your current system, if possible. Then do the OS
upgrade separately.

One problem I have found with my testing of 16.04 so far is that the
new version of mysql is using the editline library (from FreeBSD?)
instead of the readline library in its utility programs. Since I use
the SQL command line quite a bit, that is a serious problem for me as
editline does not do the right sort of things for bringing back
commands out of my command history for me to re-use. So on my test
box, I replaced mysql with MariaDB, which still uses readline and is
going to keep doing so.

Apparently Oracle have a problem with the GPL (or is it LGPL) license
and are trying to remove all such software from mysql, so they will
not be going back to readline, despite the bug reports filed about
this problem. So it is unlikely I will ever be using mysql again as
this problem is a deal breaker for me.

Fortunately, MariaDB seems to work just fine as a replacement for
mysql. It is now the default database in Fedora anyway, and no one
seems to be complaining about problems. Swapping to it was far from
easy though, as the process results in uninstalling of the MythTV
packages before the change can happen. And the mythexport package
seems to be built with the wrong dependency, as it requires the real
mysql packages and wants to uninstall MariaDB and reinstall mysql if
you try to install it. I need to file a bug report with the Mythbuntu
maintainers about that.

So if you want to switch to MariaDB also, make sure you have a good
backup of your MythTV database.

I am still debating with myself about whether I will be upgrading in
place from 14.04 to 16.04.1 when it comes out, or whether I will move
my database over to a new 16.04.1 install. I have done both types of
upgrade in the past, and there are problems and benefits for both
paths. At least I now have an ultra-fast SSD drive to boot from, so
the upgrade process will be able to be done in the available time
between recordings - my MythTV box is pretty busy most days, but there
is usually one or two days a week with a gap of 8 hours or so between
recordings. Without the SSD, I am not sure if 8 hours would be enough
to safely do a full upgrade.

_______________________________________________
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 Tue, 19 Jul 2016 04:31:49 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:


>
> If you have not already upgraded to MythTV 0.28, it would be sensible
> to do that first on your current system, if possible. Then do the OS
> upgrade separately.
>
> One problem I have found with my testing of 16.04 so far is that the
> new version of mysql is using the editline library (from FreeBSD?)
> instead of the readline library in its utility programs. Since I use
> the SQL command line quite a bit, that is a serious problem for me as
> editline does not do the right sort of things for bringing back
> commands out of my command history for me to re-use. So on my test
> box, I replaced mysql with MariaDB, which still uses readline and is
> going to keep doing so.
>
> Apparently Oracle have a problem with the GPL (or is it LGPL) license
> and are trying to remove all such software from mysql, so they will
> not be going back to readline, despite the bug reports filed about
> this problem. So it is unlikely I will ever be using mysql again as
> this problem is a deal breaker for me.
>
> Fortunately, MariaDB seems to work just fine as a replacement for
> mysql. It is now the default database in Fedora anyway, and no one
> seems to be complaining about problems. Swapping to it was far from
> easy though, as the process results in uninstalling of the MythTV
> packages before the change can happen. And the mythexport package
> seems to be built with the wrong dependency, as it requires the real
> mysql packages and wants to uninstall MariaDB and reinstall mysql if
> you try to install it. I need to file a bug report with the Mythbuntu
> maintainers about that.
>
> So if you want to switch to MariaDB also, make sure you have a good
> backup of your MythTV database.
>
> I am still debating with myself about whether I will be upgrading in
> place from 14.04 to 16.04.1 when it comes out, or whether I will move
> my database over to a new 16.04.1 install. I have done both types of
> upgrade in the past, and there are problems and benefits for both
> paths. At least I now have an ultra-fast SSD drive to boot from, so
> the upgrade process will be able to be done in the available time
> between recordings - my MythTV box is pretty busy most days, but there
> is usually one or two days a week with a gap of 8 hours or so between
> recordings. Without the SSD, I am not sure if 8 hours would be enough
> to safely do a full upgrade.
>

Thanks for the detailed reply.I don't use the SQL command line due to fear
and ignorance.You don't mention any other problems so I take it that it
has no other major problems?
I'm still on 12.04 and,correct me if I'm wrong,there is no upgrade path
from that.I intend to install the new system on an SSD but keep 12.04 on
it's original drive until I'm happy that everything is running.

_______________________________________________
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 Tue, 19 Jul 2016 08:15:00 +1200, you wrote:

>On Tue, 19 Jul 2016 04:31:49 +1200, Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>
>
>>
>> If you have not already upgraded to MythTV 0.28, it would be sensible
>> to do that first on your current system, if possible. Then do the OS
>> upgrade separately.
>>
>> One problem I have found with my testing of 16.04 so far is that the
>> new version of mysql is using the editline library (from FreeBSD?)
>> instead of the readline library in its utility programs. Since I use
>> the SQL command line quite a bit, that is a serious problem for me as
>> editline does not do the right sort of things for bringing back
>> commands out of my command history for me to re-use. So on my test
>> box, I replaced mysql with MariaDB, which still uses readline and is
>> going to keep doing so.
>>
>> Apparently Oracle have a problem with the GPL (or is it LGPL) license
>> and are trying to remove all such software from mysql, so they will
>> not be going back to readline, despite the bug reports filed about
>> this problem. So it is unlikely I will ever be using mysql again as
>> this problem is a deal breaker for me.
>>
>> Fortunately, MariaDB seems to work just fine as a replacement for
>> mysql. It is now the default database in Fedora anyway, and no one
>> seems to be complaining about problems. Swapping to it was far from
>> easy though, as the process results in uninstalling of the MythTV
>> packages before the change can happen. And the mythexport package
>> seems to be built with the wrong dependency, as it requires the real
>> mysql packages and wants to uninstall MariaDB and reinstall mysql if
>> you try to install it. I need to file a bug report with the Mythbuntu
>> maintainers about that.
>>
>> So if you want to switch to MariaDB also, make sure you have a good
>> backup of your MythTV database.
>>
>> I am still debating with myself about whether I will be upgrading in
>> place from 14.04 to 16.04.1 when it comes out, or whether I will move
>> my database over to a new 16.04.1 install. I have done both types of
>> upgrade in the past, and there are problems and benefits for both
>> paths. At least I now have an ultra-fast SSD drive to boot from, so
>> the upgrade process will be able to be done in the available time
>> between recordings - my MythTV box is pretty busy most days, but there
>> is usually one or two days a week with a gap of 8 hours or so between
>> recordings. Without the SSD, I am not sure if 8 hours would be enough
>> to safely do a full upgrade.
>>
>
>Thanks for the detailed reply.I don't use the SQL command line due to fear
>and ignorance.You don't mention any other problems so I take it that it
>has no other major problems?
>I'm still on 12.04 and,correct me if I'm wrong,there is no upgrade path
> from that.I intend to install the new system on an SSD but keep 12.04 on
>it's original drive until I'm happy that everything is running.

I have not found anything else that is a problem, so far. I am sure
you can upgrade from 12.04 LTS to 16.04 LTS if you do it in two steps
by upgrading to 14.04 first. With an SSD that might not take too long
to do so it could be worth trying. Running 12.04 from an SSD is
probably not a good thing to try as it does not have full support for
SSDs. If the SSD is a SATA one, it will likely work, but I think
there will not be any fstrim support. If the SSD is NVME (PCIe), it
likely will not have the right drivers. Even with 16.04, the version
of smartmontools is not new enough to support my SSD Samsung 650 Pro
NVME SSD, so I had to manually install a newer version.

With the MythTV upgrading, make sure you read all the release notes
for all the new versions between your current version and 0.28. There
are some manual things you need to do on some upgrades, such as
install the extra timezone support needed for when MythTV converts to
using UTC instead of local time.

Using the SQL command line need not involve fear, as you can easily
use it completely safely for queries without ever doing anything that
changes the database. If you only use the show, desc and select
commands, there is no danger. My most frequent use of SQL commands is
to do searches of the recorded, oldrecorded and program tables to see
if I have previously recorded or watched something. I find that the
EPG here in NZ is so bad at times that MythTV will be re-recording an
entire series of something that has different EPG but I already have a
copy of. An example is New Tricks, where the current series on UKTV
is the same as one I already have, and the descriptions mostly match,
but there are enough differences that mythbackend is re-recording them
all.

_______________________________________________
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 not found anything else that is a problem, so far. I am sure
> you can upgrade from 12.04 LTS to 16.04 LTS if you do it in two steps
> by upgrading to 14.04 first. With an SSD that might not take too long
> to do so it could be worth trying. Running 12.04 from an SSD is
> probably not a good thing to try as it does not have full support for
> SSDs. If the SSD is a SATA one, it will likely work, but I think
> there will not be any fstrim support. If the SSD is NVME (PCIe), it
> likely will not have the right drivers. Even with 16.04, the version
> of smartmontools is not new enough to support my SSD Samsung 650 Pro
> NVME SSD, so I had to manually install a newer version.
>
> With the MythTV upgrading, make sure you read all the release notes
> for all the new versions between your current version and 0.28. There
> are some manual things you need to do on some upgrades, such as
> install the extra timezone support needed for when MythTV converts to
> using UTC instead of local time.
>
> Using the SQL command line need not involve fear, as you can easily
> use it completely safely for queries without ever doing anything that
> changes the database. If you only use the show, desc and select
> commands, there is no danger. My most frequent use of SQL commands is
> to do searches of the recorded, oldrecorded and program tables to see
> if I have previously recorded or watched something. I find that the
> EPG here in NZ is so bad at times that MythTV will be re-recording an
> entire series of something that has different EPG but I already have a
> copy of. An example is New Tricks, where the current series on UKTV
> is the same as one I already have, and the descriptions mostly match,
> but there are enough differences that mythbackend is re-recording them
> all.
>
I'll look at the upgrade process again,but if I recall correctly, the
option was not available when I checked in April.I may be confusing it
with upgrading to 0.28 on 12.04 though.
As it is I prefer to do fresh installs.Especially if I'm installing onto a
new drive.

_______________________________________________
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 Tue, 19 Jul 2016 15:33:24 +1200, you wrote:

>
>>
>> I have not found anything else that is a problem, so far. I am sure
>> you can upgrade from 12.04 LTS to 16.04 LTS if you do it in two steps
>> by upgrading to 14.04 first. With an SSD that might not take too long
>> to do so it could be worth trying. Running 12.04 from an SSD is
>> probably not a good thing to try as it does not have full support for
>> SSDs. If the SSD is a SATA one, it will likely work, but I think
>> there will not be any fstrim support. If the SSD is NVME (PCIe), it
>> likely will not have the right drivers. Even with 16.04, the version
>> of smartmontools is not new enough to support my SSD Samsung 650 Pro
>> NVME SSD, so I had to manually install a newer version.
>>
>> With the MythTV upgrading, make sure you read all the release notes
>> for all the new versions between your current version and 0.28. There
>> are some manual things you need to do on some upgrades, such as
>> install the extra timezone support needed for when MythTV converts to
>> using UTC instead of local time.
>>
>> Using the SQL command line need not involve fear, as you can easily
>> use it completely safely for queries without ever doing anything that
>> changes the database. If you only use the show, desc and select
>> commands, there is no danger. My most frequent use of SQL commands is
>> to do searches of the recorded, oldrecorded and program tables to see
>> if I have previously recorded or watched something. I find that the
>> EPG here in NZ is so bad at times that MythTV will be re-recording an
>> entire series of something that has different EPG but I already have a
>> copy of. An example is New Tricks, where the current series on UKTV
>> is the same as one I already have, and the descriptions mostly match,
>> but there are enough differences that mythbackend is re-recording them
>> all.
>>
>I'll look at the upgrade process again,but if I recall correctly, the
>option was not available when I checked in April.I may be confusing it
>with upgrading to 0.28 on 12.04 though.
>As it is I prefer to do fresh installs.Especially if I'm installing onto a
>new drive.

One thing I have just thought of - if my memory is correct, it was in
the upgrade from 12.04 to 14.04 that the changes to lirc happened,
where the drivers moved into the kernel. So you may find that you
will have lirc problems after upgrading and will need a new lirc
config.

_______________________________________________
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 successfully updated to 0.28 and thought while I was on a roll I would
try updating to 16.04
and now it wont even boot.

I have not got a lot of recordings so I think I might try a new
installation.

I remembered following Mike Brady's guide at:-

http://www.gossamer-threads.com/lists/mythtv/mythtvnz/501872?search_string=tv_grab_nz-py;#501872

But I think I found previously one mistake.

Can someone please check

) Copy*tv_grab_nz-py*to /usr/bin. Make sure that it is executable.

I think that on Mythbuntu it has to be somewhere else?

--
Robert

On Tue, 19 Jul 2016 23:12:53 +1200, you wrote:

>I successfully updated to 0.28 and thought while I was on a roll I would
>try updating to 16.04
>and now it wont even boot.
>
>I have not got a lot of recordings so I think I might try a new
>installation.
>
>I remembered following Mike Brady's guide at:-
>
>http://www.gossamer-threads.com/lists/mythtv/mythtvnz/501872?search_string=tv_grab_nz-py;#501872
>
>But I think I found previously one mistake.
>
>Can someone please check
>
>) Copy*tv_grab_nz-py*to /usr/bin. Make sure that it is executable.
>
>I think that on Mythbuntu it has to be somewhere else?

You would normally put it in /usr/local/bin. The /usr/bin directory
is normally for files installed from packages. The /usr/local
directories are where you put your local customisations. Putting it
in /usr/bin would work though.

_______________________________________________
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 20/07/16 02:22, Stephen Worthington wrote:
> On Tue, 19 Jul 2016 23:12:53 +1200, you wrote:
>
>> I successfully updated to 0.28 and thought while I was on a roll I would
>> try updating to 16.04
>> and now it wont even boot.
>>
>> I have not got a lot of recordings so I think I might try a new
>> installation.
>>
>> I remembered following Mike Brady's guide at:-
>>
>> http://www.gossamer-threads.com/lists/mythtv/mythtvnz/501872?search_string=tv_grab_nz-py;#501872
>>
>> But I think I found previously one mistake.
>>
>> Can someone please check
>>
>> ) Copy*tv_grab_nz-py*to /usr/bin. Make sure that it is executable.
>>
>> I think that on Mythbuntu it has to be somewhere else?
> You would normally put it in /usr/local/bin. The /usr/bin directory
> is normally for files installed from packages. The /usr/local
> directories are where you put your local customisations. Putting it
> in /usr/bin would work though.
>
Thanks, I think that I recall that the problem with putting it in
/usr/bin was that it did not run automatically.


--
Robert


_______________________________________________
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 Wed, 20 Jul 2016 05:48:23 +1200, you wrote:

>On 20/07/16 02:22, Stephen Worthington wrote:
>> On Tue, 19 Jul 2016 23:12:53 +1200, you wrote:
>>
>>> I successfully updated to 0.28 and thought while I was on a roll I would
>>> try updating to 16.04
>>> and now it wont even boot.
>>>
>>> I have not got a lot of recordings so I think I might try a new
>>> installation.
>>>
>>> I remembered following Mike Brady's guide at:-
>>>
>>> http://www.gossamer-threads.com/lists/mythtv/mythtvnz/501872?search_string=tv_grab_nz-py;#501872
>>>
>>> But I think I found previously one mistake.
>>>
>>> Can someone please check
>>>
>>> ) Copy*tv_grab_nz-py*to /usr/bin. Make sure that it is executable.
>>>
>>> I think that on Mythbuntu it has to be somewhere else?
>> You would normally put it in /usr/local/bin. The /usr/bin directory
>> is normally for files installed from packages. The /usr/local
>> directories are where you put your local customisations. Putting it
>> in /usr/bin would work though.
>>

>Thanks, I think that I recall that the problem with putting it in
>/usr/bin was that it did not run automatically.

It does not run automatically unless you set that up. Where you put
it will not affect that.

It does not matter where it is put as long as you either tell MythTV
the full pathname, or it is on the $PATH, which both /usr/bin and
/usr/local/bin are. Putting it in /usr/local/bin is simply a
convention - you are not supposed to put custom things in /usr/bin,
that is where the packaging system puts things.

_______________________________________________
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 20/07/16 06:02, Stephen Worthington wrote:
> It does not run automatically unless you set that up. Where you put
> it will not affect that.
>
It may have been something to do with this from Mike.....

b) In General, on the Mythfilldatabase page (its the last page) enable
"Automatically run mythfilldatabase". Configure time, frequency, etc
to suite. Now Myth should use*tv_grab_nz-py*to update EPG
periodically. The MythWeb status page shows when it was last run and
what the results were.

--
Robert

> One thing I have just thought of - if my memory is correct, it was in
> the upgrade from 12.04 to 14.04 that the changes to lirc happened,
> where the drivers moved into the kernel. So you may find that you
> will have lirc problems after upgrading and will need a new lirc
> config.
>
I use a wireless keyboard as a remote,so that won't be a problem for me.

_______________________________________________
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 18/07/16 13:07, Paulgir wrote:
> Hi All
>
> Those who have already updated to Mythbuntu 16.04,how is it going?I
> noted that people where experiencing problems,initially.
> I'm thinking of upgrading when 16.04.1 comes out shortly.

I am more interested in reasons to change. I am on 14.04 with 0.27


~$ cat /etc/issue
Ubuntu 14.04.4 LTS

~$ aptitude show mythtv-backend-master |grep Version
Version: 2:0.27.0+fixes.20140324.8ee257c-0ubuntu3

Is there any reason to upgrade? The server machine is an old machine
that is serving me well doing this one job, supposing the problems I
sometimes have with reception are caused by the antenna....

cheers
Worik



--
Why is the legal status of chardonnay different to that of cannabis?
worik.stanton@gmail.com 021-1680650, (03) 4821804
Aotearoa (New Zealand)
I voted for love

_______________________________________________
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 Wed, Jul 20, 2016 at 8:00 AM, worik <worik.stanton@gmail.com> wrote:

> On 18/07/16 13:07, Paulgir wrote:
> > Hi All
> >
> > Those who have already updated to Mythbuntu 16.04,how is it going?I
> > noted that people where experiencing problems,initially.
> > I'm thinking of upgrading when 16.04.1 comes out shortly.
>
> I am more interested in reasons to change. I am on 14.04 with 0.27
>
>
> ~$ cat /etc/issue
> Ubuntu 14.04.4 LTS
>
> ~$ aptitude show mythtv-backend-master |grep Version
> Version: 2:0.27.0+fixes.20140324.8ee257c-0ubuntu3
>
> Is there any reason to upgrade? The server machine is an old machine
> that is serving me well doing this one job, supposing the problems I
> sometimes have with reception are caused by the antenna....
>

There is no real reason to change OS versions, but you should most
definitely be using the mythbuntu repo and getting up to date 0.27 packages.



>
> cheers
> Worik
>
>
>
> --
> Why is the legal status of chardonnay different to that of cannabis?
> worik.stanton@gmail.com 021-1680650, (03) 4821804
> Aotearoa (New Zealand)
> I voted for love
>
> _______________________________________________
> 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 20 July 2016 at 10:07, Nick Rout <nick.rout@gmail.com> wrote:

>
>
> There is no real reason to change OS versions, but you should most
> definitely be using the mythbuntu repo and getting up to date 0.27 packages.
>
> After my experience last night I would recommend holding off on the OS
upgrade.

The upgrade to 0.28 was easy though.

.......and early this morning I did a fresh install of MythBuntu 16.04 and
the setup seemed to be going OK until I edited my fstab without creating
the mount points so now it wont boot again.

(Another learn by mistakes experience)

On Wed, Jul 20, 2016 at 10:52 AM, Robert Fisher <robert@fisher.net.nz>
wrote:

>
> On 20 July 2016 at 10:07, Nick Rout <nick.rout@gmail.com> wrote:
>
>>
>>
>> There is no real reason to change OS versions, but you should most
>> definitely be using the mythbuntu repo and getting up to date 0.27 packages.
>>
>> After my experience last night I would recommend holding off on the OS
> upgrade.
>
> The upgrade to 0.28 was easy though.
>
> .......and early this morning I did a fresh install of MythBuntu 16.04 and
> the setup seemed to be going OK until I edited my fstab without creating
> the mount points so now it wont boot again.
>
> (Another learn by mistakes experience)
>


Boot from CD/USB and fix it, no need to completely reinstall.

I thought about that.

On 20 July 2016 at 11:03, Nick Rout <nick.rout@gmail.com> wrote:

>
>
> On Wed, Jul 20, 2016 at 10:52 AM, Robert Fisher <robert@fisher.net.nz>
> wrote:
>
>>
>> On 20 July 2016 at 10:07, Nick Rout <nick.rout@gmail.com> wrote:
>>
>>>
>>>
>>> There is no real reason to change OS versions, but you should most
>>> definitely be using the mythbuntu repo and getting up to date 0.27 packages.
>>>
>>> After my experience last night I would recommend holding off on the OS
>> upgrade.
>>
>> The upgrade to 0.28 was easy though.
>>
>> .......and early this morning I did a fresh install of MythBuntu 16.04
>> and the setup seemed to be going OK until I edited my fstab without
>> creating the mount points so now it wont boot again.
>>
>> (Another learn by mistakes experience)
>>
>
>
> Boot from CD/USB and fix it, no need to completely reinstall.
>
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>
>


--
Robert Fisher

On 20/07/16 10:07, Nick Rout wrote:
>
>
> On Wed, Jul 20, 2016 at 8:00 AM, worik <worik.stanton@gmail.com
> <mailto:worik.stanton@gmail.com>> wrote:
>
> On 18/07/16 13:07, Paulgir wrote:
> > Hi All
> >
> > Those who have already updated to Mythbuntu 16.04,how is it going?I
> > noted that people where experiencing problems,initially.
> > I'm thinking of upgrading when 16.04.1 comes out shortly.
>
> I am more interested in reasons to change. I am on 14.04 with 0.27
>
Well I went back and did a fresh installation of MythBuntu 16.04 and I
think that I am nearly there.
Certainly not as easy as 14.04 though.

I can play, pause, FF etc. live TV from my Kodi frontend and also record
from the frontend.

The EPG does not seem to be fully populated even though mythfilldatabase
runs with no errors.

My main problem now is with mythweb.
Backend status seems OK.

"Listings" gives this error.......


Fatal Error

!!NoTrans: SQL Error: Expression #3 of SELECT list is not in GROUP BY
clause and contains nonaggregated column 'mythconverg.program.endtime'
which is not functionally dependent on columns in GROUP BY clause; this
is incompatible with sql_mode=only_full_group_by [#1055]!!


"Recorded programs" gives this (very similar) error.....


Fatal Error

!!NoTrans: SQL Error: Expression #2 of SELECT list is not in GROUP BY
clause and contains nonaggregated column
'mythconverg.recordedmarkup.data' which is not functionally dependent on
columns in GROUP BY clause; this is incompatible with
sql_mode=only_full_group_by [#1055]!!

This makes no sense to me but I do wonder if it is related to the fact
that with this installation I was not asked for the database password.
The database configuration page which I got with my 14.04 installation
did not come up at all. (I did select "backend only" installation this
time though)

If none of you can help me I think I will reinstall 14.04

--
Robert

On 20/07/16 20:57, Robert Fisher wrote:
> On 20/07/16 10:07, Nick Rout wrote:
>>
>>
>> On Wed, Jul 20, 2016 at 8:00 AM, worik <worik.stanton@gmail.com
>> <mailto:worik.stanton@gmail.com>> wrote:
>>
>> On 18/07/16 13:07, Paulgir wrote:
>> > Hi All
>> >
>> > Those who have already updated to Mythbuntu 16.04,how is it going?I
>> > noted that people where experiencing problems,initially.
>> > I'm thinking of upgrading when 16.04.1 comes out shortly.
>>
>> I am more interested in reasons to change. I am on 14.04 with 0.27
>>
> Well I went back and did a fresh installation of MythBuntu 16.04 and I
> think that I am nearly there.
> Certainly not as easy as 14.04 though.
>
> I can play, pause, FF etc. live TV from my Kodi frontend and also
> record from the frontend.
>
> The EPG does not seem to be fully populated even though
> mythfilldatabase runs with no errors.
>
> My main problem now is with mythweb.
> Backend status seems OK.
Well (further testing needed) I may have cracked it.

I found this
https://code.mythtv.org/trac/ticket/12713
Which suggested editing /etc/mysql/conf.d/mythtv.cnf
to

[mysqld]
#bind-address=0.0.0.0
max_connections=100
sql_mode=NO_ENGINE_SUBSTITUTION

This seems to have mythweb working OK. (I hope I am not speaking too soon)
The EPG in Mythweb seems fine although not on my Kodi frontend yet.

I also had this problem *Mythbuntu 16.04 Fresh Install - always starts
MythTV Setup on boot *
and found this http://www.gossamer-threads.com/lists/mythtv/users/601385
and this https://ubuntuforums.org/showthread.php?t=2320224

The fix for me was...
Short version of solution that worked for me:
copy /lib/systemd/system/mythtv-backend.service to /etc/systemd/system/
edit /etc/systemd/system/mythtv-backend.service and insert the line
ExecStartPre=/usr/bin/nm-online --quiet --timeout=5 above the existing
ExecStartPre=... line.
reboot

On Wed, 20 Jul 2016 21:31:11 +1200, you wrote:

>On 20/07/16 20:57, Robert Fisher wrote:
>> On 20/07/16 10:07, Nick Rout wrote:
>>>
>>>
>>> On Wed, Jul 20, 2016 at 8:00 AM, worik <worik.stanton@gmail.com
>>> <mailto:worik.stanton@gmail.com>> wrote:
>>>
>>> On 18/07/16 13:07, Paulgir wrote:
>>> > Hi All
>>> >
>>> > Those who have already updated to Mythbuntu 16.04,how is it going?I
>>> > noted that people where experiencing problems,initially.
>>> > I'm thinking of upgrading when 16.04.1 comes out shortly.
>>>
>>> I am more interested in reasons to change. I am on 14.04 with 0.27
>>>
>> Well I went back and did a fresh installation of MythBuntu 16.04 and I
>> think that I am nearly there.
>> Certainly not as easy as 14.04 though.
>>
>> I can play, pause, FF etc. live TV from my Kodi frontend and also
>> record from the frontend.
>>
>> The EPG does not seem to be fully populated even though
>> mythfilldatabase runs with no errors.
>>
>> My main problem now is with mythweb.
>> Backend status seems OK.
>Well (further testing needed) I may have cracked it.
>
>I found this
>https://code.mythtv.org/trac/ticket/12713
>Which suggested editing /etc/mysql/conf.d/mythtv.cnf
>to
>
>[mysqld]
>#bind-address=0.0.0.0
>max_connections=100
>sql_mode=NO_ENGINE_SUBSTITUTION
>
>This seems to have mythweb working OK. (I hope I am not speaking too soon)
>The EPG in Mythweb seems fine although not on my Kodi frontend yet.
>
>I also had this problem *Mythbuntu 16.04 Fresh Install - always starts
>MythTV Setup on boot *
>and found this http://www.gossamer-threads.com/lists/mythtv/users/601385
>and this https://ubuntuforums.org/showthread.php?t=2320224
>
>The fix for me was...
>Short version of solution that worked for me:
>copy /lib/systemd/system/mythtv-backend.service to /etc/systemd/system/
>edit /etc/systemd/system/mythtv-backend.service and insert the line
>ExecStartPre=/usr/bin/nm-online --quiet --timeout=5 above the existing
>ExecStartPre=... line.
>reboot

That does not sound like the correct way to do it with systemd - I
would have thought it needed to use a .target that would signal when
everything was ready. But if it works...

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

Another question. I foolishly did not backup anything on the 14.04
backend (thinking that I did not care if I lost the recordings I had).

Now I still have the recordings and wondered if there is a way to update
the database to recognise them?

I will not be dissappointed if the answer is no. I will just delete them.

Rob

_______________________________________________
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 there is, if I think I understand your need. A script called
find.orphans.py. Just Google search.

On 21/07/2016 16:58, "Robert Fisher" <robert@fisher.net.nz> wrote:

> Another question. I foolishly did not backup anything on the 14.04 backend
> (thinking that I did not care if I lost the recordings I had).
>
> Now I still have the recordings and wondered if there is a way to update
> the database to recognise them?
>
> I will not be dissappointed if the answer is no. I will just delete them.
>
> Rob
>
> _______________________________________________
> 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 21/07/16 17:10, skooobie doo wrote:
>
> Yes there is, if I think I understand your need. A script called
> find.orphans.py <http://find.orphans.py>. Just Google search.
>
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.


--
Robert

> 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


_______________________________________________
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, 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/