Re: [gentoo-user] Sony AVCHD

[Mick]

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