Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
November 12th, 2014, 14:17
We work regularly with DVR failed drives and recovering the data on these drives. In this particular case all we had to do is a PCB swap with a rom swap, due to a completely fried PCB.
Normally the only way we can test these files is to obtain the original DVR or similar model and re-enter the imaged drive, or reverse engineer the saving structure into a working file. In this particular case we have a very small Linux partition which contains log files, and the rest is proprietary to the DVR it came out of.
With a raw recovery we have four separate video files that fill 470GB of the 500GB HD. However there are also the obvious 150 other files that the DVR combines with its proprietary system to view these videos.
Is there any trick, or software to configure these files to be tested on a Windows or Linux machine? I know we can try to reverse engineer the structure into a working file type, but as we have lots of jobs and little time I am looking for a better avenue. Any help or suggestion is appreciated.
November 12th, 2014, 16:24
VideoLAN (VLC) can often play files recorded on DVR/PVR devices, unless they are encrypted. Sometimes you just need to rename the file extension.
November 12th, 2014, 17:49
Fzabkar: I have some .dvr files that won't play with VLC. What extension do you recommend?
Thank you
Jon
November 12th, 2014, 18:01
I have an STB that generates files with an SQTS extension. I need to rename then as *.MTS (MPEG transport stream), then they play OK.
http://www.edaboard.co.uk/thompson-usb- ... 22721.html
November 12th, 2014, 18:08
More info: The original drive is PATA, and the partitions are Linux/Ext3, so it probably predates MP4 encoding, for example.
November 12th, 2014, 18:22
westerndatarecovery wrote:Normally the only way we can test these files is to obtain the original DVR or similar model and re-enter the imaged drive, or reverse engineer the saving structure into a working file. In this particular case we have a very small Linux partition which contains log files, and the rest is proprietary to the DVR it came out of.
With a raw recovery we have four separate video files that fill 470GB of the 500GB HD. However there are also the obvious 150 other files that the DVR combines with its proprietary system to view these videos.
This made me curious: the first paragraph perfectly describes what we see recovering data from failed DVRs. And that's the primary problem with surveillance systems.
But the second one is contradictory - do you mean that working with DVR, which uses its own format, you have extracted some files, which are perfectly playable and at the same time you're unable to extract some of the recordings?
westerndatarecovery wrote:I know we can try to reverse engineer the structure into a working file type
This is the only way to recover the video if it isn't accessible through the recorder for some reason.
Nearly always we analyze DVR drive from the scratch and develop recovery software for the particular job.
November 12th, 2014, 18:27
jono-ats wrote:More info: The original drive is PATA, and the partitions are Linux/Ext3, so it probably predates MP4 encoding, for example.
This is a kind of fortunetelling, but depending on the size and contents of remaining drive space, the partition(-s) can be a system one, where the DVR internal software and/or recordings metadata is stored.
November 12th, 2014, 19:23
Thanks, Fzabkar. I'll try that.
Postscript: That, and a few other extensions I tried didn't work.
Apparently, it's a moot point --- the file creation dates are out of the range of interest.
November 12th, 2014, 19:52
westerndatarecovery wrote:With a raw recovery we have four separate video files that fill 470GB of the 500GB HD.
Doesn't a successful raw recovery imply that the DR software either understands the file system or recognises the file type? If so, and if the file system is proprietary (ie unknown), wouldn't this imply that the file types are known formats?
November 14th, 2014, 17:02
fzabkar wrote:westerndatarecovery wrote:With a raw recovery we have four separate video files that fill 470GB of the 500GB HD.
Doesn't a successful raw recovery imply that the DR software either understands the file system or recognises the file type? If so, and if the file system is proprietary (ie unknown), wouldn't this imply that the file types are known formats?
Yes the file types are known and recovered, but without the DVR to assemble all the appropriate files you can not view them. The way this process works either has to be reverse engineered or viewed with the DVR. We did receive the DVR and have tested the drive with the DVR. It seems like we have an underlying problem with the drive we recovered, and are now looking further into it.
November 16th, 2014, 11:54
I have had couple of surveillance systems in recently. Both were H.264 files with a separate log file partition. I did a lot of research and only found one instance where someone was able to partially re-assemble a portion of the videos. This was for a murder case, so resources were pretty much unlimited, but they still only had partial files with lots of corruption (enough to convict however). I also know a software engineer who wrote a popular data recovery program and he couldn't do anything with them. Like westerndatarecovery, then only way to play them was through the original DVR.
November 17th, 2014, 11:06
Thanks for sharing your experience ddrecovery. The partial files with corruption that you obtained, was that through a raw recovery then, or from trying to re-assemble the files? It seems like there is always something new to learn in the business! In my experience with this particular drive I started off with a raw recovery of the drive. There is a separate log file partition as well, simply with log files of restarting times, so I know I have a non-corrupt hard drive. I have 4 raw video files that take up the full size of the DVR HDD, yet are not viewable by any means. The DVR now will not recognize the HDD, but will recognize and format a new drive in its place. I am in the process of further diagnosing this drive, but it seems as if no errors of any kind are arising thus far. Any ideas?
November 17th, 2014, 17:43
ddrecovery wrote:I have had couple of surveillance systems in recently ...
I did a lot of research and only found one instance where someone was able to partially re-assemble a portion of the videos ...
but they still only had partial files with lots of corruption (enough to convict however). I also know a software engineer who wrote a popular data recovery program and he couldn't do anything with them.
Recovery software engineer you talked with is right. Format diversity among DVR vendors is extensive and there's no way to handle DVR videos the same way as regular files during raw recovery.
But we can handle this problem. We analyze drive contents manually and develop custom recovery software for each job.
With this approach all the videos from surveillance system are perfectly playable and the quality is the same as it was saved by DVR, without any reduction.
Should you need any assistance with a similar system in the future, we'll be glad to help remotely.
November 17th, 2014, 17:51
westerndatarecovery wrote:I have 4 raw video files that take up the full size of the DVR HDD, yet are not viewable by any means. The DVR now will not recognize the HDD, but will recognize and format a new drive in its place. I am in the process of further diagnosing this drive, but it seems as if no errors of any kind are arising thus far. Any ideas?
Nothing is wrong, everything should be this way, that's why I wondered and asked you earlier about the playable / non-extractable recordings at the same time.
DVR uses proprietary "file system" to store video stream, so now, when you have a physically working hard drive, which isn't recognized by DVR, next and only step is to reverse engineer the format and recover the recordings.
If you stuck with that at some point, I'll be glad to look into this job remotely.
Powered by phpBB © phpBB Group.