Auto-unprotect not doing its thing

Black Hole

May contain traces of nut
As above, on one of my HDRs. I can't see anything in the logs, but then auto-unprotect doesn't leave any trail, does it?

I don't think I've seen this before. The recordings in question (OK last Saturday, failed last Sunday and yesterday) are in a [ folder but that's never mattered in the past. There's not a lot of disk space, but again that shouldn't bother auto-unprotect.

The obvious first step is a reboot, but is there anything to look at for fault analysis first?
 
Has recmon stopped running? It crashes on mine sometimes, as does epg.

I would say check the Service Management page in the WebIf (or "service" on the command line), but I don't think my various suggestions for additions ever got taken up. This is what I added:
Code:
humax ~ # cat /mod/etc/modservice.d/recmon
key=/mod/sbin/recmon
rc=54recmon
proc=/mod/sbin/recmon
 
Last edited:
You can try restarting Recmon manually from the command line.

It would be nice if there was a tool that periodically checked whether it was alive and restarted it when necessary

DetectAds (chaserun) also depends on Recmon to detect the start of a recording and I occasionally see unprocessed programs when recmon has gone AWOL but I have been unable to spot any rhyme or reason as to why it has failed.
 
Ummm...

image.jpeg

I thought maybe that's peculiar to the "failed" HDR, but I get exactly the same thing elsewhere.
 
The suggestion is to create the file as shown and it will add a new entry to the services menu to show the status of recmon
 
I'm not a Linux guru, and neither will be other readers coming across this discussion. More instruction was necessary!
 
More instruction was necessary!
Tweaked. You gave up quite early.
You can try restarting Recmon manually from the command line.
Using:
Code:
humax# /mod/etc/init.d/S54recmon stop
humax# /mod/etc/init.d/S54recmon start
or if my previous suggestion has been implemented:
Code:
humax# service stop recmon
humax# service start recmon
ISTR suggesting a mod. for a "restart" option to service too, which I have implemented locally:
Code:
humax /mnt/hd2/mod/bin # diff service~ service
--- service~
+++ service
@@ -62,6 +62,7 @@
 case "$1" in
  start) shift; control start "$@" ;;
  stop) shift; control stop "$@" ;;
+  restart) shift; control stop "$@" ; control start "$@" ;;
  toggle) shift; control toggle "$@" ;;
  auto) shift; auto "$@" ;;
  mlist)
@@ -91,6 +92,7 @@
 Syntax:
  service start <service>
  service stop <service>
+  service restart <service>
  service auto <service>  (toggles autostart)
 EOM
and then it would just be:
Code:
humax# service restart recmon
It would be nice if there was a tool that periodically checked whether it was alive and restarted it when necessary
Agreed.
 
Bah, I hate watchdog processes as sticking plasters!
However given that we don't know why recmon is going away, I'll make it restart automatically for now (and same for epg).
prpr - I'll add your suggestions regarding service too, thanks.

I wonder how often this is happening? My main box doesn't stay on all of the time, it wakes up to record and is woken up when we want to watch things so if it is failing then it just gets restarted on the next boot. I'll check my test box which is permanently on - although I've lost connectivity to it at the moment, my powerline network must be down again!
 
my powerline network must be down again!
Yours too? Funnily enough, mine has become more reliable again.

Still not enough. "Create a file named <path> containing these contents" would have been a better clue, even if the reader (including me) then had to go and look up how to do it (yes I know I can do it through the diagnostic editor - but it would still be a little bit of exploration).

You gave up quite early.
After a long day running a ballroom competition all I wanted to do was make Strictly play in bed!
 
For completeness, here are my other mods. for service monitoring:
Code:
humax /mnt/hd2/mod/etc/modservice.d # cat epg
key=/mod/bin/epg
rc=60parseepg
proc=/mod/bin/epg
humax /mnt/hd2/mod/etc/modservice.d # cat ntp
key=/mod/bin/ntpclient
rc=90ntpclient
proc=/mod/bin/ntpclient
 
Still not enough. "Create a file named <path> containing these contents" would have been a better clue
I've provided the food and the spoon... ;)
Bah, I hate watchdog processes as sticking plasters!
Well they do have their uses. At the moment we have something that works the vast majority of the time, but when it does go wrong you often don't notice for a while and then it's a case of not knowing what went wrong or when or why. With a watchdog and logging you can keeps tab on what and when at least.
my powerline network must be down again!
:eek:
 
With last night's package update, recmon should now be restarted if it fails.
Additionally, if you have the crashdiag package installed then if it happens to crash, a core file will be created in /mod/core which should help find out why.
(Same for the epg process)
 
Should there have been a package update for epg to add the file in modservice.d/ ?
 
It will be part of webif since that's what starts the daemon. The epg package just delivers the utility.
Yes, I missed it.
 
It will be part of webif since that's what starts the daemon. The epg package just delivers the utility.
Not sure I understand the logic of that. If you had service-control and epg installed but not webif, then it wouldn't show up in the list on the service command. epg is already a dependency of webif so the file is guaranteed to be there for webif to use.
 
Back
Top