Strange behaviour after Disk Full error while recording

[mlind]

simon142857: Your former problem was not the same as is discussed in this thread.
I was recording, and when the disc got full - because it WAS full - strange things started to happen for me. This is what Petur is talking about.

[simon142857]

oops!

got it.

[petur]

It isn't dircache related (it always happens with dircache disabled)

discussing this with jhMikeS, it would seem that the file isn't closed properly because the flushing of the write buffer of the filesystem fails.

[Davide-NYC]

I just ran a test to see if this was fixed after Petur's recent commit regarding this problem.

I nearly filled my disk and then recorded to WAV until I received the "Disk Full" warning.
I pressed stop, left the recording screen and was able to browse files.
[edit] I was even able to play the recording I had just made.
That is untrue. It just played the next file down the list. Which I think is yet another problem as it does not give the user any feedback that there is a problem.

I then plugged the player into USB but was unable to transfer the file to my PC.
I got a "file or directory corrupt" error.

Sorry.  

[edit] I just realized this is totally the wrong place for this comment. I didn't read the full thread. Where should I post this feedback? I can't find the Disk-Full-Corrupt-Recording-File bug on the tracker anywhere!

[petur]

I nearly filled my disk and then recorded to WAV until I received the "Disk Full" warning.
I pressed stop, left the recording screen and was able to browse files.
I was even able to play the recording I had just made.

I then plugged the player into USB but was unable to transfer the file to my PC.
I got a "file or directory corrupt" error.

a more short reply because the forum ate my previous reply

- Using dircache or not?
- what does chkdsk say the problem is?

[Davide-NYC]

Petur, please read my post (above) again. I reported something incorrectly.

chkdsk says:
The size of the \recordings\R_MIC_071012-231825.wav entry is not valid.
dirchache is ON.

Hope this helps.

Rants & Ideas:

1) since the file's gonna get chopped anyway, why not throw away whatever is in the buffer and just write the end of the file politely?

2) Is there a way for the recording code to know how much space is left on Disk and simple report the amount of space available as {{ actual_freespace - 2*Buffer }}, or something similar? Essentially lie to the recording code about how much space is actually left.

3) If a file fails to play due to this type of corruption a splash screen should be displayed saying so instead of just playing the next file in the directory. In my case the files were of near silent background noise with very similar (date stamp) names so I thought the file played OK on the DAP when in fact it did not.

[edit] I jumped on IRC for a sec and had Mike S re-open FS#5852

Check it out: http://www.rockbox.org/tracker/task/5852

[petur]

chkdsk says:
The size of the \recordings\R_MIC_071012-231825.wav entry is not valid.

alright, that is a good hint where to look

dirchache is ON.

might have had that turned off in my last tests, will check...

1) since the file's gonna get chopped anyway, why not throw away whatever is in the buffer and just write the end of the file politely?

This is what happens in fact. What my fix does it write the header and close the file properly regardless of the failure.

3) If a file fails to play due to this type of corruption a splash screen should be displayed saying so instead of just playing the next file in the directory. In my case the files were of near silent background noise with very similar (date stamp) names so I thought the file played OK on the DAP when in fact it did not.

strange... mine played fine, even on PC.

[edit] I jumped on IRC for a sec and had Mike S re-open FS#5852

Saw that... will try to find time to look further into it.