[mythtv-users] backend loglevel to check why record listing isn't showing any of the entries in the recorded table?

[Stephen Worthington]

On Wed, 29 Jul 2020 08:05:12 -0400, you wrote:

>On Wed, Jul 29, 2020 at 3:56 AM Stephen Worthington
><stephen_agent at jsw.gen.nz> wrote:
>>
>> On Tue, 28 Jul 2020 19:20:28 -0400, you wrote:
>>
>> >Can someone help me with what log settings I need to see why
>> >mythbackend isn't showing any of the recordings in my recorded table
>> >in the frontends or mythweb?
>> >
>> >Thanks!
>>
>> Are no recordings being listed, or are they there but greyed out with
>> an X icon?  The former suggests problems with the database or access
>> to it, the latter with partition mounts or permissions.
>>
>> Do other things work, such as:
>>
>> Manage Recordings > Upcoming Recordings
>> Information Centre > System Status > Input Status
>>
>> Does the database still have recordings in it?  What does this show?
>>
>> sudo mysql
>> use mythconverg;
>> select count(*) from recorded;
>> select count(*) from recordedprogram;
>> exit
>
>None are being listed. This is on a system where we changed the tuners
>and sources, so I don't think we set up any new recording schedules,
>so there wouldn't be any yet. Listings seems to be working though.
>We've been transitioning this setup, somewhat slowly, and Recordings
>seemed to work fine for a while, then we noticed they weren't showing,
>mainly after an apt-get update where we went in to check that it
>didn't break anything, that's when we noticed this.
>The recordings locations on the drives are read/write able by the user
>running the backend and readable by the frontend user, and the
>locations are in the Default storage group. with logging set to
>most:info I don't see any entries about recordings, even when I go
>into the Recordings screen or through MythWeb, even though it takes a
>while for the system to process and display both.
>
>I was hoping there might be another log setting that would show what
>is going on.
>
>Thanks for the help!

If you want logging of recordings being done, then you need to add "-v
record" to the mythbackend command line.  Or you can run this command
with mythbackend already running:

mythbackend --setverbose record

and this to turn it off again:

mythbackend --setverbose norecord

You do not need to use sudo as all this second instance of mythbackend
does is connect to the running copy of mythbackend and tell it the new
verbose setting.  Make sure not to mistype anything as if mythbackend
does not see a valid --setverbose or --setloglevel option it will try
to run as a full mythbackend instance.

I normally just have "-v record" on all the time, so I can see what
happened if I get a failed recording.  You do that in the
/etc/mythtv/additional.args file in Ubuntu.  This is what I have:

root at mypvr:/etc/mythtv# cat additional.args
ADDITIONAL_ARGS=-v record,dvbcam
root at mypvr:/etc/mythtv# ll additional.args
-rw-rw-r-- 1 mythtv mythtv 74 Nov 19  2016 additional.args

If your system is taking a long, long time to do some things, then it
might possibly be a problem I came up against a long time ago, where I
had two drives where the recording partitions were jfs format and were
needing to be fscked.  They were not in the Default storage group, but
in another storage group that was still searched for recordings, and
every time MythTV wanted to look for or create a recording file, it
tried to access those partitions and wound up waiting for a long
timeout on each before it went on to the next one.  I have also seen
this same effect where a storage group was on a network drive where
the network connection was failing and retrying.