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

Humax won't recognise external portable 160GB Hard Disk

Black Hole said:
I think wolfmanii implied he does not have the custom software installed.
Click to expand...
I realised that, that's why I suggested he run it on the Linux box.

Fraser Cavanagh said:
I have exactly the same problem. An 250GB NTFS formatted IDE drive in a USD caddy. Humax does not see it but does notice a usb being disconnected. I am ruuning the latest version of the custom firmware with ntfs-3g installed. lsusb and fdisk show nothing. Any help would be usful.
Click to expand...
At the risk of upsetting BlackHole, 'lsusb' doesn't seem to produce any output on the Custom Firmware.

Try 'cat /proc/bus/usb/devices' instead.
 
Upsetting me? Not at all. I was pointing out that no amount of "try this, try that" will get anywhere if the drive caddy is unsupported in the Humax firmware.

I'm happy to be proved wrong by the pioneering spirit.
 
I have a Buffalo 250GB mains-powered drive that works perfectly if plugged in after the Hummy is booted but stops the Hummy from booting if plugged in first. I regard it as one of life's little mysteries.
 
Ok, lsusb returns nothing.
fdisk -l Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 131 1052256+ 83 Linux
/dev/sda2 132 120295 965217330 83 Linux
/dev/sda3 120296 121601 10490445 83 Linux
When I think has not detected the external usb disk.

humax# cat /proc/bus/usb/device
-/bin/sh: cat: not found

do I need to install anything else for cat to work?

I hope this is of use.
 
cat not working is usually symptom of installing the custom firmware on a FAT32 filesystem.. it's part of the busybox package, as is lsusb so if you have one then you should have the other.
 
I had thought of that, but dismissed it because all the runes say HDR-FOX and therefore the custom software should be on the internal drive. What gives?
 
I think the cat /proc/bus/usb/device problem is a red herring. There should have been s on the end of device.
So cat /proc/bus/usb/devices gives

humax# cat /proc/bus/usb/devices

T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.18-7.1 ohci_hcd
S: Product=BRCM OHCI
S: SerialNumber=ohci-brcm
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.18-7.1 ohci_hcd
S: Product=BRCM OHCI
S: SerialNumber=ohci-brcm
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms

T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.18-7.1 ehci_hcd
S: Product=BRCM EHCI
S: SerialNumber=ehci-brcm
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms

T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.06
S: Manufacturer=Linux 2.6.18-7.1 ehci_hcd
S: Product=BRCM EHCI
S: SerialNumber=ehci-brcm
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=14cd ProdID=6600 Rev= 2.01
S: Manufacturer=Super Top
S: Product=USB 2.0 IDE DEVICE
S: SerialNumber=??????????
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
humax#
 
So it seems to be recognised by the driver but it is strange that it does not appear in the fdisk output.

Did you format the disk to NTFS or did it come preformatted?

Can you hear the disk spinning when connected to the Humax or is it the case that it starts in power save mode and never wakes up?

Could you try:

Code: 
fdisk /dev/sdb
p
q
This should print the partition table as above but it might also give an error message if it can't find the disk.
 
Tried the fdisk command below

humax# fdisk /dev/sdbfdisk
fdisk: can't open /dev/sdbfdisk

What did the p q mean in that posting?

I have connected this disk to a Ubuntu PC and inspected the usb drive via GPARTED. It seemed to be OK, no errors reported. Single paritions ntfs formatted. I have data on this disk that I don't want to lose so don't want to reformat. I will try fitting another disk that I can reformat and try various options (eg ext2, fat32 and ntfs). Happy to try any other suggestions.
 
Fraser Cavanagh said:
Tried the fdisk command below

humax# fdisk /dev/sdbfdisk
fdisk: can't open /dev/sdbfdisk

What did the p q mean in that posting?
Click to expand...
As Martin says it should be /dev/sdb. If it can't find the disk you will probably see the same result. If it can access the disk you will be left at the "Command (m for help):" prompt. If you type 'p' it will display (Print) the partition table and type 'q' to quit.

Try bringing up the "Device Information panel" within gparted. I can't run it at the moment and can't remember the exact menu option. It should show the "Partition table" as "msdos" but it may be "gpt" or some other type.
 
Hopefully without the finger trouble

humax# fdisk /dev/sdb

The number of cylinders for this disk is set to 121601.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help):
Command (m for help): p

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 131 1052256+ 83 Linux
/dev/sdb2 132 120295 965217330 83 Linux
/dev/sdb3 120296 121601 10490445 83 Linux

However when I swapped the USB IDE drive for a FAT32 memory stick the above command didn't print anything extra out.
The FAT32 1GB memory stick is seen by the Hummy and cat /proc/bus/usb/device gives

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1221 ProdID=3234 Rev= 0.00
S: Manufacturer=USB2.0
S: Product=Flash Disk
S: SerialNumber=2009090821340375
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I have another IDE disk I can put in the caddy ans try out different formats
 
It seems the internal drive is now /dev/sdb. The drive letters have swapped over - it usually depends on whether the system is powered up with the drive already connected. If a USB drive is connected at power up the Humax will find it first and allocate the device name /dev/sda, then it will look for the internal drive. If the drive wasn't connected when the box was booted up then the internal drive would be /dev/sda and the USB drive /dev/sdb etc.

Did you quit fdisk before changing to the memory stick, if not it may have allocated the next free device /dev/sdc.
 
Yet more corrections, the USB stick is NTFS formatted. Also the fdisk command should be fdisk /dev/sdb for the usb port on the rear.
With the this 1GB USB NTFS memory stick inserted I get

Disk /dev/sda: 997 MB, 997195776 bytes
61 heads, 3 sectors/track, 10642 cylinders
Units = cylinders of 183 * 512 = 93696 bytes

Device Boot Start End Blocks Id System
/dev/sda1 12 10643 972800 7 HPFS/NTFS

humax# cat /proc/bus/usb/devices

gives the last block as
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1221 ProdID=3234 Rev= 0.00
S: Manufacturer=USB2.0
S: Product=Flash Disk
S: SerialNumber=2009090821340375
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Using the USB to IDE caddy I have with a newly partitioned (ms-dos table) 80GB disk formatted with NTFS via gparted
humax# fdisk /dev/sda
fdisk: can't read from /dev/sda
humax# cat /proc/bus/usb/devices
gives the last block as
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=14cd ProdID=6600 Rev= 2.01
S: Manufacturer=Super Top
S: Product=USB 2.0 IDE DEVICE
S: SerialNumber=??????????
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Just to see what happens, I tried
humax# fdisk /dev/sdc
fdisk: can't open /dev/sdc
Reformatted the drive to ext2
humax# fdisk /dev/sda
fdisk: can't read from /dev/sda

Reformatted the drive to ext3
humax# fdisk /dev/sda
fdisk: can't read from /dev/sda
Reformatted the drive to FAT32
humax# fdisk /dev/sda
fdisk: can't read from /dev/sda
Not really a surprise but disk format is not the issue. Must be the USB to IDE interface that the humax does not like.
 
I think THIS could be the problem although it is difficult to verify without any kernel logging. Unfortunately we are not able to fix it at the moment.
 
You must log in or register to reply here.
Back
Top