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

Start Up Fails When HDD Connected

Initially I was assuming that the Linux I was using was not completely compatible with the Humax disk layout as I was having problems running smartctl, fsck etc but I now think it was because the disk is so messed up. What I did see is that the files are all still there on the My Video partition under Linux and also at the O/S level when mounted via a USB dock on the Humax. However the Humax system itself sees nothing and says the disk has 0 bytes used. I don't want to do anymore attempted disk repairs until I've attempted recovery.

So the follow up question. What is the best/correct way to transfer files in this situation.
I can't recover them on the Linux machine because of the encryption - the transferred files are unplayable.

Connected via USB on my main machines old drive I have tried copying a few progs .ts, .hmt, .thm & .nts etc via the Telnet CLI and they are playable - some may possibly not be playable because of disk corruption or have errors but it is a 2Tbyte disk and there is some stuff I would like to try to recover.

However, is this going to upset the Humax because I am copying progs outside of its control. ( I don't know how it maintains it's catalog of progs) The webif offers copy capability but very slow - the disk seems especially slow anyway but in reality this probably just does a file system copy anyway.

I assume the disk copy via the CLI works on the Humax because it is somehow correctly maintaining the file encryption?!?!

I have transferred files in the past between new and old disks but can't remember how now. I think I did it via USB but with a disk recognised by the Humax so I used it's menu system to copy the files completely under it's control (not an option at the moment with this disk).

John.
 
I can't recover them on the Linux machine because of the encryption - the transferred files are unplayable.
The fact that the files are encrypted isn't a problem, once copied to a computer the files can either be decrypted on the computer or transferred back to the original Humax's new hard disk where they will be decrypted
 
Decryption happens automatically when copying to USB storage using the on-screen menu (ie settop program) or from an HDR when indexed encrypted content is accessed via DLNA. Obviously one interaction between encryption and disk errors is that an error is propagated across the entire encrypted block, depending on the encryption algorithm and the physical disk sector size.

You could try to recover the files first and then see if they can be decrypted (+1 to @EP's post above). A tool like ddrescue (there's a GUI too) may be able to copy your content from a bad disk. The stripts utility can be run on a (suitably old) Linux to decrypt, or check the decryptability, of recovered files. As ddrescue tries to copy a file, if it succeeds in reading a dodgy sector and a spare good sector is available in its internal replacement list, the SMART firmware will automatically "repair" the sector by patching in the spare.

If you think the physical disk is really about to croak (say, it only spun up after being left in the freezer) and have enough room on some other enormous disk, you could use dd with conv=noerror to copy an image of the bad disk and work on that with ddrescue.

You could then try to repair the physical disk. If any precious content has been recovered, ATA security erase should be the quickest way. Formatting with mkfs may work but operates at a higher level and could be very slow in the presence of physical errors.
 
What I did see is that the files are all still there on the My Video partition under Linux
In which case you can use your Linux system to copy them somewhere else. Each individual recording will comprise a set of several files: .TS, .HMT, .NTS and (probably) .THM – make sure you copy at least the .TS .HMT and .NTS.

I can't recover them on the Linux machine because of the encryption - the transferred files are unplayable.
That doesn't matter.

is this going to upset the Humax because I am copying progs outside of its control.
No, just keep the files together.

I assume the disk copy via the CLI works on the Humax because it is somehow correctly maintaining the file encryption?!?!
If the recording is encrypted it can only be played on the originating HDR-FOX, and only if the .HMT is intact. You can move stuff around as you like, it's just a question of playing it.

I have transferred files in the past between new and old disks but can't remember how now.
It doesn't matter how, it's the player that matters (not the process of moving).

All that said, transferring to or from USB using the Humax menus also decrypts the recording (so long as it is StDef, or a HiDef recording which has been "unprotected"). You can also use a program written for Linux (also Windows) to decrypt HDR-FOX / HD-FOX recordings.
 
Last edited:
Thank you all for the above advice and information. It had never occured to me that the copied file was actually intact with it's encryption (I just had never tried copying an encrypted file and then decrypting it) - I had just assumed it was gibberish. Understand about keeping the 4 files together.

I am having some luck at the moment copying via USB and the CLI - a few errors e.g. "cp: can't stat 'Castle/S5/Castle_20161004_1459.ts': Input/output error"

I haven't yet done retries to see if the reading has forced a re-mapping. Once I've worked through this I'll work through some of the other suggestions.

I haven't been nursing it so can't be sure but I haven't heard any bad mechanical noises coming from the disk and it spins up OK without issues.

It is 'odd' or of course coincidence that the two machines with the very bad 4u7 caps have also both had disk issues/failures. Has anyone else reported similar? I can't say what was going on with the 12V rail on the boot loop machine before the caps were replaced but it wouldn't have been good if it was repeatedly losing it mid HDD writes. The other machine with Seagate drive which I thought was 6 years old was actually newer because the original developed faults within warranty and was replaced by Seagate with a "Certified Repaired HDD".

Update : Hmmmm..... I just checked the copy progress and the picture is frozen on the Humax and no activity on the USB disk drive and lost telnet connection. Will have to go for a reboot.
When connecting this disk direct (not via USB) to a Linux machine and testing it I did have issues where it would stop responding and the system would lose the device. When running smartctl long it would at random points start reporting every block read as failed until Linux was rebooted.

I've now been summoned by the Missus for a late dinner so will probably have to wait till tomorrow for further investigation. If I can find a big drive the copy image is sounding a good option before the problem worsens. Just before I am going to leave it doing a fix-disk just to make sure no disk errors have been introduced.
 
This is sort of linked but let me know if you would prefer a new thread.

I am starting to notice things I may have already known but subconsciously ignored.

My machines had the faulty 4u7 caps causing one to constantly reboot. This and another machine both had failing hard drives which seem to be failing prematurely to me.

I have long had the latest CF installed including SYSMON so have seen the temperature graphs. Because of the HDD failures I looked more closely at this and see that the temperatures oscillate between 50C and 55C. This seems far too high to me - if I saw this in my PC hard drives I would be worried. (I know these are AV type drives designed for prolonged usage.) Humax obviously decided these temps were OK. This is the temp when idle i.e. not actively recording so would expect this to be higher if you are working the drive harder - 2 recdordings plus TSR.

I then noticed someone has written 2 packages - fan and tempmon. I installed these and have been using fan to run at 100% with the drive temps coming down to about 32C idle.

Interestingly tempmon with defaults constantly alerted as the alert temp defaults to 50c.

In one machine I tried just by touch, others of the SMD caps feel warm especially near the HDD enclosure. Either that is because like the 4u7 cap these may need replacing or they are just being cooked because the HDD heat is not being removed from the case. Time permitting I will stick a temp probe on various caps to get a better idea of what is going on.

I have now throttled back the fans to 70% which gives about 35C. I do not find the fan noise a problem so will probably leave it on constant. (Of course next thing is the fans will now fail and cook the HDD anyway :) )

P.S. I spotted by chance when the temp was at 55C, the original Seagate drive in diagnostics was show as failing - Ok when temp reduced.
 
Last edited:
P.S. I spotted by chance when the temp was at 55C, the original Seagate drive in diagnostics was show as failing - Ok when temp reduced.
If you are referring to the HDD diagnostics line 190 this is not telling you that there is a failure, it is simply telling you that the threshold at which the fan turns on (55 Dec C), has been reached - Yes, I know that misleading, but that's the way it is, every single Humax HDR Fox T2 running the standard software does this, it is normal operation
 
I then noticed someone has written 2 packages - fan and tempmon
Have you really not looked at the catalogue of packages to see what might be useful and appropriate to install?



Many users set the fan to 40% (using the fan package) – this provides a minimum, but can go up as a result of the normal Humax thermostatic control when warranted. 40% is a compromise of cooling v. noise, and is usually sufficient. You're not so much looking for the minimum possible HDD temperature as a stable HDD temperature.
 
If you are referring to the HDD diagnostics line 190 this is not telling you that there is a failure, it is simply telling you that the threshold at which the fan turns on (55 Dec C), has been reached - Yes, I know that misleading, but that's the way it is, every single Humax HDR Fox T2 running the standard software does this, it is normal operation
Ah, OK thanks. It was line 190 - the newer disks do not have this line so perhaps won't get reported? I assumed wrongly it was getting this from smartctl. (i.e.
194Temperature_Celsius-O---K33100100000
 
Have you really not looked at the catalogue of packages to see what might be useful and appropriate to install?



Many users set the fan to 40% (using the fan package) – this provides a minimum, but can go up as a result of the normal Humax thermostatic control when warranted. 40% is a compromise of cooling v. noise, and is usually sufficient. You're not so much looking for the minimum possible HDD temperature as a stable HDD temperature.
Indeed I have looked in the past and have a number installed including as I said SYSMON which is not standard and fix-disk, disable-ota, disable-dso, zeroconf etc etc. However, I probably fall into the category of people who only look in depth to find a solution to a problem they have. (My quote : I am starting to notice things I may have already known but subconsciously ignored.) I had not perceived that temperature was a concern in the past foolishly assuming that the Humax was doing a good job on it's own so hadn't looked for a solution. [Shame I could probably have saved myself a few HDDs]

I'm still doing it now. Your quote : "but can go up as a result of the normal Humax thermostatic control when warranted" Re-reading the CF package notes now - "If the Humax requests a higher speed setting, this higher speed will be used" - so the package does not take full control and disable the Humax control and if I set it to 40% then if required the Humax will still take over and raise the fan speed higher. Reading that yesterday at 3am I missed that nuance and was concerned that if I installed the package I had to set a suitable value because it would then be fixed permanently at that level.

That is what is so great about this forum that you can get help from people who know all this stuff in more detail than I will ever have the time to achieve myself. I can also imagine that comes with a level of frustration when you have to explain something to the 1000th person to ask the same stupid question :)
 
I can also imagine that comes with a level of frustration when you have to explain something to the 1000th person to ask the same stupid question :)
As the dog says: oh yesh.

That's exactly why the wiki and my encyclopaedic posts have been written. The rarely understood problem with answering the same questions over and over again is that, with the best will in the world, answers given will vary – even when answered by the same person. Sometimes this will be an improvement on a previous answer (the situation might have changed), sometimes worse, and sometimes downright misinformation. All of those variations are then available for others to read and become confused by. Not to mention the time invested in writing them.

It is far better to invest the time in a single resource, and then (when necessary) direct people at it, but then they tend to find it overwhelming, particularly people not used to reading technical documents (and let's face it, in this age of social media, attention span is declining rapidly), and still need guidance. Sigh.

The vast majority of questions, from what's best for the newcomer to install to why a newcomer can't post a URL and how to fix a HDR-FOX, are answered in the links in my signature panel.
 
It is also confusing and doesn't help when threads go completely off topic - like this one has for the last 10 posts or so. :dunno:
 
It is also confusing and doesn't help when threads go completely off topic
I agree it's not the best with regard to finding information later, but "confusing"? I think not (unless people can't be bothered with niceties like following a conversation, that is).
 
Well - I had the constant restart and so unplugged the hard drive and it stopped restarting and went into wizard mode - so I got some 4.7uf capacitors and then tried fitting it!!!!!!! - My skills are lacking - managed to pull off the solder pads and part of the lines to other components :(.

I decided to buy a new unit - so will be up and running again soon. However I hate waste and as I have some electronic bits knocking around I plan to try again.
I want to remove the resistor on the right of the capacitor to give me more to solder to. But can not see the value of it - is it the 10K ohm shown in the wiring diagram shown on the hardware fix page?

Thanks
Will let you know if I can bodge it 👷‍♂️
 
My skills are lacking - managed to pull off the solder pads and part of the lines to other components :(.
I'm sure I said it somewhere: you needed to cut the legs off the capacitor in-situ rather than trying to desolder it.

I want to remove the resistor on the right of the capacitor to give me more to solder to. But can not see the value of it - is it the 10K ohm shown in the wiring diagram shown on the hardware fix page
Judging by the visible copper, yes.
 
I want to remove the resistor on the right of the capacitor to give me more to solder to. But can not see the value of it - is it the 10K ohm shown in the wiring diagram shown on the hardware fix page?
Correct - the component immediately to the right of the 4u7 cap is the 10k resistor shown in parallel with it in the circuit diagram. I measured the three resistors of interest with a DMM when determining the circuit (see post #91). But beware! These are ant-sized components and can easily come adrift once heat is applied - and you may never see them again!

Sadly, you are probably facing a bigger challenge now than the original one of snipping-out the dud cap and soldering in a new one. Even with some 50 years' experience with a soldering iron I nearly lifted one of the cap's pads by desoldering it rather than snipping it (the latter risks gouging the board, even with the correct tool).

Pics attached showing the board after I'd removed the cap and the Mosfet (U24) I blew up; the lengths I went to to locate the - relatively large - NPN bipolar driver transistor when soldering this back in (that's a cocktail stick); my original drawing of the circuit. Plenty of light is another top-tip. Good luck - I think you'll need it!

Finally, as was the case with our PVR last year, expect more reports of this issue once the colder weather arrives.
 

Attachments

  • PVR 1 cap + U24 removed.JPG
    PVR 1 cap + U24 removed.JPG
    324.5 KB · Views: 62
  • PVR 1 locating transplanted 2N4401.JPG
    PVR 1 locating transplanted 2N4401.JPG
    332.7 KB · Views: 61
  • HDD 12V switch schematic.JPG
    HDD 12V switch schematic.JPG
    322.6 KB · Views: 61
Thanks for your replies. So gave it another go today.

My soldering sucks but I got it working 🤓

Due to damaging the board I had to replace the 10k and 1k resistors as well as the capacitor. I was able to use the wiring diagram and some continuity tests to trace the connections.

Attached is the mess I made, but if it works don't knock it 🤣

PS going by the copper trace the 1k resistor is connected to the negative leg of the capacitor. My electronic experience means I'm not sure if the wiring diagram is quite right??
IMG_20220810_113552~2.jpg
 
Attached is the mess I made, but if it works don't knock it 🤣

PS going by the copper trace the 1k resistor is connected to the negative leg of the capacitor. My electronic experience means I'm not sure if the wiring diagram is quite right??
Well done for sticking with it and getting the PVR going again; even if your soldering isn't, your tenacity is impressive! Might be worth applying a few strategically-placed blobs of Araldite for mechanical stability/to prevent possible shorts. Looks like the cap is the correct way round with the negative plate (the single line of the component's symbol) uppermost with the 1k resistor connected to it - which is in accordance with the circuit diagram. The 1k resistor is there to limit the cap's charging current through the driver transistor when the latter turns on. The silk screen "+" on the PCB indicates the centre of the cap's footprint to aid automatic component placement during manufacture (rather than cap polarity).
 
Back
Top