Scrambled EPG after 17/10 Freeview Update

I tried doing a manual tune on mine, and it wouldn't find a signal on the HD mux (Oxford transmitter), along with another couple of channels. I ended up just letting it do the autotune.

I expect you forgot to select "DVB-T2" for the HiDef multiplex.
 
I thought 800's were from a different transmitter, but I can't understand why the Hummy would pick 2 channels from one transmitter and 3 from another (though I can quite believe it bloody well would/could!!)
The one I manage has done. It currently has 4 from Waltham and 2 from Belmont, despite the user being asked at the end of Automatic Search to select the desired region (East Midlands).
This kind of makes being asked which region you want rather pointless doesn't it?
 
That just means it didn't pick up all the multiplexs from your desired region, and had to fill in with the others.
 
You can tell - there will be no reservations in your recording schedule! Also (for example) BBC1 HD will now be found on 100 instead of 50.

Regarding stopping it, I refer you to my recipe for a bomb-proof HDR (click).
Thanks again BH - its clear now. I do have an intact schedule ( but wouldn't the CF have restored that anyway? ).

It hasn't retuned because I do in fact have disable-ota and disable-dso installed! I'm getting very old you know, well very drunk anyway. Your link mentions a theoretical possibility of an auto retune even with dso. Is this a real concern ( with hopefully a real solution ) or so remote as to be not worth worrying about?

Your link above also explains why BBC1 HD is still on 50 rather than 100 but still works perfectly - I presume it was just an LCN shuffle rather than a 'real' change. The fog is lifting......
 
but wouldn't the CF have restored that anyway?
Not without user intervention.

The chances of a retune sneaking in with disable-dso running depend on how long you leave the Humax on for, particularly unattended, and the consequences of a retune occuring depend whether you are around to put things right quickly. As said, the schedule is easy enough to restore through the WebIF as long as you are not away on holiday. I'm sure the message will get around ahead of another retune event anyway.

Yes, it was just an LCN shuffle, no significant consequences of not having done it (I haven't, and I see no need for No2 unless the user complains).
 
That just means it didn't pick up all the multiplexs from your desired region, and had to fill in with the others.

It picks up all 12 multiplexes fine. That is the problem and what this Region selection was designed to avoid. It DOES NOT work.
Here is the evidence:

tuner.PNG
 
I'm a bit stumped as I've lost the HD mux after a forced retune yesterday. The box is an RMA replacement which I only received on Monday, hence no disable-dso etc yet.

I have done a few retunes, auto and manual, expecting them to just come back as I've never had problems before. I get clean signal from a single transmitter. And yes, the manual retunes were using DVB-T2. I know the HD channels moved LCNs but the other moved channels are fine (and showing the new LCNs). Strangely, the box shows no signal strength or quality on the HD mux (C21 - sandy heath), but the Sony TV is showing everything fine. The Humax was showing them fine on Monday too. I even tried entering the frequency manually (there is an offset for this channel on sandy Heath according to ukfree.tv).

At this point I am totally stumped. Any ideas? A borked refurbish job?
 
The chances of a retune sneaking in with disable-dso running depend on how long you leave the Humax on for, particularly unattended
Is it possible to quantify this? For example would there be much risk if I was away for a week with the Humax in standby but waking to record 5 or 6 programmes of an hour or so ( ie typical pvr use?). The other extreme would be if the box was permanently on in a darkened room ( ie more like a server mode ). I have no intention of the latter use, only the former.

You can see where I'm coming from - if typical pvr use still carries a significant risk despite disable-dso then perhaps I should revert to firmware version .20. That doesn't appeal because if, as you suggest elsewhere, Humax have adopted forced retunes to comply with Freeview standards they are unlikely to change it and so I would be shut off from all future upgrades. And who knows, some of them might be highly desirable ( no, really! ).
 
I don't think you need to worry about it that much, I only mention it because if I didn't somebody would complain they hadn't been warned. Hell, it's not as if there are retunes every third week. For my unattended user to have the absolute minimum problems though, I've settled for .20 (and so far there's nothing to attract me away from .20 either).

if, as you suggest elsewhere, Humax have adopted forced retunes to comply with Freeview standards

I don't think I suggested that, did I?
 
Well I did what I planned, went home, made a cup of tea, set Hummy to autotune, had tea and biscuits, came back to it, and as expected, mt EPG was back to normal with only one of each channel, so I guess the weather must have played a part yesterday. :)
 
It picks up all 12 multiplexes fine. That is the problem and what this Region selection was designed to avoid. It DOES NOT work.
Here is the evidence:

View attachment 334
FWIW, I have effectively done a manual retune (or at least a manual delete following an automated tune) and now managed to transfer the LCNs from the two unwanted muxes to the two wanted muxes (previously in the 800+ range) and then deleted the Belmont network (which deletes all six associated transport streams, which in turn deletes all unwanted services which were upsetting the box).
On the setup in question, the unwanted muxes were rows 4 and 9, the wanted ones were 3 and 8, and the unwanted network was 1 (anyone else trying this will need to adjust as necessary).
I fed this to "sqlite3 /var/lib/humaxtv/channel.db" and then rebooted:
Code:
CREATE TEMP TABLE t AS SELECT usLcn,usSvcId FROM TBL_SVC WHERE tsIdx=4;
UPDATE TBL_SVC SET usLcn=(SELECT usLcn FROM t WHERE usSvcId=TBL_SVC.usSvcId) WHERE tsIdx=3;
DROP TABLE t;
CREATE TEMP TABLE t AS SELECT usLcn,usSvcId FROM TBL_SVC WHERE tsIdx=9;
UPDATE TBL_SVC SET usLcn=(SELECT usLcn FROM t WHERE usSvcId=TBL_SVC.usSvcId) WHERE tsIdx=8;
DROP TABLE t;
DELETE FROM TBL_NET WHERE netIdx=1;

(There is probably a better way to do this (anyone?), but I'm not too hot on SQL...)

It has worked a treat as far as I can tell.
 
I tried doing a manual tune on mine, and it wouldn't find a signal on the HD mux (Oxford transmitter), along with another couple of channels. I ended up just letting it do the autotune.

When you started the manual tune on the appropriate MUX that carries the HD channels on your transmitter, did you select the DVB-T2 option rather than the 'default' DVB-T? As BH stated above?
 
I don't think I suggested that, did I?

Not you? I remember reading it somewhere in one of the discussions about the forced retune issue - maybe someone commenting on one of your posts. not trying to put words in your mouth!

I'm going to manually retune this morning, get rid of the 800s, remove padding and go back to AR. Then all shall be well, and all manner of thing shall be well. ( as Ezra's mate might say ).
 
When you started the manual tune on the appropriate MUX that carries the HD channels on your transmitter, did you select the DVB-T2 option rather than the 'default' DVB-T? As BH stated above?

No I didn't. I didn't know one needed to. I will give it another try soon.
 
Back
Top