Timer corruption

[Piranha]

I have two TMTWIN boxes, both running Apollo, configured identically after each successive image update. In the past month or so, I have had multiple occurrences of timer corruptions taking place after an event had been recorded - the timer log changes are always the same - the last entry shows two 'record time changed' entries, one to the next correct 'start prepare' date and time, then another which is normally something like:
"2025-01-09 23-38 - record time changed, start prepare is now: (Day) Jan 09 (correct recording time) 2025"
Not surprisingly, the next timer event fails to happen and, as these are almost invariably recordings of my wife's favourite soaps, I am in the doghouse.
Not sure where this spurious data is being generated - is it a corruption in the EPG data download (I use CrossEPG 0.8.1 +gitrAUTOINC etc and OpenATV from 28.2E)?
Have started from scratch many times with both boxes and this still happens, but not consistently.
Any ideas anyone please?

[Piranha]

Finally managed to capture my timer gremlin in a log! The attached e2 debug log shows what happens (but I don't know why)! The difference between the receiver time and RTC time is calaculated as 321079828 seconds - which is exactly the TEN YEARS and a bit all my timers get shoved into the future!
Have now changed (on one box) the time source from transponder to pool.ntp as an experiment. Deleted timers.xml of course and rebulit that, a few reboots and see what happens!
Please, could one of the real clever boys at OpenVix could take a look at the log and advise if this might be a hardware issue (i.e. the box simply fails to keep the correct time).
ANY HELP WOULD BE GREATLY APPRECIATED - THIS ONE IS DRIVING ME NUTS!!!!!!

[Sicilian]

I've reported to the manufacturer.