Two Problems While Trialling CF 1.03.12 on HDR-Fox T2

dfc458b52c66754092a1bedbba57ab9385eb74c4 HDR_FOX_T2_1.03.12.hdf
I'm gratified I came up with the same hash! At least that means I have my method correct.

I've used https://www.strerr.com/en/sha1_file.html to try to validate the two 1.03.12 downloads available at https://drivers.softpedia.com/get/F...igital-Recorder-Firmware-10312.shtml#download

One of the .hdf files is 22,307KB and yields 06217d41aabdb96f68e68db0515ab58a65b2e998
The other .hdf file is 22,327KB and yields 9dd3271e40c0170a7664f77a1781cb0f6444209e

Neither matches the dfc458b52c66754092a1bedbba57ab9385eb74c4 which BH advised (elsewhere) is the SHA1 hash for the 1.03.12 firmware.
I don't understand this at all. Why would there more than one .hdf claiming to be "1.03.12" out in the wild? Humax cock-up again? Different locales (in which case you would expect different version numbers)?

I might suggest a fault with the SHA utility, but if the two sources of download were the same the hash should be the same – even if in error.
 
Last edited:
I don't understand this at all. Why would there more than one .hdf claiming to be "1.03.12" out in the wild? Humax cock-up again?
Who knows. A .hdf file is just a container, a bit like .zip or .rar or any other container you care to think of.
I unpacked and then repacked the contents of the original 1.03.12 .hdf eight different ways (using different options on the HDF tool) and got eight different SHA1 results, not surprisingly. The container files are different, obviously, but the contents are still the same when extracted.
One of them matched the 0621 SHA1, but none of them matched the original one from the 1.03.12 version I quoted earlier today.
 
Got it thanks. It's 1.03.13 official from Humax. I missed that when looking through the stuff I wrote in post #10.
 
The in-service/principal PVR was depowered for a couple of hours this morning during an abortive attempt to install our new TV. Tried to watch live TV over lunch but repeated freeze/re-start problems again - every couple of minutes picture would freeze while sound continued, then after about 15s re-start would occur. Is there anything worth looking at other than crash.log (attached) to determine cause? Seems to have settled down now (13:45). (No user interaction with PVR other than to select service after first start-up.)
 

Attachments

  • PVR warning 2.jpg
    PVR warning 2.jpg
    109.8 KB · Views: 13
  • PVR - crash log 2.jpg
    PVR - crash log 2.jpg
    204.4 KB · Views: 12
you could run diag crashdiag and post the results though I am not sure who is able to interpret the output
 
If it were my unit, I'll check the drive SMART again to see if attributes 5, 197-199 have increased.
Did you perform a SMART scan? Where the results ok?
Did you perform a file system check? What where the results?
 
If it were my unit, I'll check the drive SMART again to see if attributes 5, 197-199 have increased.
Did you perform a SMART scan? Where the results ok?
Did you perform a file system check? What where the results?
Current SMARTs 5, 197-199 exactly as reported in posts #4, #6.

Can I run a manual SMART scan in Maintenance mode? Not sure how the Disk Information and Attributes tables get populated - is it each time you choose Disk Diagnostics?

In post #4 (last sentence) I reported getting no results from a Maintenance mode short HDD test. Will try again in due course.

Bit confused about disk "tidy-up", "reformat", "filesystem check" (post #2), "fix-disk" (post #8) - don't want to risk losing recordings, etc. Fix-disk appears to have a very small - but finite - chance of losing recordings.
 
Not sure how the Disk Information and Attributes tables get populated - is it each time you choose Disk Diagnostics?
How else???!! Observe where it says "Local Time is". It's also polled from time to time inthe background, in order for WebIF to flag up warnings.

Fix-disk appears to have a very small - but finite - chance of losing recordings.
Only if the file system was corrupt anyway, in which case your recordings are lost but you just don't know it yet! What makes you say "appears"? Where is your evidence?

You've been around for quite a while, I appreciate you don't have personal experience of the CF, but if it was troublesome do you think we would be using it? Get stuck in.
 
What makes you say "appears"? Where is your evidence?

Get stuck in.
Evidence at post #8 (nobody else, I think, answered my question in post #4).

Happy to get stuck in where knowledge/experience level is high; however, a little knowledge is a dangerous thing! I'm treading carefully, given all the damage I might cause. But, a thought - can I use Macrium Reflect (8) to clone the HDD as insurance? I can use the HDD from our second spare PVR (having checked its SMARTs using CrystalDiskInfo) as destination. Will it then work in the principal PVR?
 
Evidence at post #8
What... you mean
in my experience the chances of losing any recordings are very small.
I didn't take issue with that because my interpretation of "very small" is not (unlike you) "finite" but "infinitesimal". So small as not to worry about it. Really. Just do it, you'll see how easy it is (and it could save you a heap of trouble).

Will it then work in the principal PVR?
I don't know. It depends whether the "clone" is of a file system or a raw disk - if Macrium Reflect relies on a Windows disk structure you're out of luck.
 
I haven't tried tidying-up the file system - does this risk losing recordings or schedule?
You've probably got as much chance of losing recordings doing this as you have turning the box off and on (in our collective experience).
The schedule is stored in flash, not on the disk.
I'm currently in Maintenance mode trying to run a short HDD test but results not forthcoming despite waiting >> "1 minutes".
You need to poll for the results after the advertised time. They won't suddenly appear out of the ether somehow. This involves either looking at the data in the Web Interface again or learning how to use the smartctl utility from the command line.
can I use Macrium Reflect (8) to clone the HDD as insurance?
If it understands Linux Ext3 filesystems then yes. But on a quick peruse it seems like a Windows tool using Windows methods, so who knows.
Will it then work in the principal PVR?
If it's a proper image copy then yes, and the disks need to be exactly the same size of course (or the target larger), unless whatever is doing the copy understands the filesystems and can do an intelligent copy.
 
Back
Top