Webif - Display Last Retune Date

[/df]

Some more relevant homework reading ...

...
Semantics for the network change notify descriptor:

cell_id	... 16-bit field uniquely identifies a cell within a DVB-T or DVB-T2 network (as defined by network_id). ... 0x0000 shall be used to signal a change affecting all cell_ids. ...
loop_length	... 8-bit field specifies the length in bytes of the following items.
network_change_id	... 8-bit field is a unique identifier for the network change event signalled within this cell. ...
network_change_version	... 8-bit field signals the version of the change. ...
start_time_of_change	... 40-bit field indicates the time at which the network changes are planned to start ...
change_duration	... 24-bit field indicates the planned duration of the network change ...
receiver_category	... 3-bit field indicates the category of receivers affected by the change being signalled according to[:] receiver_category Description 0x0 All receivers 0x1 DVB-T2 or DVB-S2 or DVB-C2 capable receivers only 0x2 to 0x7 reserved for future use
invariant_ts_present	... 1-bit field is set to '1', [if] an invariant transport stream is being signalled. If set to '0', all multiplexes with this cell_id (for DVB-T or DVB-T2 systems) or within the network (for other delivery systems) should be considered as subject to change. ...
change_type	... 4-bit field specifies the type of change that will take place, as defined in table [below]. change_type Description 0x0 Message only 0x1 Minor - default 0x2 Minor - multiplex removed 0x3 Minor - service changed 0x4 to 0x7 reserved for future use 0x8 Major - default 0x9 Major - multiplex frequency changed 0xA Major - multiplex coverage changed 0xB Major - multiplex added 0xC to 0xF reserved for future use for other major changes Minor changes are defined as those changes which can be detected by a receiver by comparison of the old and new SI. Major changes are defined as those which could require a receiver to tune or scan away from the current multiplex. The "default" category shall be used when another category does not adequately describe the current scenario, or when multiple categories would describe the current scenario. The "message only" category shall be used when there are no changes to the network but the broadcaster wishes to provide a message to be displayed by the receivers. The "coverage change" category shall be used when power and/or modulation parameter changes may change the coverage of a transmitter. It shall also be used when a cell or transmitter is being added or removed since this can also change the coverage. ...
message_id	... 8-bit field is used to link to a message in the message descriptor carried in the same NIT. ...
invariant_ts_tsid	... 16-bit field contains the transport_stream_id of the invariant transport stream.
invariant_ts_onid	... 16-bit field contains the original_network_id of the invariant transport stream.

Retuning of transmitters
The signalling of a change of frequency for an existing multiplex ... shall also be signalled by a network change notify descriptor ...

Use of Network change related descriptors
Network change descriptors are used to provide a receiver with additional service and network reconfiguration information, ... Two descriptors are used, one to provide network change information to the receiver and one to provide change related textual information for the end user.

The other type of descriptor is the Message descriptor, which I suppose causes the "Press Yellow to hide this message" pop-ups that we are seeing currently.

Use of the Network change notify descriptor
...
In using the change_type, the MSB is set to '1' when the signalled network change is classified as major, i.e. cannot be evaluated using [transmitted Service Information] alone.

Addition to or removal of multiplexes from a network
...
A compliant receiver shall deem there to have been a change in the number of multiplexes in a network when:
• An update occurs in the NIT (actual) bringing with it a different listing inside its transport_stream_loop AND, after a re-acquisition of SI has been
made, a new SDT (other) is found OR an existing SDT (other) is lost. ...
The fact that a new Transport Stream has become available to the viewer should be deemed inconsequential unless they are offered more
services or existing services have been moved to the new transport stream as signalled using a service relocated descriptor. ...

The Service relocated descriptor (section 8.5.3.22) is sent in the SDT . It specifies how a new service replaces an old one, each identified by (service_id, transport_stream_id, original_network_id).

Addition to or removal of services from a multiplex
...
A compliant receiver shall deem a service to have been added to a multiplex if there is an update to the SDT (actual) for that multiplex which
references the new service.
The receiver shall consider a service to have been removed if there has been no explicit reference to it in any table in any Transport Stream in which
that reference was expected for a time-out period.
...
Specifically, when a service is moved to another multiplex:
• Receivers should use the service relocated descriptor to track the change and migrate entries in favourite lists, reminders and booked recordings where possible.

Notes for Receiver manufacturers

Receivers shall store all relevant messages referenced by the network_change_notify descriptors. Manufacturers should minimise
unnecessary viewer notifications ...
Broadcaster supplied messages shall be displayed as broadcast in the message descriptor. Any additional manufacturer message shall be clearly separated from the broadcast message.
For changes signalled as a change_type 'Major' network change messages should be displayed at these times:
• On the first suitable user interaction after initial receipt of the network_change e.g. channel change, power on.
• On the first suitable user interaction 48 hours prior to the start_time_of_change.
• Either, 1 hour prior to the start_time_of_change or, on commencement of any EIT event being viewed which will finish
exactly at or after the start_time_of_change.
...
For changes signalled as a change_type 'Minor', the network change messages shall be displayed at or after the calculated finish time of the
change, messages shall not be displayed before this time. Viewers should be given the choice to permanently ignore the change, instigate a receiver
retune, or postpone the retune for a later time. ...

Apart from muxes coming and going and entire channels (viewer speak) coming and going and changing muxes, there is the possibility of regional channel variants coming and going.

 

[Black Hole]

Note the explicit use of "shall" (must) or "should" (recommended but optional)... something the government hasn't been keen to clarify in its Covid advice.

 

[Ezra Pound]

Fiddling with /mod/webif/html/diag/mux.jim has so far given me this, If only I knew what I was doing :-

 

[/df]

The incantation you need to retrieve and format ASO_LAST_SCAN_TIME is

# to test this in jimsh, first uncomment the next line
#source /mod/webif/lib/system.class
# system param param_name [param_type] [param_table]
clock format [system param ASO_LAST_SCAN_TIME Value USERCONFIG]

Other date-time formats are available by appending, eg -format {%F %T %Z}, where the format codes are those supported by strftime() (or see/search for man date).

So before line 30 (<br><br>) of /mod/webif/html/diag/mux.jim, you could put, eg:

<span style='left: 40ch;position: relative;'>Mux date: [clock format [system param ASO_LAST_SCAN_TIME Value USERCONFIG] -format {%F %T %Z}]</span>

 

[Ezra Pound]

Thanks for that, I just got a completely blank screen when entering the <span . . . . </span> line, but keeping it as a button worked, so I added :-

[line 8] clock format [system param ASO_LAST_SCAN_TIME Value USERCONFIG]

[old line 30]        <button id=last-retune> Last Re-Tune : [clock format [system param ASO_LAST_SCAN_TIME Value USERCONFIG]]</button>

I realise it's an un-used button but it does what I want - Thanks Again

 

[MymsMan]

If only I knew what I was doing :-

It has never stopped us yet,
It is only by experimenting that you start to learn how it all works

 

[Black Hole]

It is only by experimenting that you start to learn how it all works

I created an entire website from practically zero knowledge, simply by hacking the HTML/CSS/JS and looking up W3Schools whenever I got stuck. OK, so it took a while, and making it play nicely with iPhones was a bit esoteric (viewport), but I got there (still getting there, actually).

The problem is that, without the benefit of youth, I have to look it all up again the next day.

 

[Ezra Pound]

MymsMan : It has never stopped us yet,

vi almost competent, shell scripts well I'll be generous and say so-so, jim nothing, but it does make you want to know more

 

[MymsMan]

vi almost competent,

Gave up trying to understand vi. I mainly ue Atom running on my PC to edit humax files via a network link, webif editor for the common files and occasionally nano on humax.

shell scripts well I'll be generous and say so-so

ditto

jim nothing, but it does make you want to know more

I still need to keep http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html constantly open - jim is an odd language
Unfortunately the many services provided by the CF have never been documented so a lot of copy/paste and code reading is needed or ask on the forum for help.

 

[Ezra Pound]

I still need to keep http://jim.tcl.tk/fossil/doc/trunk/Tcl_shipped.html constantly open

Thanks for that, I'll get reading

 

[/df]

Thanks for that, I just got a completely blank screen when entering the <span . . . . </span> line, ...

Try it with the single quotes on the style attribute value as amended above. Plainly what I posted originally would cause the Jim script to fail and/or WebIf to create an invalid HTML page because the first double quote on the style attribute value would have terminated the string being written to the web page, and then the style attribute would have been invalid Jim syntax.

You shouldn't need the clock format ... stuff except in [] inside the HTML element being written to the page.

 

[Ezra Pound]

Yes, the modified <span> . . . </span> worked, I change the presentation a little :-

 

[Black Hole]

I can only dream of those signal strengths...

 

[prpr]

I can only dream of those signal strengths...

Get an amplifier then. You'll get more than the same amount of noise, but hey, the figures will look better.

 

[MymsMan]

or ask on the forum for help.

Try it with the single quotes on the style attribute value as amended above. Plainly what I posted originally would cause the Jim script to fail

But the help might not always be right first time!

To get your changes added to the official webif packages see