Mailing List Archive

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/