Empty Schedule

[Black Hole]

I'm getting this on a frequent basis, on a HDR-FOX and a HD-FOX, but the HD-FOX is the current case in point. I'm posting in the CF section only because CF will be involved in the process of diagnosis.

Left to its own devices over the weekend (not in standby), the unit in question recorded on Saturday evening but nothing after that. This morning, it didn't do what it had been scheduled to do, and when I checked the schedule was empty (as I have come to expect). WebIF still works, and there is nothing reported in the crash log (not recently, anyway).

I have no doubt that when I reboot the schedule will restore itself, as I have previously experienced. Previous experience suggests it is not auto-schedule-restore doing this, as there is not a multi-boot, however I will disable ASR before I reboot just to confirm.

Is there any useful information I can report before rebooting?

Weirdly, the last entry in activity.log is 2019! Why might that be? auto.log stopped in May 2023, also weird.

 

[Black Hole]

Well that's curious, and not something I have observed previously: although the SUI schedule is empty, the WebIF schedule is correctly populated.

 

[prpr]

Run fix-flash-packages diagnostic or RMA and reinstall.
You could also look at rsv.db on the Database Browser on the Diagnostics page.

 

[Black Hole]

Run fix-flash-packages diagnostic or RMA and reinstall.

How does this affect the SUI's view of the schedule?

You could also look at rsv.db on the Database Browser on the Diagnostics page.

I've rebooted. The SUI schedule is now correct.

 

[bottletop]

..
Weirdly, the last entry in activity.log is 2019! Why might that be? auto.log stopped in May 2023, also weird.

2019 was a while ago, so difficult to trace. Out of curiosity, maybe post recent entries in the activity log? For the future, it may be useful post the boot.log before reboot. Is there a function to archive the logs before reboot, eg new script or a diag function?
If you wish to check the other issue, did anything unusual happen to this specific HD-FOX in May 2023?
Was it to do with this? https://hummy.tv/forum/threads/records-but-wont-live-pause.10960/

 

[Black Hole]

I guess fix-flash-packages (etc) will fix the logging. It seems a blunt instrument though, in as much as it provides no report on whether anything actually needed fixing.

 

[Black Hole]

Weirdly, the last entry in activity.log is 2019! Why might that be? auto.log stopped in May 2023, also weird.

These logs are now showing as complete, with entries showing in the intervening period, and there is a smoking gun:

4274    30/10/2024 08:12:02 - Unscheduled --- Auto Update --- @ 1730345400
4273    30/10/2024 08:06:49 - System booted (Power cycle).
4272    30/10/2024 03:04:02 - Unscheduled --- Auto Update --- @ 1730262600
4271    30/10/2024 03:01:03 - System booted (Power cycle).
4270    29/10/2024 21:46:59 - Recorded: QI XL/QI XL (45 minutes - BBC TWO)
4269    29/10/2024 20:05:54 - Automatically upgraded package jim from 0.82-5 to 0.83
4268    29/10/2024 20:05:52 - Automatically upgraded package webif-channelicons from 1.2.10 to 1.2.11
4267    29/10/2024 20:03:21 - Automatically upgraded package tunefix-update from 1.0.147 to 1.0.148-1
4266    29/10/2024 20:03:02 - Unscheduled --- Auto Update --- @ 1730262600
4265    29/10/2024 19:59:51 - System booted (Power cycle).
4264    29/10/2024 19:59:11 - Recorded: /Star Trek: Voyager (56 minutes - Sky Mix)
4263    27/10/2024 01:07:03 - Unscheduled --- Auto Update --- @ 1730003400
4262    26/10/2024 20:10:59 - Recorded: Strictly Come Dancing/Strictly Come Dancing (106 minutes - BBC ONE West)
4261    26/10/2024 13:02:27 - Recorded: Rick Stein's Food Stories/Rick Stein's Food Stories (60 minutes - BBC TWO)
4260    26/10/2024 07:00:05 - Recorded: /Breakfast (24 minutes - BBC ONE West)
4259    25/10/2024 19:59:41 - Recorded: Star Trek_ Voyager/Star Trek: Voyager (60 minutes - Sky Mix)
4258    25/10/2024 17:59:39 - Recorded: Star Trek_ Enterprise/Star Trek: Enterprise (59 minutes - Sky Mix)
4257    24/10/2024 22:59:50 - Recorded: New_ Taskmaster/New: Taskmaster (60 minutes - Channel 4+1)
4256    24/10/2024 21:59:49 - Recorded: New_ All Creatures Great and Small/New: All Creatures Great and Small (59 minutes - Channel 5)
4255    24/10/2024 19:59:41 - Recorded: Star Trek_ Voyager/Star Trek: Voyager (60 minutes - Sky Mix)
4254    24/10/2024 17:59:39 - Recorded: Star Trek_ Enterprise/Star Trek: Enterprise (59 minutes - Sky Mix)
4253    23/10/2024 19:59:43 - Recorded: Star Trek_ Voyager/Star Trek: Voyager (59 minutes - Sky Mix)
4252    23/10/2024 17:56:15 - Recorded: Star Trek_ Enterprise/Star Trek: Enterprise (55 minutes - Sky Mix)

What is event 4263, which occurs in the window between the last successful scheduled recording and the first scheduled recording which did not occur (event 4264 was a manual recording)? Is that a check for package updates with no payload (event 4266 is followed by logged package updates)?

Filtered for "Unscheduled":



Clearly these occur on a semi-regular basis without necessarily causing this disruption, but I wonder whether there was something about that particular "Auto Update" which triggered it, perhaps a glitch. The intervals are quite random, so I assume these are initiated at the server (and polled from the client), but if so why do some seem not to have a payload?

Regardless, I now have a hypothesis to test when/if this happens again, and it remains to be explained how the WebIF can show a view of rsv.db which contradicts the SUI.

 

[bottletop]

I think event 4263 is the GMT change.
I have a similar event on one of my HDR, although on mine it appeared at 01:00:04.

Regarding the difference between the schedule timers on screen and WebIF, I've only noticed that on the occasions when WebIF does a restore, but that usually shows a reboot message on WebIF.

 

[prpr]

It seems a blunt instrument though, in as much as it provides no report on whether anything actually needed fixing.

I wrote something that would identify missing package files. It doesn't of course check whether any particular file has been corrupted.
It also doesn't check any configuration changes that packages may do. Uninstall and reinstall (which is what fix-flash-packages effectively does for any package which has components in the flash storage) resets any such stuff.

What is event 4263, which occurs in the window between the last successful scheduled recording and the first scheduled recording which did not occur

It's just disable-ota doing its stuff.

it remains to be explained how the WebIF can show a view of rsv.db which contradicts the SUI.

Indeed. I don't think I remember ever seeing that.

 

[prpr]

I don't particularly like "Auto Update" as a description of things in the schedule database:

                    5 { set name "--- Wake-up ---" }
                    6 { set name "--- Sleep ---" }
                    7 { set name "--- Auto Update ---" }
                    11 { set name "--- DSO Event ---" }

What does the panel think about a name change? I guess "OTA Event" or "OTA Check" unless anyone has something more descriptive without it being too wordy.

 

[Black Hole]

What is this, exactly? The disable-ota checking the schedule database for the 4.30 OTA check and removing it if found? If so, how about "Anti-OTA" (and the other one "Anti-DSO")?

 

[prpr]

The disable-ota checking the schedule database for the 4.30 OTA check and removing it if found?

Yes.

 

[bottletop]

Alternatively, maybe use prefix 'not-', 'suppress-' or 'disable-' to match the (installed) package name.

 

[Black Hole]

More weirdness has presented this morning:



The same is shown in SUI. I have no idea where the duplicated Breakfast reminder came from, most (if not all) methods for adding it would detect the duplication. Other entries are not duplicated.

Hmm. Auto schedule backups have a gap, last one 18/10 until I FFP'ed/rebooted, next one 29/10 just after the reboot instead of in the middle of the night. The 29/10 backup contains the duplicated entry (18/10 does not).

There's a second schedule oddity too: 18/10 shows my OTA defeat reminder set to Classic FM. That has disappeared 29/10 and 30/10, but backup 31/10 re-establishes the reminder at Red Button (the disable-OTA default).

 

[prpr]

As the intiial state is now a bit unknown, you just need to delete all the entries and re-enter them one way or the other to ensure consistency. The safest way is via the on-screen EPG.

 

[Black Hole]

I've been preserving the crime scene so far as possible, but if there's no more information to be gathered I'll nuke it...

 

[prpr]

I've had the double entry thing once myself and couldn't be bothered investigating on my own boxes, so...