On Monday 09 Apr 2012 16:56:42 James wrote: > Hello, > > In a previous thread (3apr2012 - MTS player) > I delineated some problems with the copy > of files from a new HD sony camcorder > to my gentoo system. This explains the nature > of the problem: > <snip> > Files with CPI file extension are stored on the hard disk or > memory card of AVHCD camcorders. File contains information > (metadata) about captured video such as aspect ratio, frame rate > and other information. CPI files are usually found in the > AVCHD/BDMV/CLIPINF directory of the HD digital video recording media. > > The "AVCHD" is a brand new high definition (HD) digital video camera > recorder format recording 1080i and 720p signals onto certain media by > using highly efficient codec technologies. The "AVCHD" is jointly > established by Panasonic Corporation and Sony Corporation. > <end/snip> > > Here are some things I have learned along the > way that other might find useful: > > 1. "Reverse Engineering the Microsoft exFAT > File System" is an excellent expose on learning > about exFAT, which my new sony HDR-PJ760V camcorder > uses. Facinating read for those interested > in SD (SDHC and SDXC). > > 2. The trouble I was having, appeared to occur > periodically, so initially I thought it was > due to some "protection scheme" encoded by sony > into their newer camcorders. What I found > by trial and error is that auto-usb-mount > (I just clicked on the Dolphin file manager > each time the usb cable was inserted and > click the usb-connect icon on the camcorder) > is very sensitive and drops easily. Sure > you can sometime just reinitialize the connection > form the gentoo-kde tools, or sometime you > need to reinitialize from the camcorder > usb-connect gui. Some times you have > to power cycle the camcorder and start > with a fresh session to continue the copy process. > So the usb-connections from my gentoo system > to this sony camcorder is FRAGILE, for unknown > reasons. > > 3. So, I removed the extra SD card I had installed > and made sure that the "auto lens cover" was toggled > to close and I was able to copy the files over > with plain old "cp" across the auto-usb-mount > provided via dolphin. The auto link then was > stable enough to use this command: > > cp 0007[0-9].MTS /usr/local/TR/ > > To copy the files over. Use of a wildcard > to copy files with one command, failed > regardless of what I did. > > So, I lost the originating file information, > not thinking about date/time stamps: > (sony camcorder internal flash) > -rw-r--r-- 1 james james 122M Mar 31 15:25 00053.MTS > -rw-r--r-- 1 james james 173M Mar 31 15:27 00054.MTS > -rw-r--r-- 1 james james 68M Mar 31 15:28 00055.MTS > -rw-r--r-- 1 james james 22M Mar 31 15:29 00056.MTS > > cp yeilded this: > (gentoo drive) > -rw------- 1 root root 122M Apr 9 10:20 00053.MTS > -rw------- 1 root root 173M Apr 9 10:32 00054.MTS > -rw------- 1 root root 68M Apr 9 10:33 00055.MTS > -rw------- 1 root root 22M Apr 9 10:34 00056.MTS > > > So, not being the swiftest tack in the box on the > use of rsync, could somebody suggest some detailed > rsync syntax to correct the date/time stamp > on the file in the gentoo host dir without other > harm. Note the cp proceedure is very slow, suggesting > that using "rate limiting" on the file transfer > is probably a good idea? > > cp does not have a rate limited option, so should > I try scp or rsync (syntax examples are most appreciated). > I also saw a script that used "sleep 10" but that would > only work between file names.... > > > > thoughts, comments and suggestions are most welcome.
Notwithstanding the problems with intermittent connections you're describing, rsync -v -a /source /destination should do what you're after. You may also want to add --stats --progress to see some more info, -R to mirror directory/subdirectory hierarchies and you may also want to add -n for a dry run before you let rip. The manual shows more options, should you need them. HTH. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
