So how do you want to handle that?
If your argument is: This is no good for people using FTA, so pointless adding it. If so, I would point out that the service will be omitted if FTA scan mode was used. And the fact that the hack is already in the file is being ignored. I suppose best we remove the hack and who want it can add it on their personal file.
So how do you want to handle that?
It is being added in the normal mix along with all the other encrypted channels that still open with a subscription card.abu - if the channel is omitted in an ABM FTA "scan", then fine - it's not affecting FTA users. I thought maybe it was being added into the normal ABM mix.
What are the 3 most important things...? Delete, delete, delete.If just changeing where the original code said "117" to "173" is unacceptable I don't think I'm going to be able to come up with anything.
What are the 3 most important things...? Delete, delete, delete.
That is what Satscan test tool does, so if anyone is not happy with what ABM produces they can use that tool.I have reverted the removal so that some people can continue to say that this should be in a mix file and also reject conditonalising the insert. We have yet to hear "ABM should be making bouquets exactly as per Provider order".
So Brian you are free to send a pull request (as long as you test first).
So in London region you want it in its 117 slot. 173 slot is already populated with BBC3.
For other regions it should drop in 173 if vacant, and BBC3 will be in slot 173.
Is that what happens in testing?
Correction "BBC Three" will be in 117.For other regions it should drop in 173 if vacant, and BBC3 will be in slot 173.
Shall I change the name too?I propose the variable should be called "channels_to_add_by_name" should it be re-added.
If you do it, do it as two commits.
I have removed the alleged user hack since conditionalising the hack to apply if not in London has been rejected.
I propose the variable should be called "channels_to_add_by_name" should it be re-added.