4g Cleanup

4ndy

Forum Supporter
We have, what is hopefully, our last retune tomorrow

Is it simply a case of taking a backup of the schedule in webif and restoring it back after a manual retune, or should I be taking screen shots?

I am on the Tacolneston transmitter, and I think it is just frequency changes on two muxes.
 

Black Hole

May contain traces of nut
I am on the Tacolneston transmitter, and I think it is just frequency changes on two muxes.
prpr came up with a very interesting way of preparing for frequency changes without affecting anything else at all - see HERE (click). I think this could be build into the WebIF.
 
OP
4ndy

4ndy

Forum Supporter
@Ezra, thanks for the response. I guess what I am asking is, does the schedule work by LCN, channel name, frequency etc. If it is one of the first two, I can see how backup & restore could be effective.

@BH, thanks. I can see how it might work in prpr's example. My switch tomorrow has COM6 moving from Ch50 to Ch39 and PSB3 (HD channels) moving from Ch62 to the vacated Ch50. This may be slightly too involved to manipulate in webif. The "find & replace" approach (if I understand the CLI correctly), needs to be executed in the correct order to work.
 

prpr

Well-Known Member
Tacolneston would appear to need this tonight:
Code:
humax# /etc/init.d/S90settop shut
humax# echo 'update TBL_TS set ulFrequency=618000 where ulFrequency=706000;' | sqlite3 /var/lib/humaxtv/channel.db
humax# echo 'update TBL_TS set ulFrequency=706000 where ulFrequency=802000;' | sqlite3 /var/lib/humaxtv/channel.db
humax# reboot
 

Black Hole

May contain traces of nut
does the schedule work by LCN, channel name, frequency etc. If it is one of the first two, I can see how backup & restore could be effective.
The schedule restore from WebIF searches for service names to reassign the schedule entries, so no problem there.

My switch tomorrow has COM6 moving from Ch50 to Ch39 and PSB3 (HD channels) moving from Ch62 to the vacated Ch50. This may be slightly too involved to manipulate in webif. The "find & replace" approach (if I understand the CLI correctly), needs to be executed in the correct order to work.
I see no reason specific retune events cannot be accommodated by specific diagnostics scripts in the WebIF. If you do use the prpr approach, no restoration of the schedule will be required because the service IDs will not change. In the main, the only reason the schedule ever needs restoring is because the Humax retune process deletes it.

Note that unless you are running disable-dso you are likely to get the retune nag, which only goes away if you perform a normal retune.

Tacolneston would appear to need this tonight:
Code:
humax# /etc/init.d/S90settop shut
humax# echo 'update TBL_TS set ulFrequency=618000 where ulFrequency=706000;' | sqlite3 /var/lib/humaxtv/channel.db
humax# echo 'update TBL_TS set ulFrequency=706000 where ulFrequency=802000;' | sqlite3 /var/lib/humaxtv/channel.db
humax# reboot
Excellent!
 
Top