Adam Welz
March 20th, 2010, 03:03 AM
Hi All
I've just been alerted to a post by Curtis Anderson dated 20 March 2010 in a thread I started which, to me, gives a good lead on what might be causing these buffer overflows and crashes. In short, the crashes are not triggered by actual buffer overflows -- it's an incorrect error message -- but rather by corrupted/bad sectors in flash memory that the camera can't deal with.
Curtis writes "Based on my personal experiences, data to flash memory units can become corrupt during a read/write cycle if power is interrupted. One corrupted, the unit must be reformatted. Some bit errors can still remain after a format and the unit may not work, or work until the bad spot is addressed again during usage, and in some cases may not reformat at all. I have been able to try another camera and correct the corrupted data flash unit with a good format. My thought is, one or both of your units got corrupted and the camera, with limited error reporting, limited on-board diagnostics, and no error correction feature was giving you a ‘catch-all’ error message with little to no meaningful explanation of the real trouble."
Prior to me experiencing the deep crashes on both my NXCAMs I did in fact have clips that were interrupted, in other words while recording the camera was shut down before I hit a REC button to end the clip 'normally'. Neither of my NXCAMs crashed until after I'd recorded clips that had been non-standardly interrupted.
With the first camera I turned the main power switch off while recording to test the cam, and with the second camera the battery went completely flat in the middle of a clip. This may have resulted in corruption of a small section of the flash memory in either or both the SD memory cards and/or the FMU128 flash unit. These bad sections will in theory survive a standard reformat/erase procedure, and then when the camera tries to re-record data over the bad sections, it fails and this causes a deep crash of the entire system.
This would explain the lack of correlation between card read-write speed and the crashes, and clip length and complexity and the crashes.
So, perhaps the HXR-NX5 does not have data bottlenecks or even any specific issues with writing data to SD cards (which some have thought to be the problem). The problem might rather be that the software cannot recognise and skip over bad sectors in flash memory, and also not robust enough to recover from this encounter OR (in many cases) to recover the interrupted clip.
I will now be testing my idea by 'deep reformatting' an SD card (to make sure it's as clean as it can be, so it starts recording 'at the beginning' so to speak, what Sony calls a MEDIA EMPTY operation on page 65 of the NX5's manual) and then interrupting a clip by being really awful and pulling the battery off in the middle of it, and then doing a 'standard' reformat and using the card again and seeing if the cam freezes up when it encounters the bad sector that should theoretically be lurking on the card.
As I said before, at this point it's unclear whether the cam struggles with bad sectors on the SD card or FMU128 or both because all my crashes have happened when recording to both simultaneously. I'll be trying to crash the cam using only an SD card initially.
I'd love feedback from other users!
Cheers
Adam
I've just been alerted to a post by Curtis Anderson dated 20 March 2010 in a thread I started which, to me, gives a good lead on what might be causing these buffer overflows and crashes. In short, the crashes are not triggered by actual buffer overflows -- it's an incorrect error message -- but rather by corrupted/bad sectors in flash memory that the camera can't deal with.
Curtis writes "Based on my personal experiences, data to flash memory units can become corrupt during a read/write cycle if power is interrupted. One corrupted, the unit must be reformatted. Some bit errors can still remain after a format and the unit may not work, or work until the bad spot is addressed again during usage, and in some cases may not reformat at all. I have been able to try another camera and correct the corrupted data flash unit with a good format. My thought is, one or both of your units got corrupted and the camera, with limited error reporting, limited on-board diagnostics, and no error correction feature was giving you a ‘catch-all’ error message with little to no meaningful explanation of the real trouble."
Prior to me experiencing the deep crashes on both my NXCAMs I did in fact have clips that were interrupted, in other words while recording the camera was shut down before I hit a REC button to end the clip 'normally'. Neither of my NXCAMs crashed until after I'd recorded clips that had been non-standardly interrupted.
With the first camera I turned the main power switch off while recording to test the cam, and with the second camera the battery went completely flat in the middle of a clip. This may have resulted in corruption of a small section of the flash memory in either or both the SD memory cards and/or the FMU128 flash unit. These bad sections will in theory survive a standard reformat/erase procedure, and then when the camera tries to re-record data over the bad sections, it fails and this causes a deep crash of the entire system.
This would explain the lack of correlation between card read-write speed and the crashes, and clip length and complexity and the crashes.
So, perhaps the HXR-NX5 does not have data bottlenecks or even any specific issues with writing data to SD cards (which some have thought to be the problem). The problem might rather be that the software cannot recognise and skip over bad sectors in flash memory, and also not robust enough to recover from this encounter OR (in many cases) to recover the interrupted clip.
I will now be testing my idea by 'deep reformatting' an SD card (to make sure it's as clean as it can be, so it starts recording 'at the beginning' so to speak, what Sony calls a MEDIA EMPTY operation on page 65 of the NX5's manual) and then interrupting a clip by being really awful and pulling the battery off in the middle of it, and then doing a 'standard' reformat and using the card again and seeing if the cam freezes up when it encounters the bad sector that should theoretically be lurking on the card.
As I said before, at this point it's unclear whether the cam struggles with bad sectors on the SD card or FMU128 or both because all my crashes have happened when recording to both simultaneously. I'll be trying to crash the cam using only an SD card initially.
I'd love feedback from other users!
Cheers
Adam