[tunefix] Automatic channel organisation and maintenance

[prpr]

It'll probably add it on 105, and probably 'move' it to 7, if that's what you have set it up to do.
The net result should be no change. Be interesting to see what happens .

 

[Trev]

Right then, tell me what to do and what to look for when and I'll get on with it and report back.

 

[prpr]

Upgrade your package list & packages, reboot and see what happens to the channel list, esp. 7 and 105.
If the world ends, my name is Black Hole .

 

[Trev]

Upgrade package list > No packages to upgrade??? Huh. Tunefix 1.3.1 installed, but there's so many threads about this now, I can't be assed to chase them up to see if this is the latest or not.
Incontenence again. 1.0.4 -update installed now.
Reboot:
Ch5HD now back on 105 and Ch5 on 5. LCN 7 missing. I'll try another reboot.

That's OK now, CH5HD on LCN7 and no LCN105. Back as it was before two reboots.
What's in the update?

 

[prpr]

Ch5HD now back on 105 and Ch5 on 5. LCN 7 missing. I'll try another reboot.

That's OK now, CH5HD on LCN7 and no LCN105. Back as it was before two reboots.

I've reversed the order in which the config. files are processed with 1.3.2 just released, so that tunefix-update changes get applied before your standard tunefix config. runs. This should mean you don't need a second reboot.

What's in the update?

1.3.1 adds the ability to clone (add) channels and there's a bug fix to multi-region processing to fix missing channels which had the same name (due to mux. moves i.e. CITV and ITV3+1).

 

[prpr]

Version 1.3.3 now allows you to swap channels using the Force settings.

 

[Trev]

Do you have to do them in a specific order?
e.g.
1 > 101
101 > 1
or
101 > 1
1 > 101

 

[prpr]

Why would you?

 

[Trev]

I don't know. That's why I asked. I'll take that as a "It doesn't matter" then.

 

[prpr]

If you think about it, it can't be order specific.

 

[prpr]

Updated Tunefix Guide

The tunefix package automatically removes unwanted services following a retune, as an alternative to the channeldel package and with different capabilities. It can also reorganise the allocation of services to LCNs. The objective is to ease the inconvenience of imposed automatic retunes, or when retunes are necessary due to reorganisations in the broadcast services.

tunefix and channeldel can co-exist, but there is little point in having both installed at the same time (tunefix now deactivates channeldel on installation).

Note​

​

When a retune occurs (automatic or manual), any recordings or reminders scheduled for services that are carried by the affected multiplexes (which is all of them, if it is an automatic retune or if auto is selected during a manual retune) are deleted from the schedule and must be reinstated. The schedule is backed up daily, or can be manually backed up, by the Custom Firmware Web Interface (WebIF). To restore the schedule from backup go to WebIF >> Schedule.​

​

The schedule can also be restored automatically in the event of an unattended auto-retune wiping the schedule completely (subject to certain limitations) by installing the auto-schedule-restore package.​

​

The CF can also defend the HD- and HDR-FOX against unwanted broadcast-initiated auto-retunes. See Preventing External Events from Disturbing the CF (click).​

The operation of tunefix is governed by the configuration file /mod/boot/tunefix.conf. If the file does not exist at installation time, a default will be created based on the existing tuning database. Any names listed in /mod/boot/chandel.conf (the equivalent file for the channeldel package) will also be imported. The configuration file can be viewed and edited via the WebIF file editor at WebIF >> Diagnostics >> Utilities >> File Editor, and selected from the list of "commonly edited files" at the bottom of the page.

Any line not starting with one of the thirteen (case insensitive) keywords below is ignored. There may be multiples of any of them.

LCN|x
LCN|x-y

Removes LCN x or all LCNs in the inclusive range x-y. Multiple entries of either may be specified in a comma delimited list on the same line.​

MUX|x
MUX|x-y

Removes all services tuned to RF channel x or RF channels x-y inclusive. Multiple entries of either may be specified in a comma delimited list on the same line.​

REGION|name

Defines the region the user wishes to keep, removing any services which do not belong to any of the specified regions, using an exact (case insensitive) name match. Any remaining LCNs above 799 are remapped to those from corresponding service names below 800 from the LCNs to be deleted.​

​

Note: Multi-region tuning is subject to limitations and potential mis-operation. For discussion of multi-region tuning, see HERE (click).​

NAME|name

Removes any service which has a case insensitive match to the specified name, including optional wildcards:​

​

* matches any number of characters, including none.​

? matches exactly 1 character.​

FORCE|x|name

Sets the specified service name to LCN x using an exact (case insensitive) name match.​

FORCESVC|x|svc|name

Sets the specified service name to LCN x using an exact (case insensitive) name match, but only where the service ID matches svc.​

MOVE|...
MUXMOVE|...
CLONE|...
CLONE1|...
REMOVESVC|...
REMOVEMUX|...
RENAME|...

These are reserved for use by the tunefix-update package.​

MUX, FORCESVC and more than one REGION line are not (currently) supported by the Web Interface settings page, which will remove them when saving changes. If you use these advanced configuration capabilities, you need to edit the /mod/boot/tunefix.conf file manually!


Example Configuration File

LCN|170-199,211-299,790-799
REGION|West
FORCE|1|BBC ONE West
FORCE|2|BBC TWO
FORCE|3|ITV
FORCE|4|Channel 4
FORCE|7|Made In Bristol
FORCE|33|ITV +1
FORCE|101|BBC ONE HD
FORCE|103|ITV HD
FORCE|719|BBC Bristol
NAME|Al Jazeera Arabic
NAME|BT Sport*
NAME|Community
NAME|Create & Craft
NAME|Food Network
NAME|Gems TV
NAME|Ideal World
NAME|Jewellery Maker
NAME|QVC*
NAME|Rishtey*
NAME|Rocks & Co 1
NAME|TBN UK
NAME|The Store
NAME|TJC
NAME|VIVA

Thanks to Black Hole for the original text.

 

[cdmackay]

Updated Tunefix Guide

Thanks very much for this.

Do you think you could put this somewhere easier to find, please? e.g. in the first post (or a link to it), or the wiki, or somewhere?

The post above will be difficult to find in a month's time...

thanks

 

[prpr]

It is in the first post with a link to it.

 

[Trev]

It would possibly improve understanding of this fact if it were made a bit more obvious in post 1 that you updated it yesterday rather than the tiny 'Last Edited' in the bottom right of the post. Possibly as the first line could read

"Tunefix is a package which is designed to fix up the channel list following a retune. This is a guide to the latest version updated on dd/mm/yy. It can: etc.

And as an aside, how new does something have to be to be called new?

 

[MymsMan]

And as an aside, how new does something have to be to be called new?

About a thousand years in the case of places like the New Forest and Newcastle!

 

[af123]

FORCE|x|name

Sets the specified service name to LCN x using an exact (case insensitive) name match.​

Can I suggest that you add something like:

If the destination LCN x is already in use by another service then that service will be moved to the LCN vacated by the one being moved; the two services will effectively be swapped.

That's a bit clumsy but it's the best I have with today's caffeine intake so far!

Any thoughts on the interaction with renumber? At the moment they don't interact brilliantly because tunefix does not populate the usOrgLcn field in the database. Perhaps it's time to deprecate renumber but in any case could tunefix populate that field when moving a service?

 

[Trev]

If that's what it actually does, then that makes my question at post#147 redundant. Had prpr said that at the time, it would have left me satisfied, rather the the two less than helpful answers that he gave at the time. "Why would it" and "Think about it". Had he just said it swaps the LCNs, that would have been great.

 

[cdmackay]

It is in the first post with a link to it.

Sigh; sorry!

I won't tell you that I even checked post 1 before posting my msg, saw the text was different and missed the link at the end; that would be too embarrassing.

thanks again.

 

[prpr]

It would possibly improve understanding of this fact if it were made a bit more obvious in post 1 that you updated it yesterday rather than the tiny 'Last Edited' in the bottom right of the post.

I'm not sure why it matters. People following the thread will have seen the latest update. Those who aren't and who want to know will go via the link in post #1. It is irrelevant to them where it points and when it was edited.

And as an aside, how new does something have to be to be called new?

In what context? If you mean the forum, then until you have read it.

 

[prpr]

Can I suggest that you add something like:

If the destination LCN x is already in use by another service then that service will be moved to the LCN vacated by the one being moved; the two services will effectively be swapped.

But it won't, unless you have both lines:

FORCE|1|BBC ONE HD
FORCE|101|BBC ONE West
will swap 1 and 101.

FORCE|1|BBC ONE HD
will delete BBC One West and move BBC ONE HD to 1. It will not move BBC One West to 101.

Any thoughts on the interaction with renumber? At the moment they don't interact brilliantly because tunefix does not populate the usOrgLcn field in the database. Perhaps it's time to deprecate renumber but in any case could tunefix populate that field when moving a service?

The usOrgLcn field is not guaranteed to be correct when you are removing 'wrong' regions. The right BBC One might have been on 800 for example and ends up FORCEd on to 1. You wouldn't want usOrgLcn set to 800.
If you want to swap channels, then do as above with the two FORCE statements. I don't see a need for renumber now.