[webif] Web Interface 1.4.x

[/df]

Strange behaviour observed on HDR webif when simultaneously

• listening to a radio channel;
• recording the second of two consecutive scheduled programmes;
• having a remote HD share mounted by network-shares-automount, on which machine the same two programmes were also scheduled for recording.

The status tooltip showed:

Playing /Video/Friends/Friends_20180919_1601
Decrypting [Shares] Do not delete!/Kitchen/Video/Friends/Friends_20180919_1601
Playing Friends/Friends_20180919_1631

The /mod/bin/status command showed something like this (sorry, it disappeared from the telnet scrollback):

Playing /Video/Friends/Friends_20180919_1601
Decrypting [Shares] Do not delete!/Kitchen/Video/Friends/Friends_20180919_1601
Playing Friends/Friends_20180919_1631
VFD: BBC Radio 4

Whereas I would have expected it to say something like:

Watching 704: BBC Radio 4 - ...
Recording /Video/Friends/Friends_20180919_1631
Decrypting Friends/Friends_20180919_1601
VFD: BBC Radio 4

I see several issues here.

1. The system can't distinguish between Playing and Recording (I think this has been seen before?).
2. Perhaps because of the above, it fails to display the "Watching" line.
3. Either it's confused about which Friends_20180919_1601 is being decrypted, or the wrong file is being processed.

Because of #2, the radio_ss_off package is defeated and then starts working again once the recording finishes.

Regarding #3, surely it should be at least the default not to scan into shares? Or is there some flag file (say, .noauto) that could be placed in the "[Shares] Do not delete!" directory? If not, should there be?

 

[everthewatcher]

Strange behaviour observed on HDR webif...

Funnily enough I've caught the webif reporting the HDR was playing something when it wasn't a couple of times this week and it's just done it again:

Playing [Shares] Do not delete!/CASTLE/YouTube/EEVblog...

Which was the last thing I watched on it last night.

Or is there some flag file (say, .noauto) that could be placed in the "[Shares] Do not delete!" directory?

That AIUI is what the [square brackets] do.

 

[Black Hole]

Yes, folder names prefixed "[" are supposed to be excluded from (most) CF scanning unless explicitly included by adding a flag.

 

[/df]

So just now:

• recording Vanity Fair
• playing Bodyguard

And the status output:

Playing New_ Vanity Fair/New_ Vanity Fair_20180930_2102
Playing Bodyguard/Bodyguard E5 20180916_2100
VFD: Bodyguard 00
Idle: 00:04:27

Attached are the output of status -d and the lsof command from which status tries to work out what to display (some quite advanced magic in that tcl script, I'd say).

 

[af123]

Do you have redring installed? Since that package has access to what is actually recording, it is used to improve the status display if it's installed.
Otherwise, status has to infer 'recording' from whether the .ts file is growing, but it can't wait too long to check as it needs to report the status. With redring it can determine recording state immediately without having to take two file size measurements. A reboot is required after installing redring.

 

[Black Hole]

I think it is worth adding a note to that effect in post 1 of the redring topic:

https://hummy.tv/forum/threads/redr...when-recording-in-standby-other-options.1428/

 

[af123]

I think it is worth adding a note to that effect in post 1 of the redring topic:

Done. These days there are other ways that status could get the information via nugget and perhaps that's what should be done since nugget is required by webif.

@/df - here's the section of code that handles the redring integration. Redring creates and maintains dot files in /tmp as it sees recordings start and stop - https://github.com/hummypkg/webif/blob/master/webif/cgi-bin/status.jim#L168

 

[/df]

Done. These days there are other ways that status could get the information via nugget and perhaps that's what should be done since nugget is required by webif.
...

Should the HD get a mention somewhere? The display functions of redring aren't relevant -- does it even run on HD? -- but the status tracking functions would presumably be useful.

 

[/df]

Do you have redring installed? ...

The redring package is installed and the ring was red at the time in question!

... Since that package has access to what is actually recording, it is used to improve the status display if it's installed.
...

...
- here's the section of code that handles the redring integration. Redring creates and maintains dot files in /tmp as it sees recordings start and stop - https://github.com/hummypkg/webif/blob/master/webif/cgi-bin/status.jim#L168

Indeed, thanks. The status command is a link to that script, and the debug output from line 192 showed its recs list to be empty -- unless that was a side-effect of running the script outside the webif. That in turn would override the magical lsof processing at lines 206ff.

Unrelated, but the Idle: line counts the time since a remote command. Obviously the HDR is not "Idle" in any sense if it's playing or recording, let alone both. It's not important if it's just used for display, but is there any code that considers the system "Idle" based on this (ie, on [system idletime])?

 

[af123]

Indeed, thanks. The status command is a link to that script, and the debug output from line 192 showed its recs list to be empty

That's strange then - if redring is active (and looking now, I can see that it is from the lsof output) then there should be a /tmp/.rractive file and then an associated /tmp/.rec0 if a recording is in progress. Could you check if that mechanism is working?

 

[af123]

Unrelated, but the Idle: line counts the time since a remote command. Obviously the HDR is not "Idle" in any sense if it's playing or recording, let alone both. It's not important if it's just used for display, but is there any code that considers the system "Idle" based on this (ie, on [system idletime])?

As far as I know, it's just for display - a way for the user to know when the box is likely to power off due to inactivity. It's calculated from the last remote control keypress since we have not yet found the memory location that stores the real timer.

 

[MymsMan]

It's not important if it's just used for display, but is there any code that considers the system "Idle" based on this (ie, on [system idletime])?

Chaseget use this information (and disk and program activity) to determine whether it is safe to put the system back into Standby if it woke the system up.

 

[/df]

That's strange then - if redring is active (and looking now, I can see that it is from the lsof output) then there should be a /tmp/.rractive file and then an associated /tmp/.rec0 if a recording is in progress. Could you check if that mechanism is working?

There's no .rec0 file but there is a .rractive. So it's not. If I manually create /tmp/.rec0, the status display behaves as expected, with a 1-element recs. The manual .rec0 doesn't get deleted or updated.

Also, in /mod/tmp/redring.log (my annotation with #):

[RR] Mon Oct  1 14:23:21 2018: Play icon on.                        # playing MotD; time is GMT
[RR] Mon Oct  1 15:00:57 2018: No-match, trying '20181001_1459'.    # about to record an episode of Friends
[RR] Mon Oct  1 15:00:57 2018: No-match, trying '20181001_1501'.
[RR] Mon Oct  1 15:00:57 2018: Ring going red.
[RR] Mon Oct  1 15:00:57 2018: REC icon on.
[RR] Mon Oct  1 15:26:50 2018: Play icon off.
[RR] Mon Oct  1 15:32:08 2018: REC icon off.                        # finished recording
[RR] Mon Oct  1 15:32:18 2018: No-match, trying '20181001_1531'.    # about to record a 2nd episode of Friends
[RR] Mon Oct  1 15:32:18 2018: No-match, trying '20181001_1533'.
[RR] Mon Oct  1 15:32:18 2018: Ring going red.
[RR] Mon Oct  1 15:32:19 2018: REC icon on.

I reinstalled redring (though this config was only built a couple of weeks ago) but no change.

 

[/df]

Chaseget use this information (and disk and program activity) to determine whether it is safe to put the system back into Standby if it woke the system up.

Sounds quite safe and reasonable, as might be expected given the work you've put in.

 

[af123]

I'll investigate further later, but did a quick test and it's working as expected on my box:

[RR] Mon Oct  1 17:32:27 2018: Checking recording name '20181001_1732' for '20181001_1732'
[RR] Mon Oct  1 17:32:27 2018: Recording start 47:'/mnt/hd2/My Video/Pointless_20181001_1732.nts'
[RR] Mon Oct  1 17:32:27 2018:    Recording 1

humax# echo `cat /tmp/.rec0`
/mnt/hd2/My Video/Pointless_20181001_1732

Could you please try increasing the debug level of redring through the web interface settings screens?

 

[af123]

It looks like you were falling foul of the check that's made to confirm that the new recording file has the expected timestamp in its name. That's to avoid false positives with files being moved or copied around. What are the on-disk names for those recording files?

 

[af123]

While I'd still like to get to the bottom of it, I've been experimenting with adding functionality to nugget to retrieve this information directly from the tuner routines.. seems promising.

HDR-Fox T2 1.03.12/3.13

humax#
humax# nugget recordings
humax#
humax# status
Watching 250: BBC Red Button
Will record 'NCIS: Pandora's Box Part 1' on 5 USA at 20:00
VFD: BBC Red Butt
Idle: 00:00:26

humax# nugget recordings
humax# ir 1 OK
1 (0x3)
OK (0x13)
humax# nugget recordings
/mnt/hd2/Tsr/0
humax# ir 2 5 0 OK
2 (0x4)
5 (0x7)
0 (0xc)
OK (0x13)
humax# nugget recordings
humax# date
Mon Oct  1 19:48:05 BST 2018

humax# date
Mon Oct  1 20:02:47 BST 2018

humax# nugget recordings
/mnt/hd2/My Video/NCIS/NCIS_ Pandora's Box Part 1_20181001_2002
humax# echo `cat /tmp/.rec0`
/mnt/hd2/My Video/NCIS/NCIS_ Pandora's Box Part 1_20181001_2002

 

[/df]

It looks like you were falling foul of the check that's made to confirm that the new recording file has the expected timestamp in its name. That's to avoid false positives with files being moved or copied around. What are the on-disk names for those recording files?

The "No-match" log entries would seem to indicate something like that.

The actual names are lost to Sweeper now but the file that was supposed be shown from this log excerpt ...

[RR] Mon Oct  1 15:32:18 2018: No-match, trying '20181001_1531'.    # about to record a 2nd episode of Friends
[RR] Mon Oct  1 15:32:18 2018: No-match, trying '20181001_1533'.

was "/mnt/hd2/My Video/Friends/Friends_20181001_1632" in the manual .rec0 file, according to my telnet scrollback; so the actual name was that with .ts appended.

Later, I recorded "University Challenge_20181001_2031.ts", with max RR logging:

[RR] Mon Oct  1 19:31:33 2018: Checking recording name '20181001_2031' for '20181001_1931'
[RR] Mon Oct  1 19:31:33 2018: No-match, trying '20181001_1930'.
[RR] Mon Oct  1 19:31:33 2018: No-match, trying '20181001_1932'.

So it's not use of a series folder. Is there a TZ issue? I ran the tzget utility that comes with redring:

# /mod/boot/tzget 
Micom Timestamp: 95983 - Fri Jan  2 02:39:43 1970
GMT
#

 

[af123]

Is there a TZ issue?

I'd say so, the clock in your front panel processor is 1970.. Usually putting the box into standby and out again is enough to set the clock after a power cycle. You don't even need to let it go to sleep fully. Alternatively, you can install and use the hwctl package to set the clock. The command is:

humax# hwctl -d 3 ^`date +%s`

 

[/df]

I'd say so, the clock in your front panel processor is 1970.. Usually putting the box into standby and out again is enough to set the clock after a power cycle. You don't even need to let it go to sleep fully. Alternatively, you can install and use the hwctl package to set the clock. The command is:

humax# hwctl -d 3 ^`date +%s`

So there's a separate clock in the front panel that can get out of sync even though there's a reliable time signal in the DVB-T signals? Cripes.

That fixed it, after rebooting. hwctl is a prereq of webif, anyway.

# hwctl -d 3 ^`date +%s`
Time: 1538472513
05 05 03 5b b3 3a 41 91 
06 01 03 04 
COMMAND:    3
DATALEN:    0
CHECKSUM:   4 (=4) OK

# /mod/boot/tzget 
Micom Timestamp: 1538472515 - Tue Oct  2 10:28:35 2018
BST
#
... reboot ...
# status -d
OPS: 
 DATA: ({/mnt/hd2/My Video/VOTW_ Grace Carter_20181002_1154.ts} 2310144)
 NDATA: ({/mnt/hd2/My Video/VOTW_ Grace Carter_20181002_1154.ts} 2310144)
 RECS: {/mnt/hd2/My Video/VOTW_ Grace Carter_20181002_1154.ts}
Recording VOTW_ Grace Carter_20181002_1154
Watching 704: BBC Radio 4 - Sound Lines (11:30 - 12:00) [83%]
VFD: BBC Radio 4
Idle: 00:01:05
#

Many thanks, and good luck with the nugget enhancement.