[tunefix-update] Automated Freeview channel updates

[Luke]

Why would you presume that?
...
I've been planning that since Selkirk last March.

Part of what lay behind my assumption was that while move of a channel from one mux to another can utilise some details from other channels which are known to be on the mux being used for the new location, a whole mux move could be different and you may not have known, with certain, if some values are going to be reused by the new mux;
but I'd forgotten about Selkirk, which obviously would have helped confirm what is being retained and what could just be copied over to the new mux entries with a good degree of certainty

My second underlying thinking was that unlike national moves the mux moves are not national but are staggered, which would require more work to prepare for and setup.

 

[prpr]

Part of what lay behind my assumption was that while move of a channel from one mux to another can utilise some details from other channels which are known to be on the mux being used for the new location, a whole mux move could be different and you may not have known, with certain, if some values are going to be reused by the new mux;

It's the same mux., just broadcast on a different RF channel.

I'd forgotten about Selkirk, which obviously would have helped confirm what is being retained and what could just be copied over to the new mux entries with a good degree of certainty

Well it might have done had we had any feedback about it, which we didn't.

unlike national moves the mux moves are not national but are staggered, which would require more work to prepare for and setup.

Yes, you're not wrong there.

 

[prpr]

1.0.34:

Rename VIVA to 5Spike+1
Remove True Crime
Remove truTV from COM5
Remove truTV+1
Remove The Vault
Add Sony Crime Channel
Mux. moves for 700 MHz clearance at:

Sudbury (COM6)
Tacolneston (COM8)
Waltham (COM5 and COM8)​

If anybody has any feedback from those regions about the 700 MHz clearance I would be pleased to hear it.

There is currently no link between the removal of the old service and the addition of the new one. I could make it so that there is a conditional link between the two, but the SQL query is complicated enough as it is and it hurts my head every time I think about it. I'll think a bit more about whether it's worth implementing.

This was fixed in tunefix 1.7.0 - it was actually less complicated than I thought.

 

[Howard]

The retune today for Waltham left my box without BBC4HD and SKY News and perhaps others but thats all I noticed before I did a manual retune.

 

[prpr]

The retune today for Waltham left my box without BBC4HD and SKY News and perhaps others but thats all I noticed before I did a manual retune.

It worked perfectly on mine - the first time I've been able to check and confirm anywhere. All channels present and correct with no manual intervention, so I guess you got the procedure wrong somehow.

 

[prpr]

1.0.35:

Automatic update mechanism implemented
Rename My5 to 5SELECT
Mux. moves for 700 MHz clearance at:

Mendip (COM5 and COM7)
Oxford (COM6 and COM7)​

 

[peterworks]

For info: since the automatic update mechanism was introduced I have received the following notifications:


and

 

[Wallace]

Me too!

On both my 'in service' HDRs.

Auto update enabled.

 

[Trev]

I just had the same.

 

[TimK2015]

Me too.

27/02/2018 04:22:32 - Automatically upgraded package tunefix-update from 1.0.34 to 1.0.35
28/02/2018 04:21:09 - Automatically upgraded package tunefix-update from 1.0.35 to 1.0.35 (2 instances)

 

[prpr]

For info: since the automatic update mechanism was introduced I have received the following notifications:

I wondered how long it would be before somebody noticed and commented. Bit of a gremlin crept in and I didn't notice until yesterday. It's already fixed and will go out in the update for mux. moves at Ridge Hill tonight.

 

[prpr]

1.0.36:

Remove useless log message when auto-update not performed
Mux. moves for 700 MHz clearance at:

Ridge Hill (COM7 and COM8)
​

 

[Black Hole]

1.0.35: Automatic update mechanism implemented

Would you care to elucidate?

 

[prpr]

Would you care to elucidate?

There's a mini auto-update built into tunefix-update now, just for updating itself.

 

[4ndy]

There's a mini auto-update built into tunefix-update now, just for updating itself.

Would it be possible to get the duplicate ITV3 channel on lcn 788 via tunefix-update? It is in higher def than the main channel.

http://www.a516digital.com/2018/02/itv3-duplicate-goes-live-on-freeview.html?m=1

May confuse scheduling though, so may need more than simply being available.
.

Sent from my SM-G930F using Tapatalk

 

[Luke]

May confuse scheduling though, so may need more than simply being available.

The initial samples I'd examined used different series CRIDs.
But having a fresh look, the very first one I looked at is a duplicate.

 

[Trev]

Would it be possible to get the duplicate ITV3 channel on lcn 788 via tunefix-update?

Move it using tunefix?

 

[prpr]

Would it be possible to get the duplicate ITV3 channel on lcn 788 via tunefix-update? It is in higher def than the main channel.

It's obviously still on test and not on the DigitalUK list of official channels, so I'm not going to push out an update yet. In any case, 788 is in the range that tunefix will remove by default.
Having said that, if you want to do it yourself, you can paste this into /mod/boot/tunefix-update.conf and reboot:

CLONE|Channel 5|788|ITV3|8294|2300|2301|2302|2301|www.itv.com

You will need to make sure you've tweaked tunefix's config. first though.

 

[Luke]

You will need to make sure you've tweaked tunefix's config. first though.

For an amendment not to delete 788 tunefix's settings also needs checking after each subsequent package upgrade of tunefix as some amendments, but not all, are overwritten.
What would be the 'rules' for which are rolled back and which aren't? Or rather is there a way of defining the settings channel numbers to be deleted that would stop channel 788 from reappearing in the delete list when the tunefix package is next upgraded?
Before and after:

'500' has been retained but not the absence of 788.

 

[prpr]

What would be the 'rules' for which are rolled back and which aren't?

These LCNs are re-asserted for removal on tunefix upgrade: 211,260-299,675,678,787-799
because they are the streamed services which have no use and can crash the box, or the temporary place-holders for defunct services.

Or rather is there a way of defining the settings channel numbers to be deleted that would stop channel 788 from reappearing in the delete list when the tunefix package is next upgraded?

No.
This service on 788 is only temporary.