SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[saratoga]

I have noticed that if a crash occurs during a recording, there is no file with the recorded data. It would be a really awful scenario if you have, lets say recorded a 2 hours session, and in the last few minutes it crashes. You would have lost the entire recording.

If you lose power while writing the fat table isn't properly closed.  Run check disk and it'll be updated and you'll get your file.

[DonDan]

Would this also apply to a crash during the recording or only to shutdowns caused by power down?

[saratoga]

Would this also apply to a crash during the recording or only to shutdowns caused by power down?

I can't think of any difference between the two, so presumably. 

[DonDan]

I have noticed that if a crash occurs during a recording, there is no file with the recorded data. It would be a really awful scenario if you have, lets say recorded a 2 hours session, and in the last few minutes it crashes. You would have lost the entire recording.

If you lose power while writing the fat table isn't properly closed.  Run check disk and it'll be updated and you'll get your file.

Why is the File Allocation Table is only written at the end of recording process?Would it not be better if it is done at the beginning to ensure you find the file without a fdisk procedure in case of a power down or crash?
Am I missing something?

[Vague Rant]

That would conflict with the very concept of the FAT, which you might think of as a book index which lists where everything can be found--the difference being that the FAT also has to know how large the file is ("how many pages it takes up"). The nature of a recording is that it's constantly growing in size, so adding it to the FAT record at the beginning wouldn't make any sense.

[saratoga]

Why is the File Allocation Table is only written at the end of recording process?Would it not be better if it is done at the beginning to ensure you find the file without a fdisk procedure in case of a power down or crash?
Am I missing something?

Yes, that its not the 1970s and none of us is Bill Gates.  Go ask him why he designed FAT the way he did.

[Xanikseo]

I've noticed that since r26335 (it may have been introduced earlier) I have to wait for "Refreshing your media" to finish in OF, after whenever I have used Rockbox (even when just switching on rockbox, and powering off again).

Also I can't charge anymore with a wall-charger, without it booting into OF (yes, ok you can hold down select). Surely I should be able to use a wall-charger without booting into OF, since I can't really transfer any data with a wall-charger? Or is it because we don't know how to detect if someone is just using a charger or is in fact connecting to a computer?

[Rob2222]

Hello,

my brand new FuzeV2 doesnt want to flash a patched firmware, however the original fuze02.03.33 FW he flashes flawlessly.

I tried 02.03.33 from http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=38046
with mkamsboot.exe from http://forums.rockbox.org/index.php?topic=14064.msg167356#msg167356
and output was http://pastie.org/981998

I also tried 02.02.26 from http://daniel.haxx.se/sansa/amsfw.html
with mkamsboot.exe from http://download.rockbox.org/bootloader/sandisk-sansa/mkamsboot/win32/
outpus reported success, also.

Renamed output.bin to fuzpa.bin. After disconnecting mass-storage-usb the player doesnt start the flash process.
With original fuzpa.bin he starts flash process after disconnecting mass-storage-usb.

30 minutes ago I flashed my also new Clip+ with the same mkamsboot.exe without problems.

Any hints? I can upload the output.bin if wanted.

If I don't need to set up a own compile chain it would be very nice.

EDIT: Same problem by 2 user here: http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&message.id=42952#M42952
You can only flash 03.31 and 03.33. Hmm...

EDIT2: It doesnt want to flash the original 2.1.17, 2.2.26, 2.2.28, too.
It only flashes The 2.3.31 and the 2.3.33.

Looks like it has an additional check.

BTW, here is a dirlist:
 Datenträger in Laufwerk G: ist SANSA FUZE
 Volumeseriennummer: 0CF5-6F32

 Verzeichnis von G:\

01.01.1980  00:00    <DIR>          MUSIC
01.01.1980  00:00               320 SYS_CONF.SYS
01.01.1980  00:00    <DIR>          RECORD
01.01.1980  00:00    <DIR>          AUDIBLE
01.01.1980  00:00    <DIR>          PHOTO
01.01.1980  00:00    <DIR>          VIDEO
01.01.1980  00:00    <DIR>          PODCASTS
01.01.1980  00:00    <DIR>          AUDIOBOOKS
01.01.1980  00:00            51.237 RES_INFO.SYS
01.01.1980  00:00                83 version.sdk
01.01.1980  00:00             7.800 VIDEO_BM.SYS
01.01.1980  00:00               114 DID.bin
01.01.1980  00:00         1.862.468 MTABLE.SYS
               6 Datei(en),      1.922.022 Bytes
               7 Verzeichnis(se),  7.675.346.944 Bytes frei

Any new file maybe?



BR and thanks in advance
Robert

[csavery]

I've noticed that since r26335 (it may have been introduced earlier) I have to wait for "Refreshing your media" to finish in OF, after whenever I have used Rockbox (even when just switching on rockbox, and powering off again).

I've had this same behavior with r26251.
I don't think it's Rockbox causing this since it is the OF that is deciding to refresh media.
It may be the 02.3.33 OF as it was about the same time I rebuilt my firmware file. I wonder if Sansa set it to detect changes it didn't used to and which files it may now be detecting?

Update - I reverted back to firmware based on 2.2.26 and it does the same thing now. I think this means that Rockbox is now altering some file that the OF detects as needing a media refresh...

It's quite annoying when doing development as it means having to wait for refreshes at least twice as many times. I don't think the OF has any smart key presses for bypassing the refresh - only cool rockbox devs can think of that it seems.

[FlynDice]

EDIT2: It doesnt want to flash the original 2.1.17, 2.2.26, 2.2.28, too.
It only flashes The 2.3.31 and the 2.3.33.

Looks like it has an additional check.

That's what it seems like to me also.  I had no problem updating with OF V02.03.31A with current SVN mkamsboot.  The OF must now be doing some kind of additional check on this file before commencing the update process.

It seems V02.03.31A will indeed use a Patched fuzpa.bin though.  If you can flash 2.3.31 back onto your player you may be able to use that to flash a patched firmware.

[Rob2222]

@FlynDice/All

Even with running 2.3.31 it wont flash anything other then 2.3.31-Org and 2.3.33-Org.

BR Robert

[djphatic]

It seems V02.03.31A will indeed use a Patched fuzpa.bin though.  If you can flash 2.3.31 back onto your player you may be able to use that to flash a patched firmware.

So flashing the player back to 02.03.31A you were able to get Rockbox to install? I my firmware version always showed P instead of A e.g. 02.03.31P and it does now even with Rockbox installed.

[Rob2222]

@djphatic:
The letter behind the firmware number changes regarding the region setting.
(A=America, F=Europe and P=Pacific (Rest of World)

So you have now 2 Fuze's there, one which accepts patched and older formwares than .31 and one version that only accepts .31 and .33 original, or?

Can you see any difference on these units? Any big difference in the serial number?
Maybe differences in the system files in the root folder?
Could you maybe compare that?
Where you got the working unit from? Was that a new purchase? Meaning a new unit.

BR Robert

[mitk]

I've noticed that since r26335 (it may have been introduced earlier) I have to wait for "Refreshing your media" to finish in OF, after whenever I have used Rockbox (even when just switching on rockbox, and powering off again).

Also I can't charge anymore with a wall-charger, without it booting into OF (yes, ok you can hold down select). Surely I should be able to use a wall-charger without booting into OF, since I can't really transfer any data with a wall-charger? Or is it because we don't know how to detect if someone is just using a charger or is in fact connecting to a computer?

You noticed this behavior with uSDHC card inserted?
Please take a look at http://www.rockbox.org/tracker/task/11325?project=1&show_task=&order=id&sort=desc.

[nissin]

@djphatic:
The letter behind the firmware number changes regarding the region setting.
(A=America, F=Europe and P=Pacific (Rest of World)

So you have now 2 Fuze's there, one which accepts patched and older formwares than .31 and one version that only accepts .31 and .33 original, or?

Can you see any difference on these units? Any big difference in the serial number?
Maybe differences in the system files in the root folder?
Could you maybe compare that?
Where you got the working unit from? Was that a new purchase? Meaning a new unit.

BR Robert

I've flash my fuze V2 without any problem.

Here are some details:
Stock firmware version: v02.01.17
The device has updated to v02.03.33P before flashing to rockbox.
Patched firmware transfer to the device using MSC mode.
I did not insert memory card during the flash process.

File size of patched firmware: 15,728,640 Bytes
CRC32: C2B8E669