Rockbox

This was reported recently as well. Obviously not a problem with recording at all since this was before the first big update on August 28, 2006. A bug in the file APIs (or a layer below it) must be to blame since it shouldn't even be possible to keep writing data if the disk is full. I'm trying to link to the recent incident now but can't seem to find it now. argh.

file.c does some strange things on line 539: I'm not sure it would always return an error on disk full.

actually.. it looks ok... if an error occurred but some bytes were written, it will report the number of bytes written, and not the error...

external report (does however smell like it is a hardware problem)
http://taperssection.com/index.php?topic=87758.0

first try at having it at least write the header on failure.
There is still an issue: after rebooting, the file becomes 0 bytes.
This seems to be an issue with a failing flush of data not closing the file properly (in file.c)

(partial fix, work in progress: only changes wav_enc, not mp3,...)

work in progress: no more corrupt disk or recording, but the fat_flush code now does a panic....

EDIT: have only had the panic once -> to be tested!

Also still only implemented for WAV

almost final version. Anybody care to test?

it has given me three PANICs so far at the end of a recording with disc full

apart from the panics (which just require a reboot) the recorded file is fine and the FAT is not corrupted (except for the free cluster count)

hmmm several tests caused chkdsk to complain the file is reported too big (4096 bytes or one cluster)

we're not there yet

EDIT: not failing any more right now. Anybody else testing?

adds extra checks in file.c for validness of filepointer

This is (unfortunately) not fixed.
See http://forums.rockbox.org/index.php?topic=12500.msg99879#msg99879 for more detail.

Since this affects all targets and is a filesystem bug (according to some devs) I believe this is a high priority bug.
It is also the last bug left in term of core recording functionality on the iriver h1x0 targets.

Let me know if I can do anything in terms of testing to help with this.

Davide-NYC.

Have been testing again and I can't make it fail :(

EDIT: made the amount of free space a bit bigger and now it failed... Investigating...

after diskspace is full it seems as if it continues recording into available RAM on my sansa c200, because it continues approximately 26 megs beyond available space on disk before it stops and reports that disk is full. which would indicate that it includes the RAM as available space?

No, but it indicates that it only checks for available disk space when it tries to save the RAM contents to disk.

the beginning of the file has already been written to disk, it should stop recording before continuing into RAM, shouldn't it?

to me it seems as if this is the same file, that continues inte available RAM.

if i watch the size of the file recorded, it is available diskspace + 27 megs. and the result is a corrupt file which lacks those last 27 megs...

Recording is done to RAM first, flushed to disk when RAM is full and continues in RAM at the same time. The data written to disk first is the oldest data in RAM and writes may fail before all of it can be flushed out. It's strictly FIFO. The first write to disk is a template header but only for files with headers which doesn't include MP3 at the moment - perhaps an INFO header will be added later. This is filled-in with the final stats just before closing the file. If recording has managed write this template header without error, it should at least be able to update it with what it managed to flush so far even if the disk ran out of space since it simply overwrites it in place. You should end up with a good file simply missing what's been left behind in memory.

If any cached sector flush must occur before seeking and filling-in the header and the disk is already full, attempting to do the fill-in may in fact fail anyway (right?). :) If that's correct, then this unflushed sector data must be discarded first so no further attempt is made to add more data to the file. Ok, I could be full of BS too. Do we even keep a good record of available disk space at all times?

does this mean that it actually fills up RAM completely before it does any writing to disk at all?

my sansa c200 records natively in WAV, i havent tried to do recordings in MP3.

the WAV file thats is left on disk is reported as corrupt and unreadable by msOS. though after a msScandisk i could import the raw data in audacity, so it seems you are right.

-----
then there's still the problem of the system freezing - if you get the message "The disk is full. Press LEFT to...", and don't press left within a few seconds the system freezes, if the display wasn't lit it just seems as if it is "dead".

yes. First fill up all RAM, then write it to disk. This is done like this for all targets although the reason we do it like that is only valid for HDD targets.

Yes there are still bugs with the disk full message: on H10 it shows the incorrect key and also doesn't switch on backlight on keypress.

I'm still hunting down the actual bug that causes disk corruption, it now only happens in 50% of the cases. There is some bug in the setting of the file size, and the code that keeps track of it puzzles me. Other than that, I've had limited time to look at it :/

I sure as heck wouldn't want to record directly to the flash all the time but then as long as you're not prerecording to flash in any way...not much different. With buffering in RAM you find out a few minutes later what you'll find out no matter what and your recording would be cut off at exactly the same point in either case.

Personally I'd never take a device out for any serious recording without it being essentially empty. I'm surprised people fill their drives often enough to notice this particular bug.

Bleh, I babble.

the sansa sound quality is much better in wav, which obviously requires a lot more diskspace (i only have 1gb), i'd say it's no surprise that people run in to this bug.

I do agree with Mike: if you're going to record, have enough space free. If the file system is fragmented (which it is most of the time) then you'll even risk having dropped packets before the disk is full because write performance degrades.

But Mike, you were babbling a bit, I will not keep my 80GB drive empty for recording, 25GB free ought to do it ;)

still, having a small flashbased recorder with approx. 1-2gb and recording to wav, makes it easy to fill up your diskspace.

say that you intend to do a long recording of some sort, and that you accidently forget to turn it off, or you just didn't check <u>exactly</u> how long you can record - it could easily be that you have a long recording rendered useless because you're out of space, instead of a long recording that gets cut off when disk runs out.

(it seems you are arguing to keep this bug, and people should blame them selves?) i think rockbox rules, but at the moment OF handles recordings better on the sansa c200.

committed another bugfix, please try....

for some reason my H10 freezes solid if I leave it on the DISK FULL splash too long, don't know if that is related or part of the open issue?

if nobody reports an issue I'll close this one next week