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

[disable-ota] Seems To Have Stopped Working

OK, so I switched to HDR4 which did update. Line 73 looks like a clue, like it's not finding the entry (the Auto Update is still there after reboot):

Code: 
75    Reminder already set.
74    Found 1 existing OTA reminders.
73    XOTA: Removed 0
72    XOTA: Removing any auto-update scheduled events.
71    Opening /var/lib/humaxtv/rsv.db
70    SQLite3: 3.7.5
69    XDSO: Removed DSO scheduled events.
68    Opening /var/lib/humaxtv/rsv.db
67    SQLite3: 3.7.5
 
Despite what the log says, it's still there.
Code: 
76    Reminder already set.
75    Found 1 existing OTA reminders.
74    0,2,Disable OTA,20150210042000
73    XOTA: Removed 1
72    XOTA: Removing any auto-update scheduled events.
71    Opening /var/lib/humaxtv/rsv.db
70    SQLite3: 3.7.5
69    XDSO: Removed DSO scheduled events.
68    Opening /var/lib/humaxtv/rsv.db
67    SQLite3: 3.7.5
 
Well, it thinks it removed the entry and then it's dumping out all remaining exotic entries - in your case just line 74 which is the disable OTA reminder. I find it hard to believe that the Humax is reinstating it immediately on boot.

Could there be some corruption somewhere in the schedule database which is stopping the event being removed? Bit of a long shot.
 
Might be worth checking the database...
Code: 
humax# sqlite3 /var/lib/humaxtv/rsv.db "PRAGMA integrity_check"
ok
 
BH : There is no need to use anything else
Click to expand...
I would have though you would be the first to defend a user's right to describe something however he likes. There is only one 'OTA (Auto) event' that appears in the schedule lists, it is completely unambiguous and self explanatory. 'Auto Update' is what is on the screen but I think even af123 would agree it needs some explanation as to what it refers to
 
Last edited:
Pre:
Code: 
ulslot    ersvtype    hsvc    nsttime    szsttime    nduration    erepeat    usevtid    szevtname    ulPreOffset    ulPostOffset    ulProgramId    ulSeriesId    ucVolume    ucInputMode    usChNum    ucRecKind    ucCRIDType    szCRID    szFPBRecPath    szRecordedProgCrid    szEventToRecord    aulEventToRecordInfo    bRecomRsv    usLastRecordedEvtId    eReady
0    2    131114    1423542000    20150210042000    1200    1    0    Disable OTA    0    0    0    0    0    0    0    0    0                        0    0    0
1    3    131109    1423605600    00000000000000    3600    0    50540    i7Smiley's People    0    0    0    0    0    0    0    4    50    FP.BBC.CO.UK/MOIL0V    Smiley's People    1FP.BBC.CO.UK/4CTC0X|1FP.BBC.CO.UK/4CTC0W|1FP.BBC.CO.UK/4CTC0V|1FP.BBC.CO.UK/4CTC0U|    1FP.BBC.CO.UK/4CTC0Y|    %`�Tp��Tl�    0    49913    30
2    7    0    1423542600    20150210043000    0    1    0        0    0    0    0    0    0    0    0    0                        0    0    0

Post:
Code: 
ulslot    ersvtype    hsvc    nsttime    szsttime    nduration    erepeat    usevtid    szevtname    ulPreOffset    ulPostOffset    ulProgramId    ulSeriesId    ucVolume    ucInputMode    usChNum    ucRecKind    ucCRIDType    szCRID    szFPBRecPath    szRecordedProgCrid    szEventToRecord    aulEventToRecordInfo    bRecomRsv    usLastRecordedEvtId    eReady
0    2    131114    1423542000    20150210042000    1200    1    0    Disable OTA    0    0    0    0    0    0    0    0    0                        0    0    0
1    3    131109    1423605600    00000000000000    3600    0    50540    i7Smiley's People    0    0    0    0    0    0    0    4    50    FP.BBC.CO.UK/MOIL0V    Smiley's People    1FP.BBC.CO.UK/4CTC0X|1FP.BBC.CO.UK/4CTC0W|1FP.BBC.CO.UK/4CTC0V|1FP.BBC.CO.UK/4CTC0U|    1FP.BBC.CO.UK/4CTC0Y|    %`�Tp��Tl�    0    49913    30

rsv.db:
Code: 
ulslot    ersvtype    hsvc    nsttime    szsttime    nduration    erepeat    usevtid    szevtname    ulPreOffset    ulPostOffset    ulProgramId    ulSeriesId    ucVolume    ucInputMode    usChNum    ucRecKind    ucCRIDType    szCRID    szFPBRecPath    szRecordedProgCrid    szEventToRecord    aulEventToRecordInfo    bRecomRsv    usLastRecordedEvtId    eReady
0    2    131114    1423542000    20150210042000    1200    1    0    Disable OTA    0    0    0    0    0    0    0    0    0                        0    0    0
1    3    131109    1423605600    00000000000000    3600    0    50540    i7Smiley's People    0    0    0    0    0    0    0    4    50    FP.BBC.CO.UK/MOIL0V    Smiley's People    1FP.BBC.CO.UK/4CTC0X|1FP.BBC.CO.UK/4CTC0W|1FP.BBC.CO.UK/4CTC0V|1FP.BBC.CO.UK/4CTC0U|    1FP.BBC.CO.UK/4CTC0Y|    %`�Tp��Tl�    0    49913    30
2    7    0    1423542600    20150210043000    0    1    0        0    0    0    0    0    0    0    0    0                        0    0    0

Weird or what?
 
Hmm, that's interesting. I have previously failed to delete the Auto Update schedule from HDR1 (disable-ota not installed) via WebIF >> Schedule and a CF-forced reboot; I just tried it again using a standby-restart cycle instead of a forced reboot, and it worked. Let me just try that on the others (disable-ota)...

Well what do know - the Auto Update entry has gone from them too! What it seems to be is a difference in behaviour between a boot-from-standby and a hot reboot. So what is it? Is the forced reboot stimulating the Humax firmware to insert a new Auto Update entry every time?

My HDRs are typically turned on 24/7 simply for convenience (I can't access them across the network if they're off!), so anybody going through the normal power cycles will not have noticed this problem. Yes, I know I advise against leaving them on, but they don't crash too often (and don't do what I do, do what I tell you).
 
I wonder if the forced reboot makes it detect a crash so it restores the working copy of the schedule from somewhere?
 
I don't think that's a runner. We don't get the same problem when altering the schedule database for anything except the Auto Update entry.
 
Re:my earlier post #21, the rogue "ota update" entry had disappeared from the schedule when I booted up today.
Edit: the box was still on the same version of disable_ota as yesterday.
I have now updated to latest version since rebooting.
 
Last edited:
The latest version only adds extra logging. I take it this was a power-up rather than a WebIF/Telnet reboot? That's what seems to make the difference.
 
Correct, it was turned off last night as normal and turned back on today, as normal via remote control on/off button.
 
af123 said:
Oh, and with all this messing around and multiple reboots from the web interface, my auto-update event has returned to the schedule!
Click to expand...
My three machines are still clear of Auto Update events (but have not been rebooted in days).
 
You must log in or register to reply here.
Back
Top