Repeated initial startup process

[InteraX]

Hi all,

My HDR-FOX T2 has been great since I purchased it, however I have an annoying issue that seems to have developed at some point in the past 18 months. I'm not exactly sure when it started as I was having some issues with the HDD. The sequence of events is below.

Around Christmas 2018 I started getting error messages about the HDD.
Over the next 12 months, the messages gradually started getting worse, but I was able to recover the system each time.
Sometimes, after a reboot, the initial setup menu would be shown. I have been able to recover this post re-scan etc by restoring recording schedules from backup.
Over Christmas 2019, I replaced the HDD with a 2TB Seagate ST2000VM003-1ET164, installed the custom FW, installed the old HDD into an external HDD caddy, copied any recording I wanted to keep onto the new HDD and then disconnected the caddy.

So far, the HDD seems to have been fine and has not generated any errors, but there are a couple of things that are annoying.

Occasionally, when we boot the system, the initial startup process kicks in. After we run through this, we restore the previous backup to get our scheduled recording back. It seems to be happening about once or twice a month.

Also, I have tried moving some files around, but they seems to move back to their original locations.

Are these issues with the underlying HW? Is anyone else having these problems?

 

[/df]

It has been suggested that uncommanded factory resets are due to corruption of the flash file system where some key parameters are stored. Running the "System Flush" (pseudo-)firmware update may improve the situation.

It's also possible that the flash memory chips are becoming unreliable as they age. In the end this will brick the box, if HMG doesn't sell off the terrestrial bandwidth first.

You can force the system not to run the first-time wizard after an uncommanded factory reset, but then you have to retune manually, before (CF) having your scheduled recordings and favourites automagically restored.

 

[Black Hole]

It's also possible that the flash memory chips are becoming unreliable as they age.

There are two issues with rewriteable non-volatile semiconductor memory. The first is data retention time, which might be 10 years or so, but the firmware store can be refreshed (firmware updates) so that shouldn't be too much of a problem as long as the firmware loader is also refreshed from time to time (assuming the "loader" does what I think it does, and isn't reliant on some code which was programmed at manufacture and is never refreshed).

The other problem is write wear. The recording schedule, in particular (but also the tuning database etc), is continually re-written. Does anybody know what (in Flash) is written to the most often, and how often that is?

 

[/df]

Most of the contents are static or written once per start or per retune/tunefix (CF) or per user setting change. rsv.db is probably the most volatile since it gets updated from the EPG.

With CF, there are some state flag files (.pid, .conf) for networking that get updated at least once per LAN connection. Perhaps they could be in /tmp?

 

[/df]

...Also, I have tried moving some files around, but they seems to move back to their original locations.
...

Sounds weird. Can you expand?

 

[Black Hole]

Maybe it's gone read-only.

 

[prpr]

The recording schedule, in particular (but also the tuning database etc), is continually re-written. Does anybody know what (in Flash) is written to the most often, and how often that is?

Dunno, but every time you change channel or volume, the setup.db database is updated.
I can't remember where I read it now, but I think I looked at something that said this flash was effectively good for several decades. Longer than any practical life of the box anyway.

 

[Black Hole]

Admittedly it was a long time ago, but I was involved in electronics design for military applications - for which the requirement was a 20-year service life. It was difficult finding EAROM to meet that spec.