[boot-settings] Apply settings during boot

[prpr]

If it was a recording problem why would rebuilding database cure it albeit temporarily

I don't know, seeing as we don't really know exactly what the Humax software does in relation to this or how it works.
I was just going on my (one) personal experience of this problem.

 

[Border]

Download the system flush update from https://wiki.hummy.tv/wiki/Firmware_Downloads copy it to a USB memory stick and apply it to the Humax like a normal software update

I tried that and it didn't work. I had a few wizard restarts (at least 4) since then.

This package doesn't appear to work as intended on my box, I installed as Content Sharing keeps turning itself off!

Do you use WiFi or wired connection?

Easily fixed with tunefix.

Did anyone ever try my suggestion in post #75?

I have read post 75 and think it is worth a try. I use WiFi and I think my router handshakes with the WiFi dongle and allocates it's address before the hdr is able to handshake with the dongle This may be causing me some problems.

I have had problems with start up, and wizard rescanning and reinstalling channels.( I don't want the children to access the adult channels). I tried tunefix but have multiple region signals.

it did not affect as far as I can recall the content share setting.

I have tried manual address and fixed address (via router) but my suspicions are that the wizard restart occurs when there is an IP address conflict between the hdr and some other device on the network.

When the box starts which is on first DLNA index or content sharing? I suppose that is where this tread lead to. When shutting down if the DlNA was automatically reset would it take too much time to reindex on reboot?

Did anyone ever try my suggestion in post #75?

I'll let you know how I get on

 

[Black Hole]

I think my router handshakes with the WiFi dongle and allocates it's address before the hdr is able to handshake with the dongle

I don't. The WiFi link is a physical layer and establishes point-to-point communications independent of the TCP/IP traffic that crosses it. The IP address negotiation then takes place between the Humax and the router using the WiFi as a transport mechanism no different than a piece of wire. There may be a problem if the WiFi has not established the link by the time the DHCP request is issued by the Humax.

What you need to do is go into Menu >> Settings >> System >> Internet Setting >> Configure LAN, set "DHCP" and click Apply. The WiFi should be up by then, and the fields get populated by the DHCP response from the router - this ensures you have the right parameters. Now you change the DHCP field to "Manual".

Next time you boot up, the Humax will already have the correct parameters without requiring a DHCP which fails if the WiFi hasn't set up.

That will probably be sufficient, the router will keep the same IP address for the Humax's MAC. However, you could go into the router settings and set that IP on infinite lease, or allocate an IP address outside the DHCP pool (and manually set the same IP on the Humax).

You should also install the wireless-helper package.

 

[prpr]

I think my router handshakes with the WiFi dongle and allocates it's address before the hdr is able to handshake with the dongle

It doesn't work like that. As BH said, although the bit about "problem if the WiFi has not established the link by the time the DHCP request is issued" is wrong.

I tried tunefix but have multiple region signals.

Tunefix supports multiple regions (with caveats).

 

[Black Hole]

although the bit about "problem if the WiFi has not established the link by the time the DHCP request is issued" is wrong.

In what way? The Humax firmware doesn't retry DHCP, so if the link isn't up the box ends up with default (wrong) IP details. I see this all the time when I visit my supported user: if I have my phone hotspot turned on when the HDR boots, it links up fine. If I turn the hotspot on later, the WiFi links up but the HDR is unreachable.

Edit: actually, thinking back there's something not right about that. I have the HDR set to manual, so DHCP shouldn't be the problem - and yet the WiFi links up without necessarily establishing an Ethernet link. I have wireless-helper installed. This warrants further investigation (when/if I get the opportunity).

 

[Border]

Did anyone ever try my suggestion in post #75?

Thank you (I think).....
Humax crashed again but, hurrah!!, no wizard reset. However in one of the logs there was the following entry :

Boot log says last modified Wed Nov 16 12:35:01 2011 (over 7 years ago???)
And the first 2 lines state :

/var/lib/humaxtv/var/lib/humaxtv/mod/bootstrap.d/setdlnaname: Next DLNA Server Name is now "**** ".
mod/bootstrap.d/setdlnaname: Matched: entry 3 "1.02.32" for process 419.

Server name asterisked out but there were a few spaces included between quotes after the server name
I can't find an exact time for the crash

activity log

3158	18/02/2019 21:51:05 - Scheduled --- Auto Update --- @ 1550550600
3157	18/02/2019 21:49:08 - System booted (Front panel button).
3156	18/02/2019 04:20:06 - System booted (Scheduled event).

I thought I had autoupdate disabled ... I have checked schedule and no autoupdate in schedule.

 

[Black Hole]

18/02/2019 21:51:05 - Scheduled --- Auto Update --- @ 1550550600

I think you'll find that's the Humax trying to add one, and the CF would have taken it out again.

 

[Matthew]

Possibly you have a corrupted recording that is upsetting DLNA. Finding it might be tricky though.

Thanks for the pointer, I have an idea now of what may be the cause (in my case anyway) as I stated elsewhere the IRS signal provided here has very poor quality (though the measure on the Humax is either 100% or 0% so not a guide) the time when we stopped getting constant 'Content Share Off' coincides with my fitting an aerial, though the levels were low quality was good, I suspect the low levels (it was borderline at around 35dBuv) caused the recurrence, adding an amplifier to correct that has meant no further recurrence so far!

 

[/df]

Within the setup database (/var/lib/humaxtv/setup.db) there is is a field in in the TBL_USERCONFIG table called WIZARD_CMPLTD.
...
My thought was whether it could be added to the Boot-settings list or whether boot-settings runs to late in start up to prevent the wizard running

and

It could. Probably something like this (I haven't tested it!) needs adding to /mod/webif/plugin/boot-settings/schema.jim:

{Wizard Complete} {
        table USERCONFIG
        field WIZARD_CMPLTD
        type Value
        gui boolean    
}

Fairly obviously, it is going to run early, before the main Humax software starts.

In my HD Fox-T2 with the above mod and 'Wizard Complete' forced on by boot-settings, I haven't observed a random factory reset. Instead, I've had a random "No channels found" dialogue prompting me to tune the box. You can provoke the same message by deleting all your channels explicitly, or by cancelling an Automatic Search before any channels have been found.

It seems plausible that the Humax blob checks 'Wizard Complete' and then for channels being tuned. If so, the effect of forcing 'Wizard Complete' on is that you avoid having to go through the Wizard stages before the tuning stage.

 

[Black Hole]

...but still the tuning stage, so things are buggered either way.

 

[/df]

The buggery was implicit in my hypothesis, but the severity is less because you get to the retune stage more quickly, after which you can actually watch a program or restore from backup.

A possible side-effect is that the machine in question now displays "UpdA" as it's shutting down, whereas other HDs just turn off the display, or in one case (power supply issue?) make it flicker on all 4 characters. But actually "UpdA" is what gets displayed while the HD-Fox is updating, syncing and unmounting any attached disks. This takes longer if time-shift recording is enabled and almost no time if the disk(s) are solid state. Whether it's displayed may depend on the power-saving setting.

It occurred to me that as the broadcast stream can force a retune (DSO event) it should be possible for CF to do the same (xinit time). But it's not clear that the empty channel database is a result of whatever happened between shutdown and startup, or is caused by the Humax blob reinitialising what it sees as a corrupt database (in which case the empty DB wouldn't be apparent at xinit time).

 

[prpr]

A possible side-effect is that the machine in question now displays "UpdA" as it's shutting down

Mine always does that. It then leaves a blank display, rather than the clock display that I've seen in several images but never managed to achieve.

It occurred to me that as the broadcast stream can force a retune (DSO event) it should be possible for CF to do the same (xinit time)

It can. There was also a diagnostic (force-retune) to get it to do so on next boot. I used this once before the days of tunefix to remotely retune a box (to add Wimbledon services). It was not a pleasant experience having to do it that way.

 

[/df]

...
In my HD Fox-T2 with the above mod and 'Wizard Complete' forced on by boot-settings, I haven't observed a random factory reset. ...

Now I have. A different HD with 'Wizard Complete' forced on by boot-settings suffered a random factory reset at power-up.

So either

• 'lose tuned channels' and ''factory reset' are two different failure modes, perhaps associated with different types of flash filesystem corruption, and forcing 'Wizard Complete' on has no effect, or
• the Humax blob checks 'Wizard Complete' and then for channels being tuned, but depending on process scheduling boot-settings may not yet have forced 'Wizard Complete' on when this value is checked.

 

[/df]

After a reset, unsolicited or not, the default for "Time Shift Recording" (SUI>Menu>Settings>Preferences>Recording) on the HD-Fox T2 is Off. This can lead to disappointment when it turns out not to be possible to rewind the live broadcast.

The relevant parameter is a 0/1 flag in the Value of the row named TSR_ENABLE in TBL_MENUCONFIG. However, rather than have that value != 0 ENABLE time shift recording, the Humax programmers imaginatively made it DISABLE time shift recording. But they were not that imaginative: the same feature was implemented for SUBTITLE_DISPLAY_F and the boot-settings package is wise to it.

Therefore the following fragment can be appended to /mod/webif/plugin/boot-settings/schema.jim to enable management of the "Time Shift Recording" preference using boot-settings:

{Time Shift Recording} {                                                        
        table MENUCONFIG                                                        
        field TSR_ENABLE                                                        
        type Value                                                              
        gui boolean                                                             
        get {$(!$v)}                                                            
        set {$(!$v)}                                                            
}

 

[af123]

Therefore the following fragment can be appended to /mod/webif/plugin/boot-settings/schema.jim to enable management of the "Time Shift Recording" preference using boot-settings:

Thanks, I'll add it to the next update.

 

[/df]

Although this preference is specific to the HD I think it's fine to include it in the general list, since it has to be selected it in the settings for it to be used.

Whereas the "FTP Server" and "Content Share" preferences (and perhaps others?) are specific to the HDR.

If it was desired to filter the platform-specific items, a fairly simple solution could be to have an additional platform-specific schema file to be loaded after the general one based on a model test. But that should probably come with code to override a general schema item with matching table, field and type, or otherwise insert a new one.

Instead, perhaps there should be some general way of showing when a setting is specific to one platform -- other than, say, appending "(HD only)" to the displayed preference name?

 

[Black Hole]

I'm curious whether this flag has any effect on HDR-FOX function.

 

[/df]

It's not mentioned in the default DB /var/lib/humaxtv/default_setup.db on the HDR nor in the HDR settop binary:

humax# strings -n 10 /mod/HDRfs/usr/bin/humaxtv | grep TSR_ENABLE
humax#

So I think not.

 

[/df]

If one has a preferred Favourite Group set using boot-settings, disappointment can ensue when other delinquent users switch to a channel (ie service) not in the group and the box has subsequently been restarted. The preferred Favourite Group is abandoned because the Humax settop binary always tunes to the CUR_SVC saved in TBL_USERCONFIG of setup.db.

One solution to this is to change such a saved channel that is not in the preferred Favourite Group to one that is, such as the one at the top of the group (least TBL_FAV.favidx). The following SQL achieves this:

attach '/var/lib/humaxtv/setup.db' as su;
attach '/var/lib/humaxtv/channel.db' as ch;
update su.TBL_USERCONFIG 
	set itemValue = 
			(select hSvc from ch.TBL_FAV 
				/* group number in TBL_USERCONFIG is +2 to allow for 0,1,2 = TV, Radio, HDTV */
				where eFavGroup = (select itemValue - 2 from su.TBL_USERCONFIG where itemName = 'CHLIST_GROUP')
					order by favidx asc limit 1)
				where itemName = 'CUR_SVC' 
					and (select hSvc from ch.TBL_FAV f inner join su.TBL_USERCONFIG s 
							on f.eFavGroup = (select itemValue - 2 from su.TBL_USERCONFIG where itemName = 'CHLIST_GROUP') 
								and s.itemName = 'CUR_SVC' and s.itemValue = f.hSvc) is null;

Or shorter

attach '/var/lib/humaxtv/setup.db' as su;
attach '/var/lib/humaxtv/channel.db' as ch;
/* group number in TBL_USERCONFIG is +2 to allow for 0,1,2 = TV, Radio, HDTV */
with g as (select itemValue - 2 as grp from su.TBL_USERCONFIG where itemName = 'CHLIST_GROUP')
	update su.TBL_USERCONFIG 
		set itemValue = 
				(select hSvc from ch.TBL_FAV, g where eFavGroup = g.grp order by favidx asc limit 1)
				where itemName = 'CUR_SVC' 
					and (select hSvc from g, ch.TBL_FAV f inner join su.TBL_USERCONFIG s 
							on f.eFavGroup = g.grp and s.itemName = 'CUR_SVC' and s.itemValue = f.hSvc) is null;

 

[/df]

The parameters "OSD Timeout" and "Info Display Time" are synonymous: both set INFO_DISPLAY_TIME in TBL_MENUCONFIG, but the UI is different (slider vs plain number spinner, seconds vs ms). While this isn't a fault, it could be confusing, especially if you don't know to look in the schema.jim file.