[tunefix] Automatic channel organisation and maintenance

[prpr]

Or is it the proposal for the next version? Otherwise It's just recapitulating the test that I posted originally.

That's effectively what's in 1.9.3
Can you try the stuff in #238 and see what it does?

 

[prpr]

is [ TuneFix ] going to cope with this situation

No, but tunefix-update might.

 

[Black Hole]

Sorry if this query has already been covered, but Forces TV is showing as having a frequency change this coming Monday (22nd June 2020), the epg is also showing a retune warning from about midday Monday, is [ TuneFix ] going to cope with this situation, or is this one of the exceptions

tunefix is the package that lets you organise services the way you want, and apply the configuration automatically instead of having to edit the services list each time you do a retune.

tunefix-update is the package which receives and implements tuning changes directly into the tuning database instead of having to retune.

They are separate packages, with distinct functions.

 

[Trev]

It's a shame that tunefix-update was not called channel-update or similar, to remove the confusion between it and tunefix. But I believe we have been here before.

 

[MikeSh]

Sorry if this query has already been covered, but Forces TV is showing as having a frequency change this coming Monday (22nd June 2020), the epg is also showing a retune warning from about midday Monday, is [ TuneFix ] going to cope with this situation, or is this one of the exceptions

Amongst the Forces TV retune issue, there are other changes to HD channels and +! catch-up channels being removed

Apparently mux 56 is being discontinued with a reshuffle and some losses. Although tunefix-update is very competent in general, I personally will do a manual retune and sort out for this big a change.

 

[Black Hole]

Although tunefix-update is very competent in general, I personally will do a manual retune and sort out for this big a change.

It also requires a reboot for changes to take effect (as does tunefix), and as my units are not routinely rebooted tunefix-update won't work for me. However, I am contemplating changing the situation to gain that benefit (including a daily power interruption to clear any lock-ups).

I don't generally retune at all unless I find I am inconvenienced by a tuning change.

 

[/df]

That's effectively what's in 1.9.3
Can you try the stuff in #238 and see what it does?

Same result as in your post, but still getting the xinit.log error. Is there perhaps an instance of the function in the tunefix source that you didn't catch?

 

[Code is a Hole]

Many thanks for the very kind replies from you all, of course, I did mean tunefix-update rather than just tunefix, anyone got a suggestion as to the optimum time to do the retune during Monday morning

Will tunefix-update cope with other matters other than Forces TV, or is it such a major event necessitating a manual retune, I was just asking as I have a couple or three Humax HDR Fox T2 boxes, it's going to get busy having to manually retune each, then restore all the schedule recordings, as I've not had much luck recently with the auto-restore plug-in

 

[MymsMan]

Many thanks for the very kind replies from you all, of course, I did mean tunefix-update rather than just tunefix, anyone got a suggestion as to the optimum time to do the retune during Monday morning

Will tunefix-update cope with other matters other than Forces TV, or is it such a major event necessitating a manual retune, I was just asking as I have a couple or three Humax HDR Fox T2 boxes, it's going to get busy having to manually retune each, then restore all the schedule recordings, as I've not had much luck recently with the auto-restore plug-in

With tunefix-update you don't need to do a retune at any time of the day. It should handle all of the channel moves

 

[Code is a Hole]

Thank you MymsMan, is there going to be another tunefix and tunefix-update in the next day to handle this re-shuffling of channels

It's just that Forces TV is showing a nag panel about needing a return, on the epg it is still showing 'Rescan for Forces TV Now!', which was done this morning

 

[prpr]

Although tunefix-update is very competent in general,

Oh, what specifically did it not do that you expected it to then?

I personally will do a manual retune and sort out for this big a change.

It's not a big change. No bigger really than any of the other mux. shuffling that goes on.

Will tunefix-update cope with other matters other than Forces TV

Yes, of course.

or is it such a major event necessitating a manual retune, I was just asking as I have a couple or three Humax HDR Fox T2 boxes, it's going to get busy having to manually retune each

The whole point of it is that you don't need to retune. Just leave it alone.
I don't know if I'll get round to it on Monday night, but it doesn't actually matter as there's several days of parallel running apparently - at least till the 25th and by some reports the 30th.

 

[/df]

As bandwidth has been stolen from Freeview to sell to mobile phone companies, one multiplex has to be removed, and the result is this.

The messages about retuning are intended for consumers with generic kit, rather than those with top-of-the-line user-enhanced 2011 gear, for whom our esteemed sponsor kindly handles such inconsequential changes.

In any case, if it all goes TITSUP*, just do a full re-tune, let tunefix do its work, restore the previous schedule/favourites backup, and then (as you would have to anyway) tweak the favourites to account for channels that have disappeared.

*Total Inability To See Usual Programmes

 

[prpr]

Is there perhaps an instance of the function in the tunefix source that you didn't catch?

No there's only the one.
Does "LD_LIBRARY_PATH=/usr/lib /mod/boot/xinit.d/tunefix" give the error too?

 

[/df]

Definitely.

 

[prpr]

I'm out of ideas I'm afraid. It works here. I don't know what's different about your box. Is it an HD or HDR?

 

[Black Hole]

is there going to be another tunefix and tunefix-update in the next day to handle this re-shuffling of channels

You are still not seeing the whole picture:

1. You are inappropriately discussing tunefix-update in the tunefix thread.

2. tunefix does not require an update. tunefix implements your personal preferences for service deletion and LCN allocation, as per WebIF >> Settings >> Settings for tunefix package. This is nothing to do with actual tuning (the frequency a service is received on, and the encoding format of its data stream). If you have, for example, eliminated Forces TV as a service deletion in tunefix settings, tunefix-update won't put it back even if you remove that deletion - you would need a proper retune for that.

3. prpr routinely issues tuning updates through tunefix-update, which uses its own mechanism independent of the other package updates. All you need is to have tunefix-update installed, a live Internet connection, and routine reboots. These updates are to make your existing selection of services track any tuning alterations that might take place... not exactly automatically, but managed centrally instead of us having to do it individually.

Therefore it is inappropriate to query whether prpr is planning to issue data to cover some upcoming service move - that's what he routinely monitors and acts on, as a very kind voluntary contribution to the 'fox CF community.

 

[MikeSh]

Oh, what specifically did it not do that you expected it to then?

It's not a big change. No bigger really than any of the other mux. shuffling that goes on.

Um. Well, yes. You are right now I think on it more.
The removal of 55 & 56 has loomed large in my mind over the last couple of years and mentally I was probably equating removal of a mux with adding a mux, but of course it's not the same at all.

So I will let update sort it out.

Also @Andrea Edwards

 

[prpr]

If you have, for example, eliminated Forces TV as a service deletion in tunefix settings, tunefix-update won't put it back even if you remove that deletion - you would need a proper retune for that.

I'm afraid that's a bad example (especially as it's mentioned up-thread), because it would get put back on a mux. move, such as the one tomorrow.

as a very kind voluntary contribution to the 'fox CF community.

I do it for myself actually, to update what were my own local boxes and one remote... and is now the other way round.
Anything else is a bonus.

 

[Black Hole]

I do it for myself actually, to update what were my own local boxes and one remote... and is now the other way round.
Anything else is a bonus.

I'm sure there are plenty of updates which would not affect your particular boxes, so you are definitely going the extra mile.

 

[/df]

I'm out of ideas I'm afraid. It works here. I don't know what's different about your box. Is it an HD or HDR?

This one is an HD.

After communing with gdb for a while, I can report that the failing SQL statement begins insert or replace into old.TBL_FREQ select s.ulFrequency, s.ucLevel, s.ucQuality from TBL_TS as s left join old.TBL_FREQ as d on (d.ulFrequency = s.ulFrequency) where (d.ulFrequency is null or d.ucLev...., run by SQL3::Exec(). Here's the end of the session, after the failure has thrown an exception:

(gdb) bt
#0  0x2aadeef4 in sqlite3_errcode () from /usr/lib/libsqlite3.so.0
#1  0x0040de9c in ?? ()
#2  0x0040e2a4 in ?? ()
#3  0x0040e4dc in SQL3::Exec(std::string const&) const ()
#4  0x004062cc in ?? ()
#5  0x004077d4 in ?? ()
#6  0x0040b964 in ?? ()
#7  0x0040c0f4 in main ()
(gdb) s
0x2aadeef8 in sqlite3_errcode () from /usr/lib/libsqlite3.so.0
1: x/i $pc
=> 0x2aadeef8 <sqlite3_errcode+64>:     
    beqz        v0,0x2aadef14 <sqlite3_errcode+92>
   0x2aadeefc <sqlite3_errcode+68>:     lw      ra,28(sp)
(gdb) 
0x2aadef14 in sqlite3_errcode () from /usr/lib/libsqlite3.so.0
1: x/i $pc
=> 0x2aadef14 <sqlite3_errcode+92>:     lw      v1,20(s0)
(gdb) 
0x2aadef18 in sqlite3_errcode () from /usr/lib/libsqlite3.so.0
1: x/i $pc
=> 0x2aadef18 <sqlite3_errcode+96>:     lw      v0,24(s0)
(gdb) 
0x2aadef1c in sqlite3_errcode () from /usr/lib/libsqlite3.so.0
1: x/i $pc
=> 0x2aadef1c <sqlite3_errcode+100>:    lw      s0,24(sp)
(gdb) 
0x2aadef20 in sqlite3_errcode () from /usr/lib/libsqlite3.so.0
1: x/i $pc
=> 0x2aadef20 <sqlite3_errcode+104>:    and     v0,v0,v1
(gdb) 
0x2aadef24 in sqlite3_errcode () from /usr/lib/libsqlite3.so.0
1: x/i $pc
=> 0x2aadef24 <sqlite3_errcode+108>:    jr      ra
   0x2aadef28 <sqlite3_errcode+112>:    addiu   sp,sp,32
(gdb) 
0x0040de9c in ?? ()
1: x/i $pc
=> 0x40de9c:    lw      gp,16(sp)
(gdb) 
0x0040dea0 in ?? ()
1: x/i $pc
=> 0x40dea0:    nop
(gdb) 
0x0040dea4 in ?? ()
1: x/i $pc
=> 0x40dea4:    lw      t9,-32124(gp)
(gdb) 
0x0040dea8 in ?? ()
1: x/i $pc
=> 0x40dea8:    move    a0,v0
(gdb) 
0x0040deac in ?? ()
1: x/i $pc
=> 0x40deac:    jalr    t9
   0x40deb0:    move    s1,v0
(gdb) 
/var/lib/humaxtv/mod/xinit.d/tunefix: can't resolve symbol 'sqlite3_errstr' in lib '/var/lib/humaxtv/mod/xinit.d/tunefix'.

Program exited with code 01.

Obvs it's not the failure of the statement that's interesting, as that can be addressed separately, but the consequent error handling.