• 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.

Customised Firmware 2.10 (for 1.02.27)

Yes, the script is a temporary fix until af123 can fix the proper one. If I install disable-dso, every time I reboot I see the nag screen with or without the extra database hacks.

Does that not imply the rescan event is getting added to the schedule rather than removed??
 
Aha! So your idea for a cure is to update the last scan time record so the box thinks it's been done, rather than eliminate the retune event from the schedule?
In this particular case there is no retune event in the schedule. It is producing the nag message because it thinks the time of the last scan is invalid (or hasn't been done).
 
As a matter of interest what is the value of the ASO_LAST_SCAN_TIME parameter on your machine?
Diagnostics | Database Browser | setup.db | TBL_USERCONFIG
 
Epoc time 946684805 = Sat, 01 Jan 2000 00:00:05 GMT
Yes, I am mystified as to why BHs box is working fine. With the exact same value mine produces the nag message. Some other parameter must also be affecting this - perhaps NETWORK_CHANGE_INFO (zero on my box).
 
Zero on mine too.

I've only done one reboot since disable-ota, I will continue to monitor. Let me know if you need any more data.
 
Holy s**t batman it sounds like i'm standing in the footsteps of giants!!! I'm still on .20 and watching the original version of return of the Jedi with the boys - should I go to .27 and cf 2.1x or standby till after retune event or dive in now??
 
Okay, that went spectacularly badly.

I've just published an update to disable-dso which uses xyz321's suggested timestamp instead of trying to set it the current clock time, which as xyz321 rightly pointed out is in 2000 at boot time.

This package does three things, all at boot time before the Humax software starts:

Code:
delete from TBL_RESERVATION where ersvtype = 11;
update TBL_USERCONFIG set itemValue = 2147483647 where itemName = 'ASO_LAST_SCAN_TIME';
update TBL_USERCONFIG set itemValue = 0 where itemName = 'ASO_NOTIFY_FLAG';

for reference the old version set the last scan time like this:

Code:
update TBL_USERCONFIG set itemValue = strftime('%s','now') where itemName = 'ASO_LAST_SCAN_TIME';

which always set it to January 2000 : (
 
Go for it, Batman. Resistance is futile. You will be assimilated.


Sent from my iPhone 4s using Tapatalk

Thanks Wallace knew I could count on you for a balanced point of view ha ha!!!! I'm gonna listen to the densest known object in human understanding over the fictional ( but nonetheless genius inventor) plasticine man. At this stage if anyone still needs a pre update pre .27 pre retune guinea pig then thats me but I can't promise if I can stay awake until motd at this rate!!
 
I've just published an update to disable-dso which uses xyz321's suggested timestamp instead of trying to set it the current clock time, which as xyz321 rightly pointed out is in 2000 at boot time.
It seems to be working fine with no retuning prompts on boot up but I suppose we will have to wait for a real DSO event to find out how effective it is.
 
So can we explain why I didn't have a problem, even though my last scan time got set to 2000? Is it because I don't also have an event type 11 in my schedule?

I just tried a complete power-down and restart, and confirmed my last scan time is still 2000, no problems. Any complete explanation has to account for that.
 
Small problem. I've just tried to change a ch5 recording from AR to padding and the entry in the pending events isn't the programme I changed. I tried it twice in case I miss clicked the correct programme line. The programme it is changing has 0 as the entry number on the far left of the normal events. The one I clicked has 5.
Just tried doing a different programme and it too ends up changing the same incorrect programme in the pending events.

Anyone else got this problem or is it just me?
 
Back
Top