[mythtvnz] New install setup - recording problem

[Nick Rout]

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 at 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 at 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 at lists.linuxnut.co.nz
>> http://lists.ourshack.com/mailman/listinfo/mythtvnz
>> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/mythtvnz/attachments/20160812/0ae74812/attachment-0001.html>