Mailing List Archive

On Fri, 29 Jul 2016 13:53:05 +1200, you wrote:

>
>Hi all,
>
>I'm working on a new install of mythbuntu 16.04.I have my previous install
>of 12.04 on another drive.Both systems use the same 1TB storage.I restored
>the db backup from 12.04 onto 16.04 and everything looks correct,I
>carefully confirmed this against the 12.04 settings.On 16.04 I can watch
>recordings and videos.I can also do channel scans with no apparent errors.
>
>If I try live tv I get a message saying all tuners are busy.If I try to
>record a program in the guide I get a "recorder off_line" message.In the
>Information menu section all tuners show "error".
>
>The tuners are a Haupauge 2200 and a HDHR and using HDHR config GUI and
>Me-TV I have confirm the tuners are working.
>
>Mythbackend.log has a lot of these errors:
>
>Jul 29 11:58:03 myth mythbackend: mythbackend[2547]: E ProcessRequest
>mainserver.cpp:4718 (HandleRemoteEncoder) MainServer:
>HandleRemoteEncoder(cmd GET_STATE) Unknown encoder: 46
>
>Also,this may be totally unrelated, the directories and files on the
>storage drive (/var/lib/mythtv) all had the owner and group listed as ntp.
>I changed this to owner: mythtv ;group:mythtv in accordance with what the
>12.04 install has. I was getting "unable to create file
>"var/lib/mythtv/recordings/.test" directory is not writable" messages on
>startup.Changing the owner to mythtv eliminated these.
>
>Any suggestions will be much appreciated.
>
>-Paul

When you install a Linux system, the group ids and user ids are
assigned to the various groups and users. But they can vary from one
Linux install to another, even if you use the same version of Linux.
So if you move a drive from one system to another, you often find that
the ids do not match and you get the wrong group or user. So you may
need to chown all the directories and files to what they should be.
The chown command has a -R option to recurse directories, which helps.

As for your tuners, did you just restore the database without checking
the order the tuners are in? Tuners can move in order between boots,
and they certainly move when installed in different slots or USB
ports, let alone when moved to a different motherboard. So you need
to see which tuner should be on which /dev/dvb address and make sure
they are on the same ones that your old system had them. This command
will show you what the database says the tuner addresses are:

select
cardid,parentid,videodevice,cardtype,defaultinput,tunechan,startchan,displayname,channel_timeout
from capturecard order by videodevice;

The videodevice field gives the address of the tuner. So then you
need to use the adapter_nr option in your tuner driver setup to assign
the tuners to the correct address. Not all tuners have the adapter_nr
option, and if any of yours do not, you will need to use udev rules to
assign them to the correct address. But check first for adapter_nr as
that is much easier to use.

The modinfo command followed by the device driver name gives the
options for drivers. Here is what my DVB-T drivers say:

root@mypvr:/etc/modprobe.d# modinfo dvb_usb_dib0700 | grep parm
parm: force_lna_activation:force the activation of
Low-Noise-Amplifyer(s) (LNA), if applicable for the device (default:
0=automatic/off). (int)
parm: debug:set debugging level (1=info,2=fw,4=fwdata,8=data
(or-able)). (int)
parm: nb_packet_buffer_size:Set the dib0700 driver data
buffer size. This parameter corresponds to the number of TS packets.
The actual size of the data buffer corresponds to this parameter
multiplied by 188 (default: 21) (int)
parm: adapter_nr:DVB adapter numbers (array of short)

To use the adapter_nr option, you need to create a .conf file in
/etc/modprobe.d. I have mine in options-dvb.conf. This is what I
have for my tuners:

#Set adapter numbers for Nova-TD 500 DVB-T card (dual tuners), and
AverMedia AverTV DVB-T Volar USB tuner (they use the same driver).
options dvb_usb_dib0700 adapter_nr=0,1,2

#Set adapter number for TurboSight TBS5922 QBOX S2 DVB-S2 USB tuner.
options dvb-usb-tbsqbox22 adapter_nr=3

#Set adapter number for TeVii S470 DVB-S2 PCIe x1 card.
options cx23885 adapter_nr=4

Finding the name of your tuner driver can be a bit difficult. If you
do not know what it is, looking through the kern.log file for what
happens at boot time will normally tell you, but there are some
(fortunately rare) drivers that do not actually post any messages that
have the driver name in them.

If you can not use adapter_nr, let us know and we can try to help with
udev rules.

It is also possible that your tuner order is stable with each boot, in
which case you could just delete all your tuners in mythtv-setup and
re-create them.

_______________________________________________
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, 29 Jul 2016 16:15:34 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Fri, 29 Jul 2016 13:53:05 +1200, you wrote:
>
>>
>> Hi all,
>>
>> I'm working on a new install of mythbuntu 16.04.I have my previous
>> install
>> of 12.04 on another drive.Both systems use the same 1TB storage.I
>> restored
>> the db backup from 12.04 onto 16.04 and everything looks correct,I
>> carefully confirmed this against the 12.04 settings.On 16.04 I can watch
>> recordings and videos.I can also do channel scans with no apparent
>> errors.
>>
>> If I try live tv I get a message saying all tuners are busy.If I try to
>> record a program in the guide I get a "recorder off_line" message.In the
>> Information menu section all tuners show "error".
>>
>> The tuners are a Haupauge 2200 and a HDHR and using HDHR config GUI and
>> Me-TV I have confirm the tuners are working.
>>
>> Mythbackend.log has a lot of these errors:
>>
>> Jul 29 11:58:03 myth mythbackend: mythbackend[2547]: E ProcessRequest
>> mainserver.cpp:4718 (HandleRemoteEncoder) MainServer:
>> HandleRemoteEncoder(cmd GET_STATE) Unknown encoder: 46
>>
>> Also,this may be totally unrelated, the directories and files on the
>> storage drive (/var/lib/mythtv) all had the owner and group listed as
>> ntp.
>> I changed this to owner: mythtv ;group:mythtv in accordance with whatthe
>> 12.04 install has. I was getting "unable to create file
>> "var/lib/mythtv/recordings/.test" directory is not writable" messages on
>> startup.Changing the owner to mythtv eliminated these.
>>
>> Any suggestions will be much appreciated.
>>
>> -Paul
>
> When you install a Linux system, the group ids and user ids are
> assigned to the various groups and users. But they can vary from one
> Linux install to another, even if you use the same version of Linux.
> So if you move a drive from one system to another, you often find that
> the ids do not match and you get the wrong group or user. So you may
> need to chown all the directories and files to what they should be.
> The chown command has a -R option to recurse directories, which helps.

The only changes in the hardware are the two system drives: an old HDD
with 12.04 and a new SSD for 16.04 It isn't a duel boot I am swapping the
sata cable while I'm getting 16.04 sorted.Once that is done I'll delete
12.04 off the old drive.
/var/lib/mythtv is on the 3rd drive and after changing the owner (chown
-R) for 16.04 I have just found I need to change it back when I booted
12.04.It works - no problem.
>
> As for your tuners, did you just restore the database without checking
> the order the tuners are in? Tuners can move in order between boots,
> and they certainly move when installed in different slots or USB
> ports, let alone when moved to a different motherboard. So you need
> to see which tuner should be on which /dev/dvb address and make sure
> they are on the same ones that your old system had them. This command
> will show you what the database says the tuner addresses are:

I'll have to check this.As I stated above cards and mobo have not changed.

>
> select
> cardid,parentid,videodevice,cardtype,defaultinput,tunechan,startchan,displayname,channel_timeout
> from capturecard order by videodevice;

Are these mysql commands?
>
> The videodevice field gives the address of the tuner. So then you
> need to use the adapter_nr option in your tuner driver setup to assign
> the tuners to the correct address. Not all tuners have the adapter_nr
> option, and if any of yours do not, you will need to use udev rules to
> assign them to the correct address. But check first for adapter_nr as
> that is much easier to use.
>
> The modinfo command followed by the device driver name gives the
> options for drivers. Here is what my DVB-T drivers say:
>
> root@mypvr:/etc/modprobe.d# modinfo dvb_usb_dib0700 | grep parm
> parm: force_lna_activation:force the activation of
> Low-Noise-Amplifyer(s) (LNA), if applicable for the device (default:
> 0=automatic/off). (int)
> parm: debug:set debugging level (1=info,2=fw,4=fwdata,8=data
> (or-able)). (int)
> parm: nb_packet_buffer_size:Set the dib0700 driver data
> buffer size. This parameter corresponds to the number of TS packets.
> The actual size of the data buffer corresponds to this parameter
> multiplied by 188 (default: 21) (int)
> parm: adapter_nr:DVB adapter numbers (array of short)
>
> To use the adapter_nr option, you need to create a .conf file in
> /etc/modprobe.d. I have mine in options-dvb.conf. This is what I
> have for my tuners:
>
> #Set adapter numbers for Nova-TD 500 DVB-T card (dual tuners), and
> AverMedia AverTV DVB-T Volar USB tuner (they use the same driver).
> options dvb_usb_dib0700 adapter_nr=0,1,2
>
> #Set adapter number for TurboSight TBS5922 QBOX S2 DVB-S2 USB tuner.
> options dvb-usb-tbsqbox22 adapter_nr=3
>
> #Set adapter number for TeVii S470 DVB-S2 PCIe x1 card.
> options cx23885 adapter_nr=4
>
> Finding the name of your tuner driver can be a bit difficult. If you
> do not know what it is, looking through the kern.log file for what
> happens at boot time will normally tell you, but there are some
> (fortunately rare) drivers that do not actually post any messages that
> have the driver name in them.
>
> If you can not use adapter_nr, let us know and we can try to help with
> udev rules.
>
> It is also possible that your tuner order is stable with each boot, in
> which case you could just delete all your tuners in mythtv-setup and
> re-create them.
I did this - it did not change the problem

Does this apply to the HDHR as well?
Thanks for the help.I've set it back to 12.04 for the evening and will
look at it again tomorrow.
I also ran into this
bug:https://bugs.launchpad.net/ubuntu/+source/mythbuntu-common/+bug/1576767
after changing a database setting in mythbuntu control center.It looks
like that is sorted,though.

> When you install a Linux system, the group ids and user ids are
> assigned to the various groups and users. But they can vary from one
> Linux install to another, even if you use the same version of Linux.
> So if you move a drive from one system to another, you often find that
> the ids do not match and you get the wrong group or user. So you may
> need to chown all the directories and files to what they should be.
> The chown command has a -R option to recurse directories, which helps.
>
> As for your tuners, did you just restore the database without checking
> the order the tuners are in? Tuners can move in order between boots,
> and they certainly move when installed in different slots or USB
> ports, let alone when moved to a different motherboard. So you need
> to see which tuner should be on which /dev/dvb address and make sure
> they are on the same ones that your old system had them. This command
> will show you what the database says the tuner addresses are:
>
> select
> cardid,parentid,videodevice,cardtype,defaultinput,tunechan,startchan,displayname,channel_timeout
> from capturecard order by videodevice;
>
> The videodevice field gives the address of the tuner. So then you
> need to use the adapter_nr option in your tuner driver setup to assign
> the tuners to the correct address. Not all tuners have the adapter_nr
> option, and if any of yours do not, you will need to use udev rules to
> assign them to the correct address. But check first for adapter_nr as
> that is much easier to use.
>
> The modinfo command followed by the device driver name gives the
> options for drivers. Here is what my DVB-T drivers say:
>
> root@mypvr:/etc/modprobe.d# modinfo dvb_usb_dib0700 | grep parm
> parm: force_lna_activation:force the activation of
> Low-Noise-Amplifyer(s) (LNA), if applicable for the device (default:
> 0=automatic/off). (int)
> parm: debug:set debugging level (1=info,2=fw,4=fwdata,8=data
> (or-able)). (int)
> parm: nb_packet_buffer_size:Set the dib0700 driver data
> buffer size. This parameter corresponds to the number of TS packets.
> The actual size of the data buffer corresponds to this parameter
> multiplied by 188 (default: 21) (int)
> parm: adapter_nr:DVB adapter numbers (array of short)
>
> To use the adapter_nr option, you need to create a .conf file in
> /etc/modprobe.d. I have mine in options-dvb.conf. This is what I
> have for my tuners:
>
> #Set adapter numbers for Nova-TD 500 DVB-T card (dual tuners), and
> AverMedia AverTV DVB-T Volar USB tuner (they use the same driver).
> options dvb_usb_dib0700 adapter_nr=0,1,2
>
> #Set adapter number for TurboSight TBS5922 QBOX S2 DVB-S2 USB tuner.
> options dvb-usb-tbsqbox22 adapter_nr=3
>
> #Set adapter number for TeVii S470 DVB-S2 PCIe x1 card.
> options cx23885 adapter_nr=4
>
> Finding the name of your tuner driver can be a bit difficult. If you
> do not know what it is, looking through the kern.log file for what
> happens at boot time will normally tell you, but there are some
> (fortunately rare) drivers that do not actually post any messages that
> have the driver name in them.
>
> If you can not use adapter_nr, let us know and we can try to help with
> udev rules.
>
> It is also possible that your tuner order is stable with each boot, in
> which case you could just delete all your tuners in mythtv-setup and
> re-create them.
>

I'm not sure I have the info you're asking for but here goes:

+--------+----------+-----------------------------+-----------+--------------+----------+-----------+-------------+-----------------+
| cardid | parentid | videodevice | cardtype |
defaultinput | tunechan | startchan | displayname | channel_timeout |
+--------+----------+-----------------------------+-----------+--------------+----------+-----------+-------------+-----------------+
| 37 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
Television | NULL | 1 | card-0 | 3000 |
| 35 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
Television | NULL | 1 | card-0 | 3000 |
| 36 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
Television | NULL | 1 | card-0 | 3000 |
| 27 | 0 | /dev/dvb/adapter0/frontend0 | DVB |
Television | NULL | 1 | card-0 | 3000 |
| 28 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
Television | NULL | 1 | card-0 | 3000 |
| 40 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
Television | NULL | 1 | card-1 | 3000 |
| 38 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
Television | NULL | 1 | card-1 | 3000 |
| 39 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
Television | NULL | 1 | card-1 | 3000 |
| 29 | 0 | /dev/dvb/adapter1/frontend0 | DVB |
Television | NULL | 1 | card-1 | 3000 |
| 30 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
Television | NULL | 1 | card-1 | 3000 |
| 41 | 31 | 11111EB6-0 | HDHOMERUN |
Television | NULL | 1 | HDHR-0 | 3000 |
| 31 | 0 | 11111EB6-0 | HDHOMERUN |
Television | NULL | 1 | HDHR-0 | 3000 |
| 32 | 31 | 11111EB6-0 | HDHOMERUN |
Television | NULL | 1 | HDHR-0 | 3000 |
| 42 | 31 | 11111EB6-0 | HDHOMERUN |
Television | NULL | 1 | HDHR-0 | 3000 |
| 43 | 31 | 11111EB6-0 | HDHOMERUN |
Television | NULL | 1 | HDHR-0 | 3000 |
| 33 | 0 | 11111EB6-1 | HDHOMERUN |
Television | NULL | 1 | HDHR-1 | 3000 |
| 34 | 33 | 11111EB6-1 | HDHOMERUN |
Television | NULL | 1 | HDHR-1 | 3000 |
| 44 | 33 | 11111EB6-1 | HDHOMERUN |
Television | NULL | 1 | HDHR-1 | 3000 |
| 45 | 33 | 11111EB6-1 | HDHOMERUN |
Television | NULL | 1 | HDHR-1 | 3000 |
| 46 | 33 | 11111EB6-1 | HDHOMERUN |
Television | NULL | 1 | HDHR-1 | 3000 |
+--------+----------+-----------------------------+-----------+--------------+----------+-----------+-------------+-----------------+

Kern.log:
frontend 0 (NXP TDA10048HN DVB-T)...
Jul 30 10:19:49 myth kernel: [ 15.169822] tda18271 5-0060: creating new
instance
Jul 30 10:19:49 myth kernel: [ 15.174271] TDA18271HD/C2 detected @ 5-0060
Jul 30 10:19:50 myth kernel: [ 15.423597] tda18271: performing RF
tracking filter calibration
Jul 30 10:19:52 myth kernel: [ 17.776718] tda18271: RF tracking filter
calibration complete
Jul 30 10:19:52 myth kernel: [ 17.779906] DVB: registering new adapter
(saa7164)
Jul 30 10:19:52 myth kernel: [ 17.779912] saa7164 0000:03:00.0: DVB:
registering adapter 1

I'm not sure this is the command you want:

~$ modinfo saa7164 | grep parm
parm: adapter_nr:DVB adapter numbers (array of short)
parm: debug:enable debug messages (int)
parm: fw_debug:Firmware debug level def:2 (int)
parm: encoder_buffers:Total buffers in read queue 16-512 def:64
(int)
parm: vbi_buffers:Total buffers in read queue 16-512 def:64 (int)
parm: waitsecs:timeout on firmware messages (int)
parm: card:card type (array of int)
parm: print_histogram:print histogram values once (int)
parm: crc_checking:enable crc sanity checking on buffers (int)
parm: guard_checking:enable dma sanity checking for buffer
overruns (int)
parm: enable_msi:enable the use of an msi interrupt if available
(bool)


I get:
:~# /etc/modprobe.d# modinfo saa7164|grep parm
bash: /etc/modprobe.d#: No such file or directory

_______________________________________________
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, 30 Jul 2016 11:02:35 +1200, you wrote:

>
>
>> When you install a Linux system, the group ids and user ids are
>> assigned to the various groups and users. But they can vary from one
>> Linux install to another, even if you use the same version of Linux.
>> So if you move a drive from one system to another, you often find that
>> the ids do not match and you get the wrong group or user. So you may
>> need to chown all the directories and files to what they should be.
>> The chown command has a -R option to recurse directories, which helps.
>>
>> As for your tuners, did you just restore the database without checking
>> the order the tuners are in? Tuners can move in order between boots,
>> and they certainly move when installed in different slots or USB
>> ports, let alone when moved to a different motherboard. So you need
>> to see which tuner should be on which /dev/dvb address and make sure
>> they are on the same ones that your old system had them. This command
>> will show you what the database says the tuner addresses are:
>>
>> select
>> cardid,parentid,videodevice,cardtype,defaultinput,tunechan,startchan,displayname,channel_timeout
>> from capturecard order by videodevice;
>>
>> The videodevice field gives the address of the tuner. So then you
>> need to use the adapter_nr option in your tuner driver setup to assign
>> the tuners to the correct address. Not all tuners have the adapter_nr
>> option, and if any of yours do not, you will need to use udev rules to
>> assign them to the correct address. But check first for adapter_nr as
>> that is much easier to use.
>>
>> The modinfo command followed by the device driver name gives the
>> options for drivers. Here is what my DVB-T drivers say:
>>
>> root@mypvr:/etc/modprobe.d# modinfo dvb_usb_dib0700 | grep parm
>> parm: force_lna_activation:force the activation of
>> Low-Noise-Amplifyer(s) (LNA), if applicable for the device (default:
>> 0=automatic/off). (int)
>> parm: debug:set debugging level (1=info,2=fw,4=fwdata,8=data
>> (or-able)). (int)
>> parm: nb_packet_buffer_size:Set the dib0700 driver data
>> buffer size. This parameter corresponds to the number of TS packets.
>> The actual size of the data buffer corresponds to this parameter
>> multiplied by 188 (default: 21) (int)
>> parm: adapter_nr:DVB adapter numbers (array of short)
>>
>> To use the adapter_nr option, you need to create a .conf file in
>> /etc/modprobe.d. I have mine in options-dvb.conf. This is what I
>> have for my tuners:
>>
>> #Set adapter numbers for Nova-TD 500 DVB-T card (dual tuners), and
>> AverMedia AverTV DVB-T Volar USB tuner (they use the same driver).
>> options dvb_usb_dib0700 adapter_nr=0,1,2
>>
>> #Set adapter number for TurboSight TBS5922 QBOX S2 DVB-S2 USB tuner.
>> options dvb-usb-tbsqbox22 adapter_nr=3
>>
>> #Set adapter number for TeVii S470 DVB-S2 PCIe x1 card.
>> options cx23885 adapter_nr=4
>>
>> Finding the name of your tuner driver can be a bit difficult. If you
>> do not know what it is, looking through the kern.log file for what
>> happens at boot time will normally tell you, but there are some
>> (fortunately rare) drivers that do not actually post any messages that
>> have the driver name in them.
>>
>> If you can not use adapter_nr, let us know and we can try to help with
>> udev rules.
>>
>> It is also possible that your tuner order is stable with each boot, in
>> which case you could just delete all your tuners in mythtv-setup and
>> re-create them.
>>
>
>I'm not sure I have the info you're asking for but here goes:
>
>+--------+----------+-----------------------------+-----------+--------------+----------+-----------+-------------+-----------------+
>| cardid | parentid | videodevice | cardtype |
>defaultinput | tunechan | startchan | displayname | channel_timeout |
>+--------+----------+-----------------------------+-----------+--------------+----------+-----------+-------------+-----------------+
>| 37 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
>Television | NULL | 1 | card-0 | 3000 |
>| 35 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
>Television | NULL | 1 | card-0 | 3000 |
>| 36 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
>Television | NULL | 1 | card-0 | 3000 |
>| 27 | 0 | /dev/dvb/adapter0/frontend0 | DVB |
>Television | NULL | 1 | card-0 | 3000 |
>| 28 | 27 | /dev/dvb/adapter0/frontend0 | DVB |
>Television | NULL | 1 | card-0 | 3000 |
>| 40 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
>Television | NULL | 1 | card-1 | 3000 |
>| 38 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
>Television | NULL | 1 | card-1 | 3000 |
>| 39 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
>Television | NULL | 1 | card-1 | 3000 |
>| 29 | 0 | /dev/dvb/adapter1/frontend0 | DVB |
>Television | NULL | 1 | card-1 | 3000 |
>| 30 | 29 | /dev/dvb/adapter1/frontend0 | DVB |
>Television | NULL | 1 | card-1 | 3000 |
>| 41 | 31 | 11111EB6-0 | HDHOMERUN |
>Television | NULL | 1 | HDHR-0 | 3000 |
>| 31 | 0 | 11111EB6-0 | HDHOMERUN |
>Television | NULL | 1 | HDHR-0 | 3000 |
>| 32 | 31 | 11111EB6-0 | HDHOMERUN |
>Television | NULL | 1 | HDHR-0 | 3000 |
>| 42 | 31 | 11111EB6-0 | HDHOMERUN |
>Television | NULL | 1 | HDHR-0 | 3000 |
>| 43 | 31 | 11111EB6-0 | HDHOMERUN |
>Television | NULL | 1 | HDHR-0 | 3000 |
>| 33 | 0 | 11111EB6-1 | HDHOMERUN |
>Television | NULL | 1 | HDHR-1 | 3000 |
>| 34 | 33 | 11111EB6-1 | HDHOMERUN |
>Television | NULL | 1 | HDHR-1 | 3000 |
>| 44 | 33 | 11111EB6-1 | HDHOMERUN |
>Television | NULL | 1 | HDHR-1 | 3000 |
>| 45 | 33 | 11111EB6-1 | HDHOMERUN |
>Television | NULL | 1 | HDHR-1 | 3000 |
>| 46 | 33 | 11111EB6-1 | HDHOMERUN |
>Television | NULL | 1 | HDHR-1 | 3000 |
>+--------+----------+-----------------------------+-----------+--------------+----------+-----------+-------------+-----------------+
>
>Kern.log:
>frontend 0 (NXP TDA10048HN DVB-T)...
>Jul 30 10:19:49 myth kernel: [ 15.169822] tda18271 5-0060: creating new
>instance
>Jul 30 10:19:49 myth kernel: [ 15.174271] TDA18271HD/C2 detected @ 5-0060
>Jul 30 10:19:50 myth kernel: [ 15.423597] tda18271: performing RF
>tracking filter calibration
>Jul 30 10:19:52 myth kernel: [ 17.776718] tda18271: RF tracking filter
>calibration complete
>Jul 30 10:19:52 myth kernel: [ 17.779906] DVB: registering new adapter
>(saa7164)
>Jul 30 10:19:52 myth kernel: [ 17.779912] saa7164 0000:03:00.0: DVB:
>registering adapter 1
>
>I'm not sure this is the command you want:
>
>~$ modinfo saa7164 | grep parm
>parm: adapter_nr:DVB adapter numbers (array of short)
>parm: debug:enable debug messages (int)
>parm: fw_debug:Firmware debug level def:2 (int)
>parm: encoder_buffers:Total buffers in read queue 16-512 def:64
>(int)
>parm: vbi_buffers:Total buffers in read queue 16-512 def:64 (int)
>parm: waitsecs:timeout on firmware messages (int)
>parm: card:card type (array of int)
>parm: print_histogram:print histogram values once (int)
>parm: crc_checking:enable crc sanity checking on buffers (int)
>parm: guard_checking:enable dma sanity checking for buffer
>overruns (int)
>parm: enable_msi:enable the use of an msi interrupt if available
>(bool)
>
>
>I get:
>:~# /etc/modprobe.d# modinfo saa7164|grep parm
>bash: /etc/modprobe.d#: No such file or directory

It looks like I was wrong about where the problem lies. Since you
have only one real tuner card, even though it has dual tuners, it will
never move its address around. The HDHR tuners are Ethernet, so they
do not show up as hardware devices in /dev/dvb. So there is no need
for adapter_nr settings unless you ever add another standard tuner.

The settings from the capturecard table look fine except for the
channel_timeout value (3000), which is way too small for DVB-T here in
New Zealand. In versions before 0.28, mythbackend recovered from that
and managed to tune channels anyway, but took longer than necessary as
it could retry several times. In 0.28, it can fail to ever tune
properly, so those settings need to all be increased. I am using
10000 ms, and that seems to work well. TV3 can take between 7 and 8
seconds to tune. However, that is unlikely to explain your symptoms,
it is just another problem you would have had later in getting 16.04
working properly. You change those values in mythtv-setup => Capture
Cards. On each tuner there, on the first page of its settings, change
the "Tuning timeout" from 3000 to 10000. That same change should also
be done for your old 12.04 setup - it should make tuning work faster
there too.

It looks like we need to see full logs of what is going on. So you
will probably need to set the "-v record" log option on mythbackend.
In 16.04, to work with systemd, that is done in a different way from
previously. In the /etc/mythtv directory, create a file
"additional.args" if it does not exist. Give it mythtv group and user
(chown mythtv:mythtv additional.args). Change its permissions to make
it only writeable by its user (chmod a=r,u=rw additional.args). In
that file, you put one line with additional arguments that get added
on to the end of the mythbackend command line, so put the -v record
there.

Then restart mythbackend (systemctl restart mythtv-backend) and try
tuning a channel - one of the SD ones as they tune more easily, so
Prime or ChoiceTV are good ones to try. Then stop mythbackend
(systemctl stop mythtv-backend) and post a copy of the section of
/var/log/mythtv/mythbackend.log that contains all the output from just
that run of mythbackend. To find where a run of mythbackend starts in
the log, search for the text "mythbackend version:" which is on the
first line mythbackend logs when it starts. The last thing that
mythbackend logs when it shuts down is normally a line saying "Waiting
for threads to exit.". The log will likely be way too big to post in
an email, so putting it somewhere like pastebin.com is the way to go,
unless you have a web server of your own you can put it on.

_______________________________________________
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, 30 Jul 2016 15:46:45 +1200, you wrote:

>On Sat, 30 Jul 2016 11:02:35 +1200, you wrote:
>

>Then restart mythbackend (systemctl restart mythtv-backend) and try
>tuning a channel - one of the SD ones as they tune more easily, so
>Prime or ChoiceTV are good ones to try. Then stop mythbackend
>(systemctl stop mythtv-backend) and post a copy of the section of
>/var/log/mythtv/mythbackend.log that contains all the output from just
>that run of mythbackend. To find where a run of mythbackend starts in
>the log, search for the text "mythbackend version:" which is on the
>first line mythbackend logs when it starts. The last thing that
>mythbackend logs when it shuts down is normally a line saying "Waiting
>for threads to exit.". The log will likely be way too big to post in
>an email, so putting it somewhere like pastebin.com is the way to go,
>unless you have a web server of your own you can put it on.

I should have said how to tune a specific channel in LiveTV - go to
the Guide, select the channel you want, then M (Menu) => Watch This
Channel.

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

>
> It looks like I was wrong about where the problem lies. Since you
> have only one real tuner card, even though it has dual tuners, it will
> never move its address around. The HDHR tuners are Ethernet, so they
> do not show up as hardware devices in /dev/dvb. So there is no need
> for adapter_nr settings unless you ever add another standard tuner.
>
> The settings from the capturecard table look fine except for the
> channel_timeout value (3000), which is way too small for DVB-T here in
> New Zealand. In versions before 0.28, mythbackend recovered from that
> and managed to tune channels anyway, but took longer than necessary as
> it could retry several times. In 0.28, it can fail to ever tune
> properly, so those settings need to all be increased. I am using
> 10000 ms, and that seems to work well. TV3 can take between 7 and 8
> seconds to tune. However, that is unlikely to explain your symptoms,
> it is just another problem you would have had later in getting 16.04
> working properly. You change those values in mythtv-setup => Capture
> Cards. On each tuner there, on the first page of its settings, change
> the "Tuning timeout" from 3000 to 10000. That same change should also
> be done for your old 12.04 setup - it should make tuning work faster
> there too.
>
> It looks like we need to see full logs of what is going on. So you
> will probably need to set the "-v record" log option on mythbackend.
> In 16.04, to work with systemd, that is done in a different way from
> previously. In the /etc/mythtv directory, create a file
> "additional.args" if it does not exist. Give it mythtv group and user
> (chown mythtv:mythtv additional.args). Change its permissions to make
> it only writeable by its user (chmod a=r,u=rw additional.args). In
> that file, you put one line with additional arguments that get added
> on to the end of the mythbackend command line, so put the -v record
> there.
>
> Then restart mythbackend (systemctl restart mythtv-backend) and try
> tuning a channel - one of the SD ones as they tune more easily, so
> Prime or ChoiceTV are good ones to try. Then stop mythbackend
> (systemctl stop mythtv-backend) and post a copy of the section of
> /var/log/mythtv/mythbackend.log that contains all the output from just
> that run of mythbackend. To find where a run of mythbackend starts in
> the log, search for the text "mythbackend version:" which is on the
> first line mythbackend logs when it starts. The last thing that
> mythbackend logs when it shuts down is normally a line saying "Waiting
> for threads to exit.". The log will likely be way too big to post in
> an email, so putting it somewhere like pastebin.com is the way to go,
> unless you have a web server of your own you can put it on.
>

I started on this again this morning but was interrupted by a 5 hour
powercut.
First I changed tuning timeout from 3000 to 10000 as suggested and then
created the additional.args file.
I selected a program in the guide and chose the "watch" option and the
tuner worked perfectly.
Then I selected "record" and that works too.I did this several times and
it seems ok now.It was using the tuner card not the HDHR.
I wonder if the tuning timeout was responsible for this.
I will do some more testing over the next few days.I have a copy of
mythbackend.log on google drive,the link below should allow you to access
it.
https://drive.google.com/open?id=0B5RRWPLTmilhVHdKN29obmpBWUU

There may be messages relating to the recordings database due to switching
the drive between the 2 OS versions.

One more question you may be able to answer: When I boot the system I get
mythbackend settings utility starting (every time) what do I do to stop
this?

I got more familiar with navigating mysql too :)

Thanks for the help.

On Sun, 31 Jul 2016 15:59:15 +1200, you wrote:


>I started on this again this morning but was interrupted by a 5 hour
>powercut.
>First I changed tuning timeout from 3000 to 10000 as suggested and then
>created the additional.args file.
>I selected a program in the guide and chose the "watch" option and the
>tuner worked perfectly.
>Then I selected "record" and that works too.I did this several times and
>it seems ok now.It was using the tuner card not the HDHR.
>I wonder if the tuning timeout was responsible for this.
>I will do some more testing over the next few days.I have a copy of
>mythbackend.log on google drive,the link below should allow you to access
>it.
>https://drive.google.com/open?id=0B5RRWPLTmilhVHdKN29obmpBWUU
>
>There may be messages relating to the recordings database due to switching
>the drive between the 2 OS versions.

That all seems fine - a normal LiveTV session. So I am wondering if
your original problem may have been caused by a bad chanid as the
DefaultChanid setting. That is the channel that is tuned when you go
to Watch TV from the main menu. If you do not use Live TV much, you
can have a problem where the channel that was last watched has
disappeared from the database since then, due to the usual churn of
channels. MythTV does not check for that and just tries to tune
whatever channel is in the DefaultChanid setting. And on deleting a
channel, it does not check DefaultChanid to see if it is set to the
deleted channel. Going to Live TV by selecting a channel from the
Guide gets around the bad DefaultChanid problem, if it exists.

>One more question you may be able to answer: When I boot the system I get
>mythbackend settings utility starting (every time) what do I do to stop
>this?

This is likely the fix:

https://ubuntuforums.org/showthread.php?t=2329744

But there may be an underlying problem as I thought that Mythbuntu was
supposed to remove that autostart entry automatically when the
configuration was updated and mythbackend was able to be started. I
have never found any script that would do that though.

>I got more familiar with navigating mysql too :)
>
>Thanks for the help.

_______________________________________________
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 Sun, 31 Jul 2016 21:02:01 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Sun, 31 Jul 2016 15:59:15 +1200, you wrote:
>
>
>> I started on this again this morning but was interrupted by a 5 hour
>> powercut.
>> First I changed tuning timeout from 3000 to 10000 as suggested and then
>> created the additional.args file.
>> I selected a program in the guide and chose the "watch" option and the
>> tuner worked perfectly.
>> Then I selected "record" and that works too.I did this several times and
>> it seems ok now.It was using the tuner card not the HDHR.
>> I wonder if the tuning timeout was responsible for this.
>> I will do some more testing over the next few days.I have a copy of
>> mythbackend.log on google drive,the link below should allow you toaccess
>> it.
>> https://drive.google.com/open?id=0B5RRWPLTmilhVHdKN29obmpBWUU
>>
>> There may be messages relating to the recordings database due to
>> switching
>> the drive between the 2 OS versions.
>
> That all seems fine - a normal LiveTV session. So I am wondering if
> your original problem may have been caused by a bad chanid as the
> DefaultChanid setting. That is the channel that is tuned when you go
> to Watch TV from the main menu. If you do not use Live TV much, you
> can have a problem where the channel that was last watched has
> disappeared from the database since then, due to the usual churn of
> channels. MythTV does not check for that and just tries to tune
> whatever channel is in the DefaultChanid setting. And on deleting a
> channel, it does not check DefaultChanid to see if it is set to the
> deleted channel. Going to Live TV by selecting a channel from the
> Guide gets around the bad DefaultChanid problem, if it exists.
>
>> One more question you may be able to answer: When I boot the system Iget
>> mythbackend settings utility starting (every time) what do I do to stop
>> this?
>
> This is likely the fix:
>
> https://ubuntuforums.org/showthread.php?t=2329744
>
> But there may be an underlying problem as I thought that Mythbuntu was
> supposed to remove that autostart entry automatically when the
> configuration was updated and mythbackend was able to be started. I
> have never found any script that would do that though.
>
>> I got more familiar with navigating mysql too :)
>>
>> Thanks for the help.
>

The tuner problem is intermittent.Today it's back.I can't see the cause in
the logs.
Here's a link to a new mythbackend log
https://drive.google.com/open?id=0B5RRWPLTmilhZ2lzSHFUZjdsSUk
At 10:33 I selected a channel to watch live from the guide.
At 10:34 I selected to record that channel
PS The tip from the forum thread corrected the settings utility start
issue.

On Mon, 01 Aug 2016 12:24:30 +1200, you wrote:

>The tuner problem is intermittent.Today it's back.I can't see the cause in
>the logs.
>Here's a link to a new mythbackend log
>https://drive.google.com/open?id=0B5RRWPLTmilhZ2lzSHFUZjdsSUk
>At 10:33 I selected a channel to watch live from the guide.
>At 10:34 I selected to record that channel
>PS The tip from the forum thread corrected the settings utility start
>issue.

Tuner [31] is one of the HDHR tuners. The one that was working in the
last log you posted was [17], one of the internal tuners.

This seems to be the relevant log message - there is one for each time
a tuner failure occurs:

Aug 1 10:33:11 myth mythbackend: mythbackend[2589]: E TVRecEvent
dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
Unknown tuner type = 0xffffffff80000000

"Unknown tuner type" seems to be the heart of the problem. It looks
like you need to set up something more to get the HDHR tuners working.
Do they work using their setup program? Is your networking setup
different on 16.04 from what it was on 12.04?

You may need to delete the HDHR tuners and re-create them.

You also need to test each tuner individually. The way to do that is
to use Watch TV, and once you have a channel playing, you can swap to
another tuner using M (menu) => Source => Switch Input and then select
the multi-rec tuner you want to watch. LiveTV will switch to the
specified tuner and tune it to the channel it was last on, which is
stored in the cardinput.startchan field. If you then type another
channel number, the current tuner will switch to that channel, but
only if it is capable of tuning to that channel. So if you have both
DVB-T and DVB-S tuners, if you try to tell a DVB-T tuner to tune to a
DVB-S channel, LiveTV knows that and will automatically switch to the
first available DVB-S tuner and tune that to the DVB-S channel. As
long as you keep changing to channels the tuner is capable of tuning,
a LiveTV session will keep using the same tuner, which is good for
what we want to do, testing each tuner.

So to fully test all your tuners, you need to use the Switch Input
option to change to one multi-rec tuner on each of your physical
tuners, then select a channel from each of the muxes so it will try
tuning each mux frequency. I normally use TV One (1), TV3 (3), Prime
(10) and HGTV (17) to test each mux here on Wharite, but on some
different transmitter sites, it may be that the arrangement of
channels on each mux means you need to chose different channels. It
pays to test with the highest bit rate channel on each mux, if there
is one, as that is the hardest one to tune to. Test each physical
tuner on all four muxes in turn and see if they all work, or what does
not work.

But also, in the log you posted, why was mythbackend trying to tune on
[31] when [17] presumably was not busy? What order have you got set
for your tuners? Use this query:

select
cardid,parentid,videodevice,cardtype,startchan,displayname,schedorder,livetvorder
from capturecard order by videodevice;

to see what the schedorder and livetvorder are set to. The schedorder
determines which tuners are used first for scheduled recordings, and
the livetvorder determines which are used first for LiveTV.

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

> Tuner [31] is one of the HDHR tuners. The one that was working in the
> last log you posted was [17], one of the internal tuners.
>
> This seems to be the relevant log message - there is one for each time
> a tuner failure occurs:
>
> Aug 1 10:33:11 myth mythbackend: mythbackend[2589]: E TVRecEvent
> dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
> Unknown tuner type = 0xffffffff80000000
>
> "Unknown tuner type" seems to be the heart of the problem. It looks
> like you need to set up something more to get the HDHR tuners working.
> Do they work using their setup program? Is your networking setup
> different on 16.04 from what it was on 12.04?
>
> You may need to delete the HDHR tuners and re-create them.
>
> You also need to test each tuner individually. The way to do that is
> to use Watch TV, and once you have a channel playing, you can swap to
> another tuner using M (menu) => Source => Switch Input and then select
> the multi-rec tuner you want to watch. LiveTV will switch to the
> specified tuner and tune it to the channel it was last on, which is
> stored in the cardinput.startchan field. If you then type another
> channel number, the current tuner will switch to that channel, but
> only if it is capable of tuning to that channel. So if you have both
> DVB-T and DVB-S tuners, if you try to tell a DVB-T tuner to tune to a
> DVB-S channel, LiveTV knows that and will automatically switch to the
> first available DVB-S tuner and tune that to the DVB-S channel. As
> long as you keep changing to channels the tuner is capable of tuning,
> a LiveTV session will keep using the same tuner, which is good for
> what we want to do, testing each tuner.
>
> So to fully test all your tuners, you need to use the Switch Input
> option to change to one multi-rec tuner on each of your physical
> tuners, then select a channel from each of the muxes so it will try
> tuning each mux frequency. I normally use TV One (1), TV3 (3), Prime
> (10) and HGTV (17) to test each mux here on Wharite, but on some
> different transmitter sites, it may be that the arrangement of
> channels on each mux means you need to chose different channels. It
> pays to test with the highest bit rate channel on each mux, if there
> is one, as that is the hardest one to tune to. Test each physical
> tuner on all four muxes in turn and see if they all work, or what does
> not work.
>
> But also, in the log you posted, why was mythbackend trying to tune on
> [31] when [17] presumably was not busy? What order have you got set
> for your tuners? Use this query:
>
> select
> cardid,parentid,videodevice,cardtype,startchan,displayname,schedorder,livetvorder
> from capturecard order by videodevice;
>
> to see what the schedorder and livetvorder are set to. The schedorder
> determines which tuners are used first for scheduled recordings, and
> the livetvorder determines which are used first for LiveTV.
>
I have left the tuner order as it was in 12.04,all at 1 as it was working
ok.This may be the problem.
No hardware changes were made to the network or connections.

Here is the Mysql_information

I am unable to use Live TV to view and select tuners because it
immediately aborts.However I have confirmed a card tuner works with MeTV
software I have installed (MeTV doesn't appear to allow tuners to be
selected)and HDHR tuners work with the HDHR configure GUI( I have switched
HDHR Tuners).All MUXes work ok on both sets of tuners.
In FE Information Center > System Status > Tuner Status the HDHR tuners
are marked "Not Recording" and the card tuners are marked "Has an error"

I also have another problem you may like to comment on: I have enabled
Myth Welcome and I am fair sure it worked normally to start with.At the
moment,when the system boots it boots into the XFCE desktop not the
Welcome screen.Myth Welcome seems to be running because after the 5 minute
time out the system shutsdown.If I start Myth FE from the desktop it goes
to the Myth Welcome screen and I can start the FE from there.

Cheers

-Paul

On Tue, 02 Aug 2016 10:37:42 +1200
Paulgir <paulgir@gmail.com> wrote:

> ...
> I am unable to use Live TV to view and select tuners because it
> immediately aborts.However I have confirmed a card tuner works with MeTV
> software I have installed (MeTV doesn't appear to allow tuners to be
> selected)

Run me-tv with the --devices option to specify which card to use.
Try me-tv --help to see the format.

Austin.

_______________________________________________
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, 02 Aug 2016 11:01:05 +1200, Austin Green
<austin.green@orcon.net.nz> wrote:

> On Tue, 02 Aug 2016 10:37:42 +1200
> Paulgir <paulgir@gmail.com> wrote:
>
>> ...
>> I am unable to use Live TV to view and select tuners because it
>> immediately aborts.However I have confirmed a card tuner works with MeTV
>> software I have installed (MeTV doesn't appear to allow tuners to be
>> selected)
>
> Run me-tv with the --devices option to specify which card to use.
> Try me-tv --help to see the format.
>
> Austin.
>
Thanks,I will do that

_______________________________________________
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, 02 Aug 2016 10:37:42 +1200, you wrote:


>I have left the tuner order as it was in 12.04,all at 1 as it was working
>ok.This may be the problem.
>No hardware changes were made to the network or connections.
>
>Here is the Mysql_information
>
>I am unable to use Live TV to view and select tuners because it
>immediately aborts.However I have confirmed a card tuner works with MeTV
>software I have installed (MeTV doesn't appear to allow tuners to be
>selected)and HDHR tuners work with the HDHR configure GUI( I have switched
>HDHR Tuners).All MUXes work ok on both sets of tuners.
>In FE Information Center > System Status > Tuner Status the HDHR tuners
>are marked "Not Recording" and the card tuners are marked "Has an error"
>
>I also have another problem you may like to comment on: I have enabled
>Myth Welcome and I am fair sure it worked normally to start with.At the
>moment,when the system boots it boots into the XFCE desktop not the
>Welcome screen.Myth Welcome seems to be running because after the 5 minute
>time out the system shutsdown.If I start Myth FE from the desktop it goes
>to the Myth Welcome screen and I can start the FE from there.
>
>Cheers
>
>-Paul

Since the HDHR tuners are not working, with all the order settings at
1 MythTV is likely choosing to use a non-working HDHR tuner at least
50% of the time for LiveTV, and possibly all the time as it may be
choosing by lowest cardid number, which seems to be an HDHR. So to
get the two internal tuners working, I would recommend setting them as
1 and 2 in both schedorder and livetvorder, with the HDHRs set as 3
and 4. Once they are all working, you can consider how you really
want to order them. Some people prefer to have the livetvorder order
the opposite of the schedorder. I have them set up the same. They
are set up in mythtv-setup => Input Connections on the second page for
each tuner in the "Schedule order:" and "Live TV order:" fields.

Doing that should be sufficient to get you going on 16.04 with two
working tuners. Getting the HDHRs working would seem likely to be
some networking problem. I have never used one myself, so I am not
the best person to help with that, but I do have a lot of networking
experience. How are the HDHRs connected? Are they on a separate
Ethernet card on the MythTV box, or are they just on your main
network? Does the hdhomerun_config discover command see them? Does
the 16.04 setup see an Internet connection (ie is its networking
working)? Does it use DHCP or have a static address? Is there a
firewall installed?

Mythwelcome is another thing I have never used. I did run across
where it is started from in 16.04, which seems to be the file
/etc/mythtv/session-settings. You need to uncomment the
MYTHWELCOME=true line in there. Is that how you are running it? It
may have changed since 12.04.

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

>
> Since the HDHR tuners are not working, with all the order settings at
> 1 MythTV is likely choosing to use a non-working HDHR tuner at least
> 50% of the time for LiveTV, and possibly all the time as it may be
> choosing by lowest cardid number, which seems to be an HDHR. So to
> get the two internal tuners working, I would recommend setting them as
> 1 and 2 in both schedorder and livetvorder, with the HDHRs set as 3
> and 4. Once they are all working, you can consider how you really
> want to order them. Some people prefer to have the livetvorder order
> the opposite of the schedorder. I have them set up the same. They
> are set up in mythtv-setup => Input Connections on the second page for
> each tuner in the "Schedule order:" and "Live TV order:" fields.
>
> Doing that should be sufficient to get you going on 16.04 with two
> working tuners. Getting the HDHRs working would seem likely to be
> some networking problem. I have never used one myself, so I am not
> the best person to help with that, but I do have a lot of networking
> experience. How are the HDHRs connected? Are they on a separate
> Ethernet card on the MythTV box, or are they just on your main
> network? Does the hdhomerun_config discover command see them? Does
> the 16.04 setup see an Internet connection (ie is its networking
> working)? Does it use DHCP or have a static address? Is there a
> firewall installed?
>
> Mythwelcome is another thing I have never used. I did run across
> where it is started from in 16.04, which seems to be the file
> /etc/mythtv/session-settings. You need to uncomment the
> MYTHWELCOME=true line in there. Is that how you are running it? It
> may have changed since 12.04.
>

I there was a problem with the network connection to the HDHR,surely the
capture card setup tool would fail to scan and detect channels?
Likewise the card tuners.That tool seems to work fine.
Likewise the HDHR configure tool and MeTV would not work.
I changed the schedorder and livetvorder but that made no improvement.I
delected all tuners and set up just one and that did not work.

_______________________________________________
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 must say that given your tuner numbering, I suspect you have deleted and
added tuners a bit to get yourself in that state.

I would delete all tuners (delete all capture cards on system) and add them
back, the numbering will start at 1 again and produce a much cleaner and
better operating database. I have seen doing this recommended on
mythtv-user mailing list, and it worked for me when I had some similar
difficulties.

You will not have to retune as you just connect the new tuners to the
existing video sources, which you shouldn't need to delete.

On Wed, Aug 3, 2016 at 9:23 AM, Paulgir <paulgir@gmail.com> wrote:

>
>
>
>> Since the HDHR tuners are not working, with all the order settings at
>> 1 MythTV is likely choosing to use a non-working HDHR tuner at least
>> 50% of the time for LiveTV, and possibly all the time as it may be
>> choosing by lowest cardid number, which seems to be an HDHR. So to
>> get the two internal tuners working, I would recommend setting them as
>> 1 and 2 in both schedorder and livetvorder, with the HDHRs set as 3
>> and 4. Once they are all working, you can consider how you really
>> want to order them. Some people prefer to have the livetvorder order
>> the opposite of the schedorder. I have them set up the same. They
>> are set up in mythtv-setup => Input Connections on the second page for
>> each tuner in the "Schedule order:" and "Live TV order:" fields.
>>
>> Doing that should be sufficient to get you going on 16.04 with two
>> working tuners. Getting the HDHRs working would seem likely to be
>> some networking problem. I have never used one myself, so I am not
>> the best person to help with that, but I do have a lot of networking
>> experience. How are the HDHRs connected? Are they on a separate
>> Ethernet card on the MythTV box, or are they just on your main
>> network? Does the hdhomerun_config discover command see them? Does
>> the 16.04 setup see an Internet connection (ie is its networking
>> working)? Does it use DHCP or have a static address? Is there a
>> firewall installed?
>>
>> Mythwelcome is another thing I have never used. I did run across
>> where it is started from in 16.04, which seems to be the file
>> /etc/mythtv/session-settings. You need to uncomment the
>> MYTHWELCOME=true line in there. Is that how you are running it? It
>> may have changed since 12.04.
>>
>>
> I there was a problem with the network connection to the HDHR,surely the
> capture card setup tool would fail to scan and detect channels?
> Likewise the card tuners.That tool seems to work fine.
> Likewise the HDHR configure tool and MeTV would not work.
> I changed the schedorder and livetvorder but that made no improvement.I
> delected all tuners and set up just one and that did not work.
>
>
> _______________________________________________
> 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, 03 Aug 2016 10:31:29 +1200, Nick Rout <nick.rout@gmail.com> wrote:

> I must say that given your tuner numbering, I suspect you have deleted
> and added tuners a bit to get yourself in that state.
>
> I would delete all tuners (delete all capture cards on system) and add
> them back, the numbering will start at 1 again and produce a >much
> cleaner and better operating database. I have seen doing this
> recommended on mythtv-user mailing list, and it worked for me when >I
> had some similar difficulties.
>
> You will not have to retune as you just connect the new tuners to the
> existing video sources, which you shouldn't need to delete.
>
> On Wed, Aug 3, 2016 at 9:23 AM, Paulgir <paulgir@gmail.com> wrote:
>>
Actually,I didn't,I just restored the database backup from the 12.04
installation.The tuner numbering is as it is on 12.04 and 12.04 still
works fine.
I'm deleted capture cards for the xth time and video sources and issued
the mysql commands below:
> truncate table capturecard;
> truncate table cardinput;
> quit;

and re-doing the setup.I don't expect it will rectify the problem.

On Wed, 03 Aug 2016 10:31:29 +1200, Nick Rout <nick.rout@gmail.com> wrote:

> I must say that given your tuner numbering, I suspect you have deleted
> and added tuners a bit to get yourself in that state.
>
> I would delete all tuners (delete all capture cards on system) and add
> them back, the numbering will start at 1 again and produce a >much
> cleaner and better operating database. I have seen doing this
> recommended on mythtv-user mailing list, and it worked for me when >I
> had some similar difficulties.
>
> You will not have to retune as you just connect the new tuners to the
> existing video sources, which you shouldn't need to delete.
>
> On Wed, Aug 3, 2016 at 9:23 AM, Paulgir <paulgir@gmail.com> wrote:
>>
>>
That failed as expected.
Is there a way to revert to a pristine database? i.e. the state that a
fresh install has.

>
> That failed as expected.
>>
> Is there a way to revert to a pristine database? i.e. the state that a
> fresh install has.
>

I just bit the bullet and decided that I had already watched want I was
going to watch on my old system (admittedly it was only a few months old)
and I did a fresh installation.

The old recordings are still available on their own partition just not
available from "Recordings" in MythTV
--
Robert Fisher

On Wed, 03 Aug 2016 11:15:04 +1200, Robert Fisher <robert@fisher.net.nz>
wrote:

>>>> That failed as expected.
>> Is there a way to revert to a pristine database? i.e. the state that a
>> fresh install has.
>
> I just bit the bullet and decided that I had already watched want I was
> going to watch on my old system (admittedly it was only a few >months
> old) and I did a fresh installation.
>
> The old recordings are still available on their own partition just not
> available from "Recordings" in MythTV
> --Robert Fisher

Yes ,I expect a reinstall is due I will transfer existing recordings into
the videos directory

On Wed, 03 Aug 2016 10:43:32 +1200, you wrote:

>On Wed, 03 Aug 2016 10:31:29 +1200, Nick Rout <nick.rout@gmail.com> wrote:
>
>> I must say that given your tuner numbering, I suspect you have deleted
>> and added tuners a bit to get yourself in that state.
>>
>> I would delete all tuners (delete all capture cards on system) and add
>> them back, the numbering will start at 1 again and produce a >much
>> cleaner and better operating database. I have seen doing this
>> recommended on mythtv-user mailing list, and it worked for me when >I
>> had some similar difficulties.
>>
>> You will not have to retune as you just connect the new tuners to the
>> existing video sources, which you shouldn't need to delete.
>>
>> On Wed, Aug 3, 2016 at 9:23 AM, Paulgir <paulgir@gmail.com> wrote:
>>>
>Actually,I didn't,I just restored the database backup from the 12.04
>installation.The tuner numbering is as it is on 12.04 and 12.04 still
>works fine.
>I'm deleted capture cards for the xth time and video sources and issued
>the mysql commands below:
>> truncate table capturecard;
>> truncate table cardinput;
>> quit;
>
>and re-doing the setup.I don't expect it will rectify the problem.

That is not the right way to delete all tuners. Sometimes there are
other things that need to be changed in the database when you delete
things that MythTV will do for you automatically. Just truncating a
table will not make those things happen. In this case, mythtv-setup
has a "Delete all tuners" option that is the right way to do it, and
will do any necessary cleanup. There are two delete options, one for
all tuners on one host, and one for all tuners. Use the one for all
tuners, as it does special cleanup to ensure that the tuner system is
ready to be recreated from scratch. For example, it will also delete
all the channelscan_* table entries.

When having tuner problems like yours, it is recommended by the devs
to do a full delete like that before recreating all the tuners again.
I have never done it, so I do not know if you also lose all the
channel setup, but since you are just trying things on the 16.04 setup
and still have the 12.04 to fall back to, I think it is about time to
try that, if you have not done it already.

What I normally do when I am going to set up a new system and then
move my database onto it is to first start with an empty database and
do the initial setup (including tuners and channels, but not xmltvids
and EPG). Then test the setup to make sure all the tuners work and so
on. If you want to try that, then you can empty the database and
re-create it. The way to do that is first shut down mythbackend
(systemctl stop mythtv-backend), then go into mysql and do these
commands:

drop database mythconverg;
source /usr/share/mythtv/sql/mc.sql

The source command reads a set of SQL commands from that file, which
looks like this:

CREATE DATABASE IF NOT EXISTS mythconverg;
GRANT ALL ON mythconverg.* TO mythtv@localhost IDENTIFIED BY "mythtv";
FLUSH PRIVILEGES;
GRANT CREATE TEMPORARY TABLES ON mythconverg.* TO mythtv@localhost
IDENTIFIED BY "mythtv";
FLUSH PRIVILEGES;
ALTER DATABASE mythconverg DEFAULT CHARACTER SET utf8 COLLATE
utf8_general_ci;

If you need external access to the database for non-local frontends,
then you need to also do the GRANT commands for that. It might be an
idea to create a copy of the mc.sql file with the additional grant
commands, for later reference if you ever need to do this again. I
have one, which also has a "DROP DATABASE IF EXISTS mythconverg;"
command at the start.

The rest of the database creation is done automatically by
mythtv-setup or mythbackend when they start up and see an empty
database. So next, just run mythtv-setup and start configuring your
tuners.

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

>> Actually,I didn't,I just restored the database backup from the 12.04
>> installation.The tuner numbering is as it is on 12.04 and 12.04 still
>> works fine.
>> I'm deleted capture cards for the xth time and video sources and issued
>> the mysql commands below:
>>> truncate table capturecard;
>>> truncate table cardinput;
>>> quit;
>>
>> and re-doing the setup.I don't expect it will rectify the problem.
>
> That is not the right way to delete all tuners. Sometimes there are
> other things that need to be changed in the database when you delete
> things that MythTV will do for you automatically. Just truncating a
> table will not make those things happen. In this case, mythtv-setup
> has a "Delete all tuners" option that is the right way to do it, and
> will do any necessary cleanup. There are two delete options, one for
> all tuners on one host, and one for all tuners. Use the one for all
> tuners, as it does special cleanup to ensure that the tuner system is
> ready to be recreated from scratch. For example, it will also delete
> all the channelscan_* table entries.
>
> When having tuner problems like yours, it is recommended by the devs
> to do a full delete like that before recreating all the tuners again.
> I have never done it, so I do not know if you also lose all the
> channel setup, but since you are just trying things on the 16.04 setup
> and still have the 12.04 to fall back to, I think it is about time to
> try that, if you have not done it already.
>
> What I normally do when I am going to set up a new system and then
> move my database onto it is to first start with an empty database and
> do the initial setup (including tuners and channels, but not xmltvids
> and EPG). Then test the setup to make sure all the tuners work and so
> on. If you want to try that, then you can empty the database and
> re-create it. The way to do that is first shut down mythbackend
> (systemctl stop mythtv-backend), then go into mysql and do these
> commands:
>
> drop database mythconverg;
> source /usr/share/mythtv/sql/mc.sql
>
> The source command reads a set of SQL commands from that file, which
> looks like this:
>
> CREATE DATABASE IF NOT EXISTS mythconverg;
> GRANT ALL ON mythconverg.* TO mythtv@localhost IDENTIFIED BY "mythtv";
> FLUSH PRIVILEGES;
> GRANT CREATE TEMPORARY TABLES ON mythconverg.* TO mythtv@localhost
> IDENTIFIED BY "mythtv";
> FLUSH PRIVILEGES;
> ALTER DATABASE mythconverg DEFAULT CHARACTER SET utf8 COLLATE
> utf8_general_ci;
>
> If you need external access to the database for non-local frontends,
> then you need to also do the GRANT commands for that. It might be an
> idea to create a copy of the mc.sql file with the additional grant
> commands, for later reference if you ever need to do this again. I
> have one, which also has a "DROP DATABASE IF EXISTS mythconverg;"
> command at the start.
>
> The rest of the database creation is done automatically by
> mythtv-setup or mythbackend when they start up and see an empty
> database. So next, just run mythtv-setup and start configuring your
> tuners.
>

I did delete all tuners etc. via the BE setup prior to issuing the mysql
truncate commands.
I did do the drop database mythconverg; source
/usr/share/mythtv/sql/mc.sql
And that did not help but I may have repeated the original error.

I agree that your process for a new install is preferable to my immediate
restore of an old db.I will follow that after I pursue one more lead that
has shown up.

Cheers

_______________________________________________
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, 03 Aug 2016 15:36:34 +1200, you wrote:

>
>
>>> Actually,I didn't,I just restored the database backup from the 12.04
>>> installation.The tuner numbering is as it is on 12.04 and 12.04 still
>>> works fine.
>>> I'm deleted capture cards for the xth time and video sources and issued
>>> the mysql commands below:
>>>> truncate table capturecard;
>>>> truncate table cardinput;
>>>> quit;
>>>
>>> and re-doing the setup.I don't expect it will rectify the problem.
>>
>> That is not the right way to delete all tuners. Sometimes there are
>> other things that need to be changed in the database when you delete
>> things that MythTV will do for you automatically. Just truncating a
>> table will not make those things happen. In this case, mythtv-setup
>> has a "Delete all tuners" option that is the right way to do it, and
>> will do any necessary cleanup. There are two delete options, one for
>> all tuners on one host, and one for all tuners. Use the one for all
>> tuners, as it does special cleanup to ensure that the tuner system is
>> ready to be recreated from scratch. For example, it will also delete
>> all the channelscan_* table entries.
>>
>> When having tuner problems like yours, it is recommended by the devs
>> to do a full delete like that before recreating all the tuners again.
>> I have never done it, so I do not know if you also lose all the
>> channel setup, but since you are just trying things on the 16.04 setup
>> and still have the 12.04 to fall back to, I think it is about time to
>> try that, if you have not done it already.
>>
>> What I normally do when I am going to set up a new system and then
>> move my database onto it is to first start with an empty database and
>> do the initial setup (including tuners and channels, but not xmltvids
>> and EPG). Then test the setup to make sure all the tuners work and so
>> on. If you want to try that, then you can empty the database and
>> re-create it. The way to do that is first shut down mythbackend
>> (systemctl stop mythtv-backend), then go into mysql and do these
>> commands:
>>
>> drop database mythconverg;
>> source /usr/share/mythtv/sql/mc.sql
>>
>> The source command reads a set of SQL commands from that file, which
>> looks like this:
>>
>> CREATE DATABASE IF NOT EXISTS mythconverg;
>> GRANT ALL ON mythconverg.* TO mythtv@localhost IDENTIFIED BY "mythtv";
>> FLUSH PRIVILEGES;
>> GRANT CREATE TEMPORARY TABLES ON mythconverg.* TO mythtv@localhost
>> IDENTIFIED BY "mythtv";
>> FLUSH PRIVILEGES;
>> ALTER DATABASE mythconverg DEFAULT CHARACTER SET utf8 COLLATE
>> utf8_general_ci;
>>
>> If you need external access to the database for non-local frontends,
>> then you need to also do the GRANT commands for that. It might be an
>> idea to create a copy of the mc.sql file with the additional grant
>> commands, for later reference if you ever need to do this again. I
>> have one, which also has a "DROP DATABASE IF EXISTS mythconverg;"
>> command at the start.
>>
>> The rest of the database creation is done automatically by
>> mythtv-setup or mythbackend when they start up and see an empty
>> database. So next, just run mythtv-setup and start configuring your
>> tuners.
>>
>
>I did delete all tuners etc. via the BE setup prior to issuing the mysql
>truncate commands.
>I did do the drop database mythconverg; source
>/usr/share/mythtv/sql/mc.sql
>And that did not help but I may have repeated the original error.
>
>I agree that your process for a new install is preferable to my immediate
>restore of an old db.I will follow that after I pursue one more lead that
>has shown up.
>
>Cheers

If the HDHRs are still not working, you could install Wireshark and
capture all the traffic to them from MythTV. That might give us some
clues as to what the problem is. And do a separate capture of the
traffic when they work using their setup tools or me-tv, for
comparison purposes.

_______________________________________________
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 03/08/16 14:05, Paulgir wrote:
>
> Yes ,I expect a reinstall is due I will transfer existing recordings
> into the videos directory
>
There were still a couple of "gotchas" with the latest MythBuntu 16.04
but it is running well now.

--
Robert

>>
>> I did delete all tuners etc. via the BE setup prior to issuing the mysql
>> truncate commands.
>> I did do the drop database mythconverg; source
>> /usr/share/mythtv/sql/mc.sql
>> And that did not help but I may have repeated the original error.
>>
>> I agree that your process for a new install is preferable to my
>> immediate
>> restore of an old db.I will follow that after I pursue one more lead
>> that
>> has shown up.
>>
>> Cheers
>
> If the HDHRs are still not working, you could install Wireshark and
> capture all the traffic to them from MythTV. That might give us some
> clues as to what the problem is. And do a separate capture of the
> traffic when they work using their setup tools or me-tv, for
> comparison purposes.
>

I'm just checking the functionality of my tuners again because it appears
that in MeTV I get an error if I select /dev/dvb/adapter0/frontend0 on
both the 12.04 and 16.04 installs.
These are the MeTV messages:

04/08/16 09:52:26: Not currently displaying 'TV ONE'
04/08/16 09:52:26: Exception: Failed to get available frontend
4/08/16 09:51:25: Exception: Frontend read failed
(/dev/dvb/adapter0/frontend0): Value too large for defined data type

Also, I have a bug in 12.04 that won't let me switch sources in live TV
(HDHR or PCIe card tuners).The system locks up.
So what I did to check if the Card tuner wasn't half dead was to reduce
the number of tuners per device to 1 and record 4 programs from the 3
MUXs.The tuners did all 4 successfully. Therefore I assume the 2 tuners in
the card are ok as are the 2 in the HDHR.
Is my logic correct?

Cheers
-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 Thu, Aug 4, 2016 at 10:27 AM, Paulgir <paulgir@gmail.com> wrote:

>
>
>
>>> I did delete all tuners etc. via the BE setup prior to issuing the mysql
>>> truncate commands.
>>> I did do the drop database mythconverg; source
>>> /usr/share/mythtv/sql/mc.sql
>>> And that did not help but I may have repeated the original error.
>>>
>>> I agree that your process for a new install is preferable to my immediate
>>> restore of an old db.I will follow that after I pursue one more lead that
>>> has shown up.
>>>
>>> Cheers
>>>
>>
>> If the HDHRs are still not working, you could install Wireshark and
>> capture all the traffic to them from MythTV. That might give us some
>> clues as to what the problem is. And do a separate capture of the
>> traffic when they work using their setup tools or me-tv, for
>> comparison purposes.
>>
>>
> I'm just checking the functionality of my tuners again because it appears
> that in MeTV I get an error if I select /dev/dvb/adapter0/frontend0 on both
> the 12.04 and 16.04 installs.
> These are the MeTV messages:
>
> 04/08/16 09:52:26: Not currently displaying 'TV ONE'
> 04/08/16 09:52:26: Exception: Failed to get available frontend
> 4/08/16 09:51:25: Exception: Frontend read failed
> (/dev/dvb/adapter0/frontend0): Value too large for defined data type
>
> Also, I have a bug in 12.04 that won't let me switch sources in live TV
> (HDHR or PCIe card tuners).The system locks up.
> So what I did to check if the Card tuner wasn't half dead was to reduce
> the number of tuners per device to 1 and record 4 programs from the 3
> MUXs.The tuners did all 4 successfully. Therefore I assume the 2 tuners in
> the card are ok as are the 2 in the HDHR.
> Is my logic correct?
>

No, you only need 3 tuners to get 3 muxes. The backend log will tell you
which tuner was used for each recording.



>
> Cheers
> -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/
>

O
If the HDHRs are still not working, you could install Wireshark and
capture all the traffic to them from MythTV. That might give us some
clues as to what the problem is. And do a separate capture of the
traffic when they work using their setup tools or me-tv, for
comparison purposes.

>>
>>>> I'm just checking the functionality of my tuners again because it
>>>> appears that in MeTV I get an error if I select
>>>> /dev/dvb/adapter0/>>frontend0 on both the 12.04 and 16.04 installs.
>> These are the MeTV messages:
>>
>> 04/08/16 09:52:26: Not currently displaying 'TV ONE'
>> 04/08/16 09:52:26: Exception: Failed to get available frontend
>> 4/08/16 09:51:25: Exception: Frontend read failed
>> (/dev/dvb/adapter0/frontend0): Value too large for defined data type
>>
>> Also, I have a bug in 12.04 that won't let me switch sources in live TV
>> (HDHR or PCIe card tuners).The system locks up.
>> So what I did to check if the Card tuner wasn't half dead was to reduce
>> the number of tuners per device to 1 and record 4 programs >>from the 3
>> MUXs.The tuners did all 4 successfully. Therefore I assume the 2 tuners
>> in the card are ok as are the 2 in the HDHR.
>> Is my logic correct?
>
> No, you only need 3 tuners to get 3 muxes. The backend log will tell you
> which tuner was used for each recording.
>
>
>>
Won't setting the number of tuners (virtual) to 1 force the use of 4
hardware tuners to tune 4 programmes?

On Thu, Aug 4, 2016 at 12:51 PM, Paulgir <paulgir@gmail.com> wrote:

>
> O
> If the HDHRs are still not working, you could install Wireshark and
> capture all the traffic to them from MythTV. That might give us some
> clues as to what the problem is. And do a separate capture of the
> traffic when they work using their setup tools or me-tv, for
> comparison purposes.
>
>
>> I'm just checking the functionality of my tuners again because it appears
>> that in MeTV I get an error if I select /dev/dvb/adapter0/frontend0 on both
>> the 12.04 and 16.04 installs.
>> These are the MeTV messages:
>>
>> 04/08/16 09:52:26: Not currently displaying 'TV ONE'
>> 04/08/16 09:52:26: Exception: Failed to get available frontend
>> 4/08/16 09:51:25: Exception: Frontend read failed
>> (/dev/dvb/adapter0/frontend0): Value too large for defined data type
>>
>> Also, I have a bug in 12.04 that won't let me switch sources in live TV
>> (HDHR or PCIe card tuners).The system locks up.
>> So what I did to check if the Card tuner wasn't half dead was to reduce
>> the number of tuners per device to 1 and record 4 programs from the 3
>> MUXs.The tuners did all 4 successfully. Therefore I assume the 2 tuners in
>> the card are ok as are the 2 in the HDHR.
>> Is my logic correct?
>>
>
> No, you only need 3 tuners to get 3 muxes. The backend log will tell you
> which tuner was used for each recording.
>
>
>
>>
>> Won't setting the number of tuners (virtual) to 1 force the use of 4
> hardware tuners to tune 4 programmes?
>

Sorry i missed that part. Yes that is right. However to check which tuner
was used, check the log.



>
>
>
>
> _______________________________________________
> 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, 04 Aug 2016 10:27:12 +1200, you wrote:

>
>
>>>
>>> I did delete all tuners etc. via the BE setup prior to issuing the mysql
>>> truncate commands.
>>> I did do the drop database mythconverg; source
>>> /usr/share/mythtv/sql/mc.sql
>>> And that did not help but I may have repeated the original error.
>>>
>>> I agree that your process for a new install is preferable to my
>>> immediate
>>> restore of an old db.I will follow that after I pursue one more lead
>>> that
>>> has shown up.
>>>
>>> Cheers
>>
>> If the HDHRs are still not working, you could install Wireshark and
>> capture all the traffic to them from MythTV. That might give us some
>> clues as to what the problem is. And do a separate capture of the
>> traffic when they work using their setup tools or me-tv, for
>> comparison purposes.
>>
>
>I'm just checking the functionality of my tuners again because it appears
>that in MeTV I get an error if I select /dev/dvb/adapter0/frontend0 on
>both the 12.04 and 16.04 installs.
>These are the MeTV messages:
>
>04/08/16 09:52:26: Not currently displaying 'TV ONE'
>04/08/16 09:52:26: Exception: Failed to get available frontend
>4/08/16 09:51:25: Exception: Frontend read failed
>(/dev/dvb/adapter0/frontend0): Value too large for defined data type
>
>Also, I have a bug in 12.04 that won't let me switch sources in live TV
>(HDHR or PCIe card tuners).The system locks up.
>So what I did to check if the Card tuner wasn't half dead was to reduce
>the number of tuners per device to 1 and record 4 programs from the 3
>MUXs.The tuners did all 4 successfully. Therefore I assume the 2 tuners in
>the card are ok as are the 2 in the HDHR.
>Is my logic correct?
>
>Cheers
>-Paul

As Nick said, to be sure you have to check the mythbackend.log versus
the capturecard table cardid numbers to see which tuner numbers were
actually used.

BTW There are now four muxes.

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

Also, I have a bug in 12.04 that won't let me switch sources in live TV
(HDHR or PCIe card tuners).The system locks up.
So what I did to check if the Card tuner wasn't half dead was to reduce
the number of tuners per device to 1 and record 4 programs from the 3
MUXs.The tuners did all 4 successfully. Therefore I assume the 2 tuners in
the card are ok as are the 2 in the HDHR.
Is my logic correct?
>>
>>>>>> No, you only need 3 tuners to get 3 muxes. The backend log will
>>>>>> tell you which tuner was used for each recording.
>>>
>>>
>>>>
>> Won't setting the number of tuners (virtual) to 1 force the use of 4
>> hardware tuners to tune 4 programmes?
>
> Sorry i missed that part. Yes that is right. However to check which
> tuner was used, check the log.
>
>

Quick question: in Backend Setup > Input Connections > Interactions
Between Inputs,should I create a new input group for each tuner or leave
it as Generic?
I am using only Freeview

Cheers

On Thu, 04 Aug 2016 14:58:55 +1200, you wrote:

>
>
>
>Also, I have a bug in 12.04 that won't let me switch sources in live TV
>(HDHR or PCIe card tuners).The system locks up.
>So what I did to check if the Card tuner wasn't half dead was to reduce
>the number of tuners per device to 1 and record 4 programs from the 3
>MUXs.The tuners did all 4 successfully. Therefore I assume the 2 tuners in
>the card are ok as are the 2 in the HDHR.
>Is my logic correct?
>>>
>>>>>>> No, you only need 3 tuners to get 3 muxes. The backend log will
>>>>>>> tell you which tuner was used for each recording.
>>>>
>>>>
>>>>>
>>> Won't setting the number of tuners (virtual) to 1 force the use of 4
>>> hardware tuners to tune 4 programmes?
>>
>> Sorry i missed that part. Yes that is right. However to check which
>> tuner was used, check the log.
>>
>>
>
>Quick question: in Backend Setup > Input Connections > Interactions
>Between Inputs,should I create a new input group for each tuner or leave
>it as Generic?
>I am using only Freeview
>
>Cheers

Input groups are only needed when there is mutually exclusive use of
hardware, to tell MythTV that two pieces of hardware can not be used
at the same time. The usual example was the tuner cards you used to
get that did DVB-T and analogue but only one or the other and not both
at the same time. But they produced separate tuner devices in Linux
with separate drivers running them. So you had to put each analogue
tuner in the same input group as its counterpart DVB-T tuner. Your
HVR-2200 card is that sort of card, but even then, unless you are
configuring and using the analogue inputs in MythTV, there is no need
to set up input groups for its tuners. The best thing with input
groups is to leave them at their defaults unless you really need to
use them.

If you do need to use input groups, you need to know which analogue
tuner matches which DVB-T tuner, and make sure that the matching
tuners have the same input group, and that input group name is not the
same as any other input group name on any other tuner. The actual
content of the name you choose is irrelevant, but choosing a good name
helps to understand what it is doing when you come back to it later.

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

> Input groups are only needed when there is mutually exclusive use of
> hardware, to tell MythTV that two pieces of hardware can not be used
> at the same time. The usual example was the tuner cards you used to
> get that did DVB-T and analogue but only one or the other and not both
> at the same time. But they produced separate tuner devices in Linux
> with separate drivers running them. So you had to put each analogue
> tuner in the same input group as its counterpart DVB-T tuner. Your
> HVR-2200 card is that sort of card, but even then, unless you are
> configuring and using the analogue inputs in MythTV, there is no need
> to set up input groups for its tuners. The best thing with input
> groups is to leave them at their defaults unless you really need to
> use them.
>
> If you do need to use input groups, you need to know which analogue
> tuner matches which DVB-T tuner, and make sure that the matching
> tuners have the same input group, and that input group name is not the
> same as any other input group name on any other tuner. The actual
> content of the name you choose is irrelevant, but choosing a good name
> helps to understand what it is doing when you come back to it later.
>

I'm re-installed everything and set up the backend manually.I'm still in
the same situation.No tuners will allow viewing or recording.
I've deleted the tuners and set them up again to no avail.
Here is a few lines from backend log

Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
WatchingLiveTV
Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
Unknown tuner type = 0xffffffff80000000
Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
recorders/dtvchannel.cpp:299 (SetChannelByString) DTVChan[1](11111EB6-0):
SetChannelByString(1): Failed to initialize multiplex options

As before the HDHR tuners work fine for the HDHR setup GUI

-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 Fri, 05 Aug 2016 15:16:16 +1200, you wrote:

>I'm re-installed everything and set up the backend manually.I'm still in
>the same situation.No tuners will allow viewing or recording.
>I've deleted the tuners and set them up again to no avail.
>Here is a few lines from backend log
>
>Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
>WatchingLiveTV
>Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
>Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
>Unknown tuner type = 0xffffffff80000000
>Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>recorders/dtvchannel.cpp:299 (SetChannelByString) DTVChan[1](11111EB6-0):
>SetChannelByString(1): Failed to initialize multiplex options
>
>As before the HDHR tuners work fine for the HDHR setup GUI
>
>-Paul

OK, you have the same HDHR tuner problem. If you change the LiveTV
order settings so the internal tuners are used first, they will likely
work. So now we need to see what MythTV is doing when it tries to
talk to the HDHRs. Install Wireshark and use it to capture the
Ethernet traffic when MythTV tries to use an HDHR, and also when Me-TV
does (or something that works). Post the capture files.

_______________________________________________
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, 05 Aug 2016 16:25:26 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Fri, 05 Aug 2016 15:16:16 +1200, you wrote:
>
>> I'm re-installed everything and set up the backend manually.I'm still in
>> the same situation.No tuners will allow viewing or recording.
>> I've deleted the tuners and set them up again to no avail.
>> Here is a few lines from backend log
>>
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
>> WatchingLiveTV
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>> dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
>> Unknown tuner type = 0xffffffff80000000
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>> recorders/dtvchannel.cpp:299 (SetChannelByString)
>> DTVChan[1](11111EB6-0):
>> SetChannelByString(1): Failed to initialize multiplex options
>>
>> As before the HDHR tuners work fine for the HDHR setup GUI
>>
>> -Paul
>
> OK, you have the same HDHR tuner problem. If you change the LiveTV
> order settings so the internal tuners are used first, they will likely
> work. So now we need to see what MythTV is doing when it tries to
> talk to the HDHRs. Install Wireshark and use it to capture the
> Ethernet traffic when MythTV tries to use an HDHR, and also when Me-TV
> does (or something that works). Post the capture files.
>
This must be almost as frustrating for you as for me.Getting an incomplete
view of the problem via email.
Apart from that one instance where everything seemed to work, at no other
time has either the HDHRs or the card tuners worked.I have deleted tuners
and setup only card tuners - they did not work.I have set up only HDHR
tuners and they did not work.Every variation of tuner arrangement, set up
and scanned channels correctly and the channels appeared in the channel
editor.
I am using the exact settings I used for 12.04.
I assume that the fact that the channel scans for the HDHR and tuner card
during setup implies that the tuners are working and communicating with
the myth backend software.Is this not correct?
When setting up the tuners both the HDHR and card tuners appear as options
in the setup so the software has no trouble seeing them.

In an earlier reply you stated:

"first start with an empty database and
>> do the initial setup (including tuners and channels, but not xmltvids
>> and EPG). Then test the setup to make sure all the tuners work and so
>> on. If you want to try that, then you can empty the database and
>> re-create it."

How did you confirm everything was working?

I'll describe my hardware setup.
The mythbox is connected via a network switch to the HDHR and to the
modem/router and I have a Ubuntu PC connected to the modem/router.I do the
setup on the mythbox using Remmina network sharing from the PC.The mythbox
is conected to the internet and I can install software etc with no
problems.

Since I last installed 16.04 I don't seem to be able to use the new mysql
password (mysql -u root -p) to open mysql but the frontend connects to
the database ok.

-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 Fri, 05 Aug 2016 16:25:26 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Fri, 05 Aug 2016 15:16:16 +1200, you wrote:
>
>> I'm re-installed everything and set up the backend manually.I'm still in
>> the same situation.No tuners will allow viewing or recording.
>> I've deleted the tuners and set them up again to no avail.
>> Here is a few lines from backend log
>>
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
>> WatchingLiveTV
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>> dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
>> Unknown tuner type = 0xffffffff80000000
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>> recorders/dtvchannel.cpp:299 (SetChannelByString)DTVChan[1](11111EB6-0):
>> SetChannelByString(1): Failed to initialize multiplex options
>>
>> As before the HDHR tuners work fine for the HDHR setup GUI
>>
>> -Paul
>
> OK, you have the same HDHR tuner problem. If you change the LiveTV
> order settings so the internal tuners are used first, they will likely
> work. So now we need to see what MythTV is doing when it tries to
> talk to the HDHRs. Install Wireshark and use it to capture the
> Ethernet traffic when MythTV tries to use an HDHR, and also when Me-TV
> does (or something that works). Post the capture files.
>

I think I have found the problem.

Working on the basis that because 12.04 still works and 16.04
doesn't,where,in the procedure I use to switch from one to the other,is it
likely I am introducing the problem (ie A stupid mistake)
So when I switch the system drives I have to change the storage drive
permissions because for some reason they do not stay the same between the
two system drives.

I have been using the command: sudo chown -Rv myth:myth /var/lib/mythtv
when it should be: chown -Rv mythtv:mythtv /var/lib/mythtv
I have been calling up the same erroneous command from bash history in
16.04.In 12.04 I didnot make the mistake in the command.

I made this mistake possible by calling my mythbox "myth"

D'oh!

When I selected a channel to watch live from the guide, I get the
following message in mythbackend log:

Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: I TVRecEvent
tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
WatchingLiveTV
Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: I TVRecEvent
tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: N CoreContext
autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max required
Free Space: 3.0 GB w/freq: 14 min
Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
threadedfilewriter.cpp:129 (Open)
TFW(/var/lib/mythtv/livetv/1003_20160805225000.ts:-1): Opening file
'/var/lib/mythtv/livetv/1003_20160805225000.ts'.#012#011#011#011eno:
Permission denied (13)
Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
tv_rec.cpp:4606 (GetProgramRingBufferForLiveTV) TVRec[1]: RingBuffer
'/var/lib/mythtv/livetv/1003_20160805225000.ts' not open...
Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
tv_rec.cpp:4642 (CreateLiveTVRingBuffer) TVRec[1]:
CreateLiveTVRingBuffer(3) failed

I still can't get access to mysql with the password listed in myth
frontend:

mysql -u root -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: YES)

Is there a way around this?

On Fri, 05 Aug 2016 16:25:26 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Fri, 05 Aug 2016 15:16:16 +1200, you wrote:
>
>> I'm re-installed everything and set up the backend manually.I'm still in
>> the same situation.No tuners will allow viewing or recording.
>> I've deleted the tuners and set them up again to no avail.
>> Here is a few lines from backend log
>>
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
>> WatchingLiveTV
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>> tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>> dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
>> Unknown tuner type = 0xffffffff80000000
>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>> recorders/dtvchannel.cpp:299 (SetChannelByString)
>> DTVChan[1](11111EB6-0):
>> SetChannelByString(1): Failed to initialize multiplex options
>>
>> As before the HDHR tuners work fine for the HDHR setup GUI
>>
>> -Paul
>
> OK, you have the same HDHR tuner problem. If you change the LiveTV
> order settings so the internal tuners are used first, they will likely
> work. So now we need to see what MythTV is doing when it tries to
> talk to the HDHRs. Install Wireshark and use it to capture the
> Ethernet traffic when MythTV tries to use an HDHR, and also when Me-TV
> does (or something that works). Post the capture files.
>
More info on the mysql possword problem;

I can't access the database with> mysql -u root -p with that password but
I can with> mysql -u mythtv -p

_______________________________________________
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, Aug 6, 2016 at 12:00 PM, Paulgir <paulgir@gmail.com> wrote:

> On Fri, 05 Aug 2016 16:25:26 +1200, Stephen Worthington <
> stephen_agent@jsw.gen.nz> wrote:
>
> On Fri, 05 Aug 2016 15:16:16 +1200, you wrote:
>>
>> I'm re-installed everything and set up the backend manually.I'm still in
>>> the same situation.No tuners will allow viewing or recording.
>>> I've deleted the tuners and set them up again to no avail.
>>> Here is a few lines from backend log
>>>
>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>>> tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
>>> WatchingLiveTV
>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>>> tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>>> tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>>> dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
>>> Unknown tuner type = 0xffffffff80000000
>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>>> recorders/dtvchannel.cpp:299 (SetChannelByString) DTVChan[1](11111EB6-0):
>>> SetChannelByString(1): Failed to initialize multiplex options
>>>
>>> As before the HDHR tuners work fine for the HDHR setup GUI
>>>
>>> -Paul
>>>
>>
>> OK, you have the same HDHR tuner problem. If you change the LiveTV
>> order settings so the internal tuners are used first, they will likely
>> work. So now we need to see what MythTV is doing when it tries to
>> talk to the HDHRs. Install Wireshark and use it to capture the
>> Ethernet traffic when MythTV tries to use an HDHR, and also when Me-TV
>> does (or something that works). Post the capture files.
>>
>> More info on the mysql possword problem;
>
> I can't access the database with> mysql -u root -p with that password but
> I can with> mysql -u mythtv -p
>
>
>

root has a different password than mythtv. You set the root password when
mysql-server was installed.




> _______________________________________________
> 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, Aug 6, 2016 at 1:10 PM, Nick Rout <nick.rout@gmail.com> wrote:

>
>
> On Sat, Aug 6, 2016 at 12:00 PM, Paulgir <paulgir@gmail.com> wrote:
>
>> On Fri, 05 Aug 2016 16:25:26 +1200, Stephen Worthington <
>> stephen_agent@jsw.gen.nz> wrote:
>>
>> On Fri, 05 Aug 2016 15:16:16 +1200, you wrote:
>>>
>>> I'm re-installed everything and set up the backend manually.I'm still in
>>>> the same situation.No tuners will allow viewing or recording.
>>>> I've deleted the tuners and set them up again to no avail.
>>>> Here is a few lines from backend log
>>>>
>>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>>>> tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
>>>> WatchingLiveTV
>>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>>>> tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
>>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: I TVRecEvent
>>>> tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>>>> dtvmultiplex.cpp:379 (ParseTuningParams) DTVMux: ParseTuningParams --
>>>> Unknown tuner type = 0xffffffff80000000
>>>> Aug 5 15:03:48 myth mythbackend: mythbackend[2583]: E TVRecEvent
>>>> recorders/dtvchannel.cpp:299 (SetChannelByString)
>>>> DTVChan[1](11111EB6-0):
>>>> SetChannelByString(1): Failed to initialize multiplex options
>>>>
>>>> As before the HDHR tuners work fine for the HDHR setup GUI
>>>>
>>>> -Paul
>>>>
>>>
>>> OK, you have the same HDHR tuner problem. If you change the LiveTV
>>> order settings so the internal tuners are used first, they will likely
>>> work. So now we need to see what MythTV is doing when it tries to
>>> talk to the HDHRs. Install Wireshark and use it to capture the
>>> Ethernet traffic when MythTV tries to use an HDHR, and also when Me-TV
>>> does (or something that works). Post the capture files.
>>>
>>> More info on the mysql possword problem;
>>
>> I can't access the database with> mysql -u root -p with that password but
>> I can with> mysql -u mythtv -p
>>
>>
>>
>
> root has a different password than mythtv. You set the root password when
> mysql-server was installed.
>
>
You can reset it with sudo dpkg-reconfigure mysql-server-versionnumber



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

>>> More info on the mysql possword problem;
>>>
>>> I can't access the database with> mysql -u root -p with that password
>>> but I can with> mysql -u mythtv -p
>>>
>>>
>>
>>
>> root has a different password than mythtv. You set the root password
>> when mysql-server was installed.
>>
>> You can reset it with sudo dpkg-reconfigure mysql-server-versionnumber

Will do.
Cheers

On Sat, 06 Aug 2016 13:15:35 +1200
Paulgir <paulgir@gmail.com> wrote:
> >>> I can't access the database with> mysql -u root -p with that password
> >>> but I can with> mysql -u mythtv -p
> >> root has a different password than mythtv. You set the root password
> >> when mysql-server was installed.
> >> You can reset it with sudo dpkg-reconfigure mysql-server-versionnumber

There is also a 'back-door' way in, at least on Debian-derived distros:
sudo mysql --defaults-file=/etc/mysql/debian.cnf
Will start up MySQL as the system maintenance user.
Then you can do all the password resetting stuff:
use mysql;
update user set password = password('beetroot') where user = 'root';
commit;
grant all privileges on *.* to 'root'@'localhost' identified by 'beetroot' with grant option;
flush privileges;
quit
Then you should be OK to log in as MySQL root, after which you can do anything.
mysql -u root -p mysql

_______________________________________________
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, 06 Aug 2016 15:00:35 +1200, Austin Green
<austin.green@orcon.net.nz> wrote:

> On Sat, 06 Aug 2016 13:15:35 +1200
> Paulgir <paulgir@gmail.com> wrote:
>> >>> I can't access the database with> mysql -u root -p with that
>> password
>> >>> but I can with> mysql -u mythtv -p
>> >> root has a different password than mythtv. You set the root password
>> >> when mysql-server was installed.
>> >> You can reset it with sudo dpkg-reconfigure
>> mysql-server-versionnumber
>
> There is also a 'back-door' way in, at least on Debian-derived distros:
> sudo mysql --defaults-file=/etc/mysql/debian.cnf
> Will start up MySQL as the system maintenance user.
> Then you can do all the password resetting stuff:
> use mysql;
> update user set password = password('beetroot') where user = 'root';
> commit;
> grant all privileges on *.* to 'root'@'localhost' identified by
> 'beetroot' with grant option;
> flush privileges;
> quit
> Then you should be OK to log in as MySQL root, after which you can do
> anything.
> mysql -u root -p mysql

Thanks.I'll make a note of that for the future.

Cheers

_______________________________________________
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, 06 Aug 2016 16:46:14 +1200, you wrote:

>On Sat, 06 Aug 2016 15:00:35 +1200, Austin Green
><austin.green@orcon.net.nz> wrote:
>
>> On Sat, 06 Aug 2016 13:15:35 +1200
>> Paulgir <paulgir@gmail.com> wrote:
>>> >>> I can't access the database with> mysql -u root -p with that
>>> password
>>> >>> but I can with> mysql -u mythtv -p
>>> >> root has a different password than mythtv. You set the root password
>>> >> when mysql-server was installed.
>>> >> You can reset it with sudo dpkg-reconfigure
>>> mysql-server-versionnumber
>>
>> There is also a 'back-door' way in, at least on Debian-derived distros:
>> sudo mysql --defaults-file=/etc/mysql/debian.cnf
>> Will start up MySQL as the system maintenance user.
>> Then you can do all the password resetting stuff:
>> use mysql;
>> update user set password = password('beetroot') where user = 'root';
>> commit;
>> grant all privileges on *.* to 'root'@'localhost' identified by
>> 'beetroot' with grant option;
>> flush privileges;
>> quit
>> Then you should be OK to log in as MySQL root, after which you can do
>> anything.
>> mysql -u root -p mysql
>
>Thanks.I'll make a note of that for the future.
>
>Cheers

Another trick to note down - if you are testing your tuners and the
first one will not work, LiveTV is useless (until you change the
livetvorder settings). But you can still use manual recording rules
to test with. Recording rules have an option under Schedule Options
where it normally says "Use any available tuner". You can set that to
specify a multirec tuner number as the preferred input, and unless you
have two rules clashing for the use of that number, that will then be
the tuner that gets used. Manual recording rules can only be set to
run on five minute boundaries, but if the next five minute boundary is
too far away for you to want to wait that long, you can change the
"Start recording on time" option to start as many minutes early as you
need to get the recording to start on the next minute boundary.

_______________________________________________
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 think I have found the problem.
>
> Working on the basis that because 12.04 still works and 16.04
> doesn't,where,in the procedure I use to switch from one to the >other,is
> it likely I am introducing the problem (ie A stupid mistake)
> So when I switch the system drives I have to change the storage drive
> permissions because for some reason they do not stay the same >between
> the two system drives.
>
> I have been using the command: sudo chown -Rv myth:myth /var/lib/mythtv
> when it should be: chown -Rv mythtv:mythtv /var/lib/mythtv
> I have been calling up the same erroneous command from bash history in
> 16.04.In 12.04 I didnot make the mistake in the command.
>
> I made this mistake possible by calling my mythbox "myth"
>
> D'oh!
>
> When I selected a channel to watch live from the guide, I get the
> following message in mythbackend log:
>
> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: I TVRecEvent
> tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
> >WatchingLiveTV
> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: I TVRecEvent
> tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: N CoreContext
> autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max >required
> Free Space: 3.0 GB w/freq: 14 min
> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
> threadedfilewriter.cpp:129 (Open)
> TFW(/var/lib/mythtv/>livetv/1003_20160805225000.ts:-1): Opening file
> '/var/lib/mythtv/livetv/1003_20160805225000.ts'.#012#011#011#011eno:
> Permission >denied (13)
> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
> tv_rec.cpp:4606 (GetProgramRingBufferForLiveTV) TVRec[1]: >RingBuffer
> '/var/lib/mythtv/livetv/1003_20160805225000.ts' not open...
> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
> tv_rec.cpp:4642 (CreateLiveTVRingBuffer) TVRec[1]:
> >CreateLiveTVRingBuffer(3) failed
>

I took a few days away from this thing.
It seems I was wrong about the cause of the problem.I did make the mistake
described above but it was not the cause of the continuing problem with
the tuners.
To recap, I can install the Card and HDHR tuners in backend setup ,scan
channels and populate the channel editor but I can't watch live TV or
record.The card works ok with MeTV.
To simplify things I am only doing the internal HVR 2200 tuners.I haven't
installed the HDHR yet.I get the following message in backend log at boot:

Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: W CoreContext
recorders/dvbchannel.cpp:245 (Open)
DVBChan[1](/dev/dvb/adapter0/frontend0): Opening DVB frontend device
failed.#012#011#011#011eno: No such file or directory (2)
Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
recorders/dvbchannel.cpp:250 (Open)
DVBChan[1](/dev/dvb/adapter0/frontend0): Failed to open DVB frontend
device due to fatal error or too many attempts.
Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
recorders/channelbase.cpp:870 (CreateChannel) ChannelBase: CreateChannel()
Error: Failed to open device /dev/dvb/adapter0/frontend0
Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
main_helpers.cpp:202 (setupTVs) Problem with capture cards. Card 1 failed
init
Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: W CoreContext
recorders/dvbchannel.cpp:245 (Open)
DVBChan[2](/dev/dvb/adapter0/frontend0): Opening DVB frontend device
failed.#012#011#011#011eno: No such file or directory (2)
Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
recorders/dvbchannel.cpp:250 (Open)
DVBChan[2](/dev/dvb/adapter0/frontend0): Failed to open DVB frontend
device due to fatal error or too many attempts.
Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
recorders/channelbase.cpp:870 (CreateChannel) ChannelBase: CreateChannel()
Error: Failed to open device /dev/dvb/adapter0/frontend0
Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
main_helpers.cpp:202 (setupTVs) Problem with capture cards. Card 2 failed
init

On Thu, 11 Aug 2016 11:35:38 +1200, you wrote:

>
>
>I think I have found the problem.
>>
>> Working on the basis that because 12.04 still works and 16.04
>> doesn't,where,in the procedure I use to switch from one to the >other,is
>> it likely I am introducing the problem (ie A stupid mistake)
>> So when I switch the system drives I have to change the storage drive
>> permissions because for some reason they do not stay the same >between
>> the two system drives.
>>
>> I have been using the command: sudo chown -Rv myth:myth /var/lib/mythtv
>> when it should be: chown -Rv mythtv:mythtv /var/lib/mythtv
>> I have been calling up the same erroneous command from bash history in
>> 16.04.In 12.04 I didnot make the mistake in the command.
>>
>> I made this mistake possible by calling my mythbox "myth"
>>
>> D'oh!
>>
>> When I selected a channel to watch live from the guide, I get the
>> following message in mythbackend log:
>>
>> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: I TVRecEvent
>> tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
>> >WatchingLiveTV
>> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: I TVRecEvent
>> tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: N CoreContext
>> autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max >required
>> Free Space: 3.0 GB w/freq: 14 min
>> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
>> threadedfilewriter.cpp:129 (Open)
>> TFW(/var/lib/mythtv/>livetv/1003_20160805225000.ts:-1): Opening file
>> '/var/lib/mythtv/livetv/1003_20160805225000.ts'.#012#011#011#011eno:
>> Permission >denied (13)
>> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
>> tv_rec.cpp:4606 (GetProgramRingBufferForLiveTV) TVRec[1]: >RingBuffer
>> '/var/lib/mythtv/livetv/1003_20160805225000.ts' not open...
>> Aug 6 10:50:00 myth mythbackend: mythbackend[4101]: E TVRecEvent
>> tv_rec.cpp:4642 (CreateLiveTVRingBuffer) TVRec[1]:
>> >CreateLiveTVRingBuffer(3) failed
>>
>
>I took a few days away from this thing.
>It seems I was wrong about the cause of the problem.I did make the mistake
>described above but it was not the cause of the continuing problem with
>the tuners.
>To recap, I can install the Card and HDHR tuners in backend setup ,scan
>channels and populate the channel editor but I can't watch live TV or
>record.The card works ok with MeTV.
>To simplify things I am only doing the internal HVR 2200 tuners.I haven't
>installed the HDHR yet.I get the following message in backend log at boot:
>
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: W CoreContext
>recorders/dvbchannel.cpp:245 (Open)
>DVBChan[1](/dev/dvb/adapter0/frontend0): Opening DVB frontend device
>failed.#012#011#011#011eno: No such file or directory (2)
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
>recorders/dvbchannel.cpp:250 (Open)
>DVBChan[1](/dev/dvb/adapter0/frontend0): Failed to open DVB frontend
>device due to fatal error or too many attempts.
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
>recorders/channelbase.cpp:870 (CreateChannel) ChannelBase: CreateChannel()
>Error: Failed to open device /dev/dvb/adapter0/frontend0
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
>main_helpers.cpp:202 (setupTVs) Problem with capture cards. Card 1 failed
>init
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: W CoreContext
>recorders/dvbchannel.cpp:245 (Open)
>DVBChan[2](/dev/dvb/adapter0/frontend0): Opening DVB frontend device
>failed.#012#011#011#011eno: No such file or directory (2)
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
>recorders/dvbchannel.cpp:250 (Open)
>DVBChan[2](/dev/dvb/adapter0/frontend0): Failed to open DVB frontend
>device due to fatal error or too many attempts.
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
>recorders/channelbase.cpp:870 (CreateChannel) ChannelBase: CreateChannel()
>Error: Failed to open device /dev/dvb/adapter0/frontend0
>Aug 11 11:14:24 mythpc mythbackend: mythbackend[2549]: E CoreContext
>main_helpers.cpp:202 (setupTVs) Problem with capture cards. Card 2 failed
>init

Mythbackend seems to be saying it can not see
/dev/dvb/adapter0/frontend0. But presumably mythtv-setup can see the
device, or it could not scan for channels. Does
/dev/dvb/adapter0/frontend0 show up if you look for it with the ll or
ls commands? What do these commands show:

ll /dev/dvb
ll /dev/dvb/adapter0
ll /dev/dvb/adapter1

What permissions does mythbackend have? What does this command show:

ps -ef | grep myth

That should show how mythbackend is being run (in particular, as which
user).

There is also one obvious problem in that log snippet. Both Card 1
and Card 2 are referencing adapter0/frontend0. I do not know how the
HVR-2200 does its devices, but there should be either two completely
separate devices /dev/dvb/adapter0 and /dev/dvb/adapter1 or one device
with two frontends, /dev/dvb/adapter0/frontend0 and
/dev/dvb/adapter0/frontend1. Both Card1 and Card2 should not be using
the same frontend device /dev/dvb/adapter0/frontend0.

Also, check that the firmware for the card is installed (see
https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200). Does
it show up in the logs as being loaded? There are some cards that
will do a channel scan but will not record without the firmware. But I
would have expected it to fail in Me-TV if that was the case.

How does Me-TV run? Is it running when mythbackend tries to access
the devices? If so, it could own the devices and not be allowing
mythbackend access. Is there any other TV software installed that
could be using the devices?

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

> Mythbackend seems to be saying it can not see
> /dev/dvb/adapter0/frontend0. But presumably mythtv-setup can see the
> device, or it could not scan for channels. Does
> /dev/dvb/adapter0/frontend0 show up if you look for it with the ll or
> ls commands? What do these commands show:
>
> ll /dev/dvb
> ll /dev/dvb/adapter0
> ll /dev/dvb/adapter1
>
> What permissions does mythbackend have? What does this command show:
>
> ps -ef | grep myth
>
> That should show how mythbackend is being run (in particular, as which
> user).
>
> There is also one obvious problem in that log snippet. Both Card 1
> and Card 2 are referencing adapter0/frontend0. I do not know how the
> HVR-2200 does its devices, but there should be either two completely
> separate devices /dev/dvb/adapter0 and /dev/dvb/adapter1 or one device
> with two frontends, /dev/dvb/adapter0/frontend0 and
> /dev/dvb/adapter0/frontend1. Both Card1 and Card2 should not be using
> the same frontend device /dev/dvb/adapter0/frontend0.
>
> Also, check that the firmware for the card is installed (see
> https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200). Does
> it show up in the logs as being loaded? There are some cards that
> will do a channel scan but will not record without the firmware. But I
> would have expected it to fail in Me-TV if that was the case.
>
> How does Me-TV run? Is it running when mythbackend tries to access
> the devices? If so, it could own the devices and not be allowing
> mythbackend access. Is there any other TV software installed that
> could be using the devices?
>

Firmware is installed as per the wiki.
The log snippet was recorded prior to MeTV installation (this time).So I
did extensive testing without MeTV installed.
I have a complete backend.log from a restart onwards that you can look
at:https://drive.google.com/open?id=0B5RRWPLTmilhN3Bta2xmQWEwQU0

One thing I haven't mentioned much is that 16.04 is on a SSD and 12.04 is
on a slow HDD.I saw mention online that problems have been seen if
mythbackend starts before the capture cards can initialise.So far none of
the fixes I have found work for this install.

~$ ll /dev/dvb
total 0
drwxr-xr-x 4 root root 80 Aug 11 13:57 ./
drwxr-xr-x 22 root root 4580 Aug 11 13:57 ../
drwxr-xr-x 2 root root 120 Aug 11 13:57 adapter0/
drwxr-xr-x 2 root root 120 Aug 11 13:57 adapter1/

~$ ll /dev/dvb/adapter1
total 0
drwxr-xr-x 2 root root 120 Aug 11 13:57 ./
drwxr-xr-x 4 root root 80 Aug 11 13:57 ../
crw-rw----+ 1 root video 212, 5 Aug 11 13:57 demux0
crw-rw----+ 1 root video 212, 6 Aug 11 13:57 dvr0
crw-rw----+ 1 root video 212, 4 Aug 11 13:57 frontend0
crw-rw----+ 1 root video 212, 7 Aug 11 13:57 net0

~$ ll /dev/dvb/adapter0
total 0
drwxr-xr-x 2 root root 120 Aug 11 13:57 ./
drwxr-xr-x 4 root root 80 Aug 11 13:57 ../
crw-rw----+ 1 root video 212, 1 Aug 11 13:57 demux0
crw-rw----+ 1 root video 212, 2 Aug 11 13:57 dvr0
crw-rw----+ 1 root video 212, 0 Aug 11 13:57 frontend0
crw-rw----+ 1 root video 212, 3 Aug 11 13:57 net0

~$ ps -ef | grep myth
avahi 1971 1 0 13:57 ? 00:00:00 avahi-daemon: running [mythpc.local]
mythpc 2397 1 0 13:57 ? 00:00:00 /lib/systemd/systemd --user
mythpc 2398 2397 0 13:57 ? 00:00:00 (sd-pam)
mythpc 2402 2391 0 13:57 ? 00:00:00 /bin/sh /etc/xdg/xfce4/xinitrc --
/etc/X11/xinit/xserverrc
mythpc 2448 2402 0 13:57 ? 00:00:00 /usr/bin/ssh-agent
/usr/bin/dbus-launch --exit-with-session /usr/share/mythbuntu/session.sh
mythpc 2451 1 0 13:57 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session
/usr/share/mythbuntu/session.sh
mythpc 2452 1 0 13:57 ? 00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5
--print-address 7 --session
mythpc 2464 2402 0 13:57 ? 00:00:00 xfce4-session
mythpc 2468 1 0 13:57 ? 00:00:00
/usr/lib/x86_64-linux-gnu/xfce4/xfconf/xfconfd
mythpc 2472 1 0 13:57 ? 00:00:00 gnome-keyring-daemon --start
mythpc 2477 1 0 13:57 ? 00:00:00 xfwm4
mythpc 2479 1 0 13:57 ? 00:00:01 xfce4-panel
mythpc 2481 1 0 13:57 ? 00:00:05 Thunar --daemon
mythpc 2483 1 0 13:57 ? 00:00:00 xfdesktop
mythpc 2488 2464 2 13:57 ? 00:01:03 /usr/lib/vino/vino-server --sm-disable
mythpc 2492 2464 0 13:57 ? 00:00:00 update-notifier
mythpc 2493 2464 0 13:57 ? 00:00:00
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
mythpc 2495 2464 0 13:57 ? 00:00:00 xscreensaver -no-splash
mythpc 2505 2464 0 13:57 ? 00:00:00 nm-applet
mythpc 2508 1 0 13:57 ? 00:00:00 xfce4-volumed
mythpc 2512 1 0 13:57 ? 00:00:00 /usr/bin/pulseaudio --start
--log-target=syslog
mythpc 2518 1 0 13:57 ? 00:00:00 xfsettingsd
mythtv 2521 1 0 13:57 ? 00:00:03 /usr/bin/mythbackend --quiet --syslog
local7
mythpc 2559 1 0 13:57 ? 00:00:00 /usr/lib/gvfs/gvfsd
mythpc 2575 1 0 13:57 ? 00:00:00 /usr/lib/at-spi2-core/at-spi-bus-launcher
mythpc 2581 2575 0 13:57 ? 00:00:00 /usr/bin/dbus-daemon
--config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
mythpc 2584 1 0 13:57 ? 00:00:00 /usr/lib/at-spi2-core/at-spi2-registryd
--use-gnome-session
mythpc 2606 1 0 13:57 ? 00:00:00 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
mythpc 2610 2479 0 13:57 ? 00:00:00
/usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0
/usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libsystray.so 4 12582955
systray Notification Area Area where notification icons appear
mythpc 2703 1 0 13:57 ? 00:00:00 /usr/lib/x86_64-linux-gnu/notify-osd
mythpc 3095 1 0 13:57 ? 00:00:00 /usr/lib/gvfs/gvfsd-metadata
mythpc 3099 1 0 13:57 ? 00:00:00 /usr/lib/gvfs/gvfsd-trash --spawner :1.13
/org/gtk/gvfs/exec_spaw/0
mythpc 3113 1 0 13:58 ? 00:00:00 /usr/lib/dconf/dconf-service
mythpc 3601 1 0 14:27 ? 00:00:00 /usr/lib/x86_64-linux-gnu/gconf/gconfd-2
mythpc 3857 2479 0 14:39 ? 00:00:01 xfce4-terminal
mythpc 3861 3857 0 14:39 ? 00:00:00 gnome-pty-helper
mythpc 3862 3857 0 14:39 pts/0 00:00:00 bash
mythpc 3929 3862 0 14:43 pts/0 00:00:00 ps -ef
mythpc 3930 3862 0 14:43 pts/0 00:00:00 grep --color=auto myt

>
> There is also one obvious problem in that log snippet. Both Card 1
> and Card 2 are referencing adapter0/frontend0. I do not know how the
> HVR-2200 does its devices, but there should be either two completely
> separate devices /dev/dvb/adapter0 and /dev/dvb/adapter1 or one device
> with two frontends, /dev/dvb/adapter0/frontend0 and
> /dev/dvb/adapter0/frontend1. Both Card1 and Card2 should not be using
> the same frontend device /dev/dvb/adapter0/frontend0.

I have named the tuners card-0 and card-1 in capture card setup
>
> Also, check that the firmware for the card is installed (see
> https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200). Does
> it show up in the logs as being loaded? There are some cards that
> will do a channel scan but will not record without the firmware. But I
> would have expected it to fail in Me-TV if that was the case.
>
> How does Me-TV run? Is it running when mythbackend tries to access
> the devices? If so, it could own the devices and not be allowing
> mythbackend access. Is there any other TV software installed that
> could be using the devices?

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

>
> There is also one obvious problem in that log snippet. Both Card 1
> and Card 2 are referencing adapter0/frontend0. I do not know how the
> HVR-2200 does its devices, but there should be either two completely
> separate devices /dev/dvb/adapter0 and /dev/dvb/adapter1 or one device
> with two frontends, /dev/dvb/adapter0/frontend0 and
> /dev/dvb/adapter0/frontend1. Both Card1 and Card2 should not be using
> the same frontend device /dev/dvb/adapter0/frontend0.
>
The tuners are referred to as /dev/dvb/adapter0/frontend0 and
/dev/dvb/adapter1/frontend0
Same as in the 12.04 install

_______________________________________________
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, 11 Aug 2016 15:23:16 +1200, you wrote:

>
>>
>> There is also one obvious problem in that log snippet. Both Card 1
>> and Card 2 are referencing adapter0/frontend0. I do not know how the
>> HVR-2200 does its devices, but there should be either two completely
>> separate devices /dev/dvb/adapter0 and /dev/dvb/adapter1 or one device
>> with two frontends, /dev/dvb/adapter0/frontend0 and
>> /dev/dvb/adapter0/frontend1. Both Card1 and Card2 should not be using
>> the same frontend device /dev/dvb/adapter0/frontend0.
>>
>The tuners are referred to as /dev/dvb/adapter0/frontend0 and
>/dev/dvb/adapter1/frontend0
>Same as in the 12.04 install

Yes, the device setup seems fine. I was mixing up the multirec card
numbers with the physical card numbers. Your full log makes it clear
that there are two multirec tuners per physical tuner and they seem
assigned correctly.

The idea that the tuners are not ready when mythbackend starts is
quite plausible when booting from an SSD. Systemd makes the startup
faster too, and the tuners take a while to load their firmware.
Fortunately, it is easy just to restart mythbackend once booting is
complete and mythfrontend is running. If the tuners work then, that
race condition is the problem and you will need to adjust the systemd
rules for mythbackend startup so that it waits for the tuner devices.
Take a look at this page for suggestions about how to do it:

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

In Mythbuntu 16.04, if you want to make any changes to the systemd
mythtv-backend.service file, you can apparently just use "override
files". See here:

https://wiki.ubuntu.com/SystemdForUpstartUsers

I have not tried that yet, so I do not know how well it works.

If override files do not work, or the changes are too great, you need
to copy mythtv-backend.service from /lib/systemd/system to
/etc/systemd/system and modify it there. And when mythbackend gets
updated, you need to check if there were any changes in the
/lib/systemd/system version of the file that need to also be done in
the /etc/systemd/system copy.

_______________________________________________
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, 11 Aug 2016 21:18:33 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Thu, 11 Aug 2016 15:23:16 +1200, you wrote:
>
>>
>>>
>>> There is also one obvious problem in that log snippet. Both Card 1
>>> and Card 2 are referencing adapter0/frontend0. I do not know how the
>>> HVR-2200 does its devices, but there should be either two completely
>>> separate devices /dev/dvb/adapter0 and /dev/dvb/adapter1 or one device
>>> with two frontends, /dev/dvb/adapter0/frontend0 and
>>> /dev/dvb/adapter0/frontend1. Both Card1 and Card2 should not be using
>>> the same frontend device /dev/dvb/adapter0/frontend0.
>>>
>> The tuners are referred to as /dev/dvb/adapter0/frontend0 and
>> /dev/dvb/adapter1/frontend0
>> Same as in the 12.04 install
>
> Yes, the device setup seems fine. I was mixing up the multirec card
> numbers with the physical card numbers. Your full log makes it clear
> that there are two multirec tuners per physical tuner and they seem
> assigned correctly.
>
> The idea that the tuners are not ready when mythbackend starts is
> quite plausible when booting from an SSD. Systemd makes the startup
> faster too, and the tuners take a while to load their firmware.
> Fortunately, it is easy just to restart mythbackend once booting is
> complete and mythfrontend is running. If the tuners work then, that
> race condition is the problem and you will need to adjust the systemd
> rules for mythbackend startup so that it waits for the tuner devices.
> Take a look at this page for suggestions about how to do it:
>
> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>
> In Mythbuntu 16.04, if you want to make any changes to the systemd
> mythtv-backend.service file, you can apparently just use "override
> files". See here:
>
> https://wiki.ubuntu.com/SystemdForUpstartUsers
>
> I have not tried that yet, so I do not know how well it works.
>
> If override files do not work, or the changes are too great, you need
> to copy mythtv-backend.service from /lib/systemd/system to
> /etc/systemd/system and modify it there. And when mythbackend gets
> updated, you need to check if there were any changes in the
> /lib/systemd/system version of the file that need to also be done in
> the /etc/systemd/system copy.
>
>
Restarting mythbackend never corrects the problem,so I doubt that is the
cause.

_______________________________________________
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, the device setup seems fine. I was mixing up the multirec card
> numbers with the physical card numbers. Your full log makes it clear
> that there are two multirec tuners per physical tuner and they seem
> assigned correctly.
>
> The idea that the tuners are not ready when mythbackend starts is
> quite plausible when booting from an SSD. Systemd makes the startup
> faster too, and the tuners take a while to load their firmware.
> Fortunately, it is easy just to restart mythbackend once booting is
> complete and mythfrontend is running. If the tuners work then, that
> race condition is the problem and you will need to adjust the systemd
> rules for mythbackend startup so that it waits for the tuner devices.
> Take a look at this page for suggestions about how to do it:
>
> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>
> In Mythbuntu 16.04, if you want to make any changes to the systemd
> mythtv-backend.service file, you can apparently just use "override
> files". See here:
>
> https://wiki.ubuntu.com/SystemdForUpstartUsers
>
> I have not tried that yet, so I do not know how well it works.
>
> If override files do not work, or the changes are too great, you need
> to copy mythtv-backend.service from /lib/systemd/system to
> /etc/systemd/system and modify it there. And when mythbackend gets
> updated, you need to check if there were any changes in the
> /lib/systemd/system version of the file that need to also be done in
> the /etc/systemd/system copy.
>

I'll correct my last statement.I had stopped and started mythbackend via
the GUI many times and did not see a change in the tuner status.
I just stopped and started mythbackend via cli and the status in
mythfrontend info changed from "tuner x has an error" to "tuner x is not
recording".
Mythbackend.log looks like this:

Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: N CoreContext
main_helpers.cpp:597 (run_backend) MythBackend: Starting up as the master
server.
Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: I LogForward
loggingserver.cpp:295 (SyslogLogger) Added syslogging
Aug 12 09:14:47 mythpc mythbackend: mythbackend[3130]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 12 09:14:51 mythpc mythbackend: mythbackend[3130]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: W CoreContext
scheduler.cpp:214 (VerifyCards) Scheduler: Listings source '' is defined,
but is not attached to a card input.
Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: I CoreContext
programinfo.cpp:2368 (CheckProgramIDAuthorities) Found 1 distinct
programid authorities

I don't have an .xmltv config file at the moment so I was unable to check
the actual tuning of stations.

I think we may be getting somewhere.
Modifying Systemd_mythbackend_Configuration looks daunting.

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

To eliminate possible problems with your DVB card drivers, why not try just
with the HDHR. They are very reliable.

On Fri, Aug 12, 2016 at 9:27 AM, Paulgir <paulgir@gmail.com> wrote:

>
> Yes, the device setup seems fine. I was mixing up the multirec card
>> numbers with the physical card numbers. Your full log makes it clear
>> that there are two multirec tuners per physical tuner and they seem
>> assigned correctly.
>>
>> The idea that the tuners are not ready when mythbackend starts is
>> quite plausible when booting from an SSD. Systemd makes the startup
>> faster too, and the tuners take a while to load their firmware.
>> Fortunately, it is easy just to restart mythbackend once booting is
>> complete and mythfrontend is running. If the tuners work then, that
>> race condition is the problem and you will need to adjust the systemd
>> rules for mythbackend startup so that it waits for the tuner devices.
>> Take a look at this page for suggestions about how to do it:
>>
>> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>>
>> In Mythbuntu 16.04, if you want to make any changes to the systemd
>> mythtv-backend.service file, you can apparently just use "override
>> files". See here:
>>
>> https://wiki.ubuntu.com/SystemdForUpstartUsers
>>
>> I have not tried that yet, so I do not know how well it works.
>>
>> If override files do not work, or the changes are too great, you need
>> to copy mythtv-backend.service from /lib/systemd/system to
>> /etc/systemd/system and modify it there. And when mythbackend gets
>> updated, you need to check if there were any changes in the
>> /lib/systemd/system version of the file that need to also be done in
>> the /etc/systemd/system copy.
>>
>>
> I'll correct my last statement.I had stopped and started mythbackend via
> the GUI many times and did not see a change in the tuner status.
> I just stopped and started mythbackend via cli and the status in
> mythfrontend info changed from "tuner x has an error" to "tuner x is not
> recording".
> Mythbackend.log looks like this:
>
> Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: N CoreContext
> main_helpers.cpp:597 (run_backend) MythBackend: Starting up as the master
> server.
> Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: I LogForward
> loggingserver.cpp:295 (SyslogLogger) Added syslogging
> Aug 12 09:14:47 mythpc mythbackend: mythbackend[3130]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune) DVBChan[1](/dev/dvb/adapter0/frontend0):
> Next tuning after less than 1000ms. Delaying by 1000ms
> Aug 12 09:14:51 mythpc mythbackend: mythbackend[3130]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune) DVBChan[3](/dev/dvb/adapter1/frontend0):
> Next tuning after less than 1000ms. Delaying by 1000ms
> Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: W CoreContext
> scheduler.cpp:214 (VerifyCards) Scheduler: Listings source '' is defined,
> but is not attached to a card input.
> Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: I CoreContext
> programinfo.cpp:2368 (CheckProgramIDAuthorities) Found 1 distinct programid
> authorities
>
> I don't have an .xmltv config file at the moment so I was unable to check
> the actual tuning of stations.
>
> I think we may be getting somewhere.
> Modifying Systemd_mythbackend_Configuration looks daunting.
>
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

Also this is weird:

Listings source '' is defined, but is not attached to a card input.

Looks like you didn't complete your setup.

On Fri, Aug 12, 2016 at 1:22 PM, Nick Rout <nick.rout@gmail.com> wrote:

> To eliminate possible problems with your DVB card drivers, why not try
> just with the HDHR. They are very reliable.
>
> On Fri, Aug 12, 2016 at 9:27 AM, Paulgir <paulgir@gmail.com> wrote:
>
>>
>> Yes, the device setup seems fine. I was mixing up the multirec card
>>> numbers with the physical card numbers. Your full log makes it clear
>>> that there are two multirec tuners per physical tuner and they seem
>>> assigned correctly.
>>>
>>> The idea that the tuners are not ready when mythbackend starts is
>>> quite plausible when booting from an SSD. Systemd makes the startup
>>> faster too, and the tuners take a while to load their firmware.
>>> Fortunately, it is easy just to restart mythbackend once booting is
>>> complete and mythfrontend is running. If the tuners work then, that
>>> race condition is the problem and you will need to adjust the systemd
>>> rules for mythbackend startup so that it waits for the tuner devices.
>>> Take a look at this page for suggestions about how to do it:
>>>
>>> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>>>
>>> In Mythbuntu 16.04, if you want to make any changes to the systemd
>>> mythtv-backend.service file, you can apparently just use "override
>>> files". See here:
>>>
>>> https://wiki.ubuntu.com/SystemdForUpstartUsers
>>>
>>> I have not tried that yet, so I do not know how well it works.
>>>
>>> If override files do not work, or the changes are too great, you need
>>> to copy mythtv-backend.service from /lib/systemd/system to
>>> /etc/systemd/system and modify it there. And when mythbackend gets
>>> updated, you need to check if there were any changes in the
>>> /lib/systemd/system version of the file that need to also be done in
>>> the /etc/systemd/system copy.
>>>
>>>
>> I'll correct my last statement.I had stopped and started mythbackend via
>> the GUI many times and did not see a change in the tuner status.
>> I just stopped and started mythbackend via cli and the status in
>> mythfrontend info changed from "tuner x has an error" to "tuner x is not
>> recording".
>> Mythbackend.log looks like this:
>>
>> Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: N CoreContext
>> main_helpers.cpp:597 (run_backend) MythBackend: Starting up as the master
>> server.
>> Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: I LogForward
>> loggingserver.cpp:295 (SyslogLogger) Added syslogging
>> Aug 12 09:14:47 mythpc mythbackend: mythbackend[3130]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune) DVBChan[1](/dev/dvb/adapter0/frontend0):
>> Next tuning after less than 1000ms. Delaying by 1000ms
>> Aug 12 09:14:51 mythpc mythbackend: mythbackend[3130]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune) DVBChan[3](/dev/dvb/adapter1/frontend0):
>> Next tuning after less than 1000ms. Delaying by 1000ms
>> Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: W CoreContext
>> scheduler.cpp:214 (VerifyCards) Scheduler: Listings source '' is defined,
>> but is not attached to a card input.
>> Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: I CoreContext
>> programinfo.cpp:2368 (CheckProgramIDAuthorities) Found 1 distinct programid
>> authorities
>>
>> I don't have an .xmltv config file at the moment so I was unable to check
>> the actual tuning of stations.
>>
>> I think we may be getting somewhere.
>> Modifying Systemd_mythbackend_Configuration looks daunting.
>>
>>
>> _______________________________________________
>> 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, 12 Aug 2016 09:27:47 +1200, you wrote:

>
>> Yes, the device setup seems fine. I was mixing up the multirec card
>> numbers with the physical card numbers. Your full log makes it clear
>> that there are two multirec tuners per physical tuner and they seem
>> assigned correctly.
>>
>> The idea that the tuners are not ready when mythbackend starts is
>> quite plausible when booting from an SSD. Systemd makes the startup
>> faster too, and the tuners take a while to load their firmware.
>> Fortunately, it is easy just to restart mythbackend once booting is
>> complete and mythfrontend is running. If the tuners work then, that
>> race condition is the problem and you will need to adjust the systemd
>> rules for mythbackend startup so that it waits for the tuner devices.
>> Take a look at this page for suggestions about how to do it:
>>
>> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>>
>> In Mythbuntu 16.04, if you want to make any changes to the systemd
>> mythtv-backend.service file, you can apparently just use "override
>> files". See here:
>>
>> https://wiki.ubuntu.com/SystemdForUpstartUsers
>>
>> I have not tried that yet, so I do not know how well it works.
>>
>> If override files do not work, or the changes are too great, you need
>> to copy mythtv-backend.service from /lib/systemd/system to
>> /etc/systemd/system and modify it there. And when mythbackend gets
>> updated, you need to check if there were any changes in the
>> /lib/systemd/system version of the file that need to also be done in
>> the /etc/systemd/system copy.
>>
>
>I'll correct my last statement.I had stopped and started mythbackend via
>the GUI many times and did not see a change in the tuner status.
>I just stopped and started mythbackend via cli and the status in
>mythfrontend info changed from "tuner x has an error" to "tuner x is not
>recording".

I had no idea there was a GUI way of stopping tasks. What were you
using?

> Mythbackend.log looks like this:
>
>Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: N CoreContext
>main_helpers.cpp:597 (run_backend) MythBackend: Starting up as the master
>server.
>Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: I LogForward
>loggingserver.cpp:295 (SyslogLogger) Added syslogging
>Aug 12 09:14:47 mythpc mythbackend: mythbackend[3130]: I CoreContext
>recorders/dvbchannel.cpp:712 (Tune)
>DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
>1000ms. Delaying by 1000ms
>Aug 12 09:14:51 mythpc mythbackend: mythbackend[3130]: I CoreContext
>recorders/dvbchannel.cpp:712 (Tune)
>DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
>1000ms. Delaying by 1000ms
>Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: W CoreContext
>scheduler.cpp:214 (VerifyCards) Scheduler: Listings source '' is defined,
>but is not attached to a card input.
>Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: I CoreContext
>programinfo.cpp:2368 (CheckProgramIDAuthorities) Found 1 distinct
>programid authorities
>
>I don't have an .xmltv config file at the moment so I was unable to check
>the actual tuning of stations.

There is no need to have EPG data to get tuners to record. You can
test with LiveTV or by creating a manual recording rule without EPG.

>I think we may be getting somewhere.
>Modifying Systemd_mythbackend_Configuration looks daunting.

I am sure we can work it out - I will fire up my 16.04 test box and
see how 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/

On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:

>>Modifying Systemd_mythbackend_Configuration looks daunting.
>
>I am sure we can work it out - I will fire up my 16.04 test box and
>see how it works.

I have done some experimenting on my test box now, and I have some
config files that should work to make systemd wait for the HVR-2200
tuners before starting mythbackend.

First, you need to tie down the tuner numbers so that the HVR-2200
tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
this file (the name does not matter, but the .conf does):

/etc/modprobe.d/options-dvb.conf

and put these two lines in it:

#Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
only).
options saa7164 adapter_nr=0,1

Then add the new systemd "drop-in" override file. First create a new
directory:

sudo mkdir /etc/systemd/system/mythtv-backend.service.d

Then in that directory, create a new file mythtv-backend-override.conf
(again, the name does not matter but the .conf does). In that file,
put the following five lines:

[Unit]
Wants=dev-dvb-adapter0-frontend0.device
Wants=dev-dvb-adapter1-frontend0.device
After=dev-dvb-adapter0-frontend0.device
After=dev-dvb-adapter1-frontend0.device

That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
/dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
either device does not exist, systemd will eventually timeout waiting
for the devices to appear and then start mythbackend anyway, but the
timeout is quite long. I am just guessing, but it seemed like about
60 seconds.

_______________________________________________
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, 12 Aug 2016 13:23:21 +1200, Nick Rout <nick.rout@gmail.com> wrote:

> Also this is weird:
>
> Listings source '' is defined, but is not attached to a card input.
>
> Looks like you didn't complete your setup.

I noted that. As far as I can see I have completed capture card set up
and input sources correctly.Certainly I have the same values in all the
feilds as I have in 12.04
>
>
> On Fri, Aug 12, 2016 at 1:22 PM, Nick Rout <nick.rout@gmail.com> wrote:
>> To eliminate possible problems with your DVB card drivers, why not try
>> just with the HDHR. They are very reliable.

I was also having problems with the HDHR tuners.They were not functional
either,so I decided to get the PCIe card sorted first.

.
>>>
>>
>> I'll correct my last statement.I had stopped and started mythbackend via
>> the GUI many times and did not see a change in the tuner status.
>> I just stopped and started mythbackend via cli and the status in
>> mythfrontend info changed from "tuner x has an error" to "tuner x is not
>> recording".
>
> I had no idea there was a GUI way of stopping tasks. What were you
> using?

By that I meant when the backend setup application is stared it asks to
stop mythbackend and to restart when the app is closed.
>
>> Mythbackend.log looks like this:
>>
>> Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: N CoreContext
>> main_helpers.cpp:597 (run_backend) MythBackend: Starting up as the
>> master
>> server.
>> Aug 12 09:14:40 mythpc mythbackend: mythbackend[3130]: I LogForward
>> loggingserver.cpp:295 (SyslogLogger) Added syslogging
>> Aug 12 09:14:47 mythpc mythbackend: mythbackend[3130]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>> Aug 12 09:14:51 mythpc mythbackend: mythbackend[3130]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>> Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: W CoreContext
>> scheduler.cpp:214 (VerifyCards) Scheduler: Listings source '' is
>> defined,
>> but is not attached to a card input.
>> Aug 12 09:14:52 mythpc mythbackend: mythbackend[3130]: I CoreContext
>> programinfo.cpp:2368 (CheckProgramIDAuthorities) Found 1 distinct
>> programid authorities
>>
>> I don't have an .xmltv config file at the moment so I was unable to
>> check
>> the actual tuning of stations.
>
> There is no need to have EPG data to get tuners to record. You can
> test with LiveTV or by creating a manual recording rule without EPG.
>
>> I think we may be getting somewhere.
>> Modifying Systemd_mythbackend_Configuration looks daunting.
>
> I am sure we can work it out - I will fire up my 16.04 test box and
> see how 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/

_______________________________________________
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, 12 Aug 2016 21:18:09 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:
>
>>> Modifying Systemd_mythbackend_Configuration looks daunting.
>>
>> I am sure we can work it out - I will fire up my 16.04 test box and
>> see how it works.
>
> I have done some experimenting on my test box now, and I have some
> config files that should work to make systemd wait for the HVR-2200
> tuners before starting mythbackend.
>
> First, you need to tie down the tuner numbers so that the HVR-2200
> tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
> this file (the name does not matter, but the .conf does):
>
> /etc/modprobe.d/options-dvb.conf
>
> and put these two lines in it:
>
> #Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
> only).
> options saa7164 adapter_nr=0,1
>
> Then add the new systemd "drop-in" override file. First create a new
> directory:
>
> sudo mkdir /etc/systemd/system/mythtv-backend.service.d
>
> Then in that directory, create a new file mythtv-backend-override.conf
> (again, the name does not matter but the .conf does). In that file,
> put the following five lines:
>
> [Unit]
> Wants=dev-dvb-adapter0-frontend0.device
> Wants=dev-dvb-adapter1-frontend0.device
> After=dev-dvb-adapter0-frontend0.device
> After=dev-dvb-adapter1-frontend0.device
>
> That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
> /dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
> either device does not exist, systemd will eventually timeout waiting
> for the devices to appear and then start mythbackend anyway, but the
> timeout is quite long. I am just guessing, but it seemed like about
> 60 seconds.
>

Ok, that seems to work well.I have rebooted a few times and can tune live
tv now.
Thanks for doing the tests on those mods.I had to call the file in
mythtv-backend.service.d mythtv_backend_override.conf as I could not save
the file with dashes in the file name.

I will add the HDHR tuners now and see if they still have problems.
Then look to see why my xmltv script isn't populating the guide.I am
getting
"Unknown xmltv channel identifier: tv2-plus1.freeviewnz.tv - Skipping
channel." for all channels but it was working before.

Cheers

_______________________________________________
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, 12 Aug 2016 21:18:09 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:
>
>>> Modifying Systemd_mythbackend_Configuration looks daunting.
>>
>> I am sure we can work it out - I will fire up my 16.04 test box and
>> see how it works.
>
> I have done some experimenting on my test box now, and I have some
> config files that should work to make systemd wait for the HVR-2200
> tuners before starting mythbackend.
>
> First, you need to tie down the tuner numbers so that the HVR-2200
> tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
> this file (the name does not matter, but the .conf does):
>
> /etc/modprobe.d/options-dvb.conf
>
> and put these two lines in it:
>
> #Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
> only).
> options saa7164 adapter_nr=0,1
>
> Then add the new systemd "drop-in" override file. First create a new
> directory:
>
> sudo mkdir /etc/systemd/system/mythtv-backend.service.d
>
> Then in that directory, create a new file mythtv-backend-override.conf
> (again, the name does not matter but the .conf does). In that file,
> put the following five lines:
>
> [Unit]
> Wants=dev-dvb-adapter0-frontend0.device
> Wants=dev-dvb-adapter1-frontend0.device
> After=dev-dvb-adapter0-frontend0.device
> After=dev-dvb-adapter1-frontend0.device
>
> That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
> /dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
> either device does not exist, systemd will eventually timeout waiting
> for the devices to appear and then start mythbackend anyway, but the
> timeout is quite long. I am just guessing, but it seemed like about
> 60 seconds.
>

The HDHR tuners work fine too.
The Backend takes a long time to start,now.About 1.5 mins.It seems the
tuner cards are holding things up.I can probably live with it.
Here's a section from syslog:

Aug 13 11:02:33 mythpc kernel: [ 17.539314] DVB: registering new adapter
(saa7164)
Aug 13 11:02:33 mythpc kernel: [ 17.539319] saa7164 0000:03:00.0: DVB:
registering adapter 1 frontend 0 (NXP TDA10048HN DVB-T)...
Aug 13 11:02:34 mythpc kernel: [ 17.575686] saa7164[0]: registered
device video0 [mpeg]
Aug 13 11:02:34 mythpc kernel: [ 17.802040] saa7164[0]: registered
device video1 [mpeg]
Aug 13 11:02:34 mythpc kernel: [ 18.013816] saa7164[0]: registered
device vbi0 [vbi]
Aug 13 11:02:34 mythpc kernel: [ 18.013964] saa7164[0]: registered
device vbi1 [vbi]
Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter1-frontend0.device: Job
dev-dvb-adapter1-frontend0.device/start timed out.
Aug 13 11:03:48 mythpc systemd[1]: Timed out waiting for device
dev-dvb-adapter1-frontend0.device.
Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter1-frontend0.device: Job
dev-dvb-adapter1-frontend0.device/start failed with result 'timeout'.
Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter0-frontend0.device: Job
dev-dvb-adapter0-frontend0.device/start timed out.
Aug 13 11:03:48 mythpc systemd[1]: Timed out waiting for device
dev-dvb-adapter0-frontend0.device.
Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter0-frontend0.device: Job
dev-dvb-adapter0-frontend0.device/start failed with result 'timeout'.
Aug 13 11:03:48 mythpc systemd[1]: Started MythTV Backend.
Aug 13 11:03:48 mythpc systemd[1]: Reached target Multi-User System.
Aug 13 11:03:48 mythpc systemd[1]: Reached target Graphical Interface.
Aug 13 11:03:48 mythpc systemd[1]: Started Stop ureadahead data collection
45s after completed startup.
Aug 13 11:03:48 mythpc systemd[1]: Starting Update UTMP about System
Runlevel Changes...
Aug 13 11:03:48 mythpc systemd[1]: Started Update UTMP about System
Runlevel Changes.
Aug 13 11:03:48 mythpc systemd[1]: Startup finished in 1.798s (kernel) +
1min 30.619s (userspace) = 1min 32.418s.
Aug 13 11:03:49 mythpc kernel: [ 92.670822] tda10048_firmware_upload:
waiting for firmware upload (dvb-fe-tda10048-1.0.fw)...
Aug 13 11:03:49 mythpc kernel: [ 92.671115] tda10048_firmware_upload:
firmware read 24878 bytes.
Aug 13 11:03:49 mythpc kernel: [ 92.671118] tda10048_firmware_upload:
firmware uploading
Aug 13 11:03:52 mythpc kernel: [ 95.647746] tda10048_firmware_upload:
firmware uploaded
Aug 13 11:03:52 mythpc kernel: [ 95.718869] tda18271: performing RF
tracking filter calibration
Aug 13 11:03:54 mythpc kernel: [ 98.071954] tda18271: RF tracking filter
calibration complete
Aug 13 11:03:56 mythpc kernel: [ 99.888159] tda10048_firmware_upload:
waiting for firmware upload (dvb-fe-tda10048-1.0.fw)...
Aug 13 11:03:56 mythpc kernel: [ 99.888203] tda10048_firmware_upload:
firmware read 24878 bytes.
Aug 13 11:03:56 mythpc kernel: [ 99.888204] tda10048_firmware_upload:
firmware uploading
Aug 13 11:03:59 mythpc kernel: [ 102.851201] tda10048_firmware_upload:
firmware uploaded
Aug 13 11:04:34 mythpc systemd[1]: Starting Stop ureadahead data
collection...
Aug 13 11:04:34 mythpc systemd[1]: Stopped Read required files in advance.
Aug 13 11:04:34 mythpc systemd[1]: Started Stop ureadahead data collection.



Also, the reboot and shutdown options in frontend have ceased to
function.These are performed by /sbin/reboot and /sbin/poweroff correct?

_______________________________________________
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, 13 Aug 2016 09:51:21 +1200, you wrote:

>On Fri, 12 Aug 2016 21:18:09 +1200, Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>
>> On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:
>>
>>>> Modifying Systemd_mythbackend_Configuration looks daunting.
>>>
>>> I am sure we can work it out - I will fire up my 16.04 test box and
>>> see how it works.
>>
>> I have done some experimenting on my test box now, and I have some
>> config files that should work to make systemd wait for the HVR-2200
>> tuners before starting mythbackend.
>>
>> First, you need to tie down the tuner numbers so that the HVR-2200
>> tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
>> this file (the name does not matter, but the .conf does):
>>
>> /etc/modprobe.d/options-dvb.conf
>>
>> and put these two lines in it:
>>
>> #Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
>> only).
>> options saa7164 adapter_nr=0,1
>>
>> Then add the new systemd "drop-in" override file. First create a new
>> directory:
>>
>> sudo mkdir /etc/systemd/system/mythtv-backend.service.d
>>
>> Then in that directory, create a new file mythtv-backend-override.conf
>> (again, the name does not matter but the .conf does). In that file,
>> put the following five lines:
>>
>> [Unit]
>> Wants=dev-dvb-adapter0-frontend0.device
>> Wants=dev-dvb-adapter1-frontend0.device
>> After=dev-dvb-adapter0-frontend0.device
>> After=dev-dvb-adapter1-frontend0.device
>>
>> That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
>> /dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
>> either device does not exist, systemd will eventually timeout waiting
>> for the devices to appear and then start mythbackend anyway, but the
>> timeout is quite long. I am just guessing, but it seemed like about
>> 60 seconds.
>>
>
>Ok, that seems to work well.I have rebooted a few times and can tune live
>tv now.
>Thanks for doing the tests on those mods.I had to call the file in
>mythtv-backend.service.d mythtv_backend_override.conf as I could not save
>the file with dashes in the file name.

That will just be a limitation of the program you used to edit the
file - dashes are valid in Linux file names, but not all software
understands that.

>I will add the HDHR tuners now and see if they still have problems.
>Then look to see why my xmltv script isn't populating the guide.I am
>getting
>"Unknown xmltv channel identifier: tv2-plus1.freeviewnz.tv - Skipping
>channel." for all channels but it was working before.

Do you have the <source name>.xmltv file in /home/<mythtv
for a channel, that is the error message you get. This is what I have
in my /home/stephen/.mythtv/FreeviewHD.xmltv file:

channel=tv1.freeviewnz.tv
channel=tv2.freeviewnz.tv
channel=tv3.freeviewnz.tv
channel=bravo.freeviewnz.tv
channel=maori-tv.freeviewnz.tv
channel=tv1-plus1.freeviewnz.tv
channel=tv2-plus1.freeviewnz.tv
channel=tv3-plus1.freeviewnz.tv
channel=bravo-plus1.freeviewnz.tv
channel=duke.freeviewnz.tv
channel=edge-tv.freeviewnz.tv
channel=prime.freeviewnz.tv
channel=choice.freeviewnz.tv
channel=hgtv.freeviewnz.tv
channel=shopping-channel.freeviewnz.tv
channel=parliament.freeviewnz.tv
channel=hope-channel.freeviewnz.tv
channel=fashiontv.freeviewnz.tv
channel=aljazeera.freeviewnz.tv
channel=te-reo.freeviewnz.tv
channel!shine.freeviewnz.tv
channel=firstlight.freeviewnz.tv
channel=sommet-sports.freeviewnz.tv
channel=tvsn-shopping-channel.freeviewnz.tv
channel=chinese-tv8.freeviewnz.tv
channel=tv33.freeviewnz.tv
channel=yes-shop.freeviewnz.tv
channel=apna.freeviewnz.tv
channel=rnz-national.freeviewnz.tv
channel=rnz-concert.freeviewnz.tv
channel=basefm.freeviewnz.tv

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

_______________________________________________
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, 13 Aug 2016 14:33:22 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Sat, 13 Aug 2016 09:51:21 +1200, you wrote:
>
>> On Fri, 12 Aug 2016 21:18:09 +1200, Stephen Worthington
>> <stephen_agent@jsw.gen.nz> wrote:
>>
>>> On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:
>>>
>>>>> Modifying Systemd_mythbackend_Configuration looks daunting.
>>>>
>>>> I am sure we can work it out - I will fire up my 16.04 test box and
>>>> see how it works.
>>>
>>> I have done some experimenting on my test box now, and I have some
>>> config files that should work to make systemd wait for the HVR-2200
>>> tuners before starting mythbackend.
>>>
>>> First, you need to tie down the tuner numbers so that the HVR-2200
>>> tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
>>> this file (the name does not matter, but the .conf does):
>>>
>>> /etc/modprobe.d/options-dvb.conf
>>>
>>> and put these two lines in it:
>>>
>>> #Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
>>> only).
>>> options saa7164 adapter_nr=0,1
>>>
>>> Then add the new systemd "drop-in" override file. First create a new
>>> directory:
>>>
>>> sudo mkdir /etc/systemd/system/mythtv-backend.service.d
>>>
>>> Then in that directory, create a new file mythtv-backend-override.conf
>>> (again, the name does not matter but the .conf does). In that file,
>>> put the following five lines:
>>>
>>> [Unit]
>>> Wants=dev-dvb-adapter0-frontend0.device
>>> Wants=dev-dvb-adapter1-frontend0.device
>>> After=dev-dvb-adapter0-frontend0.device
>>> After=dev-dvb-adapter1-frontend0.device
>>>
>>> That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
>>> /dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
>>> either device does not exist, systemd will eventually timeout waiting
>>> for the devices to appear and then start mythbackend anyway, but the
>>> timeout is quite long. I am just guessing, but it seemed like about
>>> 60 seconds.
>>>
>>
>> Ok, that seems to work well.I have rebooted a few times and can tune
>> live
>> tv now.
>> Thanks for doing the tests on those mods.I had to call the file in
>> mythtv-backend.service.d mythtv_backend_override.conf as I could not
>> save
>> the file with dashes in the file name.
>
> That will just be a limitation of the program you used to edit the
> file - dashes are valid in Linux file names, but not all software

I tried gedit and nano both objected.Not to worry ,it's ok as is.

> understands that.
>
>> I will add the HDHR tuners now and see if they still have problems.
>> Then look to see why my xmltv script isn't populating the guide.I am
>> getting
>> "Unknown xmltv channel identifier: tv2-plus1.freeviewnz.tv - Skipping
>> channel." for all channels but it was working before.
>
> Do you have the <source name>.xmltv file in /home/<mythtv
> user>/.mythtv? If you do not have a "channel" line in the .xmltv file
> for a channel, that is the error message you get. This is what I have
> in my /home/stephen/.mythtv/FreeviewHD.xmltv file:
>
> channel=tv1.freeviewnz.tv
> channel=tv2.freeviewnz.tv
> channel=tv3.freeviewnz.tv
> channel=bravo.freeviewnz.tv
> channel=maori-tv.freeviewnz.tv
> channel=tv1-plus1.freeviewnz.tv
> channel=tv2-plus1.freeviewnz.tv
> channel=tv3-plus1.freeviewnz.tv
> channel=bravo-plus1.freeviewnz.tv
> channel=duke.freeviewnz.tv
> channel=edge-tv.freeviewnz.tv
> channel=prime.freeviewnz.tv
> channel=choice.freeviewnz.tv
> channel=hgtv.freeviewnz.tv
> channel=shopping-channel.freeviewnz.tv
> channel=parliament.freeviewnz.tv
> channel=hope-channel.freeviewnz.tv
> channel=fashiontv.freeviewnz.tv
> channel=aljazeera.freeviewnz.tv
> channel=te-reo.freeviewnz.tv
> channel!shine.freeviewnz.tv
> channel=firstlight.freeviewnz.tv
> channel=sommet-sports.freeviewnz.tv
> channel=tvsn-shopping-channel.freeviewnz.tv
> channel=chinese-tv8.freeviewnz.tv
> channel=tv33.freeviewnz.tv
> channel=yes-shop.freeviewnz.tv
> channel=apna.freeviewnz.tv
> channel=rnz-national.freeviewnz.tv
> channel=rnz-concert.freeviewnz.tv
> channel=basefm.freeviewnz.tv
>
>> Cheers

I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv in
either 12.04 or 16.04 so I don't know why 12.04 works.
I'll create the file.

_______________________________________________
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 13/08/16 14:33, Stephen Worthington wrote:
> Do you have the <source name>.xmltv file in /home/<mythtv
> user>/.mythtv? If you do not have a "channel" line in the .xmltv file
> for a channel, that is the error message you get. This is what I have
> in my /home/stephen/.mythtv/FreeviewHD.xmltv file:
>
I had to create a symlink on my backend.......

sudo ln -s /home/robert/.mythtv/Freeview.xmltv
/home/mythtv/.mythtv/Freeview.xmltv

_______________________________________________
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 13/08/16 14:42, Paulgir wrote:
> I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv
> in either 12.04 or 16.04 so I don't know why 12.04 works.
> I'll create the file.
As per my previous email
I had to create a symlink on my backend.......

sudo ln -s /home/robert/.mythtv/Freeview.xmltv
/home/mythtv/.mythtv/Freeview.xmltv

On Sat, 13 Aug 2016 14:56:11 +1200, Robert Fisher <robert@fisher.net.nz>
wrote:

> On 13/08/16 14:42, Paulgir wrote:
>> I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv
>> in either 12.04 or 16.04 so I don't know why 12.04 >>works.I'll create
>> the file.
> As per my previous email
> I had to create a symlink on my backend.......
> sudo ln -s /home/robert/.mythtv/Freeview.xmltv
> /home/mythtv/.mythtv/Freeview.xmltv

Thanks.I'll check it out.

On Sat, 13 Aug 2016 12:13:31 +1200, you wrote:

>On Fri, 12 Aug 2016 21:18:09 +1200, Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>
>> On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:
>>
>>>> Modifying Systemd_mythbackend_Configuration looks daunting.
>>>
>>> I am sure we can work it out - I will fire up my 16.04 test box and
>>> see how it works.
>>
>> I have done some experimenting on my test box now, and I have some
>> config files that should work to make systemd wait for the HVR-2200
>> tuners before starting mythbackend.
>>
>> First, you need to tie down the tuner numbers so that the HVR-2200
>> tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
>> this file (the name does not matter, but the .conf does):
>>
>> /etc/modprobe.d/options-dvb.conf
>>
>> and put these two lines in it:
>>
>> #Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
>> only).
>> options saa7164 adapter_nr=0,1
>>
>> Then add the new systemd "drop-in" override file. First create a new
>> directory:
>>
>> sudo mkdir /etc/systemd/system/mythtv-backend.service.d
>>
>> Then in that directory, create a new file mythtv-backend-override.conf
>> (again, the name does not matter but the .conf does). In that file,
>> put the following five lines:
>>
>> [Unit]
>> Wants=dev-dvb-adapter0-frontend0.device
>> Wants=dev-dvb-adapter1-frontend0.device
>> After=dev-dvb-adapter0-frontend0.device
>> After=dev-dvb-adapter1-frontend0.device
>>
>> That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
>> /dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
>> either device does not exist, systemd will eventually timeout waiting
>> for the devices to appear and then start mythbackend anyway, but the
>> timeout is quite long. I am just guessing, but it seemed like about
>> 60 seconds.
>>
>
>The HDHR tuners work fine too.
>The Backend takes a long time to start,now.About 1.5 mins.It seems the
>tuner cards are holding things up.I can probably live with it.
>Here's a section from syslog:
>
>Aug 13 11:02:33 mythpc kernel: [ 17.539314] DVB: registering new adapter
>(saa7164)
>Aug 13 11:02:33 mythpc kernel: [ 17.539319] saa7164 0000:03:00.0: DVB:
>registering adapter 1 frontend 0 (NXP TDA10048HN DVB-T)...
>Aug 13 11:02:34 mythpc kernel: [ 17.575686] saa7164[0]: registered
>device video0 [mpeg]
>Aug 13 11:02:34 mythpc kernel: [ 17.802040] saa7164[0]: registered
>device video1 [mpeg]
>Aug 13 11:02:34 mythpc kernel: [ 18.013816] saa7164[0]: registered
>device vbi0 [vbi]
>Aug 13 11:02:34 mythpc kernel: [ 18.013964] saa7164[0]: registered
>device vbi1 [vbi]
>Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter1-frontend0.device: Job
>dev-dvb-adapter1-frontend0.device/start timed out.
>Aug 13 11:03:48 mythpc systemd[1]: Timed out waiting for device
>dev-dvb-adapter1-frontend0.device.
>Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter1-frontend0.device: Job
>dev-dvb-adapter1-frontend0.device/start failed with result 'timeout'.
>Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter0-frontend0.device: Job
>dev-dvb-adapter0-frontend0.device/start timed out.
>Aug 13 11:03:48 mythpc systemd[1]: Timed out waiting for device
>dev-dvb-adapter0-frontend0.device.
>Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter0-frontend0.device: Job
>dev-dvb-adapter0-frontend0.device/start failed with result 'timeout'.

That is not good. The new systemd jobs to detect the creation of the
tuners are not actually working. Instead, they are timing out. The
timeout is long enough so that when mythbackend gets started, the
tuner devices are actually present, so mythbackend seems to be seeing
working tuners once it gets started, but the timeouts likely slow down
booting much more than needs to happen.

>Aug 13 11:03:48 mythpc systemd[1]: Started MythTV Backend.
>Aug 13 11:03:48 mythpc systemd[1]: Reached target Multi-User System.
>Aug 13 11:03:48 mythpc systemd[1]: Reached target Graphical Interface.
>Aug 13 11:03:48 mythpc systemd[1]: Started Stop ureadahead data collection
>45s after completed startup.
>Aug 13 11:03:48 mythpc systemd[1]: Starting Update UTMP about System
>Runlevel Changes...
>Aug 13 11:03:48 mythpc systemd[1]: Started Update UTMP about System
>Runlevel Changes.
>Aug 13 11:03:48 mythpc systemd[1]: Startup finished in 1.798s (kernel) +
>1min 30.619s (userspace) = 1min 32.418s.
>Aug 13 11:03:49 mythpc kernel: [ 92.670822] tda10048_firmware_upload:
>waiting for firmware upload (dvb-fe-tda10048-1.0.fw)...
>Aug 13 11:03:49 mythpc kernel: [ 92.671115] tda10048_firmware_upload:
>firmware read 24878 bytes.
>Aug 13 11:03:49 mythpc kernel: [ 92.671118] tda10048_firmware_upload:
>firmware uploading
>Aug 13 11:03:52 mythpc kernel: [ 95.647746] tda10048_firmware_upload:
>firmware uploaded
>Aug 13 11:03:52 mythpc kernel: [ 95.718869] tda18271: performing RF
>tracking filter calibration
>Aug 13 11:03:54 mythpc kernel: [ 98.071954] tda18271: RF tracking filter
>calibration complete
>Aug 13 11:03:56 mythpc kernel: [ 99.888159] tda10048_firmware_upload:
>waiting for firmware upload (dvb-fe-tda10048-1.0.fw)...
>Aug 13 11:03:56 mythpc kernel: [ 99.888203] tda10048_firmware_upload:
>firmware read 24878 bytes.
>Aug 13 11:03:56 mythpc kernel: [ 99.888204] tda10048_firmware_upload:
>firmware uploading
>Aug 13 11:03:59 mythpc kernel: [ 102.851201] tda10048_firmware_upload:
>firmware uploaded

And here more firmware is loaded for the HVR-2200 tuners, AFTER
mythbackend has been started. So the HVR-2200 tuners may not actually
have been fully working when mythbackend was started. On the LinuxTV
Wiki page:

https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200

there are reports that recording has problems every half an hour or so
without the dvb-fe-tda10048-1.0.fw file being loaded, so it may be
that having loaded late is OK, but it is still a bad idea. But it may
also be that the dvb-fe-tda10048-1.0.fw firmware file never gets
loaded until something tries to use the HVR-2200 tuners, which
mythbackend does at startup.

Please do two test runs, where you boot, wait for everything to start
up, then run LiveTV on a channel, watch for a few seconds, then stop
it. Do that in both 12.04 and 16.04 and post the complete syslog and
mythbackend.log file from start of booting until LiveTV is finished.

>Aug 13 11:04:34 mythpc systemd[1]: Starting Stop ureadahead data
>collection...
>Aug 13 11:04:34 mythpc systemd[1]: Stopped Read required files in advance.
>Aug 13 11:04:34 mythpc systemd[1]: Started Stop ureadahead data collection.
>
>
>
>Also, the reboot and shutdown options in frontend have ceased to
>function.These are performed by /sbin/reboot and /sbin/poweroff correct?

Yes and no. Before systemd, the reboot command was a real executable
file and poweroff was a link to the reboot file. The reboot file
detected whether it was called via the poweroff link or directly in
order to decide whether it should just power off or reboot. Now, that
function is done by systemctl and both reboot and poweroff are links
to /bin/systemctl and systemctl detects whether it is being run via a
link as to which function it should perform. So if the /sbin links to
systemctl do not work now for some reason when used from MythTV, you
should probably just put the base command into the MythTV settings
instead of using the links:

/bin/systemctl reboot
/bin/systemctl poweroff

_______________________________________________
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, 13 Aug 2016 14:42:24 +1200, you wrote:

>On Sat, 13 Aug 2016 14:33:22 +1200, Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>
>> On Sat, 13 Aug 2016 09:51:21 +1200, you wrote:
>>
>>> On Fri, 12 Aug 2016 21:18:09 +1200, Stephen Worthington
>>> <stephen_agent@jsw.gen.nz> wrote:
>>>
>>>> On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:
>>>>
>>>>>> Modifying Systemd_mythbackend_Configuration looks daunting.
>>>>>
>>>>> I am sure we can work it out - I will fire up my 16.04 test box and
>>>>> see how it works.
>>>>
>>>> I have done some experimenting on my test box now, and I have some
>>>> config files that should work to make systemd wait for the HVR-2200
>>>> tuners before starting mythbackend.
>>>>
>>>> First, you need to tie down the tuner numbers so that the HVR-2200
>>>> tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
>>>> this file (the name does not matter, but the .conf does):
>>>>
>>>> /etc/modprobe.d/options-dvb.conf
>>>>
>>>> and put these two lines in it:
>>>>
>>>> #Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
>>>> only).
>>>> options saa7164 adapter_nr=0,1
>>>>
>>>> Then add the new systemd "drop-in" override file. First create a new
>>>> directory:
>>>>
>>>> sudo mkdir /etc/systemd/system/mythtv-backend.service.d
>>>>
>>>> Then in that directory, create a new file mythtv-backend-override.conf
>>>> (again, the name does not matter but the .conf does). In that file,
>>>> put the following five lines:
>>>>
>>>> [Unit]
>>>> Wants=dev-dvb-adapter0-frontend0.device
>>>> Wants=dev-dvb-adapter1-frontend0.device
>>>> After=dev-dvb-adapter0-frontend0.device
>>>> After=dev-dvb-adapter1-frontend0.device
>>>>
>>>> That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
>>>> /dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
>>>> either device does not exist, systemd will eventually timeout waiting
>>>> for the devices to appear and then start mythbackend anyway, but the
>>>> timeout is quite long. I am just guessing, but it seemed like about
>>>> 60 seconds.
>>>>
>>>
>>> Ok, that seems to work well.I have rebooted a few times and can tune
>>> live
>>> tv now.
>>> Thanks for doing the tests on those mods.I had to call the file in
>>> mythtv-backend.service.d mythtv_backend_override.conf as I could not
>>> save
>>> the file with dashes in the file name.
>>
>> That will just be a limitation of the program you used to edit the
>> file - dashes are valid in Linux file names, but not all software
>
>I tried gedit and nano both objected.Not to worry ,it's ok as is.
>
>> understands that.
>>
>>> I will add the HDHR tuners now and see if they still have problems.
>>> Then look to see why my xmltv script isn't populating the guide.I am
>>> getting
>>> "Unknown xmltv channel identifier: tv2-plus1.freeviewnz.tv - Skipping
>>> channel." for all channels but it was working before.
>>
>> Do you have the <source name>.xmltv file in /home/<mythtv
>> user>/.mythtv? If you do not have a "channel" line in the .xmltv file
>> for a channel, that is the error message you get. This is what I have
>> in my /home/stephen/.mythtv/FreeviewHD.xmltv file:
>>
>> channel=tv1.freeviewnz.tv
>> channel=tv2.freeviewnz.tv
>> channel=tv3.freeviewnz.tv
>> channel=bravo.freeviewnz.tv
>> channel=maori-tv.freeviewnz.tv
>> channel=tv1-plus1.freeviewnz.tv
>> channel=tv2-plus1.freeviewnz.tv
>> channel=tv3-plus1.freeviewnz.tv
>> channel=bravo-plus1.freeviewnz.tv
>> channel=duke.freeviewnz.tv
>> channel=edge-tv.freeviewnz.tv
>> channel=prime.freeviewnz.tv
>> channel=choice.freeviewnz.tv
>> channel=hgtv.freeviewnz.tv
>> channel=shopping-channel.freeviewnz.tv
>> channel=parliament.freeviewnz.tv
>> channel=hope-channel.freeviewnz.tv
>> channel=fashiontv.freeviewnz.tv
>> channel=aljazeera.freeviewnz.tv
>> channel=te-reo.freeviewnz.tv
>> channel!shine.freeviewnz.tv
>> channel=firstlight.freeviewnz.tv
>> channel=sommet-sports.freeviewnz.tv
>> channel=tvsn-shopping-channel.freeviewnz.tv
>> channel=chinese-tv8.freeviewnz.tv
>> channel=tv33.freeviewnz.tv
>> channel=yes-shop.freeviewnz.tv
>> channel=apna.freeviewnz.tv
>> channel=rnz-national.freeviewnz.tv
>> channel=rnz-concert.freeviewnz.tv
>> channel=basefm.freeviewnz.tv
>>
>>> Cheers
>
>I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv in
>either 12.04 or 16.04 so I don't know why 12.04 works.
>I'll create the file.

The <mythtv user> bit in the file path is a placeholder for whatever
user name you use that runs mythfrontend. Mythfilldatabase, in my
system, is run by that user. I do not use the standard system for
running mythfilldatabase though, so I am not entirely sure if the
.xmltv file needs to be in /home/mythtv/.mythtv (if mythfilldatabase
is run by user mythtv) or in /home/<mythtv user>/.mythtv (if it is run
by the user that runs mythfrontend). To be safe, I think it should
probably be put in /home/mythtv/.mythtv, and then these commands used
to put a link to it under the mythfrontend user:

cd /home/<mythtv user>.mythtv
ln -s /home/mythtv/.mythtv/<your .xmltv file>.xmltv

The name used for the .xmltv file needs to be the name used for
defining the MythTV "source", with the .xmltv extension added. My
source is "FreeviewHD" for my DVB-T channels and "SkyNZ-Digital" for
my DVB-S Sky channels. So I have two .xmltv files:

/home/stephen/.mythtv/FreeviewHD.xmltv
/home/stephen/.mythtv/SkyNZ-Digital.xmltv

The case of the filename must match.

In your case, if you are doing your EPG the same way in 12.04 and
16.04, you should already have the files in your 12.04 setup in the
right place, so the simple thing to do is to just copy them from there
to the same place in your 16.04 system.

The channels in the .xmltv files vary depending on what is available
in each part of the country, so just copying mine would not work
completely. And every time a new channel appears or one is renamed or
disappears, you have to make the corresponding change in your .xmltv
files manually, unless you completely delete all your channels and set
them up from scratch again (not recommended). The tv_grab_nz-py EPG
grabber does not have the ability to modify the .xmltv files, but
IIRC, it can create them on initial setup. But it is a long time
since I used tv_grab_nz-py like that, as I do my channel setup using
other means, so I may be wrong about that.

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

Given that you'll rarely (like once or twice a year if that) reboot your
backend
a small delay is not going to worry you too much is it?

On Sat, Aug 13, 2016 at 3:47 PM, Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sat, 13 Aug 2016 14:42:24 +1200, you wrote:
>
> >On Sat, 13 Aug 2016 14:33:22 +1200, Stephen Worthington
> ><stephen_agent@jsw.gen.nz> wrote:
> >
> >> On Sat, 13 Aug 2016 09:51:21 +1200, you wrote:
> >>
> >>> On Fri, 12 Aug 2016 21:18:09 +1200, Stephen Worthington
> >>> <stephen_agent@jsw.gen.nz> wrote:
> >>>
> >>>> On Fri, 12 Aug 2016 14:25:25 +1200, you wrote:
> >>>>
> >>>>>> Modifying Systemd_mythbackend_Configuration looks daunting.
> >>>>>
> >>>>> I am sure we can work it out - I will fire up my 16.04 test box and
> >>>>> see how it works.
> >>>>
> >>>> I have done some experimenting on my test box now, and I have some
> >>>> config files that should work to make systemd wait for the HVR-2200
> >>>> tuners before starting mythbackend.
> >>>>
> >>>> First, you need to tie down the tuner numbers so that the HVR-2200
> >>>> tuners are always /dev/dvb/adapter0 and /dev/dvb/adapter1. Create
> >>>> this file (the name does not matter, but the .conf does):
> >>>>
> >>>> /etc/modprobe.d/options-dvb.conf
> >>>>
> >>>> and put these two lines in it:
> >>>>
> >>>> #Set adapter numbers for Hauppauge HVR-2200 dual tuner (DVB-T tuners
> >>>> only).
> >>>> options saa7164 adapter_nr=0,1
> >>>>
> >>>> Then add the new systemd "drop-in" override file. First create a new
> >>>> directory:
> >>>>
> >>>> sudo mkdir /etc/systemd/system/mythtv-backend.service.d
> >>>>
> >>>> Then in that directory, create a new file mythtv-backend-override.conf
> >>>> (again, the name does not matter but the .conf does). In that file,
> >>>> put the following five lines:
> >>>>
> >>>> [Unit]
> >>>> Wants=dev-dvb-adapter0-frontend0.device
> >>>> Wants=dev-dvb-adapter1-frontend0.device
> >>>> After=dev-dvb-adapter0-frontend0.device
> >>>> After=dev-dvb-adapter1-frontend0.device
> >>>>
> >>>> That causes systemd to wait until /dev/dvb/adapter0/frontend0 and
> >>>> /dev/dvb/adapter1/frontend0 both exist before starting mythbackend. If
> >>>> either device does not exist, systemd will eventually timeout waiting
> >>>> for the devices to appear and then start mythbackend anyway, but the
> >>>> timeout is quite long. I am just guessing, but it seemed like about
> >>>> 60 seconds.
> >>>>
> >>>
> >>> Ok, that seems to work well.I have rebooted a few times and can tune
> >>> live
> >>> tv now.
> >>> Thanks for doing the tests on those mods.I had to call the file in
> >>> mythtv-backend.service.d mythtv_backend_override.conf as I could not
> >>> save
> >>> the file with dashes in the file name.
> >>
> >> That will just be a limitation of the program you used to edit the
> >> file - dashes are valid in Linux file names, but not all software
> >
> >I tried gedit and nano both objected.Not to worry ,it's ok as is.
> >
> >> understands that.
> >>
> >>> I will add the HDHR tuners now and see if they still have problems.
> >>> Then look to see why my xmltv script isn't populating the guide.I am
> >>> getting
> >>> "Unknown xmltv channel identifier: tv2-plus1.freeviewnz.tv - Skipping
> >>> channel." for all channels but it was working before.
> >>
> >> Do you have the <source name>.xmltv file in /home/<mythtv
> >> user>/.mythtv? If you do not have a "channel" line in the .xmltv file
> >> for a channel, that is the error message you get. This is what I have
> >> in my /home/stephen/.mythtv/FreeviewHD.xmltv file:
> >>
> >> channel=tv1.freeviewnz.tv
> >> channel=tv2.freeviewnz.tv
> >> channel=tv3.freeviewnz.tv
> >> channel=bravo.freeviewnz.tv
> >> channel=maori-tv.freeviewnz.tv
> >> channel=tv1-plus1.freeviewnz.tv
> >> channel=tv2-plus1.freeviewnz.tv
> >> channel=tv3-plus1.freeviewnz.tv
> >> channel=bravo-plus1.freeviewnz.tv
> >> channel=duke.freeviewnz.tv
> >> channel=edge-tv.freeviewnz.tv
> >> channel=prime.freeviewnz.tv
> >> channel=choice.freeviewnz.tv
> >> channel=hgtv.freeviewnz.tv
> >> channel=shopping-channel.freeviewnz.tv
> >> channel=parliament.freeviewnz.tv
> >> channel=hope-channel.freeviewnz.tv
> >> channel=fashiontv.freeviewnz.tv
> >> channel=aljazeera.freeviewnz.tv
> >> channel=te-reo.freeviewnz.tv
> >> channel!shine.freeviewnz.tv
> >> channel=firstlight.freeviewnz.tv
> >> channel=sommet-sports.freeviewnz.tv
> >> channel=tvsn-shopping-channel.freeviewnz.tv
> >> channel=chinese-tv8.freeviewnz.tv
> >> channel=tv33.freeviewnz.tv
> >> channel=yes-shop.freeviewnz.tv
> >> channel=apna.freeviewnz.tv
> >> channel=rnz-national.freeviewnz.tv
> >> channel=rnz-concert.freeviewnz.tv
> >> channel=basefm.freeviewnz.tv
> >>
> >>> Cheers
> >
> >I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv in
> >either 12.04 or 16.04 so I don't know why 12.04 works.
> >I'll create the file.
>
> The <mythtv user> bit in the file path is a placeholder for whatever
> user name you use that runs mythfrontend. Mythfilldatabase, in my
> system, is run by that user. I do not use the standard system for
> running mythfilldatabase though, so I am not entirely sure if the
> .xmltv file needs to be in /home/mythtv/.mythtv (if mythfilldatabase
> is run by user mythtv) or in /home/<mythtv user>/.mythtv (if it is run
> by the user that runs mythfrontend). To be safe, I think it should
> probably be put in /home/mythtv/.mythtv, and then these commands used
> to put a link to it under the mythfrontend user:
>
> cd /home/<mythtv user>.mythtv
> ln -s /home/mythtv/.mythtv/<your .xmltv file>.xmltv
>
> The name used for the .xmltv file needs to be the name used for
> defining the MythTV "source", with the .xmltv extension added. My
> source is "FreeviewHD" for my DVB-T channels and "SkyNZ-Digital" for
> my DVB-S Sky channels. So I have two .xmltv files:
>
> /home/stephen/.mythtv/FreeviewHD.xmltv
> /home/stephen/.mythtv/SkyNZ-Digital.xmltv
>
> The case of the filename must match.
>
> In your case, if you are doing your EPG the same way in 12.04 and
> 16.04, you should already have the files in your 12.04 setup in the
> right place, so the simple thing to do is to just copy them from there
> to the same place in your 16.04 system.
>
> The channels in the .xmltv files vary depending on what is available
> in each part of the country, so just copying mine would not work
> completely. And every time a new channel appears or one is renamed or
> disappears, you have to make the corresponding change in your .xmltv
> files manually, unless you completely delete all your channels and set
> them up from scratch again (not recommended). The tv_grab_nz-py EPG
> grabber does not have the ability to modify the .xmltv files, but
> IIRC, it can create them on initial setup. But it is a long time
> since I used tv_grab_nz-py like that, as I do my channel setup using
> other means, so I may be wrong about that.
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>

> The tv_grab_nz-py EPG
> grabber does not have the ability to modify the .xmltv files, but
> IIRC, it can create them on initial setup. But it is a long time
> since I used tv_grab_nz-py like that, as I do my channel setup using
> other means, so I may be wrong about that.
>
IIRC tv_grab_nz-py did try to create the xmltv file but did not complete
the job and I had to manually edit it.
(Was it a problem with the Maori TV special character or something?)

It is a documented problem but the easy fix for me was manually editing.

On Sat, 13 Aug 2016 19:08:21 +1200, Nick Rout <nick.rout@gmail.com> wrote:

> Given that you'll rarely (like once or twice a year if that) reboot your
> backend
> a small delay is not going to worry you too much is it?
>
> nz/

My setup is a combined BE/FE and I use Mythwelcome to start and stop the
system as needed.

>> The HDHR tuners work fine too.
>> The Backend takes a long time to start,now.About 1.5 mins.It seems the
>> tuner cards are holding things up.I can probably live with it.
>> Here's a section from syslog:
>>
>> Aug 13 11:02:33 mythpc kernel: [ 17.539314] DVB: registering newadapter
>> (saa7164)
>> Aug 13 11:02:33 mythpc kernel: [ 17.539319] saa7164 0000:03:00.0: DVB:
>> registering adapter 1 frontend 0 (NXP TDA10048HN DVB-T)...
>> Aug 13 11:02:34 mythpc kernel: [ 17.575686] saa7164[0]: registered
>> device video0 [mpeg]
>> Aug 13 11:02:34 mythpc kernel: [ 17.802040] saa7164[0]: registered
>> device video1 [mpeg]
>> Aug 13 11:02:34 mythpc kernel: [ 18.013816] saa7164[0]: registered
>> device vbi0 [vbi]
>> Aug 13 11:02:34 mythpc kernel: [ 18.013964] saa7164[0]: registered
>> device vbi1 [vbi]
>> Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter1-frontend0.device:Job
>> dev-dvb-adapter1-frontend0.device/start timed out.
>> Aug 13 11:03:48 mythpc systemd[1]: Timed out waiting for device
>> dev-dvb-adapter1-frontend0.device.
>> Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter1-frontend0.device:Job
>> dev-dvb-adapter1-frontend0.device/start failed with result 'timeout'.
>> Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter0-frontend0.device:Job
>> dev-dvb-adapter0-frontend0.device/start timed out.
>> Aug 13 11:03:48 mythpc systemd[1]: Timed out waiting for device
>> dev-dvb-adapter0-frontend0.device.
>> Aug 13 11:03:48 mythpc systemd[1]: dev-dvb-adapter0-frontend0.device:Job
>> dev-dvb-adapter0-frontend0.device/start failed with result 'timeout'.
>
> That is not good. The new systemd jobs to detect the creation of the
> tuners are not actually working. Instead, they are timing out. The
> timeout is long enough so that when mythbackend gets started, the
> tuner devices are actually present, so mythbackend seems to be seeing
> working tuners once it gets started, but the timeouts likely slow down
> booting much more than needs to happen.
>
>> Aug 13 11:03:48 mythpc systemd[1]: Started MythTV Backend.
>> Aug 13 11:03:48 mythpc systemd[1]: Reached target Multi-User System.
>> Aug 13 11:03:48 mythpc systemd[1]: Reached target Graphical Interface.
>> Aug 13 11:03:48 mythpc systemd[1]: Started Stop ureadahead data
>> collection
>> 45s after completed startup.
>> Aug 13 11:03:48 mythpc systemd[1]: Starting Update UTMP about System
>> Runlevel Changes...
>> Aug 13 11:03:48 mythpc systemd[1]: Started Update UTMP about System
>> Runlevel Changes.
>> Aug 13 11:03:48 mythpc systemd[1]: Startup finished in 1.798s (kernel) +
>> 1min 30.619s (userspace) = 1min 32.418s.
>> Aug 13 11:03:49 mythpc kernel: [ 92.670822] tda10048_firmware_upload:
>> waiting for firmware upload (dvb-fe-tda10048-1.0.fw)...
>> Aug 13 11:03:49 mythpc kernel: [ 92.671115] tda10048_firmware_upload:
>> firmware read 24878 bytes.
>> Aug 13 11:03:49 mythpc kernel: [ 92.671118] tda10048_firmware_upload:
>> firmware uploading
>> Aug 13 11:03:52 mythpc kernel: [ 95.647746] tda10048_firmware_upload:
>> firmware uploaded
>> Aug 13 11:03:52 mythpc kernel: [ 95.718869] tda18271: performing RF
>> tracking filter calibration
>> Aug 13 11:03:54 mythpc kernel: [ 98.071954] tda18271: RF trackingfilter
>> calibration complete
>> Aug 13 11:03:56 mythpc kernel: [ 99.888159] tda10048_firmware_upload:
>> waiting for firmware upload (dvb-fe-tda10048-1.0.fw)...
>> Aug 13 11:03:56 mythpc kernel: [ 99.888203] tda10048_firmware_upload:
>> firmware read 24878 bytes.
>> Aug 13 11:03:56 mythpc kernel: [ 99.888204] tda10048_firmware_upload:
>> firmware uploading
>> Aug 13 11:03:59 mythpc kernel: [ 102.851201] tda10048_firmware_upload:
>> firmware uploaded
>
> And here more firmware is loaded for the HVR-2200 tuners, AFTER
> mythbackend has been started. So the HVR-2200 tuners may not actually
> have been fully working when mythbackend was started. On the LinuxTV
> Wiki page:
>
> https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200
>
> there are reports that recording has problems every half an hour or so
> without the dvb-fe-tda10048-1.0.fw file being loaded, so it may be
> that having loaded late is OK, but it is still a bad idea. But it may
> also be that the dvb-fe-tda10048-1.0.fw firmware file never gets
> loaded until something tries to use the HVR-2200 tuners, which
> mythbackend does at startup.

Yes,I know of this problem.I had it happen to me on 12.04 so I make sure
all the driver files are where they should be.
>
> Please do two test runs, where you boot, wait for everything to start
> up, then run LiveTV on a channel, watch for a few seconds, then stop
> it. Do that in both 12.04 and 16.04 and post the complete syslog and
> mythbackend.log file from start of booting until LiveTV is finished.
>
>> Aug 13 11:04:34 mythpc systemd[1]: Starting Stop ureadahead data
>> collection...
>> Aug 13 11:04:34 mythpc systemd[1]: Stopped Read required files in
>> advance.
>> Aug 13 11:04:34 mythpc systemd[1]: Started Stop ureadahead data
>> collection.
>>
>>
>>
>> Also, the reboot and shutdown options in frontend have ceased to
>> function.These are performed by /sbin/reboot and /sbin/poweroffcorrect?
>
> Yes and no. Before systemd, the reboot command was a real executable
> file and poweroff was a link to the reboot file. The reboot file
> detected whether it was called via the poweroff link or directly in
> order to decide whether it should just power off or reboot. Now, that
> function is done by systemctl and both reboot and poweroff are links
> to /bin/systemctl and systemctl detects whether it is being run via a
> link as to which function it should perform. So if the /sbin links to
> systemctl do not work now for some reason when used from MythTV, you
> should probably just put the base command into the MythTV settings
> instead of using the links:
>
> /bin/systemctl reboot
> /bin/systemctl poweroff
>
> _______________________________________________
Here's a link to a text file with the log snippets you requested:
https://drive.google.com/open?id=0B5RRWPLTmilhLUFhLTFkN3dEeUU

>> I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv in
>> either 12.04 or 16.04 so I don't know why 12.04 works.
>> I'll create the file.
>
> The <mythtv user> bit in the file path is a placeholder for whatever
> user name you use that runs mythfrontend. Mythfilldatabase, in my
> system, is run by that user. I do not use the standard system for
> running mythfilldatabase though, so I am not entirely sure if the
> .xmltv file needs to be in /home/mythtv/.mythtv (if mythfilldatabase
> is run by user mythtv) or in /home/<mythtv user>/.mythtv (if it is run
> by the user that runs mythfrontend). To be safe, I think it should
> probably be put in /home/mythtv/.mythtv, and then these commands used
> to put a link to it under the mythfrontend user:
>
> cd /home/<mythtv user>.mythtv
> ln -s /home/mythtv/.mythtv/<your .xmltv file>.xmltv
>
> The name used for the .xmltv file needs to be the name used for
> defining the MythTV "source", with the .xmltv extension added. My
> source is "FreeviewHD" for my DVB-T channels and "SkyNZ-Digital" for
> my DVB-S Sky channels. So I have two .xmltv files:
>
> /home/stephen/.mythtv/FreeviewHD.xmltv
> /home/stephen/.mythtv/SkyNZ-Digital.xmltv
>
> The case of the filename must match.
>
> In your case, if you are doing your EPG the same way in 12.04 and
> 16.04, you should already have the files in your 12.04 setup in the
> right place, so the simple thing to do is to just copy them from there
> to the same place in your 16.04 system.
>
> The channels in the .xmltv files vary depending on what is available
> in each part of the country, so just copying mine would not work
> completely. And every time a new channel appears or one is renamed or
> disappears, you have to make the corresponding change in your .xmltv
> files manually, unless you completely delete all your channels and set
> them up from scratch again (not recommended). The tv_grab_nz-py EPG
> grabber does not have the ability to modify the .xmltv files, but
> IIRC, it can create them on initial setup. But it is a long time
> since I used tv_grab_nz-py like that, as I do my channel setup using
> other means, so I may be wrong about that.
>

I realise the path you gave was generic.I appear to have a file called
tv_grab_nz-py.conf with the same xmltv.id data in /home/<mythtv>
user>/.mythtv in 12.04.Perhaps mythfilldatabase is using that.
I'm not too concerned.It works.I'll create the correct file in 16.04.

_______________________________________________
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, 13 Aug 2016 14:56:11 +1200, Robert Fisher <robert@fisher.net.nz>
wrote:

> On 13/08/16 14:42, Paulgir wrote:
>> I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv
>> in either 12.04 or 16.04 so I don't know why 12.04 >>works.I'll create
>> the file.
> As per my previous email
> I had to create a symlink on my backend.......
> sudo ln -s /home/robert/.mythtv/Freeview.xmltv
> /home/mythtv/.mythtv/Freeview.xmltv

I have my freeview.xmltv in /home/mythpc/.mythtv/ and a symlink in
/home/mythtv/.mythtv/
mythfilldatabase does not appear to see it. What permmissions should it
have?


mythpc@mythpc:~$ !55
/usr/bin/updateEPG.sh
2016-08-14 11:51:09.337531 C mythfilldatabase version: fixes/0.28
[v0.28-2-g15cf421] www.mythtv.org
2016-08-14 11:51:09.337555 C Qt version: compile: 5.5.1, runtime: 5.5.1
2016-08-14 11:51:09.337559 N Enabled verbose msgs: general
2016-08-14 11:51:09.337571 N Setting Log Level to LOG_INFO
2016-08-14 11:51:09.348059 N Only updating guide data, channel and icon
updates will be ignored
2016-08-14 11:51:09.348084 I Bypassing grabbers, reading directly from file
2016-08-14 11:51:09.348565 I Setup Interrupt handler
2016-08-14 11:51:09.348573 I Setup Terminated handler
2016-08-14 11:51:09.348582 I Setup Segmentation fault handler
2016-08-14 11:51:09.348589 I Setup Aborted handler
2016-08-14 11:51:09.348596 I Setup Bus error handler
2016-08-14 11:51:09.348602 I Setup Floating point exception handler
2016-08-14 11:51:09.348610 I Setup Illegal instruction handler
2016-08-14 11:51:09.348618 I Setup Real-time signal 0 handler
2016-08-14 11:51:09.348627 I Setup Hangup handler
2016-08-14 11:51:09.348708 N Using runtime prefix = /usr
2016-08-14 11:51:09.348712 N Using configuration directory =
/home/mythpc/.mythtv
2016-08-14 11:51:09.348765 I Assumed character encoding: en_NZ.UTF-8
2016-08-14 11:51:09.348995 N Empty LocalHostName.
2016-08-14 11:51:09.349000 I Using localhost value of mythpc
2016-08-14 11:51:09.350574 I Added logging to the console
2016-08-14 11:51:09.357382 N Setting QT default locale to en_NZ
2016-08-14 11:51:09.357393 I Current locale en_NZ
2016-08-14 11:51:09.357428 E No locale defaults file for en_NZ, skipping
2016-08-14 11:51:09.358152 I Loading en_gb translation for module
mythfrontend
2016-08-14 11:51:09.359327 I Current MythTV Schema Version (DBSchemaVer):
1344
2016-08-14 11:51:09.361403 I MythCoreContext::ConnectCommandSocket():
Connecting to backend server: 127.0.0.1:6543 (try 1 of 1)
2016-08-14 11:51:09.362345 I MythCoreContext::CheckProtoVersion(): Using
protocol version 88 XmasGift
2016-08-14 11:51:09.362600 I Opening blocking connection to master backend
2016-08-14 11:51:09.831868 N Skipping Channel Updates
2016-08-14 11:51:09.832940 N Unknown xmltv channel identifier:
aljazeera.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.833213 N Unknown xmltv channel identifier:
basefm.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.833470 N Unknown xmltv channel identifier:
bravo.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.833661 N Unknown xmltv channel identifier:
canterbury-tv.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.833837 N Unknown xmltv channel identifier:
channel-north-tv.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.834040 N Unknown xmltv channel identifier:
chinese-tv8.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.834223 N Unknown xmltv channel identifier:
choice.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.834392 N Unknown xmltv channel identifier:
duke.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.834561 N Unknown xmltv channel identifier:
dunedin-tv.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.834727 N Unknown xmltv channel identifier:
edge-tv.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.834894 N Unknown xmltv channel identifier:
firstlight.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.835060 N Unknown xmltv channel identifier:
hgtv.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.835227 N Unknown xmltv channel identifier:
info-rotorua.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.835394 N Unknown xmltv channel identifier:
maori-tv.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.835582 N Unknown xmltv channel identifier:
parliament.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.835748 N Unknown xmltv channel identifier:
prime.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.835916 N Unknown xmltv channel identifier:
rnz-concert.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.836082 N Unknown xmltv channel identifier:
rnz-national.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.836253 N Unknown xmltv channel identifier:
shopping-channel.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.836420 N Unknown xmltv channel identifier:
tv-hawkes-bay.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.836588 N Unknown xmltv channel identifier:
tv1-plus1.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.836755 N Unknown xmltv channel identifier:
tv1.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.836922 N Unknown xmltv channel identifier:
tv2-plus1.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.837089 N Unknown xmltv channel identifier:
tv2.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.837259 N Unknown xmltv channel identifier:
tv3-plus1.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.837425 N Unknown xmltv channel identifier:
tv3.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.837593 N Unknown xmltv channel identifier:
tv33.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.837766 N Unknown xmltv channel identifier:
tvsn-shopping-channel.freeviewnz.tv - Skipping channel.
2016-08-14 11:51:09.837778 I Updated programs: 0 Unchanged programs: 0

>>
>>
>> Also, the reboot and shutdown options in frontend have ceased to
>> function.These are performed by /sbin/reboot and /sbin/poweroff
>> correct?
>
> Yes and no. Before systemd, the reboot command was a real executable
> file and poweroff was a link to the reboot file. The reboot file
> detected whether it was called via the poweroff link or directly in
> order to decide whether it should just power off or reboot. Now, that
> function is done by systemctl and both reboot and poweroff are links
> to /bin/systemctl and systemctl detects whether it is being run via a
> link as to which function it should perform. So if the /sbin links to
> systemctl do not work now for some reason when used from MythTV, you
> should probably just put the base command into the MythTV settings
> instead of using the links:
>
> /bin/systemctl reboot
> /bin/systemctl poweroff
>
> _______________________________________________
Those commands work.I entered them in the relevant fields in frontend
setup and the shutdown options work now.

_______________________________________________
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, 13 Aug 2016 14:56:11 +1200, Robert Fisher <robert@fisher.net.nz>
wrote:

> On 13/08/16 14:42, Paulgir wrote:
>> I don't appear to have freeview.xmltv in /home/<mythtv> user>/.mythtv
>> in either 12.04 or 16.04 so I don't know why 12.04 >>works.I'll create
>> the file.
> As per my previous email
> I had to create a symlink on my backend.......
> sudo ln -s /home/robert/.mythtv/Freeview.xmltv
> /home/mythtv/.mythtv/Freeview.xmltv
I decided to have another go at tv_grab_nz-py ,which I could not get to
work in 12.04 after a reinstall (worked ok in the original install)
This seems to work ok now,so I'll test it and if it is reliable,keep it
running.

On Sun, 14 Aug 2016 10:32:48 +1200, you wrote:

>Here's a link to a text file with the log snippets you requested:
>https://drive.google.com/open?id=0B5RRWPLTmilhLUFhLTFkN3dEeUU

I have finally had a free moment to start looking at the log files,
starting with the syslogs, and the thing that right away I can see as
a problem is that the hostname of the PC has changed from 12.04 (myth)
to 16.04 (mythpc). That screws up the MythTV database quite badly, as
lots of settings are per hostname and many other tables have a
hostname field. When changing the hostname of a PC, you have to
follow this procedure:

https://www.mythtv.org/wiki/Hostname_change#Change_the_hostname_of_a_MythTV_frontend_or_backend

and also see this:

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

I am not sure how well the hostname change options on
mythconverg_restore.pl work - I have never used them. If they change
all the hostnames in all the tables, everything should work a lot
better than before. I believe the right sequence would be to do a new
restore of the 12.04 database to the 16.04 setup, then run the
hostname change command, then run mythtv-setup to upgrade the database
schema, then start mythbackend and run mythfrontend to upgrade any
other plugin database that needed it.

I think you said you are just installing 16.04 on a new SSD in the
same PC. If so, then it might be easier to just do a reinstall of
16.04 keeping the old hostname, and then do an ordinary restore of the
database. Once things are all working again, you could then look at
changing the hostname.

However, that problem would not affect you if you were just running a
new database on 16.04, and I have not checked all the emails to see if
the latest tests (for the log files) were done with a clean database,
or using a restored one. I may be able to work it out from the logs,
but please let me know if you can remember. If the tests were done
with a database with wrong hostnames, there is not much point in
looking at the mythbackend logs until that problem is fixed.

One other minor thing I can see is that the language locale seems to
be en_gb on the 12.04 setup, but en_us on the 16.04 one. Since en_NZ
is a variant of en_gb, lots of things show en_gb when the locale is
set to en_NZ, so check the output of the "locale" command on 12.04 to
see if it is really set to en_NZ. If so, 16.04 should be set up the
same way. There can be problems with MythTV themes and other subtle
things if the locales do not match between the operating system and
the MythTV database.

When I have some more time I will look further at the logs.

BTW My test PC is down for a few days - my mother's MythTV box power
supply fan suddenly became very noisy, so I had to use my spare power
supply from the test PC to keep her MythTV going until we can get a
new power supply for it. So I am unable to do any testing with 16.04
at the moment.

_______________________________________________
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, 16 Aug 2016 20:23:03 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> On Sun, 14 Aug 2016 10:32:48 +1200, you wrote:
>
>> Here's a link to a text file with the log snippets you requested:
>> https://drive.google.com/open?id=0B5RRWPLTmilhLUFhLTFkN3dEeUU
>
> I have finally had a free moment to start looking at the log files,
> starting with the syslogs, and the thing that right away I can see as
> a problem is that the hostname of the PC has changed from 12.04 (myth)
> to 16.04 (mythpc). That screws up the MythTV database quite badly, as
> lots of settings are per hostname and many other tables have a
> hostname field. When changing the hostname of a PC, you have to
> follow this procedure:


My original install of 16.04 had the same hostname as the 12.04
install.This was the one where I restored a DB backup from 12.04 onto
16.04.When I discovered that this led to a typo error in the command I
used to change the permissions on the storage drive,I did a reinstall of
16.04 with a new hostname to avoid that mistake.
On the new install I did not restore a 12.04 DB backup onto it.So the logs
you have seen are from a system with a pristine DB.


>
> https://www.mythtv.org/wiki/Hostname_change#Change_the_hostname_of_a_MythTV_frontend_or_backend
>
> and also see this:
>
> https://www.mythtv.org/wiki/Backend_migration
>
> I am not sure how well the hostname change options on
> mythconverg_restore.pl work - I have never used them. If they change
> all the hostnames in all the tables, everything should work a lot
> better than before. I believe the right sequence would be to do a new
> restore of the 12.04 database to the 16.04 setup, then run the
> hostname change command, then run mythtv-setup to upgrade the database
> schema, then start mythbackend and run mythfrontend to upgrade any
> other plugin database that needed it.
>
> I think you said you are just installing 16.04 on a new SSD in the
> same PC.

That is correct.

If so, then it might be easier to just do a reinstall of
> 16.04 keeping the old hostname, and then do an ordinary restore of the
> database. Once things are all working again, you could then look at
> changing the hostname.

As of yesterday ,I somehow killed the 16.04 system's ability to
boot,setting up Myth Welcome.I ran boot repair but it did not correct the
problem.
I could probably find the problem and fix it but I have decided to
reinstall as that will be much quicker.
I will use the same hostname as 12.04 ,in case I decide to do a DB restore
from 12.04.
I will probably not do a restore,though as I don't have a huge number of
recordings on 12.04 and may just move them to /Videos.

I want to,initially, only install the HDHR tuners to see if I have the
same start delay.

>
> However, that problem would not affect you if you were just running a
> new database on 16.04, and I have not checked all the emails to see if
> the latest tests (for the log files) were done with a clean database,

Yes it was clean.

> or using a restored one. I may be able to work it out from the logs,
> but please let me know if you can remember. If the tests were done
> with a database with wrong hostnames, there is not much point in
> looking at the mythbackend logs until that problem is fixed.
>
> One other minor thing I can see is that the language locale seems to
> be en_gb on the 12.04 setup, but en_us on the 16.04 one. Since en_NZ
> is a variant of en_gb, lots of things show en_gb when the locale is
> set to en_NZ, so check the output of the "locale" command on 12.04 to
> see if it is really set to en_NZ. If so, 16.04 should be set up the
> same way. There can be problems with MythTV themes and other subtle
> things if the locales do not match between the operating system and
> the MythTV database.

12.04:
~$ locale
LANG=en_NZ.UTF-8
LANGUAGE=en_NZ:en
LC_CTYPE="en_NZ.UTF-8"
LC_NUMERIC="en_NZ.UTF-8"
LC_TIME="en_NZ.UTF-8"
LC_COLLATE="en_NZ.UTF-8"
LC_MONETARY="en_NZ.UTF-8"
LC_MESSAGES="en_NZ.UTF-8"
LC_PAPER="en_NZ.UTF-8"
LC_NAME="en_NZ.UTF-8"
LC_ADDRESS="en_NZ.UTF-8"
LC_TELEPHONE="en_NZ.UTF-8"
LC_MEASUREMENT="en_NZ.UTF-8"
LC_IDENTIFICATION="en_NZ.UTF-8"
LC_ALL=


>
> When I have some more time I will look further at the logs.
>
> BTW My test PC is down for a few days - my mother's MythTV box power
> supply fan suddenly became very noisy, so I had to use my spare power
> supply from the test PC to keep her MythTV going until we can get a
> new power supply for it. So I am unable to do any testing with 16.04
> at the moment.
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

_______________________________________________
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 now got my 16.04 test box running again, and spent some time
this afternoon looking at the log files.

On Wed, 17 Aug 2016 09:40:37 +1200, you wrote:

>On Tue, 16 Aug 2016 20:23:03 +1200, Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>
>> On Sun, 14 Aug 2016 10:32:48 +1200, you wrote:
>>
>>> Here's a link to a text file with the log snippets you requested:
>>> https://drive.google.com/open?id=0B5RRWPLTmilhLUFhLTFkN3dEeUU
>>
>> I have finally had a free moment to start looking at the log files,
>> starting with the syslogs, and the thing that right away I can see as
>> a problem is that the hostname of the PC has changed from 12.04 (myth)
>> to 16.04 (mythpc). That screws up the MythTV database quite badly, as
>> lots of settings are per hostname and many other tables have a
>> hostname field. When changing the hostname of a PC, you have to
>> follow this procedure:
>
>
>My original install of 16.04 had the same hostname as the 12.04
>install.This was the one where I restored a DB backup from 12.04 onto
>16.04.When I discovered that this led to a typo error in the command I
>used to change the permissions on the storage drive,I did a reinstall of
>16.04 with a new hostname to avoid that mistake.
>On the new install I did not restore a 12.04 DB backup onto it.So the logs
>you have seen are from a system with a pristine DB.
>
>
>>
>> https://www.mythtv.org/wiki/Hostname_change#Change_the_hostname_of_a_MythTV_frontend_or_backend
>>
>> and also see this:
>>
>> https://www.mythtv.org/wiki/Backend_migration
>>
>> I am not sure how well the hostname change options on
>> mythconverg_restore.pl work - I have never used them. If they change
>> all the hostnames in all the tables, everything should work a lot
>> better than before. I believe the right sequence would be to do a new
>> restore of the 12.04 database to the 16.04 setup, then run the
>> hostname change command, then run mythtv-setup to upgrade the database
>> schema, then start mythbackend and run mythfrontend to upgrade any
>> other plugin database that needed it.
>>
>> I think you said you are just installing 16.04 on a new SSD in the
>> same PC.
>
>That is correct.
>
> If so, then it might be easier to just do a reinstall of
>> 16.04 keeping the old hostname, and then do an ordinary restore of the
>> database. Once things are all working again, you could then look at
>> changing the hostname.
>
>As of yesterday ,I somehow killed the 16.04 system's ability to
>boot,setting up Myth Welcome.I ran boot repair but it did not correct the
>problem.
>I could probably find the problem and fix it but I have decided to
>reinstall as that will be much quicker.
>I will use the same hostname as 12.04 ,in case I decide to do a DB restore
> from 12.04.
>I will probably not do a restore,though as I don't have a huge number of
>recordings on 12.04 and may just move them to /Videos.
>
>I want to,initially, only install the HDHR tuners to see if I have the
>same start delay.

The HDHR tuners will need a reasonable start delay as they need to
have networking fully up before they can be used. This page gives how
to do it:

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

in the "Delay starting the backend until network has initialized"
section. But that information is generic, not specific to Ubuntu
16.04. What I think you need to do first is to try setting things up
so that you can wait for NetworkManager to say the network is up. Only
if that does not work should pingnetwork.service be needed. So the
first thing to do is this command to see if the right NetworkMangager
target is enabled in systemd:

systemctl status NetworkManager-wait-online.service

If that does not show that the NetworkManager-wait-online.service is
enabled and working, then enable it:

systemctl enable NetworkManager-wait-online.service

Then mythbackend must be made to wait for that target. In your
mythtv_backend_override.conf, in the [Unit] section, add a new line:

After=NetworkManager-wait-online.service

>>
>> However, that problem would not affect you if you were just running a
>> new database on 16.04, and I have not checked all the emails to see if
>> the latest tests (for the log files) were done with a clean database,
>
>Yes it was clean.
>
>> or using a restored one. I may be able to work it out from the logs,
>> but please let me know if you can remember. If the tests were done
>> with a database with wrong hostnames, there is not much point in
>> looking at the mythbackend logs until that problem is fixed.
>>
>> One other minor thing I can see is that the language locale seems to
>> be en_gb on the 12.04 setup, but en_us on the 16.04 one. Since en_NZ
>> is a variant of en_gb, lots of things show en_gb when the locale is
>> set to en_NZ, so check the output of the "locale" command on 12.04 to
>> see if it is really set to en_NZ. If so, 16.04 should be set up the
>> same way. There can be problems with MythTV themes and other subtle
>> things if the locales do not match between the operating system and
>> the MythTV database.
>
>12.04:
>~$ locale
>LANG=en_NZ.UTF-8
>LANGUAGE=en_NZ:en
>LC_CTYPE="en_NZ.UTF-8"
>LC_NUMERIC="en_NZ.UTF-8"
>LC_TIME="en_NZ.UTF-8"
>LC_COLLATE="en_NZ.UTF-8"
>LC_MONETARY="en_NZ.UTF-8"
>LC_MESSAGES="en_NZ.UTF-8"
>LC_PAPER="en_NZ.UTF-8"
>LC_NAME="en_NZ.UTF-8"
>LC_ADDRESS="en_NZ.UTF-8"
>LC_TELEPHONE="en_NZ.UTF-8"
>LC_MEASUREMENT="en_NZ.UTF-8"
>LC_IDENTIFICATION="en_NZ.UTF-8"
>LC_ALL=
>
>
>>
>> When I have some more time I will look further at the logs.
>>
>> BTW My test PC is down for a few days - my mother's MythTV box power
>> supply fan suddenly became very noisy, so I had to use my spare power
>> supply from the test PC to keep her MythTV going until we can get a
>> new power supply for it. So I am unable to do any testing with 16.04
>> at the moment.

I think I know why systemd was timing out waiting for the /dev/dvb
devices. It seems I forgot to tell you about creating an
/etc/udev/rules.d/99-mythbackend.rules file:

#
# Create systemd device units for capture devices
#
SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"
SUBSYSTEM=="firewire", TAG+="systemd"

What that does is to make udev send systemd messages when those
devices are created. Without it, systemd never received any messages
to tell it the devices were ready, hence the timeout. I think I must
have created that file a while ago, so when I was working out how to
get systemd to wait for the DVB devices, I completely forgot it was
needed. I really think that file should be installed automatically by
the MythTV packages. Like the other files in that directory, it needs
to be chown root:root and chmod u=rw,g=r,o=r.

With those changes, systemd should be able to bring up mythbackend
only after both the HVR-2200 and HDHR tuners are available.

From the logs, I am pretty sure that the second firmware file for the
HVR-2200 tuners (dvb-fe-tda10048-1.0.fw) is only loaded after
mythbackend sends them a tuning command for the first time, so there
is no need to wait for that firmware to be loaded. Doing the firmware
load means that the first tuning of the HVR-2200 tuners will likely
take a bit longer - it is possible that mythbackend may timeout
waiting for a response from the tuner and that may be why it seems to
try those tuners several times as it starts up:

Aug 14 10:09:53 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:09:58 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:09:59 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:10:00 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:10:02 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms
Aug 14 10:10:03 mythpc mythbackend: mythbackend[3168]: I CoreContext
recorders/dvbchannel.cpp:712 (Tune)
DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
1000ms. Delaying by 1000ms

That looks a bit worrying compared to what I see with my /dev/dvb
tuners, where each tuner gets tuned only once, in tuner number order.
But if the tuners are working afterward, that is all that matters.

_______________________________________________
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, 25 Aug 2016 21:02:40 +1200, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> I have now got my 16.04 test box running again, and spent some time
> this afternoon looking at the log files.
>
> On Wed, 17 Aug 2016 09:40:37 +1200, you wrote:
>
>> On Tue, 16 Aug 2016 20:23:03 +1200, Stephen Worthington
>> <stephen_agent@jsw.gen.nz> wrote:
>>
>>> On Sun, 14 Aug 2016 10:32:48 +1200, you wrote:
>>>
>>>> Here's a link to a text file with the log snippets you requested:
>>>> https://drive.google.com/open?id=0B5RRWPLTmilhLUFhLTFkN3dEeUU
>>>
>>> I have finally had a free moment to start looking at the log files,
>>> starting with the syslogs, and the thing that right away I can see as
>>> a problem is that the hostname of the PC has changed from 12.04 (myth)
>>> to 16.04 (mythpc). That screws up the MythTV database quite badly, as
>>> lots of settings are per hostname and many other tables have a
>>> hostname field. When changing the hostname of a PC, you have to
>>> follow this procedure:
>>
>>
>> My original install of 16.04 had the same hostname as the 12.04
>> install.This was the one where I restored a DB backup from 12.04 onto
>> 16.04.When I discovered that this led to a typo error in the command I
>> used to change the permissions on the storage drive,I did a reinstall of
>> 16.04 with a new hostname to avoid that mistake.
>> On the new install I did not restore a 12.04 DB backup onto it.So the
>> logs
>> you have seen are from a system with a pristine DB.
>>
>>
>>>
>>> https://www.mythtv.org/wiki/Hostname_change#Change_the_hostname_of_a_MythTV_frontend_or_backend
>>>
>>> and also see this:
>>>
>>> https://www.mythtv.org/wiki/Backend_migration
>>>
>>> I am not sure how well the hostname change options on
>>> mythconverg_restore.pl work - I have never used them. If they change
>>> all the hostnames in all the tables, everything should work a lot
>>> better than before. I believe the right sequence would be to do a new
>>> restore of the 12.04 database to the 16.04 setup, then run the
>>> hostname change command, then run mythtv-setup to upgrade the database
>>> schema, then start mythbackend and run mythfrontend to upgrade any
>>> other plugin database that needed it.
>>>
>>> I think you said you are just installing 16.04 on a new SSD in the
>>> same PC.
>>
>> That is correct.
>>
>> If so, then it might be easier to just do a reinstall of
>>> 16.04 keeping the old hostname, and then do an ordinary restore of the
>>> database. Once things are all working again, you could then look at
>>> changing the hostname.
>>
>> As of yesterday ,I somehow killed the 16.04 system's ability to
>> boot,setting up Myth Welcome.I ran boot repair but it did not correct
>> the
>> problem.
>> I could probably find the problem and fix it but I have decided to
>> reinstall as that will be much quicker.
>> I will use the same hostname as 12.04 ,in case I decide to do a DB
>> restore
>> from 12.04.
>> I will probably not do a restore,though as I don't have a huge number of
>> recordings on 12.04 and may just move them to /Videos.
>>
>> I want to,initially, only install the HDHR tuners to see if I have the
>> same start delay.
>
> The HDHR tuners will need a reasonable start delay as they need to
> have networking fully up before they can be used. This page gives how
> to do it:
>
> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>
> in the "Delay starting the backend until network has initialized"
> section. But that information is generic, not specific to Ubuntu
> 16.04. What I think you need to do first is to try setting things up
> so that you can wait for NetworkManager to say the network is up. Only
> if that does not work should pingnetwork.service be needed. So the
> first thing to do is this command to see if the right NetworkMangager
> target is enabled in systemd:
>
> systemctl status NetworkManager-wait-online.service
>
> If that does not show that the NetworkManager-wait-online.service is
> enabled and working, then enable it:
>
> systemctl enable NetworkManager-wait-online.service
>
> Then mythbackend must be made to wait for that target. In your
> mythtv_backend_override.conf, in the [Unit] section, add a new line:
>
> After=NetworkManager-wait-online.service
>
>>>
>>> However, that problem would not affect you if you were just running a
>>> new database on 16.04, and I have not checked all the emails to see if
>>> the latest tests (for the log files) were done with a clean database,
>>
>> Yes it was clean.
>>
>>> or using a restored one. I may be able to work it out from the logs,
>>> but please let me know if you can remember. If the tests were done
>>> with a database with wrong hostnames, there is not much point in
>>> looking at the mythbackend logs until that problem is fixed.
>>>
>>> One other minor thing I can see is that the language locale seems to
>>> be en_gb on the 12.04 setup, but en_us on the 16.04 one. Since en_NZ
>>> is a variant of en_gb, lots of things show en_gb when the locale is
>>> set to en_NZ, so check the output of the "locale" command on 12.04 to
>>> see if it is really set to en_NZ. If so, 16.04 should be set up the
>>> same way. There can be problems with MythTV themes and other subtle
>>> things if the locales do not match between the operating system and
>>> the MythTV database.
>>
>> 12.04:
>> ~$ locale
>> LANG=en_NZ.UTF-8
>> LANGUAGE=en_NZ:en
>> LC_CTYPE="en_NZ.UTF-8"
>> LC_NUMERIC="en_NZ.UTF-8"
>> LC_TIME="en_NZ.UTF-8"
>> LC_COLLATE="en_NZ.UTF-8"
>> LC_MONETARY="en_NZ.UTF-8"
>> LC_MESSAGES="en_NZ.UTF-8"
>> LC_PAPER="en_NZ.UTF-8"
>> LC_NAME="en_NZ.UTF-8"
>> LC_ADDRESS="en_NZ.UTF-8"
>> LC_TELEPHONE="en_NZ.UTF-8"
>> LC_MEASUREMENT="en_NZ.UTF-8"
>> LC_IDENTIFICATION="en_NZ.UTF-8"
>> LC_ALL=
>>
>>
>>>
>>> When I have some more time I will look further at the logs.
>>>
>>> BTW My test PC is down for a few days - my mother's MythTV box power
>>> supply fan suddenly became very noisy, so I had to use my spare power
>>> supply from the test PC to keep her MythTV going until we can get a
>>> new power supply for it. So I am unable to do any testing with 16.04
>>> at the moment.
>
> I think I know why systemd was timing out waiting for the /dev/dvb
> devices. It seems I forgot to tell you about creating an
> /etc/udev/rules.d/99-mythbackend.rules file:
>
> #
> # Create systemd device units for capture devices
> #
> SUBSYSTEM=="video4linux", TAG+="systemd"
> SUBSYSTEM=="dvb", TAG+="systemd"
> SUBSYSTEM=="firewire", TAG+="systemd"
>
> What that does is to make udev send systemd messages when those
> devices are created. Without it, systemd never received any messages
> to tell it the devices were ready, hence the timeout. I think I must
> have created that file a while ago, so when I was working out how to
> get systemd to wait for the DVB devices, I completely forgot it was
> needed. I really think that file should be installed automatically by
> the MythTV packages. Like the other files in that directory, it needs
> to be chown root:root and chmod u=rw,g=r,o=r.
>
> With those changes, systemd should be able to bring up mythbackend
> only after both the HVR-2200 and HDHR tuners are available.
>
> From the logs, I am pretty sure that the second firmware file for the
> HVR-2200 tuners (dvb-fe-tda10048-1.0.fw) is only loaded after
> mythbackend sends them a tuning command for the first time, so there
> is no need to wait for that firmware to be loaded. Doing the firmware
> load means that the first tuning of the HVR-2200 tuners will likely
> take a bit longer - it is possible that mythbackend may timeout
> waiting for a response from the tuner and that may be why it seems to
> try those tuners several times as it starts up:
>
> Aug 14 10:09:53 mythpc mythbackend: mythbackend[3168]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune)
> DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
> 1000ms. Delaying by 1000ms
> Aug 14 10:09:58 mythpc mythbackend: mythbackend[3168]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune)
> DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
> 1000ms. Delaying by 1000ms
> Aug 14 10:09:59 mythpc mythbackend: mythbackend[3168]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune)
> DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
> 1000ms. Delaying by 1000ms
> Aug 14 10:10:00 mythpc mythbackend: mythbackend[3168]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune)
> DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
> 1000ms. Delaying by 1000ms
> Aug 14 10:10:02 mythpc mythbackend: mythbackend[3168]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune)
> DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
> 1000ms. Delaying by 1000ms
> Aug 14 10:10:03 mythpc mythbackend: mythbackend[3168]: I CoreContext
> recorders/dvbchannel.cpp:712 (Tune)
> DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
> 1000ms. Delaying by 1000ms
>
> That looks a bit worrying compared to what I see with my /dev/dvb
> tuners, where each tuner gets tuned only once, in tuner number order.
> But if the tuners are working afterward, that is all that matters.



> I really appreciate your research into this problem.
I did some searching on the forums to see what other commentaries on 16.04
were saying and found one that matched my experience very closely.One
major concern that has nagged at me is the way the set up pages seems to
behave when setting up capture cards.Even before the tuners are set
up,trying to get the "set up new capture card" page to open takes 3 to 5
minutes.
To me this says there are bugs in this part of the software.A post on
Ubuntu forums describes the same behaviour and goes on to say that Mythtv
would lose the capture card setup every week and it would have to be
redone.That poster decided to use 14.04.
I certainly don't want to risk introducing that kind of instability into
my PVR.

So I decided to see how 14.04.5 (with mythtv 0.28) installs.This was
dream.It took about 3 hours to get up and running with no hardware related
problems.
Interestingly, 14.04.5 boots as fast as 16.04 on the SSD - in about 18
seconds.So if the boot in 16.04 was too fast for the cards to
initialise,why is it not a problem for 14.04.5?

I'm inclined to stick with 14.04 and hope 16.04 gets ironed out in the
next 2 years.

_______________________________________________
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, 26 Aug 2016 10:47:09 +1200, you wrote:

>On Thu, 25 Aug 2016 21:02:40 +1200, Stephen Worthington
><stephen_agent@jsw.gen.nz> wrote:
>
>> I have now got my 16.04 test box running again, and spent some time
>> this afternoon looking at the log files.
>>
>> On Wed, 17 Aug 2016 09:40:37 +1200, you wrote:
>>
>>> On Tue, 16 Aug 2016 20:23:03 +1200, Stephen Worthington
>>> <stephen_agent@jsw.gen.nz> wrote:
>>>
>>>> On Sun, 14 Aug 2016 10:32:48 +1200, you wrote:
>>>>
>>>>> Here's a link to a text file with the log snippets you requested:
>>>>> https://drive.google.com/open?id=0B5RRWPLTmilhLUFhLTFkN3dEeUU
>>>>
>>>> I have finally had a free moment to start looking at the log files,
>>>> starting with the syslogs, and the thing that right away I can see as
>>>> a problem is that the hostname of the PC has changed from 12.04 (myth)
>>>> to 16.04 (mythpc). That screws up the MythTV database quite badly, as
>>>> lots of settings are per hostname and many other tables have a
>>>> hostname field. When changing the hostname of a PC, you have to
>>>> follow this procedure:
>>>
>>>
>>> My original install of 16.04 had the same hostname as the 12.04
>>> install.This was the one where I restored a DB backup from 12.04 onto
>>> 16.04.When I discovered that this led to a typo error in the command I
>>> used to change the permissions on the storage drive,I did a reinstall of
>>> 16.04 with a new hostname to avoid that mistake.
>>> On the new install I did not restore a 12.04 DB backup onto it.So the
>>> logs
>>> you have seen are from a system with a pristine DB.
>>>
>>>
>>>>
>>>> https://www.mythtv.org/wiki/Hostname_change#Change_the_hostname_of_a_MythTV_frontend_or_backend
>>>>
>>>> and also see this:
>>>>
>>>> https://www.mythtv.org/wiki/Backend_migration
>>>>
>>>> I am not sure how well the hostname change options on
>>>> mythconverg_restore.pl work - I have never used them. If they change
>>>> all the hostnames in all the tables, everything should work a lot
>>>> better than before. I believe the right sequence would be to do a new
>>>> restore of the 12.04 database to the 16.04 setup, then run the
>>>> hostname change command, then run mythtv-setup to upgrade the database
>>>> schema, then start mythbackend and run mythfrontend to upgrade any
>>>> other plugin database that needed it.
>>>>
>>>> I think you said you are just installing 16.04 on a new SSD in the
>>>> same PC.
>>>
>>> That is correct.
>>>
>>> If so, then it might be easier to just do a reinstall of
>>>> 16.04 keeping the old hostname, and then do an ordinary restore of the
>>>> database. Once things are all working again, you could then look at
>>>> changing the hostname.
>>>
>>> As of yesterday ,I somehow killed the 16.04 system's ability to
>>> boot,setting up Myth Welcome.I ran boot repair but it did not correct
>>> the
>>> problem.
>>> I could probably find the problem and fix it but I have decided to
>>> reinstall as that will be much quicker.
>>> I will use the same hostname as 12.04 ,in case I decide to do a DB
>>> restore
>>> from 12.04.
>>> I will probably not do a restore,though as I don't have a huge number of
>>> recordings on 12.04 and may just move them to /Videos.
>>>
>>> I want to,initially, only install the HDHR tuners to see if I have the
>>> same start delay.
>>
>> The HDHR tuners will need a reasonable start delay as they need to
>> have networking fully up before they can be used. This page gives how
>> to do it:
>>
>> https://www.mythtv.org/wiki/Systemd_mythbackend_Configuration
>>
>> in the "Delay starting the backend until network has initialized"
>> section. But that information is generic, not specific to Ubuntu
>> 16.04. What I think you need to do first is to try setting things up
>> so that you can wait for NetworkManager to say the network is up. Only
>> if that does not work should pingnetwork.service be needed. So the
>> first thing to do is this command to see if the right NetworkMangager
>> target is enabled in systemd:
>>
>> systemctl status NetworkManager-wait-online.service
>>
>> If that does not show that the NetworkManager-wait-online.service is
>> enabled and working, then enable it:
>>
>> systemctl enable NetworkManager-wait-online.service
>>
>> Then mythbackend must be made to wait for that target. In your
>> mythtv_backend_override.conf, in the [Unit] section, add a new line:
>>
>> After=NetworkManager-wait-online.service
>>
>>>>
>>>> However, that problem would not affect you if you were just running a
>>>> new database on 16.04, and I have not checked all the emails to see if
>>>> the latest tests (for the log files) were done with a clean database,
>>>
>>> Yes it was clean.
>>>
>>>> or using a restored one. I may be able to work it out from the logs,
>>>> but please let me know if you can remember. If the tests were done
>>>> with a database with wrong hostnames, there is not much point in
>>>> looking at the mythbackend logs until that problem is fixed.
>>>>
>>>> One other minor thing I can see is that the language locale seems to
>>>> be en_gb on the 12.04 setup, but en_us on the 16.04 one. Since en_NZ
>>>> is a variant of en_gb, lots of things show en_gb when the locale is
>>>> set to en_NZ, so check the output of the "locale" command on 12.04 to
>>>> see if it is really set to en_NZ. If so, 16.04 should be set up the
>>>> same way. There can be problems with MythTV themes and other subtle
>>>> things if the locales do not match between the operating system and
>>>> the MythTV database.
>>>
>>> 12.04:
>>> ~$ locale
>>> LANG=en_NZ.UTF-8
>>> LANGUAGE=en_NZ:en
>>> LC_CTYPE="en_NZ.UTF-8"
>>> LC_NUMERIC="en_NZ.UTF-8"
>>> LC_TIME="en_NZ.UTF-8"
>>> LC_COLLATE="en_NZ.UTF-8"
>>> LC_MONETARY="en_NZ.UTF-8"
>>> LC_MESSAGES="en_NZ.UTF-8"
>>> LC_PAPER="en_NZ.UTF-8"
>>> LC_NAME="en_NZ.UTF-8"
>>> LC_ADDRESS="en_NZ.UTF-8"
>>> LC_TELEPHONE="en_NZ.UTF-8"
>>> LC_MEASUREMENT="en_NZ.UTF-8"
>>> LC_IDENTIFICATION="en_NZ.UTF-8"
>>> LC_ALL=
>>>
>>>
>>>>
>>>> When I have some more time I will look further at the logs.
>>>>
>>>> BTW My test PC is down for a few days - my mother's MythTV box power
>>>> supply fan suddenly became very noisy, so I had to use my spare power
>>>> supply from the test PC to keep her MythTV going until we can get a
>>>> new power supply for it. So I am unable to do any testing with 16.04
>>>> at the moment.
>>
>> I think I know why systemd was timing out waiting for the /dev/dvb
>> devices. It seems I forgot to tell you about creating an
>> /etc/udev/rules.d/99-mythbackend.rules file:
>>
>> #
>> # Create systemd device units for capture devices
>> #
>> SUBSYSTEM=="video4linux", TAG+="systemd"
>> SUBSYSTEM=="dvb", TAG+="systemd"
>> SUBSYSTEM=="firewire", TAG+="systemd"
>>
>> What that does is to make udev send systemd messages when those
>> devices are created. Without it, systemd never received any messages
>> to tell it the devices were ready, hence the timeout. I think I must
>> have created that file a while ago, so when I was working out how to
>> get systemd to wait for the DVB devices, I completely forgot it was
>> needed. I really think that file should be installed automatically by
>> the MythTV packages. Like the other files in that directory, it needs
>> to be chown root:root and chmod u=rw,g=r,o=r.
>>
>> With those changes, systemd should be able to bring up mythbackend
>> only after both the HVR-2200 and HDHR tuners are available.
>>
>> From the logs, I am pretty sure that the second firmware file for the
>> HVR-2200 tuners (dvb-fe-tda10048-1.0.fw) is only loaded after
>> mythbackend sends them a tuning command for the first time, so there
>> is no need to wait for that firmware to be loaded. Doing the firmware
>> load means that the first tuning of the HVR-2200 tuners will likely
>> take a bit longer - it is possible that mythbackend may timeout
>> waiting for a response from the tuner and that may be why it seems to
>> try those tuners several times as it starts up:
>>
>> Aug 14 10:09:53 mythpc mythbackend: mythbackend[3168]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>> Aug 14 10:09:58 mythpc mythbackend: mythbackend[3168]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>> Aug 14 10:09:59 mythpc mythbackend: mythbackend[3168]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>> Aug 14 10:10:00 mythpc mythbackend: mythbackend[3168]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[1](/dev/dvb/adapter0/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>> Aug 14 10:10:02 mythpc mythbackend: mythbackend[3168]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>> Aug 14 10:10:03 mythpc mythbackend: mythbackend[3168]: I CoreContext
>> recorders/dvbchannel.cpp:712 (Tune)
>> DVBChan[3](/dev/dvb/adapter1/frontend0): Next tuning after less than
>> 1000ms. Delaying by 1000ms
>>
>> That looks a bit worrying compared to what I see with my /dev/dvb
>> tuners, where each tuner gets tuned only once, in tuner number order.
>> But if the tuners are working afterward, that is all that matters.
>
>
>
>> I really appreciate your research into this problem.
>I did some searching on the forums to see what other commentaries on 16.04
>were saying and found one that matched my experience very closely.One
>major concern that has nagged at me is the way the set up pages seems to
>behave when setting up capture cards.Even before the tuners are set
>up,trying to get the "set up new capture card" page to open takes 3 to 5
>minutes.
>To me this says there are bugs in this part of the software.A post on
>Ubuntu forums describes the same behaviour and goes on to say that Mythtv
>would lose the capture card setup every week and it would have to be
>redone.That poster decided to use 14.04.
>I certainly don't want to risk introducing that kind of instability into
>my PVR.
>
>So I decided to see how 14.04.5 (with mythtv 0.28) installs.This was
>dream.It took about 3 hours to get up and running with no hardware related
>problems.
>Interestingly, 14.04.5 boots as fast as 16.04 on the SSD - in about 18
>seconds.So if the boot in 16.04 was too fast for the cards to
>initialise,why is it not a problem for 14.04.5?
>
>I'm inclined to stick with 14.04 and hope 16.04 gets ironed out in the
>next 2 years.

The use of systemd in 16.04 is what makes the difference in booting.
Systemd works completely differently from upstart, and allows things
to start better in parallel, rather than having to wait and start in
sequence. But because of that, you can get race conditions if you do
not set up the startup conditions properly. The mythbackend startup
conditions in the package as installed are only OK for systems that do
not have external access to MythTV and which have very standard
tuners. Putting in the right conditions (which is where I hope we
have arrived at now) should allow mythbackend to start at the right
time.

The reports about mythtv-setup taking ages to get to the new capture
card page are likely what I saw when I first tried 0.28 on 16.04. That
is a problem with the code supporting the new VBox network tuners,
where the code involved takes a very long time to decide that there
are no VBoxes on the network. In my case, that happened because I had
not set up my networking on my new test box at that point, so it was
not working properly. Once I sorted out my network setup, the long
timeout waiting for VBox detection went away, although it still takes
longer than it used to. The reason for the problem was quite visible
in the xterm window that pops up to run mythtv-setup.real - I could
see the messages about VBoxes when I swapped to that window while I
was waiting for mythtv-setup.real to open the new tuner page. VBox
support is new in 0.28 and I think this problem is just a bug, but I
have not checked to see if it has been reported yet.

I have not heard anything about 16.04 losing its capture card setup
though. That is pretty major and I would have expected to see reports
about it on the mythtv-users mailing list by now, but there has been
nothing.

Using 14.04.05 and 0.28 should be fine for a while, if you want to do
that, but the kernel will not be updated as I think the 14.04.5 kernel
is the last one from 15.10, which is no longer supported. The 14.04.0
kernel (3.13.x) is still being updated and will be as long as 14.04 is
being supported. You would not be avoiding the VBox problem or the
possible loss of capture card setup if you use 0.28 on 14.04. And as
you are using an SSD, 16.04 is recommended for better support for
that. SSDs do work in 14.04, but you do not get all the latest tweaks
without a 4.x kernel.

What sort of SSD do you have? In 14.04, there are problems running
the fstrim command or the fstab discard option (one or other of which
is necessary for using an SSD). Only a limited range of SSDs are
supported, so you need to check if yours is supported. This comment
is present in the /etc/cron.weekly/fstrim file in 14.04 and is gone in
16.04:

# This only runs on Intel and Samsung SSDs by default, as some SSDs
with faulty
# firmware may encounter data loss problems when running fstrim under
high I/O
# load (e. g. https://launchpad.net/bugs/1259829). You can append the
# --no-model-check option here to disable the vendor check and run
fstrim on
# all SSD drives.

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

> The use of systemd in 16.04 is what makes the difference in booting.
> Systemd works completely differently from upstart, and allows things
> to start better in parallel, rather than having to wait and start in
> sequence. But because of that, you can get race conditions if you do
> not set up the startup conditions properly. The mythbackend startup
> conditions in the package as installed are only OK for systems that do
> not have external access to MythTV and which have very standard
> tuners. Putting in the right conditions (which is where I hope we
> have arrived at now) should allow mythbackend to start at the right
> time.
>
> The reports about mythtv-setup taking ages to get to the new capture
> card page are likely what I saw when I first tried 0.28 on 16.04. That
> is a problem with the code supporting the new VBox network tuners,
> where the code involved takes a very long time to decide that there
> are no VBoxes on the network. In my case, that happened because I had
> not set up my networking on my new test box at that point, so it was
> not working properly. Once I sorted out my network setup, the long
> timeout waiting for VBox detection went away, although it still takes
> longer than it used to. The reason for the problem was quite visible
> in the xterm window that pops up to run mythtv-setup.real - I could
> see the messages about VBoxes when I swapped to that window while I
> was waiting for mythtv-setup.real to open the new tuner page. VBox
> support is new in 0.28 and I think this problem is just a bug, but I
> have not checked to see if it has been reported yet.

In my case networking was the first thing I setup.I used remmina remote
desktop to work on the PVR,so it is the first task on a new install.Then I
tried HDHR configure GUI and that always worked so networking was
functional.So I'm skeptical whether this applies to my situation.
>
> I have not heard anything about 16.04 losing its capture card setup
> though. That is pretty major and I would have expected to see reports
> about it on the mythtv-users mailing list by now, but there has been
> nothing.
>
> Using 14.04.05 and 0.28 should be fine for a while, if you want to do
> that, but the kernel will not be updated as I think the 14.04.5 kernel
> is the last one from 15.10, which is no longer supported. The 14.04.0
> kernel (3.13.x) is still being updated and will be as long as 14.04 is
> being supported. You would not be avoiding the VBox problem or the
> possible loss of capture card setup if you use 0.28 on 14.04. And as
> you are using an SSD, 16.04 is recommended for better support for
> that. SSDs do work in 14.04, but you do not get all the latest tweaks
> without a 4.x kernel.

>
> What sort of SSD do you have? In 14.04, there are problems running
> the fstrim command or the fstab discard option (one or other of which
> is necessary for using an SSD). Only a limited range of SSDs are
> supported, so you need to check if yours is supported. This comment
> is present in the /etc/cron.weekly/fstrim file in 14.04 and is gone in
> 16.04:

> The SSD is an Adata SP600 64GB the same as I have had on my desktop PC
> for several years.Fstrim has not given any trouble on that.
This does not appear in the whitelist.When I run sudo fstrim -v / I get:

myth@myth:~$ sudo fstrim -v /
/: 53121429504 bytes were trimmed
myth@myth:~$ sudo fstrim -v /
/: 0 bytes were trimmed

This is the script I have in /cron.weekly :

#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG


> # This only runs on Intel and Samsung SSDs by default, as some SSDs
> with faulty
> # firmware may encounter data loss problems when running fstrim under
> high I/O
> # load (e. g. https://launchpad.net/bugs/1259829). You can append the
> # --no-model-check option here to disable the vendor check and run
> fstrim on
> # all SSD drives.

I now have 14.04 set up completed, so I should be able to backup the
database and use that backup to set up 16.04 should I install it.
Would this be correct?
If this is the case I will have another go at 16.04

_______________________________________________
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 27/08/16 09:23, Paulgir wrote:
> I now have 14.04 set up completed, so I should be able to backup the
> database and use that backup to set up 16.04 should I install it.
> Would this be correct?
> If this is the case I will have another go at 16.04
If you are going to install 16.04 I would recommend that either you use
the latest version (16.04.1) or do all of the available updates (to
16.04) before setting up MythTV.
I have a feeling that several early bugs were fixed with 16.04.1/

_______________________________________________
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, 27 Aug 2016 09:33:20 +1200, Robert Fisher <robert@fisher.net.nz>
wrote:

> On 27/08/16 09:23, Paulgir wrote:
>> I now have 14.04 set up completed, so I should be able to backup the
>> database and use that backup to set up 16.04 should I install it.
>> Would this be correct?
>> If this is the case I will have another go at 16.04
> If you are going to install 16.04 I would recommend that either you use
> the latest version (16.04.1) or do all of the available updates (to
> 16.04) before setting up MythTV.
> I have a feeling that several early bugs were fixed with 16.04.1/
>
> _______________________________________________
The version I have been working with is 16.04.1

Cheers

_______________________________________________
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, Aug 27, 2016 at 9:23 AM, Paulgir <paulgir@gmail.com> wrote:

>
> The use of systemd in 16.04 is what makes the difference in booting.
>> Systemd works completely differently from upstart, and allows things
>> to start better in parallel, rather than having to wait and start in
>> sequence. But because of that, you can get race conditions if you do
>> not set up the startup conditions properly. The mythbackend startup
>> conditions in the package as installed are only OK for systems that do
>> not have external access to MythTV and which have very standard
>> tuners. Putting in the right conditions (which is where I hope we
>> have arrived at now) should allow mythbackend to start at the right
>> time.
>>
>> The reports about mythtv-setup taking ages to get to the new capture
>> card page are likely what I saw when I first tried 0.28 on 16.04. That
>> is a problem with the code supporting the new VBox network tuners,
>> where the code involved takes a very long time to decide that there
>> are no VBoxes on the network. In my case, that happened because I had
>> not set up my networking on my new test box at that point, so it was
>> not working properly. Once I sorted out my network setup, the long
>> timeout waiting for VBox detection went away, although it still takes
>> longer than it used to. The reason for the problem was quite visible
>> in the xterm window that pops up to run mythtv-setup.real - I could
>> see the messages about VBoxes when I swapped to that window while I
>> was waiting for mythtv-setup.real to open the new tuner page. VBox
>> support is new in 0.28 and I think this problem is just a bug, but I
>> have not checked to see if it has been reported yet.
>>
>
> In my case networking was the first thing I setup.I used remmina remote
> desktop to work on the PVR,so it is the first task on a new install.Then I
> tried HDHR configure GUI and that always worked so networking was
> functional.So I'm skeptical whether this applies to my situation.


The point is not whether networking works on your machine, but whether
networking is started when mythbackend starts. If networking isn't up when
mythbackend starts, it won't be able to see the networked HDHR.