Strictly not recorded on Saturday 2nd Nov...

peterworks

Ye Olde Bowler
It was set up to go okay and, according to the activity log, '02/11/2019 18:55:30 - System booted (Scheduled event)' ready for recording at 19:00.
However nothing recorded. The Humax was not being used for viewing at the time. I use padding (2 mins before and 5 mins after).
Anything I can look for please ?
 
I can't help directly but on the same transmitter the AR recording here (BBC1 HD) started at 18:59:08, nearly a minute early but well within the padding you set.
 
my 2nd of November, not 3rd as in the title of this thread, strictly recording says it started 18.58.

so your padding could have let you down. just can't remember when AR let me down in normal circumstances
 
Thanks @/df I had considered this but:
1. The activity log time is consistent with what I would expect.
2. I have Ntpclient installed.
3. Although I have the front panel clock off (using redring) the screen saver always shows the time to be correct within a second or two.
If I am missing something please let me know.
 
If you read back from the linked post, there are instructions for checking the sync from telnet.

#1 seems to indicate that it isn't an issue, but AFAIK #2 and #3 only relate to the main-board time.

I don't understand the need for ntpclient, unless your main board clock is very sick. Wouldn't a box that is regularly put to sleep update from the broadcast signal when woken? It is supposed to sync the front panel when put to sleep, but apparently there are cases when this doesn't happen.

Incidentally the Humax HDR Fox T2 binary, alongside which Humax provided a /usr/bin/ntpclient, mentions these two relevant strings: "uk.pool.ntp.org" and "ntpclient". It's not clear when these might be used and there doesn't seem to be any way in which NTP use by the Humax software is accessible or visible in the UI.
 
Have removed ntpclient which, as you say, is unnecessary and have tried to find the instructions for checking the sync from telnet. From what I can tell you get:
# /mod/boot/tzget
Micom Timestamp: 1538472515 - Tue Oct 2 10:28:35 2018
BST
but, when I run the tzget command, I only get GMT (no timestamp or day/date).
 
Wouldn't a box that is regularly put to sleep update from the broadcast signal when woken?
Experiments demonstrated that the clock only updates if it exceeds a certain margin of error from the broadcast time (30s either way, IIRC).
I don't understand the need for ntpclient,
Internal clock accuracy is needed for accurate padding (which obviously has to work on scheduled times rather than the start flag). However, the real use for it is with no aerial at all for its streaming and Portal functionality - the latter doesn't work unless the unit "knows" what the date is.

See Things Every... (click) section 6. You might also like to read the thread starting roughly here:
Particularly for users of padding, it would seem to be necessary that the internal clock gets synced to EPG regularly (via a cold boot), otherwise recorded consecutive programmes are more likely to get splt in the wrong place. This could be a reason to install ntpclient even with an aerial connected!
 
Last edited:
Back
Top