Problem with ntfs-3g package on HDR FOX-T2 ?

ed209

New Member
I have a 1TB USB drive formatted NTFS connected to my HDR-T2.
I use the ntfs-3g package to allow me to write to this USB, and for a long time it worked well with no issues at all.
After upgrading the CF to the latest version, I started to get errors when I try to read / write from the USB

It works ok for maybe 15 minutes , and after that I get an "input/output error" when I access the drive.
If I dismount the drive and remount it , it works OK again for a short while.

The drive is fine. It checks out OK with a windows chkdsk. I also get the same problem with a second 1TB USB.

I downgraded the firmware to 1.03.12_mod_2.23 and did an RMA , and re-installed all the packages.
But the problem still exists...

So I upgraded to the latest version again and I am living with the problem on the latest firmware.

As a workaround, I have set up a cron job that checks the USB every 10 minutes.
If it detects a problem with it, it remounts the USB.
The 10 minute check script simply touches a file and checks for an error.
This has the effect of keeping the disk "alive", as it very rarely (if ever) has to perform a remount

It might be that the drive is going to sleep after a period of inactivity which is causing a problem.
But it did used to work, and would wake up/ spin up without any problems. I considered adjusting the sleep timeout on the disk but cannot find a way of doing this. The Seagate utility to adjust the timer does not work for this paricular drive.

I believe the problem is with the ntfs-3g package. The version available for the humax is 2013.1.13-2
This is not the latest version that can be found for other unix systems which I believe to be 2014.2.15

So I was wondering if anyone else has had the same problem.

Ideally I would like the latest version of the driver, but dont know how to acquire/build it for the humax.

Thanks in advance...
 
Regrettably xyz321 was originally responsible for the ntfs-3g package, and he doesn't seem to be around any more. Maybe af123 can take a look - but it works fine for me. What might be different about your drive?
 
The drive in question isn't a Seagate STBU1000200 is it (see here)? I have one and it has been a pain. It seems OK to read from, but copying to the drive (on the HDR-FOX) is sometimes unreliable: the copy may appear to have completed but the resulting file is unplayable. A similar issue has been reported on Mac computers and Seagate have issued a firmware update (here) but the firmware updater is for Mac only! I have given up with it and bought another WD. I have also had problems with a duff Seagate Pipeline (2TB, ST2000VM003) recently and am beginning to agree with Wallace :(
 
So I upgraded to the latest version again and I am living with the problem on the latest firmware.
This change in behaviour could be due to the new kernel that is installed with CFW 3. Perhaps it is implementing disk spin down or something similar (although if it is, it isn't an intentional change). When you downgraded to the previous version, did you install the official release first? If not then you would still have had the CFW 3 kernel. It would be worth trying official 1.03.12 followed by the 1.03.12_mod_2.23.
 
Regrettably xyz321 was originally responsible for the ntfs-3g package, and he doesn't seem to be around any more. Maybe af123 can take a look - but it works fine for me. What might be different about your drive?

You made me wonder if the problem might be the USB cable, but I've now tried several with no improvement.
 
The drive in question isn't a Seagate STBU1000200 is it

No it's not an STBU1000200, it's a Seagate 1tb st3100005exd101-rk
So far I haven't noticed any playback problems on the USB, but then I dont often try and play them back as I use the drive for incremental backups of the videos on the hard disk in the humax (I have my own script for this).
 
This change in behaviour could be due to the new kernel that is installed with CFW 3. Perhaps it is implementing disk spin down or something similar (although if it is, it isn't an intentional change). When you downgraded to the previous version, did you install the official release first? If not then you would still have had the CFW 3 kernel. It would be worth trying official 1.03.12 followed by the 1.03.12_mod_2.23.

When I downgraded, I *think* I installed the official release before applying the CF. But then again maybe I didn't. I'll downgrade again and make sure.
If I cant make the problem go away with a downgrade, I'll free up a spare USB drive and see if that is better.

Thanks to all who have offered suggestions, you are giving me hope!
 
The kernel version is displayed in the bottom right hand corner of the Web-If landing page. In Web-If>Diagnostics try doing a forced reinstall of the ntfs-3g package and see if this helps.
 
As I mentioned, I had some problems with a 1TB Seagate USB drive. Occasionally when copying over an mp4 file, the copy would appear OK but on attempting to play, this failed with a 'cannot support this file format' message. Repeating the file copy after a reboot always worked, giving a playable file: the initial copy was corrupted in some fashion. Occasionally too, although the drive still seemed to be mounted, the contents of the folders would disappear, but reappear after a reboot. I put a 1TB WD drive in its place and this was fine for several months. I recently upgraded to a new 2TB WD USB drive but this behaves just like the Seagate. Any ideas? The problem is intermittent, and is temporarily fixed by rebooting or by disconnecting and reconnecting the USB lead.
The new Web-If functionality allows a USB drive to be unmounted. Is there an easy way to get the HDR-FOX to rescan the USB ports afterwards? A proper fix would be nice, but rescanning would allow the fault to be recovered without rebooting the HDR-FOX or physically disconnecting and reconnecting the USB drive.
 
OK I've tested as much as I can now. Here's what I found

I did a "proper" downgrade by applying the official 1.03.12 followed by the custom 1.03.12_mod_2.23 and all is well. There are no problems with that Seagate USB.

So I went back to the official 1.03.12 and then retried 1.03.12_mod_3.00, and the problem returned.
I tried using a different USB drive and that is fine. The problem only happens on the two Seagate drives (Both drives are the same model)

So it looks to be a combination of this particular seagate drive and the change from mod_2.23 to mod_3.00.

So now I'm stuck. I could re-instate my cronjob to keep the usb alive and remount it if there is a problem.
Though I'll probably revert to 1.03.12_mod_2.23 just in case something is going wrong with writes to the ntfs drive that I haven't observed yet.

I'm happy to diagnose further if someone has any ideas on what to do next.
 
If it really is something to do with the CF version, I am confident in af123's ability to find and fix it.
 
I think my problems with the Seagate drive started before CFW3.0 was released, so perhaps my issue is different to the one reported by ed209? This could be a red herring, but I think the older 1TB WD drive (the one that works fine) uses standard format disks (I think there are 2 platters). The newer Seagate and WD drives have AF disks inside. Could this be an issue? Is the problem related to the USB disk controller firmware?
 
Hmm.. so it seems the problem occurs when you're using the custom kernel. Could be tricky to diagnose because the custom kernel is built from the source code and configuration files published by Humax in the open source section of their web site. However, the stock humax 1.03 kernel is definitely different from the source code they have published so there's no knowing what else they may have changed.

I will have a look at it but in the meantime, does the hdparm utility allow you to turn off drive spin-down?

Code:
humax# hdparm -S 0 /dev/sda

/dev/sda:
 setting standby to 0 (off)

(your external drive could be /dev/sdb rather than /dev/sda depending on whether it was connected during boot)
 
As mentioned by MontysEvilTwin:-

"The new Web-If functionality allows a USB drive to be unmounted. Is there an easy way to get the HDR-FOX to rescan the USB ports afterwards?

Is this something that could be added?
 
No it wont let me spin it down using hdparm

The device show up as /dev/sda1

humax# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 21824 21824 0 100% /
tmpfs 62508 100 62408 0% /tmp
tmpfs 62508 0 62508 0% /media
/dev/mtdblock1 2048 532 1516 26% /var/lib/humaxtv
/dev/mtdblock2 2048 456 1592 22% /var/lib/humaxtv_backup
/dev/sdb1 1035692 45840 937240 5% /mnt/hd1
/dev/sdb2 950070404 836947048 64862492 93% /mnt/hd2
/dev/sdb3 10325780 1325784 8475476 14% /mnt/hd3
/dev/sda1 976760000 844484904 132275096 86% /media/usb-drive1


I tried setting the timeout to zero

humax# hdparm -S 0 /dev/sda1

/dev/sda1:
setting standby to 0 (off)
HDIO_DRIVE_CMD(setidle) failed: Invalid argument
err_num = 22, err_str = Invalid argument


(With the same result on /dev/sda)

I unplugged the seagate and I tried the same on a toshiba 1Tb drive (which does not give this problem) and I got the same result.
 
Hmm.. so it seems the problem occurs when you're using the custom kernel. Could be tricky to diagnose because the custom kernel is built from the source code and configuration files published by Humax in the open source section of their web site. However, the stock humax 1.03 kernel is definitely different from the source code they have published so there's no knowing what else they may have changed.

This means Humax are in breach of the open source licence(s) that the kernel came with. They are required to publish all of their changes to the kernel. I know this because we are going through the same issue at work, writing user space drivers and other stuff to keep patented, security critical or just plain commercial property code out of the kernel.
 
I've now managed to change the timeout of those two seagate drives using "Seagate Dashboard"
With no timeout, so far I have not seen any problems. I dont get the error. I'll let it run for a few days just to make sure...

I also set a timeout of 3 minutes (default was 15 minutes), and "probed" the disk every 5 minutes to check the status.
It would ususally give the error (but not always). The frequency of the error has definitley increased a lot with this lower timeout.

So as suspected it's something about the timeout (and this particular seagate drive).
It could be the updated kernel, or the ntfs3g package or both. It is odd that I only see it on this drive.
It would be interesting to know if anyone out there would see this problem if they set a very low timeout (such as 3 minutes)
 
Last edited:
I've now managed to change the timeout of those two seagate drives using "Seagate Dashboard"
With no timeout, so far I have not seen any problems. I dont get the error. I'll let it run for a few days just to make sure...

I also set a timeout of 3 minutes (default was 15 minutes), and "probed" the disk every 5 minutes to check the status.
It would ususally give the error (but not always). The frequency of the error has definitley increased a lot with this lower timeout.

So as suspected it's something about the timeout (and this particular seagate drive).
It could be the updated kernel, or the ntfs3g package or both. It is odd that I only see it on this drive.
It would be interesting to know if anyone out there would see this problem if they set a very low timeout (such as 3 minutes)
Would you be up for trying a new custom kernel to see if it fixes this? If so, I'll send you a link when I have it built.
 
Back
Top