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

af123 said:
It isn't going to be easy to confirm any fix since I've never had a retune message : (
Click to expand...

I've just spotted a re-tune message on the TV in the spare room for the 9th May which is confirmed by the info on digitaluk website. I haven't seen a prompt yet on the main tv (with the Hummy connected) or the TV in the kitchen yet. Can I help? Is there any info I could get for you?

To confirm I'm still on 1.02.20 but can update to .27 if required, I've got the webif on if you need diagnostics running, I can run (well paste really!) Telnet commands if you tell me what they are, and I could probably get FTP working onto the box as well if that was needed to drag anything else off. Would most likely be Saturday night when I'm on sitting duty but might get something for you tonight maybe depending what you need.

[EDIT - Ah xyz seems to have beat me to it - anyway the offer still stands if it's of any use for the cause]
 
Hmm. That's annoying - the WebIF file editor complains the .rbk is not a plain text file. Guess I'll have to break out the other computer!

Sorry, all I've got are events type 2, 3, & 7.
 
I have a DSO event in my pending list now. Following the next reboot it should be in the table so I'll see what happens.
 
Well, I got this and set a stopwatch running. After exactly 3 minutes, it went into auto-tune by itself.

DSO.jpg
 
af123 said:
Since you asked so nicely, the disable-dso package should do what you want. Time will tell of course as I can only replicate it so far.
Click to expand...

Thanks for working on this.

Coincidentally after no problems since a couple of re-tunes post DSO. I installed this anyway...

This morning? It's asking for a retune :( will the script stop the auto tune or should it stop the Notification appearing at all?

UPDATE: after 3mins it auto tuned by itself.
 
Not me. Pruned channel list and schedule intact this morning, but then the box was on all night (as usual) and didn't have any reboots. So I gave it a reboot and still nothing to report.
 
Black Hole said:
Not me. Pruned channel list and schedule intact this morning, but then the box was on all night (as usual) and didn't have any reboots. So I gave it a reboot and still nothing to report.
Click to expand...
I think it may be dependent upon the system clock at boot up. If the system clock is not set at that time the last scan time is set in the database to 1st Jan 2000 which will then cause the message box to appear. Perhaps you have one of the system clock setting packages installed.
 
xyz321 said:
I think it may be dependent upon the system clock at boot up. If the system clock is not set at that time the last scan time is set in the database to 1st Jan 2000 which will then cause the message box to appear. Perhaps you have one of the system clock setting packages installed.
Click to expand...

Not on the HDR, it's getting its system time from the aerial the same as everybody else. My HD doesn't suffer from retune events anyway, because without an aerial it doesn't know there is one.
 
freestyle_gus said:
It's now showing that message every time I change a channel :(
Click to expand...
You can either let it do the scan or copy this script to /tmp as 'fix_dso.sh' then type 'sh fix_dso.sh'. Note: Do not run this if you are currently recording anything since it will cause the box to freeze.

Code: 
#!/bin/sh
 
opkg remove disable-dso
/etc/init.d/S90settop shut
sleep 3
cat <<EOD | sqlite3 /var/lib/humaxtv/setup.db
update TBL_USERCONFIG set itemValue=0 WHERE itemName='ASO_NOTIFY_FLAG';
update TBL_USERCONFIG set itemValue=2147483647 WHERE itemName='ASO_LAST_SCAN_TIME';
EOD

When it has run type 'reboot' and hopefully the box will no longer appear.

Edit: Fixed typo in the line 2 of the sqlite commands in the above script
 
freestyle_gus said:
You lucky thing. It's now showing that message every time I change a channel :(
Click to expand...

I wonder what's going wrong here then?

The way I anticipate disable-dso to work is that it searches for event type 11 in the schedule, and when it finds one uses the well-established mechanism to put a "delete event" in the pending queue for the next reboot. The CF then kicks in at reboot to apply the changes to the schedule database before the Humax code can muster its defences.

Unless af has cocked up the implementation in some way [wash mouth out with soap], there must be something else going on we do not yet understand.

Edit: posted simultaneously with the previous (by which I mean I was in the process of preparing this before the previous got posted).
 
Black Hole said:
Not on the HDR, it's getting its system time from the aerial the same as everybody else. My HD doesn't suffer from retune events anyway, because without an aerial it doesn't know there is one.
Click to expand...
My HDR is also connected using the aerial. The disable-dso package runs early on in the boot process before the humaxtv application is run so the system time may not be set at that point. The ASO_LAST_SCAN_TIME parameter was showing 946684805 (1st Jan 2000 00:00:05) on my box.
 
xyz321 said:
Code: 
#!/bin/sh
 
opkg remove disable-dso
/etc/init.d/S90settop shut
sleep 3
cat <<EOD | sqlite3 /var/lib/humaxtv/setup.db
update TBL_USERCONFIG set itemValue=0 WHERE itemName='ASO_NOTIFY_FLAG';
update YBL_USERCONFIG set itemValue=2147483647 WHERE itemName='ASO_LAST_SCAN_TIME';
EOD
Click to expand...

Is it necessary to remove disable-dso in that script (the point being that it should prevent any new scheduling of a retune)? Are you saying that disable-dso is not fit for purpose at the moment? Is this script what disable-dso should do?
 
Black Hole said:
I wonder what's going wrong here then?

The way I anticipate disable-dso to work is that it searches for event type 11 in the schedule, and when it finds one uses the well-established mechanism to put a "delete event" in the pending queue for the next reboot. The CF then kicks in at reboot to apply the changes to the schedule database before the Humax code can muster its defenses.
Click to expand...
I think it is supposed to set ASO_LAST_SCAN_TIME to the current time but I think it would be better to set it to the latest possible time in the future.
 
Black Hole said:
Are you saying that disable-dso is not fit for purpose at the moment? Is this script what disable-dso should do?
Click to expand...
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.
 
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?
 
You must log in or register to reply here.
Back
Top