Webif - Display Last Retune Date

[Ezra Pound]

I have valid (Expected dates) for all 3 of my Humaxs, but I only ever perform full scans, not partial

 

[Ezra Pound]

@/df so are you seeing ASO_LAST_SCAN_TIME with a value of 2147483647 which equates to
Tuesday, 19 January 2038 03:14:07 GMT+00:00 ?, or 0, I'm getting real (current) time stamps

Do you think this timestamp can be used to produce a Diagnostis >> Mux info. screen like the one in post #1, at least for Humaxs that have performed a full re-tune?

 

[/df]

I hypothesise that there are 3 cases for ASO_LAST_SCAN_TIME:

1. an actual time_t (epoch) value, representing the time of the last full retune;
2. 0, if the last tuning event was a manual retune (?);
3. 2147483647 (ie the maximum 32-bit time_t*), set by disable-dso to prevent the system from showing "retune needed" pop-ups that default on time-out to "full retune".

If the first case is available, it could be shown.

With more difficulty, and assuming case 2 is correctly diagnosed, it could be possible to defeat the reset of the value to 0 and perhaps record a manual retune event separately. The retune time could be maintained as per-MUX values, and then ASO_LAST_SCAN_TIME could be calculated as the minimum of these values; but this doesn't work if new MUXes are introduced, a good rationale for setting ASO_LAST_SCAN_TIME to 0 on manual retunes; however better would have been to keep the last full retune time in ASO_LAST_SCAN_TIME and detect retune-needed as ASO_LAST_SCAN_TIME < max(per-MUX retune times).

The last case could be hidden or flagged, or, if disable-dso were modified to save the original ASO_LAST_SCAN_TIME, that value could be shown (but as the package no longer seems to be required, unlikely: at least, with ASO_NOTIFY_FLAG = 0 I don't get retune prompts).

*The time_t limit is one of the things that will kill the HD/R Foxes, but by 2038 we'll probably all be receiving our programme content direct from the disembodied brain of President Xi (absolutely no Winnie the Pooh?).

 

[Black Hole]

The time_t limit is one of the things that will kill the HD/R Foxes, but by 2038...

Surely this is akin to the millennium bug, and will require a concerted global bug fix.

 

[/df]

Difficult if the target is pre-built proprietary abandonware. The Year 2038 Wikipedia article seems lucid.

Also

...I came up with this, after a bit of head-scratching, which works on an off-line database:

CREATE TRIGGER if not exists ts_u_lq before update of ucLevel,ucquality on TBL_TS when new.ucLevel=0 and new.ucQuality=0 begin select raise(ignore); end;

According to spec, that will cancel whatever statement caused the trigger, which might be OK since SQLite only updates one table per statement (except via triggers), but would prevent other TBL_TS columns from being updated. With an INSTEAD_OF trigger, changes to other columns could be allowed while preventing ucLevel and ucQuality from being zeroed. I'm not sure if we need to care about such changes, but changing ulFrequency would certainly be important.

 

[prpr]

OK, thanks for the info. Never played with triggers before. It's all moot anyway.

 

[Ezra Pound]

ASO_LAST_SCAN_TIME seems to have been manipulated (set to 2^31 -1 ~ 2038) by the disable-dso package as part of the ploy to defeat the retune pop-up introduced in some version of the OEM firmware.

Are auto-retune DSO popups still transmitted?, I uninstalled the disable-dso package some years ago and have not had an un-invited re-tune or a popup threatening one for many years

Also as your Humax returned ASO_LAST_SCAN_TIME = 0, (due to a partial re-tune), how were you aware of the 2^31 posibility

 

[MymsMan]

Are auto-retune DSO popups still transmitted?, I uninstalled the disable-dso package some years ago and have not had an un-invited re-tune or a popup threatening one for many years

No, but nobody told the Humax so it sill wakes up to listen for updates, this is harmless

 

[Black Hole]

No, but nobody told the Humax so it sill wakes up to listen for updates, this is harmless

Not the same thing. The 'fox wakes up for OTA, not DSO (which is what we call it, even if no longer accurate).

DSO is an instruction from the broadcast network to warn of tuning updates and trigger an auto-retune. DSOs get set as hidden timers in the schedule database (same as OTA is a hidden schedule entry), and disable-dso removes them (hopefully before they get acted on, which RTS is helpful for). I have no idea whether they are still a "thing", but they could be.

I am perplexed by the assertion that disable-dso also meddles with the timestamp in the tuning database. I have not heard of this before - what do you say @af123?

 

[af123]

I am perplexed by the assertion that disable-dso also meddles with the timestamp in the tuning database. I have not heard of this before - what do you say @af123?

I say yes; here's what disable-dso does on each boot.

delete from TBL_RESERVATION where ersvtype = 11;
update TBL_USERCONFIG set itemValue = 2147483647
            where itemName = 'ASO_LAST_SCAN_TIME';
update TBL_USERCONFIG set itemValue = 0
            where itemName = 'ASO_NOTIFY_FLAG';

 

[Black Hole]

LOL! They appear to call it Analogue Switch-Off!

 

[/df]

The standards refer to Network Change Notification.

[The Network change notify descriptor] allows broadcasters to signal network change events to receivers. A network change event is a single, clearly identifiable change in the network configuration, e.g. transmission parameters and/or available services, which may require action on the part of receivers. ... The absence of a network_change_notify descriptor shall be used to indicate that there are no scheduled network change events.

This descriptor is transmitted, if it is, as part of the Network Information Table.

One might infer that any future retune event might be designated as a "Network Change" and thus potentially trigger retune pop-ups for the HD/R viewer.

Apparently it was found necessary to set both ASO_ parameters in disable-dso as just turning off ASO_NOTIFY_FLAG wasn't enough.

 

[Ezra Pound]

If an auto-retune is triggered then I can see that af123's disable-dso and the 2^31 may be required, but if it is only a pop-up suggestion for a re-tune then I don't think they are required

BTW
The Offcom Broadcast TV Technical Codes document dated 2016 still refers to DSO

 

[af123]

If an auto-retune is triggered then I can see that af123's disable-dso and the 2^31 may be required, but if it is only a pop-up suggestion for a re-tune then I don't think they are required

If I remember correctly, that depends on the underlying firmware version. Some of them go straight into retune in the absence of any interaction.

 

[Black Hole]

If an auto-retune is triggered

Have you never experienced one? It pops up a message saying a retune is required, with an OK or Cancel for user input - and defaults to OK if you don't respond. Cancel just defers it to pop up again another time.

 

[Black Hole]

If I remember correctly, that depends on the underlying firmware version. Some of them go straight into retune in the absence of any interaction.

Yes.

There is an even bigger "gotcha" with firmware versions 1.02.27+ and retunes. Sometimes the broadcast network invites you to perform a retune, because there have been transmitter frequency changes or new services added. With firmware 1.02.20 (and previous) a message appears on-screen inviting a retune. With 1.02.27 onwards, the message appears but if you do not cancel it within a few minutes the retune continues without permission (at cost of your recording schedule and the possible need of repeating the retune manually). Call it an opt-out rather than an opt-in. You could be off making a cup of tea, and return to find it in the process of tuning - or even worse return from holiday to find it retuned and no recordings made while you were away*.

 

[Ezra Pound]

Have you never experienced one? It pops up a message saying a retune is required, with an OK or Cancel for user input - and defaults to OK if you don't respond. Cancel just defers it to pop up again another time.

Yes, but not for quite a few years, I don't get it for the current 22nd June pop-ups for example, I guess this stopped with 1.03.**

 

[prpr]

Are auto-retune DSO popups still transmitted?

Yes, potentially, but there hasn't been one for a while as there hasn't been a change deemed big enough to make one necessary.

I don't get it for the current 22nd June pop-ups for example

That's incredibly inconsequential in the grand scheme of things, so why would it?

 

[Ezra Pound]

That's incredibly inconsequential in the grand scheme of things, so why would it?

So what kind of event is deemed big enough if the loss of a complete MUX isn't? , maybe the loss of a 'DSO*' MUX would fit the bill

* The original 6 MUXs are referred to as DSO MUXs

 

[prpr]

So what kind of event is deemed big enough if the loss of a complete MUX isn't?

Something like Freeview retune day 2-3 years ago.
COM8 reach is tiny, as is COM7, and not even on all main transmitters, let alone relays.