Jump to content


Welcome to DBSTalk


Sign In 

Create Account
Welcome to DBSTalk. Our community covers all aspects of video delivery solutions including: Direct Broadcast Satellite (DBS), Cable Television, and Internet Protocol Television (IPTV). We also have forums to discuss popular television programs, home theater equipment, and internet streaming service providers. Members of our community include experts who can help you solve technical problems, industry professionals, company representatives, and novices who are here to learn.

Like most online communities you must register to view or post in our community. Sign-up is a free and simple process that requires minimal information. Be a part of our community by signing in or creating an account. The Digital Bit Stream starts here!
  • Reply to existing topics or start a discussion of your own
  • Subscribe to topics and forums and get email updates
  • Send private personal messages (PM) to other forum members
  • Customize your profile page and make new friends
 
Guest Message by DevFuse

Photo
- - - - -

Transferring individual recordings between eSATA drives - solved!


  • Please log in to reply
24 replies to this topic

#21 OFFLINE   UhClem

UhClem

    Cool Member

  • Registered
  • 22 posts
Joined: Oct 01, 2009

Posted 25 August 2012 - 04:23 AM

Wow, this thread is back?

Mea culpa :).
And, congratulations on your accomplishment! (Also, thank you. I'd been meaning to investigate this for a long time, but ... )

Anyway, restoring timestamps has NO importance in terms of the watchability of the recordings. It only comes into play, ...

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.)

As for using the "touch" command - these recordings may include hundreds of segment files. To use it for preserving time stamps, it would essentially require some fairly good facility with Unix scripting.

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)

A note to our board mods - if this topic broaches the limits of acceptable discussions on the boards, please contact me before deleting it so I can be sure to preserve a copy for my own use. Thanks. I'm not sure I have documentation this complete anywhere else.

Just above your Post #1 ... Thread Tools => Download this thread

(I don't plan to do this any more if I can avoid it - I've found that there is a non-trivial chance of corrupting a drive just by something going wrong in the process of mounting and dismounting it in Unix. I would not do it simply as a convenient way of moving a recording between my external drives, even ones that both work on the same DVR.)

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.

...Ads Help To Support This SIte...

#22 OFFLINE   cigar95

cigar95

    Legend

  • Topic Starter
  • Registered
  • 135 posts
Joined: May 23, 2008

Posted 27 August 2012 - 11:25 AM

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)

That would work, making the scripting less complex. Probably still need a script just because of the large number of files involved.

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.]

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?

Edited by cigar95, 27 August 2012 - 05:43 PM.


#23 OFFLINE   jdspencer

jdspencer

    Hall Of Fame

  • Registered
  • 6,572 posts
Joined: Nov 07, 2003

Posted 28 August 2012 - 11:35 AM

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.
DirecTV since '96, Waivers for ABC, CBS, NBC, & Fox, HR23-700 & HR24-500/AM21, using ethernet based MRV.

#24 OFFLINE   cigar95

cigar95

    Legend

  • Topic Starter
  • Registered
  • 135 posts
Joined: May 23, 2008

Posted 28 August 2012 - 11:52 AM

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.

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.

#25 OFFLINE   UhClem

UhClem

    Cool Member

  • Registered
  • 22 posts
Joined: Oct 01, 2009

Posted 28 August 2012 - 10:54 PM

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 - ...

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.)

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.

I experienced something similar, but under different circumstances. If I learn more, I'll post.

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.

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.




Protected By... spam firewall...And...