• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[tunefix] Automatic channel organisation and maintenance

Tunefix 1.5.1 implements support for changing the frequency of a whole mux. by tunefix-update.
Hopefully (as this is guesswork at this point) this will allow the mux. moves caused by the 700 MHz clearance process to be less painful.
Do we have a volunteer who receives direct from the Selkirk transmitter to monitor on Mar. 1st?
 
1.5.2 supports the move of services between muxes more cleanly.

You can all now see "Rocks & Co 1" again, but only if you get COM8.
This is definitely an improvement on where it was before (COM6), as fewer people will be able to receive it!
I felt ill with having it on my box last night, but I'm better again now.
 
prpr said:
1.5.2 supports the move of services between muxes more cleanly.

You can all now see "Rocks & Co 1" again, but only if you get COM8.
This is definitely an improvement on where it was before (COM6), as fewer people will be able to receive it!
I felt ill with having it on my box last night, but I'm better again now.
Click to expand...
Perhaps we need a package that can delete unwanted channels :p:D
 
tunefix 1.6.0 released to prevent it from deleting all services when you've forgotten to change the config. before moving regions.
 
tunefix 1.6.1 released to cope with Freeview Retune day!
I would suggest everybody who uses it upgrades before doing a retune.
 
tunefix 1.7.1 released:
  • resolves a bug with duplicate LCNs when forcing/changing LCNs
  • handles mux. moves for the new COM7/COM8 network
Please make sure you upgrade if you don't have auto-update installed.
 
Can somebody explain why tunefix 1.7.1 (without going anywhere near the GUI config editor) keeps rearranging my (supported user) .conf file?

Here's what I want to do:
Code: 
REGION|West
FORCE|700|BBC Radio 2
FORCE|701|BBC Radio 3
FORCE|702|BBC Radio 4
FORCE|703|BBC Radio 4 Ex
FORCE|704|BBC World Sv.
FORCE|705|Smooth Radio
FORCE|706|Classic FM
FORCE|897|CBBC
FORCE|898|Sky News
FORCE|899|BBC NEWS
LCN|100-249,251-600,605-700,707-799
NAME|*HD
NAME|QVC*
NAME|4Music
NAME|Create & Craft
NAME|Rocks & Co 1
NAME|Gems TV
NAME|The Store
NAME|Jewellery Maker
NAME|Sewing Quarter
NAME|Forces TV
NAME|Ideal World
NAME|TJC
NAME|TBN UK
NAME|TCC
NAME|Hochanda

Here's what I keep ending up with (which, of course, doesn't do what I want):
Code: 
REGION|West
LCN|100-249,251-600,605-700,707-799
NAME|*HD
NAME|QVC*
NAME|4Music
NAME|Create & Craft
NAME|Rocks & Co 1
NAME|Gems TV
NAME|The Store
NAME|Jewellery Maker
NAME|Sewing Quarter
NAME|Forces TV
NAME|Ideal World
NAME|TJC
NAME|TBN UK
NAME|TCC
NAME|Hochanda
FORCE|700|BBC Radio 2
FORCE|701|BBC Radio 3
FORCE|702|BBC Radio 4
FORCE|703|BBC Radio 4 Ex
FORCE|704|BBC World Sv.
FORCE|705|Smooth Radio
FORCE|706|Classic FM
FORCE|897|CBBC
FORCE|898|Sky News
FORCE|899|BBC NEWS
 
Black Hole said:
Can somebody explain why tunefix 1.7.1 (without going anywhere near the GUI config editor) keeps rearranging my (supported user) .conf file?
Click to expand...
Will I do?
Because the whole management of the config. file changed in 1.7.0 for various reasons and it now gets rewritten if a change is required.
The order it emits the sections is now fixed. Even if you change the file, the sections are all read back in at startup, parsed and turned into an internal config., then processed in a defined order, so order is essentially irrelevant. The internal config. may get modified as the statements are executed and then an internal representation of the file is regenerated, in that defined order. If the original and the new are different it rewrites the file.
Here's what I keep ending up with (which, of course, doesn't do what I want)
Click to expand...
Perhaps you could explain what you do want then, and how they differ?
Also the stuff with LCN 700 seems weird.
 
The initial FORCE operations place wanted named services (radio and news) in known (and handy) places, and then the LCN operation can just remove fixed blocks. This has been shown to be desirable because of BBC NEWS and Sky News changing LCN. Having to do the LCN list first means the list has to be changed any time services change LCN (which they do).

Now you've explained that, I can see it has also corrupted my multiple-region strategy on HDR3 (and therefore also my advice post for dealing with multiple regions) - I haven't bitten the bullet and retuned that one yet, otherwise I would have noticed. What's happened to the MUX command?

Sorry, but I don't like this change. It's OK enforcing a particular order through the GUI, but if the user edits tunefix.conf directly it should stay as written (at the user's own risk). Don't take this personally, but as far as I can see a change to key functionality has been made with no announcement. "Resolves a bug" doesn't hack it, and philosophically it doesn't feel right to re-write a .conf file on behalf of the user. I would like in-order execution restored please.
 
Last edited:
Black Hole said:
The initial FORCE operations place wanted named services (radio and news) in known (and handy) places, and then the LCN operation can just remove fixed blocks. This has been shown to be desirable because of BBC NEWS and Sky News changing LCN. Having to do the LCN list first means the list has to be changed any time services change LCN (which they do).
Click to expand...
One of the benefits of the new architecture is that if the LCNs do change (via tunefix-update), then any FORCE statements are automatically updated to follow.
Now you've explained that, I can see it has also corrupted my multiple-region strategy on HDR3 (and therefore also my advice post for dealing with multiple regions) - I haven't bitten the bullet and retuned that one yet, otherwise I would have noticed.
Click to expand...
I can't comment without real examples. AFAIK, it should be possible to achieve what was previously possible, but things may need doing slightly differently.
What's happened to the MUX command?
Click to expand...
I don't know. What do you think has happened to it?
Sorry, but I don't like this change. It's OK enforcing a particular order through the GUI, but if the user edits tunefix.conf directly it should stay as written (at the user's own risk). Don't take this personally, but as far as I can see a change to key functionality has been made with no announcement. "Resolves a bug" doesn't hack it, and philosophically it doesn't feel right to re-write a .conf file on behalf of the user. I would like in-order execution restored please.
Click to expand...
Sorry, but it's not possible to cope with new changes in an easy to maintain way and preserve old ways of doing things.
The previous architecture had come to the end of being maintainable. This thing is quite complicated!
 
prpr said:
One of the benefits of the new architecture is that if the LCNs do change (via tunefix-update), then any FORCE statements are automatically updated to follow.
Click to expand...
That's no good for my use-case (ugh!). The supported user is not on Internet and I don't have tunefix-update installed there. The old model worked very satisfactorily: if a retune occurred (or was required), a reboot restored the schedule and the constellation. Would tunefix-update also update the LCN line to account for LCN changes? It would be very difficult to work out the original intention and take account of it.

Black Hole said:
What's happened to the MUX command?
Click to expand...
prpr said:
I don't know. What do you think has happened to it?
Click to expand...
If you don't know then who does? The MUX line that was in my HDR3 tunefix.conf has been removed - I presume by the same process as re-ordered my other command lines.

What about the user guide in posts 1 and 151? I don't think they've been updated to reflect the new situation, and I think it will be quite tricky to explain the new rationale.

prpr said:
Sorry, but it's not possible to cope with new changes in an easy to maintain way and preserve old ways of doing things.
The previous architecture had come to the end of being maintainable. This thing is quite complicated!
Click to expand...
Sorry, but in my view tunefix has been buggered up. It seems to me that tunefix has been tweaked to suit tunefix-update rather than serve its original purpose, and it has to be said that previously tunefix and tunefix-update were completely separate. It was useful before, but now it's a pig's ear.

What I request is you roll out the old version of tunefix as a different package (eg tunefixed) - with appropriate warnings about it being an alternative to tunefix+tunefix-update. As they now seem to go hand-in-hand, you could even combine tunefix and tunefix-update into one package.
 
Black Hole said:
Would tunefix-update also update the LCN line to account for LCN changes? It would be very difficult to work out the original intention and take account of it.
Click to expand...
No, for exactly that reason.
If you don't know then who does?
Click to expand...
You, presumably. But you didn't say what the problem was - only that there was a problem. So I'm left to guess, which isn't exactly helpful.
The MUX line that was in my HDR3 tunefix.conf has been removed - I presume by the same process as re-ordered my other command lines.
Click to expand...
That's a bug/oversight with the mux. move stuff. Fixed in the next version.
it has to be said that previously tunefix and tunefix-update were completely separate.
Click to expand...
No they weren't. The latter has always been completely dependent on the former.
What I request is you roll out the old version of tunefix as a different package (eg tunefixed) - with appropriate warnings about it being an alternative to tunefix+tunefix-update. As they now seem to go hand-in-hand, you could even combine tunefix and tunefix-update into one package.
Click to expand...
I don't want to maintain two versions of nearly the same thing, and I think it would generate more confusion for most people.
Would making the FORCE and FORCESVC commands have priority over LCN (and NAME and MUX) commands satisfy you and any other users? It does seem better that way round than how it is currently. It's trivial to change as well.
 
prpr said:
No they weren't. The latter has always been completely dependent on the former.
Click to expand...
I think that's what I meant but it didn't come out right. My point is that tunefix has a life of its own without being subservient to tunefix-update.

prpr said:
Would making the FORCE and FORCESVC commands have priority over LCN (and NAME and MUX) commands satisfy you and any other users? It does seem better that way round than how it is currently. It's trivial to change as well.
Click to expand...
This would make more sense, I think (assuming the demands of tunefix-update are compatible with that policy). I can't see how to make a scheme of block removal (with the exclusion of certain specific services and proof against subsequent LCN changes without the help of tunefix-update) work unless FORCE is executed before LCN. The only alternative would be a very long list of NAME.

If you can turn it around, why was it necessary to change it in the first place?

prpr said:
I don't want to maintain two versions of nearly the same thing, and I think it would generate more confusion for most people.
Click to expand...
Fair enough. All I need is an option to prevent tunefix rearranging the config file and then execute in order. How about a flag at the start of the file, eg tunefix-update=no?

Philosophically I don't think it is right to rewrite a config file, but if you must rewrite the config file to suit tunefix-update either provide an option to protect the config file as is or disable the rewriting when it is not required (ie when tunefix-update is not active).
 
Somebody remind me: what happens to the current occupant of (say) LCN 40 if tunefix FORCEs a different service onto LCN 40?
 
You must log in or register to reply here.
Back
Top