Webif - Display Last Retune Date

Ezra Pound

Ezra Pound

Well-Known Member
Is the date that the last tuning run was done on the Humax stored anywhere?, if it is may be it could be added to the Diagnostics >> Mux Info. screen, this may stop users thinking it is 'Live'

new2.jpg
 
I don't know of anywhere this timestamp might be saved, but the schema of freq.db (comprising one user table, TBL_FREQ) could be tweaked with an update trigger to record it, supposing the settop binary doesn't re-create the database on each retune.

As manual tuning is possible, the timestamp should perhaps be a per-frequency (per-MUX) item rather than a single value.

Something like this:
Code: 
alter table TBL_FREQ add column updated INT default 0;
create trigger if not exists freq_u after update of ucLevel on TBL_FREQ begin update TBL_FREQ set updated=strftime('%s','now') where ulFrequency = NEW.ulFrequency; end;
create trigger if not exists freq_i after insert on TBL_FREQ begin update TBL_FREQ set updated=strftime('%s','now') where ulFrequency = NEW.ulFrequency; end;
I put this on one of my Humaxen and we'll see what happens come 22 June.
 
/df said:
the schema of freq.db (comprising one user table, TBL_FREQ) could be tweaked with an update trigger to record it, supposing the settop binary doesn't re-create the database on each retune.
Click to expand...
It would be difficult for it to, because freq.db is created by tunefix!
 
Ha!
So s/freq.db/channel.db/, then ... since TBL_FREQ seems to be just select ulFrequency, ucLevel, ucQuality from TBL_TS.

Code: 
alter table TBL_TS add column updated INT default 0;
create trigger if not exists ts_u after update of ucLevel on TBL_TS begin update TBL_TS set updated=strftime('%s','now') where tsIdx = NEW.tsIdx; end;
create trigger if not exists ts_i after insert on TBL_TS begin update TBL_TS set updated=strftime('%s','now') where tsIdx = NEW.tsIdx; end;

Since this can be applied to the default_channel.db as well, it should be immune to unwanted re-creation of the DB, and as before we'll see what happens come 22 June (should retuning be necessary, as opposed to channel moves).
 
I could try this out now on a spare HDR Fox T2 if you like but I would need a bit more guidance on how / where to insert the code, I am guessing I need to install Tunefix as a starter, insert the code, perform a re-tune and then examine a database?
 
Is it possible to set a trigger to stop the stupid Humax code from setting ucLevel and ucQuality to 0 in the first place when doing a manual tune I wonder?
 
Ezra Pound said:
I could try this out now on a spare HDR Fox T2 if you like but I would need a bit more guidance on how / where to insert the code...
Click to expand...
Tunefix is good for conditioning the weird renumberings used by the broadcasters and for eliminating channels that can't be shown (IPTV) or aren't wanted, but isn't necessary here.

The settop box binary writes the tuning data to the database /var/lib/humaxtv/channel.db. This database also holds favourites data, except the custom favourite group names. Under some circumstances (factory reset, eg?) it may make a new version of the database from /var/lib/humaxtv/default_channel.db; the commands that create the database schema are embedded in the settop binary as well, but this appears to be for a last resort. The database gets rewritten when the settop binary closes down, but we can prevent that.

In your telnet or webshell session:
  1. close the settop binary:
    Code: 
    /etc/init.d/S90settop shut
  2. make a safety copy of the channel database:
    Code: 
    cp /var/lib/humaxtv/channel.db /mod/tmp
  3. open the database in the query tool:
    Code: 
    sqlite3 /var/lib/humaxtv/channel.db
  4. copy each line in turn from the code in post 4 above (including the final ;) and paste it into the query tool at the > prompt; there should be no diagnostic but just a new prompt each time;
  5. close the query tool with the command .close (or ctrl+d);
  6. resume the settop binary:
    Code: 
    /etc/init.d/S90settop resume
    After this, either your programme will reappear with video as well as sound, or the system will crash, or it will hang and have to be power-cycled.
    Now retune (based on @prpr's posts above, a full retune) and then:
  7. open the channel database again:
    Code: 
    sqlite3 /var/lib/humaxtv/channel.db
  8. see if the update column is present and populated (this should be like columns 2-4 of the WebIf tuning diagnostic table, plus the new column if it has survived, or an error) with non-zero values:
    Code: 
    .mode column
select ulFrequency, ucLevel, ucQuality, updated from TBL_TS;
  9. close the query tool;
If there are valid time_t values (like 1592224217) in the updated column, then the WebIf diagnostics page (generated by /mod/webif/html/diag/mux.jim) could be modified to display them.
 
prpr said:
Is it possible to set a trigger to stop the stupid Humax code from setting ucLevel and ucQuality to 0 in the first place when doing a manual tune I wonder?
Click to expand...
So is it the case that a manual retune sets those to 0 and doesn't then update them to the actual values seen in the retune? And that's why tunefix caches the last best versions in freq.db?

The same procedure would apply, but what values should be used? Just keep the last ones? And how would you distinguish the no-aerial/broken tuner case from an unwanted update to 0? That question isn't resolved in the proposals below:
Code: 
create trigger if not exists ts_u_ucLevel after update of ucLevel on TBL_TS begin update TBL_TS set ucLevel=OLD.ucLevel where tsIdx = NEW.tsIdx and NEW.ucLevel = 0;
create trigger if not exists ts_u_ucQuality after update of ucQuality on TBL_TS begin update TBL_TS set ucQuality=OLD.ucQuality where tsIdx = NEW.tsIdx and NEW.ucQuality = 0;
 
/df said:
So is it the case that a manual retune sets those to 0 and doesn't then update them to the actual values seen in the retune? And that's why tunefix caches the last best versions in freq.db?
Click to expand...
A manual retune sets the details for the mux. you are retuning correctly, but then sets ALL other muxes' details to 0. So, yes, tunefix caches the last non-zero values and puts them back (if the real ones are 0) on the next restart.

I came up with this, after a bit of head-scratching, which works on an off-line database:
Code: 
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;
 
/df : I don't think anything got updated, BTW I did a /etc/init.d/S90settop shut after re-tune and before step 7.
Code: 
Humax3# /etc/init.d/S90settop shut

[Video freezes but audio continues]

Humax3# cp /var/lib/humaxtv/channel.db /mod/tmp

Humax3# sqlite3 /var/lib/humaxtv/channel.db
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> alter table TBL_TS add column updated INT default 0;
sqlite> create trigger if not exists ts_u after update of ucLevel on TBL_TS begin update TBL_TS set updated=strftime('%s','now') where tsIdx = NEW.tsIdx; end;
sqlite> create trigger if not exists ts_i after insert on TBL_TS begin update TBL_TS set updated=strftime('%s','now') where tsIdx = NEW.tsIdx; end;
sqlite>
[CTRL D]
Humax3# /etc/init.d/S90settop resume

[first time I tried resume the Humax restored video, however as db had "no such column",
I rebooted, did settop shut, copied /tmp/ db back to /var/lib/humaxtv/ and re-traced steps several
times but after first run resume always results in a green screen crash needing a power cycle]


[ FULL RE-TUNE EXECUTED (first run only)]

Humax3# /etc/init.d/S90settop shut
Humax3# sqlite3 /var/lib/humaxtv/channel.db
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> .mode column
sqlite> select ulFrequency, ucLevel, ucQuality, updated from TBL_TS;
Error: no such column: updated
sqlite>
[CTRL D]

re-load original db and try again

updated.jpg

Edit

after I found this new column I did another re -Tune, but the db was then regenerated wihout the new column
 
Last edited:
Ezra Pound said:
/df : I don't think anything got updated, BTW I did a /etc/init.d/S90settop shut after re-tune and before step 7.
...
Click to expand...
Not required but shouldn't have made a difference.
...
after I found this new column I did another re -Tune, but the db was then regenerated wihout the new column
Click to expand...
Clearly, the settop binary is re-creating channel.db on a full retune. If it's just copying default_channel.db, the same procedure but this time saving and modifying /var/lib/humaxtv/default_channel.db might succeed.

Otherwise, if it's using or enforcing its version of the schema, a more subtle approach (ie, much worse hack) will be needed.
 
prpr said:
I came up with this, after a bit of head-scratching, which works on an off-line database
Click to expand...
But it's no use as the Humax software regenerates the database on every shutdown or retune. You can poke the trigger in at startup, but it's pointless.
So, back to the freq.db thing in post #2 I think.
 
prpr said:
So, back to the freq.db thing in post #2 I think.
Click to expand...
Well that doesn't work either:
SQL error: table old.TBL_FREQ has 4 columns but 3 values were supplied; rc=1 - SQL logic error
but at least I could modify that to make the trigger unnecessary. It all gets a bit clunky taking it any further forward though...
 
Even better would be to find the source of the live strength feed and obviate the need for the out of date static data
 
/df : I tried adding the extra column to the default_channel.db but after a resume - green screen -power cycle this db does not appear to contain the new column, I did a retune but as there wasn't an 'update' column there obviously wasn't any time stamps either, I will try this again in the morning but as yet it hasn't done what is needed
 
I think I have found what we were looking for in /var/lib/humaxtv/tempsetup.db

scan-time.jpg
NOTE:- this picture is from Humax2 NOT Humax3

I did a re-tune of Humax3 at Monday, 15 June 2020 23:22:09 GMT+01:00 DST and Tuesday, 16 June 2020 13:31:22 GMT+01:00 DST and got 1592259729 before a power cycle and 1592310682 after it
 
Last edited:
And
Code: 
# date -d '@1592259729'
Mon Jun 15 23:22:09 BST 2020
# date -d '@1592310682'
Tue Jun 16 13:31:22 BST 2020
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.

On the machine I'm looking at here it's 0 - perhaps resulting from a manual scan?
 
You must log in or register to reply here.
Back
Top