DVR-recover 0.2 gave it this Easter Year to the usual "surprise" was a quite unexpected. My uncle brought a defective hard disk recorder. After a rather short diagnosis, it was clear that the appliance could be fixed, unfortunately not so simple. The DVD drive is broken, so it's impossible to get the data from the device down. This seems to be a "fad" (DMR-EH56 Panasonic) to be attached to the device, since many users complain of a rapid death of the drive. In our particular case, the engine went from the drive no longer reliable, so that the DVD was not even turned on properly. Unfortunately, can not exchange the unit because it no ordinary DVD drive PATA port, but a kind custom made. The drive itself has no controller logic, which is located away everything on the board the rest of the recorder. At this point, can wangle so much.
Theoretically, the device is still operational, but you get just the shots simply do not get off of the device. This is somewhat unfavorable. However, in the recorder still incorporated a standard PATA hard disk on which all recordings are stored neatly (but it takes much to * g *). So the plate was just plugged in to a USB HDD controller, and lo and behold, the plate was detected. However, the contents were not detected, which is not surprising, since the panel had no partition table. Panasonic also seems to use a known file system. Previous models have used old file system from the number-ext. Nevertheless, I succeeded in many (or all, I do not know, because it was not my recorder) to completely copy pictures from your hard disk. How exactly proceeded follows: (Note, it is treated and the technical background who will not know that, but would like to know just how he can possibly save the images with the script I developed, which should continue to read below. : D)
First, I examined the hard disk in a hex editor. According to a found string was the board assembly with a file system of the name "MEIHDFS. Google provides for this search phrase no less than three results! So this is a dead end, because in order to analyze the file system itself and to "decipher" by reverse engineering I miss a) the know-how, b) the period of several decades, and most importantly c) something the freaky;). is Funnily enough, the file system is relatively low on the hard drive. Before that you will not find much. The majority are all zeros, which probably should not have a larger purpose. In between then again something else. Presumably, these are the firmware for the device. In Internet forums can be found repeatedly that the devices do not work with a brand new identical hard disk, probably because it lacks precisely this firmware there. But well, in principle, I do not care.
The next step for me was that I used the hex editor to the search pattern "00 00 01 BA (hex) sought. Each header of an MPEG program stream that is starting with exactly this "sync byte". Luckily I found one. Apparently, the recorder saves the recordings as directly as MPEG stream in a proprietary file system-yourself. It was noticeable that all the "sync byte" were at a distance of exactly 2048 bytes. Accordingly, the works So file system with a block size of 2048 bytes (I can not guarantee that this is always the case with the unit but it is definitely the case). So, one approach is not available. Now it's down to business:) 
now so you could read the MPEG packets, but how do you know when a film begins and ends? After all, the data is fragmented on the hard disk, so not written continuously. The drive writes at the exact spot of the disk where he has just the place. A film must thus not necessarily in a row, and continuously stored in the correct order.
precisely for this task I wrote a Python script that the different parts of the images seen, sorted, recognize parts of the same shots and automatically dumped to output in files.
The script reads the hard drive (or a copy of this) in blocks (block size, the above-mentioned 2048 bytes, but is configurable) and see if the block is an MPEG-Chunk. The required specifications can be found well described in the English Wikipedia
. First, the correct occurrence of the "sync byte" and then checked that the "marker bits". If these "tests" have been passed, it is therefore an MPEG-Chunk. That will immediately make the existing 33-bit from the System Clock Reference to "read. Where have now two consecutive MPEG-chunks too large a deviation in the "system clock" value, you are probably not connected, at this point begins a new part of a recording. But what is a great value? Since the "System Clock" 90 000 times per second "tick", I have a difference of 90,000 ticks used as a border. In my tests this worked wonderfully.
Now you can so any cuts on your hard drive to locate. But the complete recording would have still put together by hand. Also, no optimal solution. The script is still just able to do! For this purpose, it compares the "System Clock Reference "at the end of a part with the beginning of another. If these are close to each other (difference
Now everything is together and the pictures just have to be read out and named. The whole process takes several hours to script, that script works most of the time but completely autonomous.
problem is only advertising . If that was previously cut out and the recorder advertising fragments has already been overwritten, the camera is not recognized as a whole. Since hand labor is required. Also you can find before and after many recordings still advertising. Both problems can, however, relatively simple video editing programs such as Avidemux resolve.
But how to use the script now?
< 90.000 Ticks) gehören beide zur gleichen Aufnahme und müssen nur „zusammengeklebt“ werden. (Ein Glück, dass das MPEG-Format relativ einfach aufgebaut ist *g*)
First: If you think that the hard disk image is important: Creating a backup. I assume no warranty.
Downloade extract and the script (or copy from the Git repo pick) and Shell Open:
$ cd / path / to / script $ python DVR usage recover.py
This should reduce the usage-information display. Creating 
configuration file: $ python
DVR recover.py sample_settings
configuration file editing (See Usage The most important settings are:. "hdd-filename", "chunk-filename" and "export-dir")
chunk list to create: (!. Takes a while I am here only a very small part of the HDD have read) If the process is not complete, any data collected will be lost! The script stores the information until the very end!
$ python DVR recover.py create [46.8%] 471420/1006929 blocks (15713.9 bl / s; 30.7 MiB / s): 6 chunks [93.5%] 941768/1006929 blocks (15678.2 bl / s 6.30 MiB / s ): 6 chunks Finished. Read 1006929 1006929 of blocks. Found 7 chunks. Took 64.08 seconds. Average speed was 15714.0 blocks / s (30.7 MiB / s).
's Chunk info:
$ python DVR recover.py show
Sort chunks:
$ python DVR recover.py sort
chunk info again View:
$ python DVR recover.py show --+--------------+---- ----------+--------------+--------------+--------- ---- chunk: start # 0 Chunk: chunk size 391 379: 615 548 42.22s (14579.92 blocks / s; 28.48 MiB / s). [...]
That was just a brief introduction. I hope it was somewhat understandable.
Simply announce to questions. Would be good if I am told that the script works or not (and what hard drive recorder models, it works).
More Script:
site
Download
Have fun!
nova 
post 
why I have written the script again and installed again soon many new features and fix old weaknesses. Additional features will follow and that if and when I even need;). As part of the redesign of the homepage (the project pages automatically using the project files generated), the script got a 
Error Open the settings file will now be caught. 
First, I examined the hard disk in a hex editor. According to a found string was the board assembly with a file system of the name "MEIHDFS. Google provides for this search phrase no less than three results! So this is a dead end, because in order to analyze the file system itself and to "decipher" by reverse engineering I miss a) the know-how, b) the period of several decades, and most importantly c) something the freaky;). 
