[tunefix] Automatic channel organisation and maintenance

I think we could do with a formal description of the syntax for the tunefix config file. There doesn't seem to be one in this topic or the wiki.
 
Yes. I know. You've given that reference before and I've looked at it... and it does not constitute a formal description of the syntax.
 
The examples in the WiKi I am referring to have only been there for 7 hours, maybe you need to refresh your browser page to see this :-
tunefix.png
 
Yes, I've seen that. What do you not understand in "formal description of the syntax"?

I'm not saying you should write it, I can't write it because I know no more about the ins and outs than you do. Really it's a job for prpr.

Something like:

"tunefix.conf is a plain-text file containing a series of commands for the tunefix package. Each line starts with a command, followed by a number of parameters separated by colons."

Commands

REGION <what does it do exactly>

MUX

LCN

FORCE

etc

What are the limitations? How much syntax checking is done? What are the consequences of malformed commands?

Loads of stuff simply is not specified, and I am struggling to understand why you find this difficult.
 
The 'Examples' placed in the WiKi are the only info. supplied by prpr as far as I know, I do understand your term "formal description of the syntax", however, I think the examples supplied will be good enough for most users to do what they want and maybe it's only you who is finding it difficult
 
But is the example a force to use mux 46 and 49 and assign the LCNs, as I was given this clue to MUX 46 when I wanted to get rid of it and force a tune on MUX 25 and I didn't understand it. (But being a bear of little brain, that doesn't take much doing)
 
Black Hole said:
I think we could do with a formal description of the syntax for the tunefix config file. There doesn't seem to be one in this topic or the wiki.
Click to expand...
If you're volunteering, I'll send you my (terse) notes to write up. You can then ask me questions as you see fit and I will (attempt to) answer them.
 
I have changed the wording that accompanies the 'Examples' in the WiKi, I'm sure prpr will comment if this is not correct :-

Tunefix restores a user's settings after a retune has been run, the fixes include :-
  • Region to be used (channels from other regions will be removed)
  • LCNs by number and/or range will be removed
  • LCNs by name will be removed
  • MUXs (all channels from these MUXs will be removed)
  • Forcing named services to the correct LCN
 
Last edited:
Ezra Pound said:
The 'Examples' placed in the WiKi are the only info. supplied by prpr as far as I know, I do understand your term "formal description of the syntax", however, I think the examples supplied will be good enough for most users to do what they want and maybe it's only you who is finding it difficult
Click to expand...
A few examples does not a description make. Put yourself in the position of a newcomer. It was not even clear that LCN is a list of services to be deleted!
prpr said:
If you're volunteering, I'll send you my (terse) notes to write up. You can then ask me questions as you see fit and I will (attempt to) answer them.
Click to expand...
We could do that. I have other stuff to do first though.
 
Black Hole said:
REGION:name

Removes any LCNs which do NOT belong to the specified region, using an exact (case sensitive) name match.​
Click to expand...
Is this right? All the other match operations are case-insensitive.

I suggest you either link to post 111 from post 1 as "further notes", or copy the above into post 1 (once refinement is complete).
 
I am not currently a tunefix user so feel free to discount my views.

Consistency is valuable in software unless there is a good reason otherwise.
In general searches should all be case sensitive or all case insensitive.

It doesn't seem likely that the only difference between two region names will be the case of the names so I would vote for insensitive
 
MymsMan said:
I am not currently a tunefix user so feel free to discount my views.

Consistency is valuable in software unless there is a good reason otherwise.
In general searches should all be case sensitive or all case insensitive.

It doesn't seem likely that the only difference between two region names will be the case of the names so I would vote for insensitive
Click to expand...
Thanks. That's a good point well made. I've just uploaded 1.0.9 which is now case insensitive in the Region name.
 
Having the ability for REGION to take a comma-separated list of regions not to delete would be good, it would remove the noted limitation. The NAME command could also take a comma-separated list in addition to having multiple lines.
 
You must log in or register to reply here.
Back
Top