External USB problem (nonsense!)

[devotee]

I have an external USB drive (1TB, iomega) and I suffer from the infamous "No Content Found" problem.

I've searched the forum, the wiki, read a lot about gparted, inodes, blocks and so on, but I still don't get it.

The drive is formatted as ext3, and it was formatted from a Linux system (I don't remember if it was Slackware or Ubuntu, sorry). The drive is detected and mounted by the device without problem:

Code:

EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with writeback data mode.

It's shown when I do a df:

Code:

root@iStarHD /root# df
Filesystem                Size      Used Available Use% Mounted on
/dev/hda1               247.0M    104.9M    142.1M  42% /mnt
/dev/hda3               916.2G    913.4G      2.8G 100% /opt/sybhttpd/localhost.drives/HARD_DISK
/dev/sda1               916.9G    767.6G    149.2G  84% /opt/sybhttpd/localhost.drives/USB_DRIVE_A-1

I can even browse all contents from the command line via ssh and midnight commander. What's more funny, I can copy a video file from the external USB drive to the internal disk, and that file will be found and played without problem from the GUI.

So, if the system detects the external drive, can see its contents, and even "work" with them flawlessly,... how comes I cannot browse its contents from the player GUI?

Just in case it helps, here is a detailed information on the filesystem:

Code:

root@iStarHD /root# tune2fs -l /dev/sda1
tune2fs 1.39 (29-May-2006)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          0782acb2-4e5c-4ecb-9304-a2b1ecd3283a
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal dir_index needs_recovery sparse_super large_file
Default mount options:    journal_data_writeback
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122109952
Block count:              244190000
Reserved block count:     0
Free blocks:              39123139
Free inodes:              121729690
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   512
Filesystem created:       Thu Dec 18 20:12:48 2008
Last mount time:          Thu Nov 26 04:22:49 2009
Last write time:          Thu Nov 26 04:22:49 2009
Mount count:              7
Maximum mount count:      33
Last checked:             Sun Aug 23 01:42:01 2009
Check interval:           15552000 (6 months)
Next check after:         Fri Feb 19 01:42:01 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      73546b70-01c4-4e5c-bd0e-d8c039b108b2
Journal backup:           inode blocks

Thanks in advance for any help/advice

[dh2005]

Which NMT do you have, mate? C-200...? A-110...?

[chris57]

First there is no infamous 'No Content' issue. That is an error message displayed for a variety of reasons, most frequently when having firewall/permissions errors when accessing via network shares.

What Iomega model is it, others may have it working as we see a lot of iomega users having problems and posting.

You are connecting via external power supply as well aren't you?

You have an istarhd I think?

[devotee]

(11-26-2009 05:18 AM)dh2005 Wrote:  Which NMT do you have, mate? C-200...? A-110...?

It's an iStar H6. If I'd known all the problems it was going to have regarding the NMT team/fimware, I'd have bought a Popcorn. Sigh.

In fact, I would like to buy the C200 in a near future

(11-26-2009 07:58 AM)chris57 Wrote:  First there is no infamous 'No Content' issue. That is an error message displayed for a variety of reasons, most frequently when having firewall/permissions errors when accessing via network shares.

No network here, it's an USB drive connected directly to the player's USB port. I used the word "infamous" because while searching I encountered many threads that seemed to describe the same symptons I have.

(11-26-2009 07:58 AM)chris57 Wrote:  What Iomega model is it, others may have it working as we see a lot of iomega users having problems and posting.

I'm not sure about the model, as it's not clear at all in the packaging. There's a label that reads "HDD 3.5 DRIVE DESKTOP CLASSIC 1TB", along with the serial number. Using Google I found a picture:

(11-26-2009 07:58 AM)chris57 Wrote:  You are connecting via external power supply as well aren't you?

Yes. In fact the drive works flawlessly if used from the command line. It's just the GUI that can't show the contents of that particular media source. I mean, I can use it normally if I access the player through SSH: I can list files, folders, move/copy them around,...

I also made some tests. One of them was copying a video file to the root folder of the drive. To my surprise, that file showed up when going to "Media source" > "USB_DRIVE_A-1" > "Videos". But it still refuses to show the folders. I tried to create a familiar structure ("Video", "Music", "Photo") without any success. Trough the GUI I can only see the files that are placed in the root folder.

Which, after a search in the forum, lead me to this thread: http://www.networkedmediatank.com/showth...?tid=26050

The solution proposed there is to repartition and format the disk using gparted. However, I still can't understand why everything works from the perspective of the underlying system (the kernel and the filesystem utils), but it doesn't when you use the NMT's GUI. Why do "ls", "du", "find",... see the folders and its contents, while the NMT's media browser don't?

Since I used the flag "dir_index" when I formatted the drive, I'm checking if by removing it (and clearing/rebuilding the directories with fsck -which is taking a loooooooong time-) the problem is solved. I still think it shouldn't make any difference (it doesn't make any difference to the base system, at least) but that's the only thing I can think of right now as a pausible problem.

BTW, thanks for your fast reply!

---

(11-26-2009 08:45 AM)devotee Wrote:  Since I used the flag "dir_index" when I formatted the drive, I'm checking if by removing it (and clearing/rebuilding the directories with fsck -which is taking a loooooooong time-) the problem is solved. I still think it shouldn't make any difference (it doesn't make any difference to the base system, at least) but that's the only thing I can think of right now as a pausible problem.

And no luck with that. Removed the dir_index flag with tune2fs (tune2fs -O ^dir_index) and rebuilded the directory tree (fsck -f -D). Nothing new: I still can see files placed in the root folder, but browsing using the NMT's GUI won't show the subfolders of the drive or its contents.

[chris57]

Any unusual characters in folder names? Spaces, apostrophe's, etc.

You definately have no hiddens partitions with any Iomega propritory software on it. You have completely flattened the HDD when formatting via ext.

Have you tried searching for 'Iomega' as there have been a few threads im sure, may be a bad sign and mean that there is a USB compatibility problem

[devotee]

(11-26-2009 10:03 AM)chris57 Wrote:  Any unusual characters in folder names? Spaces, apostrophe's, etc.

Nope, no special characters. In fact I tried one thing: I created three folders following the NMT "standards", "Video", "Music" and "Photos", and I moved all folders into "Video". Again, I got the "No content found" message. *But* if I copied any media file in the root folder of the hard drive, it would be shown in the media browser, no matter what type of file it is (video, music, or even an html file!), although the folders ("Video", "Music" and "Photos" are ommited).

Just in case it was a permissions issue, I ran a "chown -R nmt.nmt *" and a "chmod -R 777 *" in the folder drive, again without any change.

(11-26-2009 10:03 AM)chris57 Wrote:  You definately have no hiddens partitions with any Iomega propritory software on it. You have completely flattened the HDD when formatting via ext.

I completely destroyed the iomega's content previously to partition and format it (all operations done from Linux). When I buy a new disk I usually perform a destructive badblocks test on it, followed by short and extended SMART tests (if allowed since it's not always possible on USB external drives). The destructive badblocks test simply erases all the data from beginning to end, and after that I directly create a single partition (to avoid problems with multiple partition and some devices detecting only one of them) using the whole disk.

(11-26-2009 10:03 AM)chris57 Wrote:  Have you tried searching for 'Iomega' as there have been a few threads im sure, may be a bad sign and mean that there is a USB compatibility problem

The only problem I have encountered is that it's not always detected, it depends on when/how you plug it. Sometimes it gives a load of kernel errors, but I think it's because when you plug the USB drive, it has not properly spinned up when the kernel tries to identify the device.

It's not a USB compatibility problem since everything just works fine from the command line. It's really strange. If I access the device through ssh I can use the drive, and see al the contents, even mess with them (file operations like copy, move, create files and folders). It's just the NMT media browser ignoring the subfolders of the drive (not the files in the root folder). If it was a "big" problem with the disk (or the partition scheme of the drive), I'd have encountered problems when using the disk from the command line. That is what really puzzles me

Since I have to format a fresh 1.5TB drive I intend to use to archive movies, I'll try to partition it with fdisk to see if the problem happens again, and if it goes away by using gparted. But, again, I wouldn't understand why this happens since, from a (underlying) system point of view, the drive is there, the filesystem is there, and the files and folders are there too, so no problem handling the partition.

[seven47]

I have the same problem with my newly installed WD 1TB USB. First i format it to NTFS and then i saw everything on the drive but couldnt write to it thru the PCH. (Yes, i know, because of the none NTFS permissions) I tried the Lundmans 3gNTFS application but couldnt get it to work so i reformatted the drive to ext3 and now i get the "No Files Found" on the drive if i have my files in folders. If i have them in root of the drive then there no problem.

[devotee]

(11-28-2009 01:06 PM)seven47 Wrote:  i reformatted the drive to ext3 and now i get the "No Files Found" on the drive if i have my files in folders. If i have them in root of the drive then there no problem.

Thanks for your report, seven47 I was starting to think I was the only one experimenting this

Could you please tell us how did you format the drive to ext3? You did it from Windows, Linux? You used a Windows utility for that (Partition Magic) or a Linux one (fdisk, gparted)?

[seven47]

(11-28-2009 04:19 PM)devotee Wrote:  Thanks for your report, seven47 I was starting to think I was the only one experimenting this

Could you please tell us how did you format the drive to ext3? You did it from Windows, Linux? You used a Windows utility for that (Partition Magic) or a Linux one (fdisk, gparted)?

I used Partition Magic in windows. But its not something i recommend cus now i´ve lost 60GB. I will probably redo it later on when i see that everything works ok otherwise and then use some Linuxbased live cd.

[chris57]

Here's a guide on Ext formatting via Linux gparted:-
http://www.networkedmediatank.com/showth...?tid=26629

Always try to format to Ext in a Linux environment not with a Windows app. Long term the ext windows formatting causes problems.

[devotee]

(11-28-2009 07:32 PM)seven47 Wrote:  I used Partition Magic in windows. But its not something i recommend cus now i´ve lost 60GB. I will probably redo it later on when i see that everything works ok otherwise and then use some Linuxbased live cd.

Yes, I would follow chris57's suggestion and do the whole partitioning/formatting process from a Linux environment (an Ubuntu live CD should work).

Regarding the 60GB, I don't think you lost them. Ext3 usually reserves some space in the filesystem for the root user (so it doesn't get filled by user data, and the root user always has some free space to use -system logs, incoming mail,administration tasks...-). The default is 10% (AFAIR), but you can find cases where the default is 1% or 5%. On you 1TB drive, a 5% would mean 50GB reserved for the root user. Add the space used by the filesystem internally (inode table, journaling, etc) and you can easily end up with 60GB that, apparently, have 'disappeared'.

From Linux you can 'recall' that reserved space by doing a 'tune2fs -m 0 /dev/sdaX' (where sdaX is the identifier of the drive and partition you want to modify). The rest of space is used internally by the filesystem, and it's not recaoverable, though you can minimize it playing the filesystem formatting options (number of inodes, 'sparse_super' and 'largefile' attributes, ...). However, I don't know right now if modifying these features would lead to the same "No content found" problem.

[devotee]

I've just done some tests with the 1.5TB drive:

On Slackware 12.1.0, using fdisk to create the partition.

Code:

# fdisk -l /dev/sda

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x2d71df2a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      182401  1465136001   83  Linux

Ext3 with default values (except for the reserved blocks):

Code:

# mke2fs -j -m 0 /dev/sda1
mke2fs 1.40.8 (13-Mar-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
91578368 inodes, 366284000 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

# tune2fs -l /dev/sda1
This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@bender:/home/shares/almacen# tune2fs -l /dev/sda1|less
tune2fs 1.40.8 (13-Mar-2008)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          adba1574-8752-4661-896c-c296b546165e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284000
Reserved block count:     0
Free blocks:              360485711
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Mon Nov 30 12:21:00 2009
Last mount time:          n/a
Last write time:          Mon Nov 30 12:40:54 2009
Mount count:              0
Maximum mount count:      36
Last checked:             Mon Nov 30 12:21:00 2009
Check interval:           15552000 (6 months)
Next check after:         Sat May 29 13:21:00 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      e3c3fc7e-1598-46c6-ac67-617e193228cc
Journal backup:           inode blocks

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            1442145212    202368 1441942844   1% /mnt/usb
root@bender:/home/shares/almacen# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             1.4T  198M  1.4T   1% /mnt/usb

I created three folders (Music, Photos, Video) and copied several folders which contained media files. BROWSING WORKS. Tried the other external USB drive and, again, I can only see the files stored in the root folder.

I can see several differences using tune2fs on both drives, I would say that the problem comes from one of these subtle differences but again, why does it work perfectly through the command line?

On the other hand, I tried to format the 1.5TB drive again changing some options to see if I could have even more free space.

From a point of view of the inode count, if we're using BIG media files, like divx, mkv, or even DVD or BD dumps, you don't need so many inodes. There's no need to reserve 91578368 inodes when you'll be only able to store a few thousand files (1 file/folder = 1 inode). Let's say I store 1400MB divx files on that drive, that would mean around 1100 files. If I store each media file in a subfolder (Video/This.Picture.(AC3).[English]/), and I also like to put in a jpeg of the cover and a text file with the imdb info (plot summary and such), we're talking of 4/5 files per movie. Let's reserve 10000 inodes, which will be more than enough to hold all the files:

Code:

# mke2fs -j -m 0 -N 10000 /dev/sda1
mke2fs 1.40.8 (13-Mar-2008)
Warning: 256-byte inodes not usable on older systems
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
178864 inodes, 366284000 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
11179 block groups
32768 blocks per group, 32768 fragments per group
16 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1            1464995088    202368 1464792720   1% /mnt/usb

As you might see, it didn't allow to use only 10000 inodes, as the minimum should be 178864 inodes (check the mke2fs manual for more info on this). To summarize, I will be able to store 178864 files/folders in the drive, and I just saved like 20GB. It's not such a big deal on a 1.5TB drive, but it still some room for media files

Still no luck with the 1TB iomega drive, I guess the only solution will be to reformat it again, or try to fix the subtle differences in the ext3 parameters shown with tune2fs so they match both drives as much as possible

---

OK, got it fixed...

On a Linux system (didn't try it on the iStar):

Code:

# tune2fs -O filetype,dir_index /dev/sda1

Followed by a

Code:

e2fsck -fD /dev/sda1

Now I see all the contents of the drive including folders.

I've stumbled upon a totally different and funny problem. When I plug the USB disk, the iStar either shuts the video output off (I can recover it killing and relaunching the gaya process) or it reboots. It seems that it does some kind a shortcut somewhere, as both green and orange leds of the ethernet port (which has no cable plugged) flash briefly as the iStar goes "boom".

I definitely should get a Popcorn...

Anyway, if you have this kind of problem ("No content found") on an external USB disk formatted as ext3, the previous solution seemed to fix it.

[chris57]

Do you have a firmware on the USB stick in the ROOT as I remember this happening to others, think it was firmware but check what else you have on the USB stick.

During boot the NMT will look to USB first as part of the recovery firmware procedure.