1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Transferring individual recordings between eSATA drives - solved!

Discussion in 'DIRECTV Tips and Resources' started by cigar95, Aug 12, 2011.

  1. UhClem

    UhClem Cool Member

    22
    0
    Oct 1, 2009
    Mea culpa :).
    And, congratulations on your accomplishment! (Also, thank you. I'd been meaning to investigate this for a long time, but ... )
    I believe you're correct--the DVR store its own timestamps (not relying on the filesystem ones). But, your example (for trimming leading/trailing excess) is clever, and prompted me to offer an assist. In addition, I like to preserve original information whenever possible. Myself, I would touch all those copied files (*.xm?, *.dmd, etc.)
    You mean, like parsing the date-time strings (from "ls -l")? Yuk.
    How about: "touch -r oldfile newfile"
    (which bestows newfile with oldfile's timestamps)
    Just above your Post #1 ... Thread Tools => Download this thread
    Since it was over a year ago that you first did this, has the procedure/methodology itself proved reliable? I was contemplating using this to consolidate/categorize various recordings (ie, Movies, Sports, Shows) on separate (smaller) drives. [I can solve the slow rt copy speed.]

    Thanks again.
     
  2. cigar95

    cigar95 Legend

    135
    1
    May 23, 2008
    That would work, making the scripting less complex. Probably still need a script just because of the large number of files involved.
    I haven't tried it since last October, or so. My goal was to recover the recordings from a corrupted drive, and that succeeded. Later on, as appears in the thread, I discovered that it seemed to not work on one of my drives when I tried to transfer recordings simply for convenience reasons. For the drive in question, I noticed that the copied segment files were not exactly 16mb in size - about half of them had an extra 4096 bytes in them, which somehow caused readability problems. This might have been related to the advanced technology that some manufacturers were using - I knew enough about this at the time to get things to work on my original drives, but I don't remember any of those details now.
    And then soon after, I had an incident with recordings being damaged in the process of mounting and un-mounting the drives, so I don't think I've tried it since.
    Can't remember if I mentioned this anywhere - if the file system is damaged such that one of the segment files is missing, when playback reaches that point, playback will automatically go back and start at the beginning. The only way to "jump the gap" is to skip to a bookmark or tickmark that is past the missing segment file. (Problem is, corruption usually results in lots of different files missing, so that there may be many gaps to get past. The only other alternative is to mount the drive in Unix again, and simply move a lot of files to another folder somewhere. Playback will then begin at the first file it finds.)

    Bottom line - I now see this functionality as a way of recovering when there's no other choice, not as a standard method for moving things around.

    Also have to add that I'm intrigued by your last comment regarding speeding up rtcp. Can you expand on that?
     
  3. jdspencer

    jdspencer Hall Of Fame

    6,637
    13
    Nov 7, 2003
    It's really too bad that DirecTV makes us resort to this procedure.
    IMO, as long as the external drives have been married to a DVR on the account, just make it possible to transfer the recordings where needed.
     
  4. cigar95

    cigar95 Legend

    135
    1
    May 23, 2008
    I agree with your sentiment in general, but in my case, I had to come up with this because my drive had been partially corrupted and it wouldn't even boot into a working mode. So officially supporting external drives in a way that allows transfers wouldn't have helped me.

    What is somewhat ironic is that I later discovered that the well-known procedure of using xfsdum/xfsrestore to copy an ENTIRE drive would have solved my original problem much faster, since that process leaves existing recordings intact on the target drive. I just needed to copy a working system to the corrupted drive. So my original drive ended up working just fine, although the death of my DVR a month ago last night rendered those recordings now worthless.

    I'm still glad I went through the process - I learned a fair amount about how the DVR file system works.
     
  5. UhClem

    UhClem Cool Member

    22
    0
    Oct 1, 2009
    There is a possible explanation for that behavior, but I don't have any 4KB-sector drive to test my "theory". (It could be xfs_rtcp not "playing nice" with 4KB-sectors under certain conditions.)
    I experienced something similar, but under different circumstances. If I learn more, I'll post.
    In general. I'm inclined to agree. But, it might be safe to do the mix-and-match onto a freshly-prepped drive--ie, such as one that had just received the standard "xfsdump ... | xfsrestore ..." treatment. Iow, once the HD-DVR has established its turf, and marked its territory, it doesn't like us strays pissing on the bushes.
     

Share This Page