Prevent Bricking your S9! (Win, Linux, Mac)

[lane32x]

Originally Posted by nickrv8

i would love to be able to safely remove mine, but whenever i do i get an error saying that the device is in use no matter what, this only happens with my S9, never with my flash drives

I've got that on a few friends computers while using external hard drives. It seems to only happen on one USB port generally. Don't know why. Try a different port?

Also, make sure Caching is disabled in the Device Manager (or make sure it says Optimize for quick removal).

[gemi]

I can now count myself to the unlucky Linux users of a Cowon S9 32 GB. The bug hit me after one day of using it. I have to send it back, but I doubt that I can really use it again.

However I have two possible solutions in mind:

• There is a fuse implementation of fat at http://sourceforge.net/projects/libfat/ which may work better that the ordinary vfat.

• It also possible to use mtools. By defining a drive for the S9 device, for example m, one uses mcopy FILES m:MUSIC. This also has the benefit, that filesystem caches are not used.

I was not able to try these, since, as I said, my S9 is broken. However, on my Sony A818, the mtools variant works fine, as far as I can see.

I any case I find Cowon's attitude utterly reprehensible. There is not communication, no acknowledgement, no apology for such a fatal problem.

[Chokkan]

I just got my replacement the other day. Will be using Windows to do all s9 related stuff from now on.

[lane32x]

So I'm curious. What caused the bug in your case?
What steps did you take leading up to the corruption of your filesystem?
Also, what distribution of Linux were you running?

Since I have had no issues with any removable storage (including my s9) in linux I was just wondering.

Originally Posted by gemi

I can now count myself to the unlucky Linux users of a Cowon S9 32 GB. The bug hit me after one day of using it. I have to send it back, but I doubt that I can really use it again.

However I have two possible solutions in mind:

• There is a fuse implementation of fat at http://sourceforge.net/projects/libfat/ which may work better that the ordinary vfat.

• It also possible to use mtools. By defining a drive for the S9 device, for example m, one uses mcopy FILES m:MUSIC. This also has the benefit, that filesystem caches are not used.

I was not able to try these, since, as I said, my S9 is broken. However, on my Sony A818, the mtools variant works fine, as far as I can see.

I any case I find Cowon's attitude utterly reprehensible. There is not communication, no acknowledgement, no apology for such a fatal problem.

[gemi]

Originally Posted by lane32x

So I'm curious. What caused the bug in your case?
What steps did you take leading up to the corruption of your filesystem?
Also, what distribution of Linux were you running?

Since I have had no issues with any removable storage (including my s9) in linux I was just wondering.

The bug happened just like in other documented cases. I first copied some 15GB of FLAC and one AVI file to the player. Everything worked fine, and I could use it during the day. In the evening I added a bunch of FLAC files, then during copying there was an I/O error. After disconnecting, the player was bricked. It was only recognized as a USB device, but not as a mass storage device anymore.

Maybe it was the large amount of data copied in one session. Anyway, even if the filesystem becomes corrupted, the player should boot and offer to reformat the device. Even a Meizu M6 I owned, which is not really a high quality device, was able to recover after a botched operation.

I had no real problems with USB devices before (on Fedora 10). I have many USB devices in use, among them a mouse, a webcam, an external HD, cameras, a WACOM tablet, a Sennheiser headset. On one USB port, the Sony A818 kept connecting and disconnecting, but on another port, everything was fine. In no case was the Sony affected in its operation. Linux is NOT to blame in this case.

Even unplugging the device during writes should not result in it becoming bricked. In bad cases, the filesystem becomes slightly corrupt. In very bad cases, some crucial files cannot be read, but the device MUST recover from such a corruption. If it cannot, it is defective.

I exclusively use Linux, so I cannot (and do not want to) use Windows as a workaround.

I am getting really angry at Cowon, their support and quality control is mockery.

[Chokkan]

My situation was exactly the same. It's not as if every USB device, or even every Cowon device messes up like this. I use Archlinux.

[lane32x]

Originally Posted by gemi

The bug happened just like in other documented cases. I first copied some 15GB of FLAC and one AVI file to the player. Everything worked fine, and I could use it during the day. In the evening I added a bunch of FLAC files, then during copying there was an I/O error. After disconnecting, the player was bricked. It was only recognized as a USB device, but not as a mass storage device anymore.

Maybe it was the large amount of data copied in one session. Anyway, even if the filesystem becomes corrupted, the player should boot and offer to reformat the device. Even a Meizu M6 I owned, which is not really a high quality device, was able to recover after a botched operation.

I had no real problems with USB devices before (on Fedora 10). I have many USB devices in use, among them a mouse, a webcam, an external HD, cameras, a WACOM tablet, a Sennheiser headset. On one USB port, the Sony A818 kept connecting and disconnecting, but on another port, everything was fine. In no case was the Sony affected in its operation. Linux is NOT to blame in this case.

Even unplugging the device during writes should not result in it becoming bricked. In bad cases, the filesystem becomes slightly corrupt. In very bad cases, some crucial files cannot be read, but the device MUST recover from such a corruption. If it cannot, it is defective.

I exclusively use Linux, so I cannot (and do not want to) use Windows as a workaround.

I am getting really angry at Cowon, their support and quality control is mockery.

I agree with most everything you said. You are correct that linux is not to blame. And I actually wonder if the slow memory modules that they used in the S9 have anything to do with the problems people are experiencing... one thing that is definitely NOT correct:

Originally Posted by gemi

Even unplugging the device during writes should not result in it becoming bricked. In bad cases, the filesystem becomes slightly corrupt. In very bad cases, some crucial files cannot be read, but the device MUST recover from such a corruption. If it cannot, it is defective.

This has been proven false several times over with hard drives, jump drives, and digital cameras.

[gemi]

Originally Posted by lane32x

This has been proven false several times over with hard drives, jump drives, and digital cameras.

What I meant was, that in such a case, the firmware must a least be able to boot into a recovery mode that allows to reformat the memory, and not brick.

[gemi]

If speed or amount of data transferred is the problem, then one might try change the data transfer size. On the iAudio 7 mounted on /dev/sdi the settings are in /sys/block/sdi/queue. The value of max_sectors_kb is 120 and tells the size of data that is sent in one request. Lowering to something small such as 16 could possibly help. Is there someone adventurous enough to try it on his/her Cowon S9?

[slowburn]

To prevent bricking your S9, I understand you need to 'disconnect usb drive' via the taskbar in MSC mode, but how do you stop the device in MTP mode? The green checkmark doesn't appear in the taskbar?

[Houle_Marauder]

MTP mode is a whole different ballgame. just make sure that whatever program is using it has disconnected (if that's how the program works) and that it's done working on stuff. I've always felt that MTP mode is kinda shifty so I stay away from it. never really saw a reason to use it.

[JayCee]

Hey there!

I was about to buy a S9 when i read about its bricking tendency in an Amazon review [oddly, none of the reviews I read about it mentioned this bug].
So i wanted to know some more about this issue and did a bit of google-ing.

Now, as I understood it, many people bricked their S9s WHILE copying data to it, not after plugging it out.
Has anyone had such an expirience? And if yes, is tehre away to avoid that? [a lot of people said to not copy many GBs to it at once, but none were sure as to how many were too many, and if this is what causes the brick at all]

Darn, just as I thought I knew which player to buy! ^^

Best regards
JayCee

[lane32x]

The only instance I've heard of someone killing the s9 during a file transfer was when one of our own iAudiophile members accidentally pulled the cord out in the middle of a file transfer.

You won't get the "invalid resource" brick message until you have unplugged the s9 from the computer and turned the S9 back on. So I don't see how somebody could claim factually, without a doubt that the cause was during file transfer, and not when they forcibly pulled the s9's usb cable from the front ports.

It is a known problem with usb devices if you transfer a LOT of files (especially on slower memory modules like the s9 has), even after the file transfer dialog closes, the OS still accesses the drive for some reason, even when disk-caching is disabled.

oh. and I bricked mine the other day. I'm updating my first post right now.

[JayCee]

I based my question on this post [which I found in multiple forums] and people claiming teh same happend to them:

Here are the basic steps that cause and brick this device.
1. Started seeing i/o errors.
2. Umounted the device.
3. It was off so I turned it on.
4. Got the " No resources No Fonts" message.
5. Plugged it back into the USB.
6. Tried to delete the album that it i/o erred out on. Could not delete the directory. Error given was the directory was not there. You can see it, but the OS says it still isn't there.
7. Recopied the same album which fixed the direrctory problem.
8. At this point my only choice was to unplug from USB and turn back on. Device will not turn back on.
9. I do see OS logs saying it sees the drive when plugged in, but I can't get a drive to format. It just shows the device.

Now that I re-read it I'm puzzled... what is an i/o error? Seems I confused it with the "no resources..." error?

[OnYourMark]

edit: oops nvm this was asked and answered already. i wonder why it didn't show up in my search for MTP in this thread.

In MTP mode there is no safe remove in Windows. Is it ok to just disconnect it after file transfers and after closing everything?

edit: by the way, i don't usually have my player in MTP other than for scrobbling with last.fm.