[mythtvnz] Recordings not happening without a reboot

[Stephen Worthington]

On Thu, 19 Jun 2014 22:40:01 +1200, you wrote:

>On Thu, Jun 19, 2014 at 10:22 PM, Stephen Worthington
><stephen_agent at jsw.gen.nz> wrote:
>>
>> On Thu, 19 Jun 2014 19:41:39 +1200, you wrote:
>>
>> >On Thu, 19 Jun 2014 19:21:04 +1200, you wrote:
>> >
>> >>My MythTV woes continue.
>> >>
>> >>Now after some indeterminate length of time (less than 24 hours)
>> >>recordings stop.  In the logs there is no sign of them.
>> >>
>> >>After a reboot recordings happen as usual.
>> >>
>> >>I can find no sign of errors in mysql logs.
>> >>
>> >>How can I start to diagnose the problem?
>> >
>> >If you look at the Upcoming Recordings list, are your recordings still
>> >there?  What does mythbackend.log actually show around the time of the
>> >a scheduled recording that did not happen?  If you shut down
>> >mythbackend after recordings have failed ("stop mythtv-backend"), does
>> >the log show anything then?  Does it shut down cleanly?  Is your
>> >database OK - is anything reported in the daily email from the
>> >/etc/cron.daily/optimize_mythdb run?  If you are not set up to receive
>> >those emails, try running that command manually from a root prompt or
>> >sudo.
>> >
>> >To get more relevant data logged, you should probably add the "-v
>> >record" option to the end of the line in /etc/init/mythtv-backend.conf
>> >that runs mythbackend.  Then do the command "restart mythtv-backend"
>> >(not while recording, obviously).
>> >
>> >Are all your tuners working?  Go to WatchTV, then use the M -> Source
>> >-> Switch Input menu to change to one multirec tuner from each of your
>> >physical tuners and make sure each tuner is working.
>>
>> One more thing to check - is the partition with your database on it
>> full?  Do you have a runaway log file?  That can may mythbackend do
>> exactly as you are describing, although I do not see why rebooting
>> would free up enough space in that case - maybe there is a runaway
>> file in /tmp as that gets deleted on reboot.
>>
>
>Not sure if this still happens in the latest version (I'm still on
>0.25.something), but another possibility is if a drive a storage group
>uses was accessible when the backend starts but becomes inaccessible
>some time after. Doesn't have to be an active storage group either. I
>added an 'old' storage group to that accessed a share on a NAS. If the
>NAS was initially visible to Myth but disappears (e.g. I turned it
>off) recordings after the drive disappeared failed even though the
>'old' storage group is never recorded directly to. I can't recall
>whether the failure was logged.

That is not a problem if you make sure you have one level of directory
on the drive for the storage group.  If you have a partition mounted
as /mnt/rec3 say, and then have the storage group write directly to
/mnt/rec3, then there is no way for mythbackend to know if the drive
is there or if it will end up storing to the root partition because
the drive is unmounted.  But if you make a recordings directory on the
drive and set the storage group to point to that, ie to
/mnt/rec3/recordings, then mythbackend will know that the drive is
unmounted if it can not see the recordings directory and will not
write to that storage group.