Changing Channel Numbers After Retune

[pkb4809]

I can't think of a good way out of this at the moment, so I've implemented something where you have to tell it.

How about if the only version of a channel is in the 750s allow it to be moved but if there are multiple definitions ignore the ones in the 750 range

... while I recognise that more people will be experiencing the problems I've been having over the course of the upcoming months/years as all these muxes get allocated to different channels to free up more frequencies for telecoms ... I think we need to recognise that this is a "temporary" issue ... and it's important to remember that the whole point of the approach that is being used to migrating these channels, is to leave people with service, but make it "inconvenient" for them ... ultimately to convince them to do what they need to do to overcome the issues ... so, FWIW, I don't feel it's too much of a problem if these feature don't become too "automated" and it'd be advantageous in the long run to have people in the situation I find myself in to need to come to the forum and get the sort of (excellent) advice I've had above ... not just about getting tunefix to work, to help make things a little more convenient in the short term, but also about the "shortcomings" of my aerial and what I need to do about it, to solve the problem longer term

Cheers, Phil

 

[Black Hole]

It's designed to remove 751-799.

This doesn't add up. AFAICS pkb4809 wasn't having 751-799 removed, they just wouldn't move. So what is it actually doing?

I can't think of a good way out of this at the moment

What I would like is for everything to be explicit in the .conf file, even if some of the .conf file is set by default, and have a comment syntax so that the default lines can be explained. Default lines can be enforced by the GUI, and then the user has carte blanche to edit the .conf directly in the knowledge that nothing else will go on behind the scenes.

It seems to me there needs to be a conditional syntax:

IFEXIST(1) LCN|750-799 \ Remove retune temporary services only if BBC1 also exists in the right place

Obviously this won't work if somebody happens to want a weird tuning set, but then they would be free to tweak the .conf to their own requirements.

 

[pkb4809]

Hi @Black Hole

It's designed to remove 751-799.

This doesn't add up. AFAICS pkb4809 wasn't having 751-799 removed, they just wouldn't move.

... to be clear, when I first installed tunefix the range 751-799 was included in the set of logical channels to be removed by the LCN statement in the tunefix.conf file ... I edited that out to stop BBC1 & 2 disappearing altogether ... I'm sure @prpr will be along to explain, but I took that statement he made (quoted above) to mean that this range of LCNs "shouldn't really be there" ... so tunefix, by default, will look to remove them and (separately) will not allow channels to be moved from them into other LCNs using the FORCE statement ... the outcomes of implementing the SIMMUX statement appear to be two-fold ... to change the range of LCNs automatically added for removal into the tunefix.conf LCN statement (to
778-799) and to include LCNs 751-777 into the range of LCNs from which channels can be FORCEd

At least that's as far as I understand it
Cheers, Phil

 

[Black Hole]

so tunefix, by default, will look to remove them and (separately) will not allow channels to be moved from them into other LCNs using the FORCE statement

Fair enough, but that's not exactly what prpr said and only he knows for sure what's going on behind the scenes. If nothing went on behind the scenes everything would be available for user intervention.

 

[prpr]

once I've had a new aerial fitted, my plan would be … to uninstall the tunefix package, delete the /mod/boot/tunefix.conf file and then do a full retune … and then only once it's looking like the tuning processes have identified all the available channels correctly, will I then re-install tunefix (if I want/need to perform any further channel re-arranging/sorting) … does that sound like an OK plan?

It sounds rather like overkill to me. If I were doing it, I would just do a Manual tune on channel 32 to add the new PSB1. Assuming it detects it OK, you can then get rid of the old PSB1 and shuffle everything into the correct place by adding this line to /mod/boot/tunefix-update.conf
REMOVEMUX|12330|32|12330|50
and rebooting.

 

[prpr]

This doesn't add up. AFAICS pkb4809 wasn't having 751-799 removed, they just wouldn't move. So what is it actually doing?

OK, I should have said it ignores them. It also has a rule that then removes them, unless somebody changes the rule.

What I would like is for everything to be explicit in the .conf file, even if some of the .conf file is set by default, and have a comment syntax so that the default lines can be explained.

That's not how it works. The config. file gets processed and sometimes rewritten. Preserving comment lines is not possible, without losing context. Nor does the GUI support it.

It seems to me there needs to be a conditional syntax

That's not going to happen. Especially as this may never be needed in the future.

Obviously this won't work if...

And therein lies the problem. Sometimes users need to be protected from themselves.

 

[prpr]

I took that statement he made (quoted above) to mean that this range of LCNs "shouldn't really be there" ... so tunefix, by default, will look to remove them and (separately) will not allow channels to be moved from them into other LCNs using the FORCE statement ... the outcomes of implementing the SIMMUX statement appear to be two-fold ... to change the range of LCNs automatically added for removal into the tunefix.conf LCN statement (to
778-799) and to include LCNs 751-777 into the range of LCNs from which channels can be FORCEd

At least that's as far as I understand it

Yep, that's about the gist of it. The only thing I would change is "...and not to exclude LCNs 751-777 from the range...", but that's just semantics.

 

[prpr]

If nothing went on behind the scenes everything would be available for user intervention.

But there's got to be some mystery. Nobody would have watched Scooby-Doo without it .

 

[EEPhil]

And therein lies the problem. Sometimes users need to be protected from themselves.

 

[Ezra Pound]

So, it needed updating, but it wasn't out of date? (When clearly it was, because the image was wrong.)
Hmm...

In my opinion you statement that The Wiki is outdated was badly worded, when one small part of a very large document requires an update it does not mean the whole thing is outdated

 

[pkb4809]

Hi @Ezra Pound

... when one small part of a very large document requires an update it does not mean the whole thing is outdated.

... be that as it may (or may not) ... the wiki still needs updating

As I advised at post #50 in this thread the "preferred" method of specifying settings for the tunefix package is now via the GUI in the Webif at
>> Settings >> Settings for tunefix package

… the wiki still only defines the Keywords available for adding into the mod/boot/tunefix.conf file and the picture of that file being edited there still implies that that's the only/preferred way of changing its settings

Perhaps a sentence steering people towards the Webif GUI would help them avoid having to face questions of the form ... ​

Why have you hand-edited this instead of using the GUI?

...

Cheers, Phil

 

[af123]

I will try and fix this, but it means getting my hands dirty with the Javascript and Jim code, and I didn't write that bit...

If it's of use, I just wrote http://hpkg.tv/misc/tunefix.web.extra.diff
which adds a new box to the GUI page for 'other stuff' which is just added to the top of the config file verbatim.

 

[prpr]

If it's of use, I just wrote http://hpkg.tv/misc/tunefix.web.extra.diff
which adds a new box to the GUI page for 'other stuff'

It does, thanks. Just one minor niggle: it adds a blank line to the box every time.

 

[af123]

It does, thanks. Just one minor niggle: it adds a blank line to the box every time.

Ah, the line that puts <textarea> needs to have -nonewline.

 

[prpr]

Ah, the line that puts <textarea> needs to have -nonewline.

That didn't help. A better solution was to filter out the blank line that got tacked on the end of cfg(extra):

if {[string length $line] && ![string match {#*} $line]} {
        lappend cfg(extra) $line
}

 

[pkb4809]

Hi All

Just coming back to update the thread ... I've now had a new aerial and masthead amplifier fitted (both claiming to have 4g/LTE filters built in) ... and I've uninstalled the tunefix package and retuned, by doing a complete first time install ... and everything is looking perfectly fine

Thank you so much, once again, for all who have helped me with the problems above

Cheers, PhilB

 

[prpr]

I've now had a new aerial and masthead amplifier fitted ... and everything is looking perfectly fine

Good stuff.

I've uninstalled the tunefix package

You'll still need tunefix-update come 22nd April, or you'll be retuning manually again.

 

[Trev]

I've uninstalled the tunefix package

Why would you do that? Just set it up properly.

 

[pkb4809]

Hi prpr/Trev

You'll still need tunefix-update come 22nd April, or you'll be retuning manually again

...

Why would you do that? Just set it up properly.

... I suppose one reason for uninstalling is just to see the panic it creates in members on here

... but then again, maybe I'm just following the sage advice given earlier on in the thread … that went…

IMO the best idea would be to disable/uninstall tunefix until you can receive all the available channels on the correct LCNs and MPXs. Once you have done that, reinstall tunefix to shuffle any around or delete, and tunefix update to keep everything tickety boo.

… and I'm only at the end of the first step ... so far

At the moment, apart from having two (apparently identical) versions of BBC North West (on LCN1 and LCN751), and BBC2, and BBC Four, etc., there really isn't any problem ... and even then scheduled recordings and the like don't seem to be having problems with conflicts between the two versions of the same channels ... I'll probably re-install tunefix and tunefix-update in the near enough future (and probably before 22nd April), but if/when I do, I wanted to make sure I'd be starting off with a "clean" install ... for that reason I deleted the tunefix.conf file as well ... Yes!!! @prpr, I know you gave me instructions for changing the configuration up in post #65 above, but that really did look a little "advanced" for me

Meanwhile, I'm finding the delights of the detectads package is taking up more and more of my attention … but that's a matter for another thread

Cheers, Phil

 

[prpr]

apart from having two (apparently identical) versions of BBC North West (on LCN1 and LCN751), and BBC2, and BBC Four, etc., there really isn't any problem ... and even then scheduled recordings and the like don't seem to be having problems with conflicts between the two versions of the same channels

Because it's the same region. The problems come when it's a different one.

that really did look a little "advanced" for me

How hard can it be (as Jezza used to say)? It's editing one line in to a file. Anyway, I'll be applying it for the good folk of the NW in April (who have the update package installed of course).