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?
 

prpr

Well-Known Member
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:

MymsMan

Ad detector
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.
 
OP
Black Hole

Black Hole

May contain traces of nut
Ummm...

image.jpeg

I thought maybe that's peculiar to the "failed" HDR, but I get exactly the same thing elsewhere.
 

MymsMan

Ad detector
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
 
OP
Black Hole

Black Hole

May contain traces of nut
I'm not a Linux guru, and neither will be other readers coming across this discussion. More instruction was necessary!
 

prpr

Well-Known Member
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.
 

af123

Administrator
Staff member
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!
 
OP
Black Hole

Black Hole

May contain traces of nut
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!
 

prpr

Well-Known Member
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
 

prpr

Well-Known Member
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:
 

af123

Administrator
Staff member
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)
 

prpr

Well-Known Member
Should there have been a package update for epg to add the file in modservice.d/ ?
 

af123

Administrator
Staff member
It will be part of webif since that's what starts the daemon. The epg package just delivers the utility.
Yes, I missed it.
 

prpr

Well-Known Member
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.
 
Top