I sent iRiver's customer support a file which causes troubles in my device, but answered me that they couldn't reproduce the problem. I find it really weird, maybe it is in fact a hardware problem (though I don't think so). Here I attach the same file and ask someone to try to reproduce the problem too. This are the steps:

Don't see an attachment, but taking any PDF file and giving it that name (including the folders), causes the loop for me.

It's not a hardware issue. You can send the device back but it won't help you, best case you'll be without your reader for a couple weeks, worst case they claim the display is broken or whatever ... better not risk it, esp. considering the workaround is so easy (just pick a shorter name)

EDIT:
This time around the loop came back even after deleting the offending path on the SD card. Had to delete system/bookDB* on the internal memory to get rid of it

Don't see an attachment, but taking any PDF file and giving it that name (including the folders), causes the loop for me.

Sorry, forgot to attach it. I just did.

Quote:

Originally Posted by frostschutz

It's not a hardware issue. You can send the device back but it won't help you, best case you'll be without your reader for a couple weeks, worst case they claim the display is broken or whatever ... better not risk it, esp. considering the workaround is so easy (just pick a shorter name)

I totally agree with you. I don't have the intention to send it, but to get a fix. It's so strange that they cannot reproduce it, I don't understand the reason.

You're right about the simplicity of the workaround, but I haven't found a way to automatically identify and shorten the longnamed files. Considering that only in the folder of my studies I have more that 25.000 files, it would be a pain in the a** to manually find them. Maybe I should focus my energy in finding a way to automatize that job instead of getting a fix from iRiver. By the way, I'm a Linux user.

EDIT:
This time around the loop came back even after deleting the offending path on the SD card. Had to delete system/bookDB* on the internal memory to get rid of it

So, it's the exact same problem. It *must* be caused by software.

Quote:

They're probably not putting the folders on the reader. Who knows.

Listing too long names in Linux, for example assuming that 200 is too long:

Code:

cd /mnt/SDCARD # or where ever you mounted it
find | grep -E .{200}

If you have long folder names also, best to abbreviate those first as that makes paths for all files inside shorter in one go.

You're the man!

PS: took a while (I had about 45 files over 200 characters), but now my Story HD works wonderfully and tolerates as many files as my 32GB card can handle. So the problem is not really solved, but a good and simple workaround was found.

My trouble was that when I changed the SD card to another one the new SD card would not load, neither would the original one when I put it back in.
I have discovered that after I remove an SD card with the unit turned off it is then necessary to turn the unit on and off before putting a different SD card in. The different SD card then loads fine. - No big drama but is that normal?

Spot on Frostschutz - it was only in the sleep mode. I use it so often that I had forgotten it has a complete off as well. Actually though, I have now found that it is much quicker to change SD cards in the sleep mode with a quick turn on and off in between than to power right off and then have to wait while it re-boots.

Although the card is mounted in read-write mode, the device only ever reads. For the filesystem to go corrupt, you'd have to write. But even then, FAT usually doesn't break all the way but just has the newly written files defective or missing.

Just tested if the Story HD as a card reader (i.e. hooked up to USB) detects medium changes: close but no cigar. The capacity change shows up but the PC can still get confused regarding the currently mounted filesystem. In Linux, changing the card while mounted resulted in this:

Eeeh, yup. And that's where it gets dangerous. It thinks it's got the old card mounted but reads data from the new card, write anything to it now and the data on the new card will be seriously damaged.

So don't switch SD cards with the Story HD hooked to USB while the filesystem is mounted. Umount (Windows calls it eject I think) the device properly first.

Without USB connection you can switch SD cards any time you like. If you do it while reading a book it'll kick you out of the book though.