[webif] Web Interface 1.2.x

Just noticed this on "ps ax" output:
Code: 
22198 ?  SN  0:00 sh -c /mod/etc/recmon.d/auto-unprotect -stop "/media/
22201 ?  SN  3:16 /mod/bin/jimsh /mod/etc/recmon.d/auto-unprotect -stop
22774 ?  SN  0:00 sh -c /mod/etc/recmon.d/auto-unprotect -stop "/media/
22778 ?  SN  2:43 /mod/bin/jimsh /mod/etc/recmon.d/auto-unprotect -stop
 3106 ?  SN  0:00 sh -c /mod/etc/recmon.d/auto-unprotect -stop "/media/
 3109 ?  SN  2:36 /mod/bin/jimsh /mod/etc/recmon.d/auto-unprotect -stop
The files in question were deleted a couple of weeks ago, so these have been running for rather a long time. What's causing this I wonder?
 
prpr said:
What's causing this I wonder?
Click to expand...
Lsof (as used by "system inuse" as used by "ts inuse") spews a load of stuff if the file doesn't exist, which makes "system inuse" return 1 as though the file is in use. Might I suggest an existence check beforehand to make it return 0 if not a file?

Edit: Removed broken code
 
Last edited:
af123 said:
Can you post the tail end of your auto.log file?
Depending on your debug level it may have enough in to give me a clue about what's happening here. I half suspect it could be related to the recmon-triggered automatic processing.
Could you also increase the auto processing log level in settings? That will provide more information for next time.
Click to expand...
Hi af123,
Hopefully this info is not too large and assists.
I have uploaded the Activity Log and the Auto Log for overnight last night. Transporter up'd the count OK but MOTD did not.
 

Attachments

  • Activity Log.pdf
    128.8 KB · Views: 2
  • auto log.txt
    439.4 KB · Views: 2
prpr said:
Lsof (as used by "system inuse" as used by "ts inuse") spews a load of stuff if the file doesn't exist, which makes "system inuse" return 1 as though the file is in use. Might I suggest an existence check beforehand to make it return 0 if not a file?
Click to expand...
Thanks, good idea (although I'll have to do it in Jim rather than Bourne shell : )
 
prpr said:
Just noticed this on "ps ax" output:
Code: 
22198 ?  SN  0:00 sh -c /mod/etc/recmon.d/auto-unprotect -stop "/media/
22201 ?  SN  3:16 /mod/bin/jimsh /mod/etc/recmon.d/auto-unprotect -stop
22774 ?  SN  0:00 sh -c /mod/etc/recmon.d/auto-unprotect -stop "/media/
22778 ?  SN  2:43 /mod/bin/jimsh /mod/etc/recmon.d/auto-unprotect -stop
3106 ?  SN  0:00 sh -c /mod/etc/recmon.d/auto-unprotect -stop "/media/
3109 ?  SN  2:36 /mod/bin/jimsh /mod/etc/recmon.d/auto-unprotect -stop
The files in question were deleted a couple of weeks ago, so these have been running for rather a long time. What's causing this I wonder?
Click to expand...
I don't know but will try and replicate it.
Could you try an strace on one of the jimsh processes to see what it's doing and maybe grab a core file to see if it helps (although gdb struggles to analyse MIPS cores)
 
af123 said:
I don't know but will try and replicate it.
Could you try an strace on one of the jimsh processes to see what it's doing and maybe grab a core file to see if it helps (although gdb struggles to analyse MIPS cores)
Click to expand...
Cause found in #82 (which you already responded to!!!).
 
peterworks said:
Hi af123,
Hopefully this info is not too large and assists.
I have uploaded the Activity Log and the Auto Log for overnight last night. Transporter up'd the count OK but MOTD did not.
Click to expand...

Incrementing the count following a recording is done by the standard Humax firmware. I can see that MOTD was decrypted by background processing at 09:47 and then it was passed to sweeper as a file that needed looking at at 09:56 but sweeper didn't need to do anything to it.
The recording was shrunk at 09:57.
Unfortunately I can't see anything there that would explain why the count wasn't incremented.
 
prpr said:
Cause found in #82 (which you already responded to!!!).
Click to expand...
Aha! Just catching up and didn't make the link.
So the processes are waiting for the file to stop being in use, which they never will because of the bug. Got it.
 
Every time I reboot a machine (not from the browser, obviously) I end up with "If the system has only recently been started, it could still be initialising - refresh this page to try again." on the browser page.
It might be nice to put a 30s automatic refresh on this...
 
And having rebooted, the Idle timer now says "22h, 47m" which is patently wrong as I've been using it this afternoon. Initial conditions problem on a variable somewhere?
 
The idle time is based on the modification time stamp of the /tmp/.lastir file, perhaps this wasn't reset on boot for you.

I am seeing the idle timer resetting to zero far too frequently, it appears to be detecting any IR button push not just those controlling the Humax.

I first noticed it when using the Humax remote to control the TV but it also happens when using the TV's own remote (LG tv)
 
I have a new ir package ready for testing which should hopefully resolve these problems. Interesting that the current version sees any IR command as a trigger - I'll need to test that.
 
MymsMan said:
The idle time is based on the modification time stamp of the /tmp/.lastir file, perhaps this wasn't reset on boot for you.
Click to expand...
It's got a garbage timestamp, as have other things:
Code: 
-rw-r--r--  1 root  root  0 Mon Feb 16 23:31:05 1970 .lastir
-rw-r--r--  1 root  root  0 Mon Feb 16 23:30:59 1970 .humaxtv.running
-rw-------  1 root  root  1 Mon Feb 16 23:30:59 1970 .lbr
-rw-r--r--  1 root  root  318 Mon Feb 16 23:30:59 1970 rsvsync.log
-rw-r--r--  1 root  root  1059 Mon Feb 16 23:30:59 1970 xinit.log
-rw-------  1 root  root  3 Mon Feb 16 23:30:58 1970 .tz
It's always about 22:45 adrift though, ignoring the date. When does the clock get set in the boot process?
I am seeing the idle timer resetting to zero far too frequently, it appears to be detecting any IR button push not just those controlling the Humax.

I first noticed it when using the Humax remote to control the TV but it also happens when using the TV's own remote (LG tv)
Click to expand...
I get it on both HDRs using either remote, but not with the TV or any other remote.
 
MymsMan said:
I am seeing the idle timer resetting to zero far too frequently, it appears to be detecting any IR button push not just those controlling the Humax.

I first noticed it when using the Humax remote to control the TV but it also happens when using the TV's own remote (LG tv)
Click to expand...

My TV & Bluray are both Sony and their remotes have no effect on the timer, so it may depend on brand (i.e. whether it is a "compatible" signal encoding?).
 
I think the purpose of it was for people who have enabled the on-telly UI power-saving mode, to rudely turn off after some idle time, whilst you are in the middle of watching Buffy.

Of course, you would not then also be looking at the WebIF, so it wouldn't help you :)
 
You must log in or register to reply here.
Back
Top