New version of RTVPatch

[FlipFlop]

I made a new update to RTVPatch. This should be considered beta, although the changes are minor so I shouldn't have messed anything up. Changes are:

1) When copying, it now retries, and then skips over bad sectors. Previous versions would simply abort the copy on a read failure

2) After a "Restore target drive", "Copy system partition", and "Copy MPEG partition" operations it will prompt to do the "Patch target drive" operation. People tended to miss the patch stop in previous versions, so this should make it obvious.

3) Detect more partition types, so PC drives should always get reported as PC drives. Previous versions wouldn't properly detect things like partition manager or utility partitions.

4) The "about" box now actually works (shows the version number and build date)

Could some daring souls please test this version out, and report back here any problems (or success). If no problems are found, I'll update the version on SourceForge.

[Edit: 12/3/2004 Removed 2.5pre2 attachment due to bug - see message below for new version]
[Edit: 1/13/2005 See http://sourceforge.net/project/showfiles.php?group_id=17245 for the latest version]

[l8er]

While you're updating, what about changing the 3 instances of RTV4000 (as in RTV4000 Disk) to RTV4/5k, and the one instance of 4xxx at the large cluster screen? (If possible). It's another source of confusion when it reports a 50XX/55XX drive is a 4000 and recommends you choose no to large clusters on a 4xxx unit. Thanks.

[l8er]

Tested the new version a couple of ways...copying from an existing drive and restoring from an image and it worked great, prompting to patch after the system partition was copied each time. Thanks.

[FlipFlop]

Ok, I changed all of the "4000" references to be "4xxx/5xxx", changed all of the older unit references to "2xxx/3xxx", and updated the download link on the first post in this thread with this new version.

[GlassEtcher]

FlipFlop

Over on MacReplayTV in the Extending/Enhancing ReplayTV section I described my experience of imaging a disk on a Mac using RTVPatch (http://designwork.net/phpBB/viewtopic.php?t=76&start=0&postdays=0&postorder=asc&highlight=). If you get a chance please look at the post. I did an 80GB and 160GB disk. The 80GB disk worked just fine, but the 160GB disk gave an error at the end. As described, the only way around the error was to change the answer to the "do you want to completely reformat the MPEG partition" question. I have since done two 200GB disks and found the same situation. Does this have to do with the size of the disks or did I do something wrong?

Your comments about this problem and the write-up in general would be appreciated.

Thanks,
Glassetcher

[davester2]

Did anybody yet say......THANKS!!

[Lazlo]

Nope. Not yet. So, I'll say it. Thanks, FF! RTVPatch is a true wonder. I like DVA, but with streaming issues, and the fact that it takes an hour to move a single MQ show, the ability to put whatever sized drive I want in my ReplayTV is just the bees knees. I've got a 5200 now and a stock 5040. Waiting for a good, cheap (no rebate) 200 or 250 GB drive to come out to upgrade the 5040. Probably wait until after Christmas, though.

[frankz00]

So the copy really works? Why did I get the impression it was unrealiable at some point. I have a 160 in it now and would love to throw my 250 in it if I can copy all my shows. If FlipFlop can say he's reasonably certain it will, I give it a go!

[l8er]

Originally posted by frankz00
So the copy really works? Why did I get the impression it was unrealiable at some point. It's probably no more or less reliable than before, but has been changed so it won't choke and stop if it finds a bad sector on the source. Copying the mpeg partition has always been possible. It works for most people most of the time, but there's always a chance it won't be successful, and it does take a long time. Because of the time factor, it's usually better (quicker) to offload the shows to DVArchive and not worry about copying the mpeg partition.

And thanks for the 2.5 update FlipFlop.

[FlipFlop]

I just updated the download link to version 2.5pre2.

Changes:

1) completely removed the "large cluster" question, and always uses large clusters for 2xxx and 3xxx units, and always use the default 256kB cluster size for 4xxx or 5xxx units.

2) made it always re-create the MPEG partition's formatting from scratch when reformatting it, so it doesn't require there to be any pre-existing format info on that partition.

This should make things slightly less confusing, and slightly more reliable.

[ekaxel]

I haven't downloaded it yet, or seen an answer---Is this a replacement for the Windows version 2.2.4?

[l8er]

Originally posted by ekaxel
Is this a replacement for the Windows version 2.2.4? Replacement for the last Windows release: RTVPatch_2.4.

[lizard_boy]

Originally posted by l8er
It's probably no more or less reliable than before, but has been changed so it won't choke and stop if it finds a bad sector on the source. Copying the mpeg partition has always been possible. It works for most people most of the time, but there's always a chance it won't be successful, and it does take a long time. Because of the time factor, it's usually better (quicker) to offload the shows to DVArchive and not worry about copying the mpeg partition.

And thanks for the 2.5 update FlipFlop.
Gotta disagree with you on this one Gary. Copying the MPEG partition (for me at least) only seems to take 3 or 4 hours. Compare this with the 3 or 4 days it would take to unload every show I have on a 200GB hard drive. I've swapped drives in my 5040's dozens and dozens of times, copied the MPEG partition every time, and I've never had a problem.

[l8er]

Originally posted by lizard_boy
Gotta disagree with you on this one Gary. Copying the MPEG partition (for me at least) only seems to take 3 or 4 hours. Even so, with a little planning, the DVArchive route is no big deal. Then you're without a DVR for about 15 minutes compared to hours if you let RTVPatch copy the mpeg partition. And RTVPatch will take the same length of time to copy the mpeg partion if you have 1 show there or 50.

[FlipFlop]

I removed the 2.5pre2 version because I got too carried away when removing the "large cluster" question, to the point that the program would no longer properly patch up the MPEG filesystem size after a "Copy MPEG partition" operation. I'll get this fixed and upload a new version, probably tonight.

Don't use 2.5pre2 if you want to copy the MPEG partition.

[FlipFlop]

Ok, as promised, here is version 2.5pre3. This one should do the copy and preserve of both the MPEG and Photo partitions properly.

I changed the logic around to hopefully make things a little less confusing by reducing the number of prompts. Now it checks first to see if the MPEG and/or Photo partitions look somewhat valid, and if so, then it prompts to see if you want to try to preserve them. If you don't copy the MPEG and/or Photo partitions, then those partitions wouldn't look valid. If the partitions don't look valid, then there is no need to prompt as they must be reformatted.

Note: "valid" is defined as a proper magic number (offset 0x0110) and a reasonably sized cluster size (offset 0x0114) which is a multiple of 512.

Edit: Removed attachment. See http://sourceforge.net/project/showfiles.php?group_id=17245 for the latest version

[grgeiger]

Thanks for the file.. I have tried the new patch.. I am now getting a lot of errors.. Failed to read block from source.. After the first retry the patch moves on to the next block.. Maybe that explains why my other patches didn't work tonight..... I have some bad blocks on the source.. This doesn't appear to be a bug in the patch. I think I have a bug in my source drive. Is there a way to fix errors on the source drive?

More bad luck tonight.. I couldn't get my C: Drive to boot.. After trying different IDE cables, playing with bios settings, giving my bios a hard reset (SEVERAL times), pulling out the CD roms, floppy, pulling out all cards except the video card.. I discovered that I was trying to boot with a Replay TV Drive.. Man I hate those kind of nights.. Sorry!! I need to vent!! :)

[grgeiger]

Update.. This patch worked when the older versions didn't!!! I think it was the ability to retry bad blocks.. Good work!!! Thanks!!!

[l8er]

I used 2.5pre3 to copy from two Maxtor 250 GB drives to two Seagate 200 GB drives (55XX ReplayTVs). Shows remained intact (since the 250s weren't anywhere close to being full), and the copy process was faster than I remembered. Right around 2 hours for each drive.

Thanks for the updated version FlipFlop.

[Conspiracy]

Damn! My 250GB Maxtor crashed 2 months too soon! I lost all my shows (good thing it's just TV) and the mpeg copy was failing in Patch due to bad clusters. Oh well, it's going to be nice to have this for next time. Thanks.

[boekjar]

Originally posted by FlipFlop
I made a new update to RTVPatch. This should be considered beta, although the changes are minor so I shouldn't have messed anything up.
Is it safe to assume that this is not a release for using the Linux Boot Disk method? And that method has remained relatively unchanged for a long time now?

[FlipFlop]

Originally posted by boekjar
Is it safe to assume that this is not a release for using the Linux Boot Disk method? And that method has remained relatively unchanged for a long time now?
You are right: this is a windows version only. One of these days I'll rebuild the Linux boot disk, but most of the changes are related to the Windows interface, so there isn't much advantage to this version over the current Linux boot disk version.

[repnewbie]

Am i correct in assuming that copying the entire contents of a 40G original drive ( disk is full to the brim!) to a new drive should take no more than 4 hours? How long does the entire patch process take? Thanks.

[rm -rf *.*]

Originally posted by repnewbie
Am i correct in assuming that copying the entire contents of a 40G original drive ( disk is full to the brim!) to a new drive should take no more than 4 hours? How long does the entire patch process take? Thanks.
4 hours to copy 40Gb of MPEGs? Very hard to say - depends on how fast the disks are, how fast the ATA/IDE controller in the system is, the overall performance & speed of the computer... (list keeps going and going and going...) I'm curious, how did you arrive at that time estimate for the given amount of data?

As for the amount of time it will take to Partition the drive, install the OS image and patch the MPEG partition (no shows are copied to the new drive in this instance): a minute or two, literally.

--------
EDIT @ 4:17PM - Just read Gary's post (#25) which immediately follows this post - nevermind about where that 4hour estimate came from.

[l8er]

Originally posted by repnewbie
How long does the entire patch process take? As stated here (http://www.avsforum.com/avs-vb/showthread.php?postid=4803140#post4803140) it took around 2 hours for a 250 to 200 GB drive. So in my case, RTVPatch was copying 200 GB. A 40 GB drive would take much less time.

[gatomon]

Does anyone know who did the port to Mac OSX?

*****
***** RTVPatch version 2.3, built on 10/22/02, 19:01:00
*****

Where is the source for 2.5? I might give a port to Mac OSX a shot.

-Chris

[FlipFlop]

I did the port to OS/X, using ssh into a kind soul's box who was crazy enough to risk me overwritting the wrong drive. 2.5 should compile fine with no changes, but I haven't tried it. However, the OS/X version doesn't detect the drive size properly, so it is of limited use. If you are capable, and interested in fiddling and recompiling it, maybe you could look at the drive size detection, and get that to work. It simply seeks forward until the seek fails, then backs up and counts how far it can seek before failure. It appears that OS/X doesn't return any failure codes when seeking on block devices???

I just added the 2.5 changes to CVS on Sourceforge, so you can get the latest source there. Use tag "v_2_5".

I also uploaded this 2.5 Windows version to SourceForge in the downloads section, replacing version 2.4.

[BoulderGeek]

Thanks for all of the efforts on this code. It is a great asset to the community.

May I ask why no source is available. I had a bear of a time trying to get the Linux binaries to work on my fedora Core 2 system. I would have loved to compile a localized copy for Linux. It's the first Sourceforce project I've seen with no actual source!

I don't use floppies anymoer. Ihad to go cannibalize an old drive from my parts pile, and couldn't get a linux boot floppy to work, it always bombed out with a bad CRC.

My needs are over with for now, as I had to build up a Windoze disk to get teh win32 version to work, which it finallydid. I just hate Doze so much, and do everything on Linux or OS X (on a PowerBook, so no IDE drive work there).

Thanks. Just a suggestion.

[FlipFlop]

Originally posted by BoulderGeek
May I ask why no source is available.
Not sure why you think the source isn't available. It is all there, right under the "Source code" link at http://rtvpatch.sourceforge.net
I don't use floppies anymoer. Ihad to go cannibalize an old drive from my parts pile, and couldn't get a linux boot floppy to work, it always bombed out with a bad CRC.
I've found that the latest generation of floppy drives and/or floppy media have a very high error rate. Quite often I have to try 2 or 3 different floppies before one would work. I can't imagine how we used to rely on floppies as reliable storage for our trusted data, but I guess the quality control was better when the drives cost more than $10, and media more than a couple pennies ;)

[BoulderGeek]

[QUOTE]Originally posted by FlipFlop
[B]Not sure why you think the source isn't available. It is all there, right under the "Source code" link at http://rtvpatch.sourceforge.net


Ah, heck. Sorry about that. I missed it completely. Must have been non-obvious, and I was multitasking.

Cool, good to know for the future. Thanks for the reply.

[gatomon]

FlipFlop,
I downloaded the source and it did compile find. I discovered the
problem with the determination of the size of the disk. In the file
rtv_patch_funcs.c, the function scan_model_info, line 2084:
if(FileOffset==NewOffset)
should be
if(1==NewOffset)

(the call NewOffset = rtv_lseek(fd, FileOffset); returns a 0 or 1). With
this fix, it correctly determined the size of a 160GB disk.

-Chris

[BoulderGeek]

Now THAT is community interaction!

I'm going to grab the code and compile it up so I have a solid copy for the next time.


I hate having to keep Windows around unnecessarily. Windows sucks. Apologies to all the douchebags who love it.

[FlipFlop]

Originally posted by gatomon
if(FileOffset==NewOffset)
should be
if(1==NewOffset)
Good catch! And the only place that piece of code is used is in the OSX version, as Linux always has /proc information giving the drive size. I've made the changes to the source in CVS.

I also changed the photo partition size selector to be always available in the Windows GUI, and uploaded version 2.5.1. Now you can set the desired photo partition size prior to doing the copy or restore.

[gatomon]

FlipFlop,
I would change the name NewOffset to SeekSuccess
and change:

NewOffset = rtv_lseek(fd, FileOffset);
if(1==NewOffset)

to:

SeekSuccess = rtv_lseek(fd, FileOffset);
if(SeekSuccess)

-Chris

[replayed]

Wow, that was embarrassing. Two minutes of searching led me to emmarie extremely useful recent post on the subject of USB enclosures. Apologies about the noise. Carry on.

[l8er]

Just an observation on the 2.5 version of RTVPatch: I copied the system partition and it asked about patching the drive (I answered no), I then copied the mpeg partition and it asked about patching the drive (I answered no), I then copied the photo partition and it did not ask about patching. Should it?

[xyzzy]

Hard to believe the longevity of RTVPatch.

I finally sold what I think might be the very first 80-hour unit that I built from a 2020 with a very early cmdline version, soon after the team (sean?) figured out the CRCs in the partition table.

I had some emotional attachment to that box, and it ran reliably for 5 years or so, but it got slidelined by the newer networked boxes.

Anyway, it's cool that things are still being added to the tools...

X.

[Abini]

I've looked on the SourceForge website and it still lists the RTVPatch 2.5.1, how do you get the newer version?

[l8er]

Originally posted by Abini
I've looked on the SourceForge website and it still lists the RTVPatch 2.5.1, how do you get the newer version? 2.5.1 is the newer version.

[Abini]

Thanks, I should have read page two of the thread 1st.

[Freddy B.]

Originally posted by BoulderGeek
Now THAT is community interaction!

I'm going to grab the code and compile it up so I have a solid copy for the next time.


I hate having to keep Windows around unnecessarily. Windows sucks. Apologies to all the douchebags who love it.

Would it be possible to post your compiled version of the OSX executable here as an attachment for a fellow Windows Despiser?
I'm about to try my first upgrade (from 40 to 200GB) and hate to have to borrow a PC. I would love to compile the source myself but am a bit confused by what I find in the CVS. Which files do I need to download, and how do I construct a proper Makefile?

And finally, I would be using two FireWire enclosures for the drives. Would this pose any problems?

Thanks for all of the great work done by all of you in this thread!

[Abini]

First, let me say thanks to FlipFlop for the new version.

I just upgraded a factory 5508 with a Maxtor 320 GB drive. My replay had an 80 GB Maxtor drive in it. The jumpers were set to CS. I used the new version 2.5.1 on a P4 Windows XP computer with ATA/133. I used Powermax to LLF the HD and had no problems with RTVPatch recognizing the drives.

I did the upgrade in this manner: Copied Partition one, Patched, Copied Partition two (my saved shows), Patched. I don't know how long it took as I started it and went to bed last night and patched it this morning. I had about 20 hours of shows saved at medium quality.

I put the new drive in my REPLAYTV and it booted right up first time. Saved all my shows, I checked a sampling to make sure.

I am stoked as I didn't want to have to go back and DVArchive 20+ hours of shows so I could swap drives.

[gatomon]

send me a note with an email address. I don't think I can attach the complied application to the forum. It should be put on the download page at sourceforge.

It should work with two enclosures, although I haven't tried that.

-Chris

[bsoplinger]

I don't know about version 2.5.x, but I used 2.4 to successfully copy a 5040 80G drive onto a 250 G Maxtor using 2 enclosures with my Digital Audio G4. Just a bit of advice, make sure at least 1 of your enclosures will support a big drive ;)

[Freddy B.]

Originally posted by Abini
I did the upgrade in this manner: Copied Partition one, Patched, Copied Partition two (my saved shows), Patched. I don't know how long it took as I started it and went to bed last night and patched it this morning. I had about 20 hours of shows saved at medium quality.

Originally posted by l8er
Just an observation on the 2.5 version of RTVPatch: I copied the system partition and it asked about patching the drive (I answered no), I then copied the mpeg partition and it asked about patching the drive (I answered no), I then copied the photo partition and it did not ask about patching. Should it?

I'm a bit confused - The instructions on the Source Forge "Single Drive Update" page lists the procedure as:

16. Click the "Copy System Partition" button. You will be asked the following question:
You are are about to mirror disk SOURCE to disk TARGET
Answer "Yes' only if the SOURCE accurately describes the original ReplayTV drive, and the TARGET accurately descibes your new hard drive.
It will take a couple minutes to copy the partition.
17. Select the desired photo partition size (Note: this setting is only available when patching RTV4xxx or RTV5xxx units)
18. Click the "Patch Target" button.


But no mention of when to copy the MPEG partition if desired. Abini above seems to have patched the drive both after the copies the system partition AND after the MPEG partition. l8ter seems to imply that patching is only done once, at the end of the process.

I will be copying the system and MPEG partition, and resizing (but not coying) the photo partition on the new disk. What is the correct sequence for me to follow?

Also, i presume that when I do patch the drive in my case I will not reset the MPEG partion when I do the patch...

Thanks in advance for your help!
FB

[FlipFlop]

The patching must always be done as the last step. It doesn't hurt (or help) to do it more often. verison 2.5.1 always prompts you to patch after each operation to make sure you remember to do it, as this was an often forgotten step.

[l8er]

1) Copy system partition. RTVPatch 2.5 will ask you to patch.
2) Copy mpeg partition. RTVPatch 2.5 will ask you to patch.
3) Copy photo partition. RTVPatch 2.5 won't ask you to patch, but you should.

RTVPatch 2.4 will never ask you to patch, but "Patch target drive" should be the last step performed in either version. The partitions can probably be copied in different order, but I've never tried it.

The original instructions do not cover copying the mpeg partition, since at the time they were written, it was not recommended that you copy the mpeg partition.

Lots of upgrade, repair and other information is available at the ReplayTV DIY Upgrade/Repair/Info site: www.replaytvupgrade.com.

[l8er]

Originally posted by FlipFlop
verison 2.5.1 always prompts you to patch after each operation In my testing, 2.5.1 does not prompt to patch after copying the photo partition. I usually copy system, mpeg and photo partitions in that order.

[FlipFlop]

The way it works, if you copy the photo partition, it will keep the same size photo partition on the target disk, so there should be no reason to repeat the patch after copying the photo partition.

However, I do see a problem: if you change the size of the photo partition (setting other than "no change") and then try to copy the photo partition, the photo partition will fail to work. The only way to change the size of the photo partition is if you reformat the photo partition. So the photo partition copy should really be disabled if the size is set to something other than "no change".

[Freddy B.]

Originally posted by FlipFlop
The patching must always be done as the last step. It doesn't hurt (or help) to do it more often. verison 2.5.1 always prompts you to patch after each operation to make sure you remember to do it, as this was an often forgotten step.


Thanks - that was what I suspected. Thanks also l8ter for the further clarification. In my case I have no photo partition on my existing 40GB drive and will create one on the 200GB drive, so the issue of copying/resizing it will not affect me (this time).

Things seem pretty clear at this point - all I need now is the time to extricate my ReplayTV unit from the pile of A/V equipment and spider web of cables that it is tangled in.

[Freddy B.]

Originally posted by FlipFlop
Not sure why you think the source isn't available. It is all there, right under the "Source code" link at rtvpatch.sourceforge.net

FlipFlop (or others who compile from source),

I'd like to compile RTVPatch 2.5.1 on Mac OSX, but am confused by what I see in the CVS at Source Forge.

EDIT Instructions: Download all the files from both the "common" and the "console" directories (with the 2.5.1 tag), preserving the directory structure, to a master directory on your machine named "RTVPatch", or whatever. cd to the console directory and type:

make depend
make

and the executable RTVPatch will be created in that directory.

NOTE - you must have the latest version of Xcode developer tools and gcc installed!

Follow-up is posted below.

[l8er]

Someone correct me if I'm wrong, but as I recall, the only way to create a photo partition that works is by using quick setup in the ReplayTV. IIRC, creating a photo partition by using RTVPatch, where a photo partition didn't exist previously, results in a non-functional photo partition.

[gatomon]

Is there some way to add the binary version to the download page on sourceforge? I have a working copy and people have been asking for it.

-Chris

[toots]

Well, I already just added a new devo to the sourceforge page (the guy who's redoing extract_rtv).

You wanna be added to the project so you can do it yourself?

[Freddy B.]

Thanks to gatomon for helping me compile RTVPatch 2.5.1 on my MacOSX machine - I updated my request above with the instructions. Still Windows Free!!

As I haven't opened my RTV box to get the source drive yet, I could only verify that this version does correctly identify my intended target drive (Maxtor DiamondMax 9 in a USB-2 enclosure) as a 200GB drive. I'll post my final experience with the upgrade in a day or two.

l8ter's comment above about not being able to create a working photo partition on the target without one on the source sounds correct. I certainly don't want to do a factory reset to create one, so I may burn 500MB and try anyway.

Thanks again everyone!

[gatomon]

I could probably do that. I've never been a sourceforge developer (I'm a member). What do I have to do?
-Chris

[Freddy B.]

Originally posted by gatomon
Is there some way to add the binary version to the download page on sourceforge? I have a working copy and people have been asking for it.
-Chris

I've attached the OSX executable here so that it can be posted on sourceforge by a registered devo, or can be used from here.

FB

[toots]

You know, it's been so long since I've done anything on sourceforge that I don't rightly remember.

[FlipFlop]

Originally posted by l8er
Someone correct me if I'm wrong, but as I recall, the only way to create a photo partition that works is by using quick setup in the ReplayTV. IIRC, creating a photo partition by using RTVPatch, where a photo partition didn't exist previously, results in a non-functional photo partition.
You should be wrong, because the way the program is written it should create the partition from scratch. But there might be a bug in the program? I did see a comment once before that the photo partition didn't work. I know it did work at one time, so maybe the 2.5.1 changes screwed it up.

[FlipFlop]

I looked at the code, and the logic for the photo partition is backwards. So if you say "Yes" to format the photo partition, it doesn't touch it, but if you say "No" to not from the the photo partition, then it will format it.

So for 2.5.1, answer "No" to the format photo question, and it should work.

[l8er]

Originally posted by FlipFlop
So if you say "Yes" to format the photo partition, it doesn't touch it, but if you say "No" to not from the the photo partition, then it will format it. Hmmm, did someone used to work for Microsoft? :D

[gatomon]

Has anyone compiled extract_rtv for Mac OSX? Does it work with 50xx replays? Are there alternatives? I think I could compile it with a bit of work. Any interest?

-Chris

[FlipFlop]

Originally posted by gatomon
Has anyone compiled extract_rtv for Mac OSX? Does it work with 50xx replays? Are there alternatives? I think I could compile it with a bit of work. Any interest?
I did compile it once, quite a while back, and posted the binary code here. There didn't seem to be any interest, and I don't have an OSX machine myself, so it was simply idle curiosity on my part. But, it does compile under OSX, and should work on 5xxx units the same as it does under windows.

[madSkeelz]

I have a copy of the binary FlipFlop built for OSX. I'd assume there's little interest because it's usually much more convenient to just grab stuff from the RTV over the LAN.

Anyway, I've attached the binary, ZIPped by OSX's built-in compression engine. [StuffIt Expander might screw with the executable permissions, I forget.]

[gatomon]

with a little bit of effort. There is an error in extract_rtv.c

101c101
< typedef int64_t int64;
---
> typedef int64_t int64

(missing ';'). Also, the Makefile needs to add

NAME = extract_rtv

at the top and remove the "cd" line in order that

make clean

will work. I'm going to see if I can recover some videos that are
gone after a crash. I can post

extract_rtv version 16 built on Feb 27 2005 11:46:32

if there is interest.

-Chris

[Freddy B.]

Nice catch on the ";" Chris. I was looking in the wrong place, and now can compile with a simple "make", as the Makefile I grabbed did not have the "cd" line you refer to.

"extract_rtv" is one of those things that you would never have any interest in until the one time that your RTV fails before you've had a chance to archive or watch the Cup Final (Stanley, World, FA, etc.), and then it's a must have. I'll file it away with the knowlege that I won't have to steal a Windows box to recover. As Gary observed above, Microsoft is not the source of good things.

I'll post the compiled binary here (not to steal Chris' thunder) - let us know how your recovery goes.

FB

[gatomon]

for the compliment. The Makefile needs fixing only if you need to run

make clean

command (try it). I wrote that so the sourceforge files will be updated.
BTW, I'm the one that fixed the disk size problem in RTVPatch2.4 (you
used to manually override the size because of the error). It's fun to
be a member of such a co-operative community.

-Chris

PS: we need to work on the mac version of WiRNS (MacRNS?)...

[Freddy B.]

The upgrade from 40GB to 200GB using two external USB cases on my Powerbook went fine. I had originally intended to copy the MPEG partition as well, but after seeing that it took 15 minutes to copy the system partition I abandoned that idea as it would have taken ~20 hours. I had DVArchived the important shows just in case, so I have the many Simpsons episodes to test "extract_rtv" - I'll post those results later.

The only twist to my experience was that I din't have a photo partition on the original drive, and wanted to create one during this process (I tried 500MB). During the patch process I was not asked about reformatting the Photo partition as FlipFlop and Gary had discussed above. Below is an excerpted portion of the dialog.

Was I not asked to format the photo partition during the patch because one was not detected on the source drive? Or is 500MB too small for a valid photo partition? When I launched DVArchive, the message seems to indicate so:
"02/27 17:52:24 DVR Living Room Photo space not allocated (less than 512MB) - Photos usage is disabled for this ReplayTV"

I'm not going to disassemble my system to try this again, but perhaps you all might see some cluse here as to how to make this work in the future.

Thanks everyone for making this a fun and educational process!

*****
***** RTVPatch version 2.5.1, built on Feb 26 2005, 15:14:40
*****

/dev/disk1 : Using binary search drive size detection
/dev/disk1 (Drive 1) : Detected size = 80293248 sectors
/dev/disk2 : Using binary search drive size detection
/dev/disk2 (Drive 2) : Detected size = 398297088 sectors

The system contains the following disks:
1 /dev/disk1, Drive 1, 41GB, ReplayTV Disk (4xxx or 5xxx)
2 /dev/disk2, Drive 2, 203GB, NOT a ReplayTV Disk (2xxx or 3xxx)

...

Enter Command: m

You are about to mirror disk /dev/disk1 (Drive 1)
to disk /dev/disk2 (Drive 2).
THIS WILL DESTROY ALL DATA ON DISK /dev/disk2!

Do you really want to proceed?
(y/n)? y

...

Done: Copy Complete

Enter Command: l
Enter photo partition length, in MB (0 = default)
500

Photo partition length is set to 500MB

***** You must now use the (p)atch command to set the partition table
***** and format the photo partition using the new length

Enter Command: p

You are about to patch disk /dev/disk2 (Drive 2).
Do you really want to proceed?
(y/n)? y
*********************************************
***** PATCHING DISK *****
*********************************************

Target disk is /dev/disk2 (398297088 sectors)
***** Patching partition block...
Enabling RTV 4xxx/5xxx byteswapping functions
Original partition table values:
Partition 1, type 0x4d, start: 2, length: 1024000
Partition 2, type 0x4d, start: 1024002, length: 79267198
Partition 3, type 0x4d, start: 80291200, length: 2048
Partition 4, type 0x00, start: 0, length: 0
Partition 2 cluster size is 262144 bytes.

** Do you want to try to preserve the shows on the MPEG partition?
** Answer 'yes' here ONLY IF you copied the whole MPEG partition!!!
** The safe answer is 'no'
(y/n)? n
Changing partition 3 start sector to 397273088 (0x17ade800)
Photo partition size will be 1024000 blocks (500MB)
Partition 2 will be 396249086 (0x179e47fe) blocks.

***** Clearing volume sequence block...

Partition 2 cluster size will be 262144 bytes.
*** Formatting partition on device '/dev/disk2' at offset=524289024
Using RTV 4xxx/5xxx byteswapping operations
Writing system block with 773923 clusters of 262144 bytes each
Writing superblock with label 'mpeg'
CRC is 0xe8f4
XOR byte is 0x84
Writing root directory entry
CRC is 0x235f
XOR byte is 0x22
*** Partition format complete
*** Formatting partition on device '/dev/disk2' at offset=203403821056
Using RTV 4xxx/5xxx byteswapping operations
Writing system block with 16000 clusters of 32768 bytes each
Writing superblock with label 'storage'
CRC is 0x2292
XOR byte is 0x28
Writing root directory entry
CRC is 0xf90a
XOR byte is 0xad
Adding directory 'tmp' to partition
CRC is 0x5f0e
XOR byte is 0x09
Adding directory 'Photo' to partition
CRC is 0x0298
XOR byte is 0xc0
*** Partition format complete
*********************************************
***** PATCH COMPLETE *****
*********************************************

[FlipFlop]

Originally posted by FlipFlop
I looked at the code, and the logic for the photo partition is backwards. So if you say "Yes" to format the photo partition, it doesn't touch it, but if you say "No" to not from the the photo partition, then it will format it.

So for 2.5.1, answer "No" to the format photo question, and it should work.
I thought I was wrong, but I was mistaken.

The logic is correct. The question has changed from "do you want to format the photo partition" to "do you want to preserve the photo partition", so answering "no" will not preserve the photo partition, and therefore it will be formatted.

So, I'm not sure why the photo partition part wouldn't work. It all looks fine to me. Could someone experiencing this problem post an rtvpatch.log file from the patch that failed?

[Freddy B.]

Testing this on the 5504 drive I just removed gives functional, but not perfect results. It will list and extract files, but cannot display the show info associated with them. The only way to tell what is on the .mpg is to begin extracting and do a quick preview (not difficult) This is my first time ever using this so I'm not sure how it should act ideally, but I "THINK" I've tried every possible cmd line option.

The problem seems to be that it will only look in the first partition for the "Channels List", even when explicitly told to do otherwise with -p2. What is this file called and where does it actually reside so that I can look for it in the listing? Here is what I consider to be relevant command line excerpts. If anyone wants me to try something else let me know:

[rimsky-korsakov:~/Desktop/extract_rtv] freddyb% extract_rtv -l
This looks like a ReplayTV 4000 series drive!
Enabling the byte-reversing code
ReplayTV drive detected: /dev/disk1
Partition Type Start Length
1 0x4d 2 1024000
2 0x4d 1024002 79267198
3 0x4d 80291200 2048
4 0x00 0 0

Select partition: 2
178352 ./1108699077.ndx
1751011840 ./1108699077.mpg
<DIR> ./tmp
448883200 ./1109206797.mpg
13448 ./1109374197.evt
70688 ./1108699077.evt

and a whole lot more in that list. Listing partition 1 shows lots of system files. Then I tried:

[rimsky-korsakov:~/Desktop/extract_rtv] freddyb% extract_rtv -d
This looks like a ReplayTV 4000 series drive!
Enabling the byte-reversing code
ReplayTV drive detected: /dev/disk1
Couldn't find the ReplayChannels list

[rimsky-korsakov:~/Desktop/extract_rtv] freddyb% extract_rtv -dv -p2
Forcing to first partition to read program descriptions.
This looks like a ReplayTV 4000 series drive!
Enabling the byte-reversing code
ReplayTV drive detected: /dev/disk1
Couldn't find the ReplayChannels list

I tried a few other things that aren't worth posting here. Is there anything I can do differently to make the "-d" option work, or does the source code not look in the right place on the 55xx series?

Thanks again,
FB

[FlipFlop]

The -d functions were written for the 3xxx series, and haven't been implemented for the 4xxx or 5xxx series. It is feasible, and the info has been figured out, just no one has been motivated enough to implement it.

[JadeEast]

I have two 5500's and installed dual Maxtor DiamondMax 10 300GB drives in each using RTV 2.4. Both worked fine for a time and then would lose all setup information. I would then go into setup, re-enter the setup information and all would be well for a time. Is 600GB too much for ReplayTV? Also, I did try the Deskstar 400GB drive as single, dual and no matter what, it was not compatible with the Replay 5500. Has there been any testing with dual drives using RTV 2.51?

[l8er]

Originally posted by JadeEast
I have two 5500's and installed dual Maxtor DiamondMax 10 300GB drives in each using RTV 2.4. Both worked fine for a time and then would lose all setup information. If the drives are the Diamondmax 10s with 16 MB cache, there have been problems reported when used in a ReplayTV.

[JadeEast]

Thank you, yes they have 16MB cache. I bought these drives in November so there was no history at that time. I did a search and found that other people have had the same problems with these drives. What is the brand/model of the largest drive that works in the ReplayTV 5500?

[l8er]

Originally posted by JadeEast
What is the brand/model of the largest drive that works in the ReplayTV 5500? It would be easier to state which drives won't work in the 5XXX series ReplayTVs (http://www.replaytvupgrade.com/#drivecompatibility). From the ReplayTV DIY Upgrade/Repair/Information Site: www.replaytvupgrade.com.

[FlipFlop]

Originally posted by Freddy B.
The only twist to my experience was that I din't have a photo partition on the original drive, and wanted to create one during this process (I tried 500MB). During the patch process I was not asked about reformatting the Photo partition as FlipFlop and Gary had discussed above. Below is an excerpted portion of the dialog.

Was I not asked to format the photo partition during the patch because one was not detected on the source drive? Or is 500MB too small for a valid photo partition? When I launched DVArchive, the message seems to indicate so:
"02/27 17:52:24 DVR Living Room Photo space not allocated (less than 512MB) - Photos usage is disabled for this ReplayTV"

Sorry I missed your post the first time because you submitted at almost exactly the same time I posted mine.

The reason you weren't asked about the Photo partition is because it didn't need to ask. RTVPatch recognized that it needed to create the photo partition from scratch, and did so without prompting. If you look in the log you can see where it creates the 512MB photo partition.

Your results also prove that the photo partition IS working on the ReplayTV. DVArchive has a setting that expects a minimum 1GB photo partition, but since yours is "only" 500MB it reports that your photo partition is too small. However DVArchive has a "minimum partition size to enable photos" setting which you can set to allow DVArchive to work with photo partitions smaller than 1GB.

I did look over and test the code again, and the photo partition code is working fine in version 2.5.1

[FlipFlop]

I changed the logic for the "do you want to patch" prompt, so it only prompts after a "restore target" operation, or if you try to exit the program without patching. This way you won't get that prompt after every copy operation. I also added the ability to abort a copy operation (the exit button changes to a cancel button while copying).

New version (2.5.2) is attached.

[JadeEast]

Version 2.5.1 required one click to exit and now version 2.5.2 requires two clicks. In other words, to end the program requires clicking on the "exit" button or the x twice. Is this a feature? :-)

Also, thanks for all of your hard work on this program, it's greatly appreciated by all!

JadeEast

[FlipFlop]

Originally posted by JadeEast
Version 2.5.1 required one click to exit and now version 2.5.2 requires two clicks. In other words, to end the program requires clicking on the "exit" button or the x twice. Is this a feature?
This is a byproduct of the logic to prompt for patch on exit, but it wasn't intentional. I'll fix it.

[Freddy B.]

Originally posted by FlipFlop
Your results also prove that the photo partition IS working on the ReplayTV. DVArchive has a setting that expects a minimum 1GB photo partition, but since yours is "only" 500MB it reports that your photo partition is too small. However DVArchive has a "minimum partition size to enable photos" setting which you can set to allow DVArchive to work with photo partitions smaller than 1GB.

I did look over and test the code again, and the photo partition code is working fine in version 2.5.1

I agree that the log I posted indicates that the partition was created, but the ReplayTV can't "see" it.

Selecting "Photo Viewer" from the main menu on the ReplayTV simply gives the message "No space available in the photo directory".

My first attempt at reducing the minimum photo partition size to 256MB in DVArchive preferences, the "Photo Usage is Disabled" message went away, but the "Photos" folder was still not visible and Photo Manager options were not available. At this point a couple of days ago I gave up and posted what you saw before.

However, after reading your confident reply I decided to make another attempt. I selected the Photo Viewer on the RTV and again saw the "No Space Available" message. WIth this screen displayed I started DVArchive on my Powerbook (the first time it was actually started with the reduced allowable size in the settings), and immediately the THE PHOTOS FOLDER IS VISIBLE, and sure enough I am allowed to create sub-folders and load .jpg's onto the device.

The Photo Viewer menu on the RTV now shows the subfolders I created and will play slide shows. The "Screen Saver and Pause Screen" menu in setup will allow me to select the image folders and displays the images when it should.

So the new photo partition I created behaves exactly as expected with one exception. In the "Photo Viewer" menu, the "No space available in the photo directory" message IS STILL DISPLAYED, even though I have only put 15MB in the 500MB partition. So somehow the system seems to be reading what's on the partition, but since it was originally set up (before the HD upgrade) as zero size, it thinks it has no space in it no matter what?

Anyway, FlipFlop, thanks so much for providing this awesome software and working with us to test and improve it. And thanks Gary, Chris, and the others who helped get it and extract_rtv working on OSX. Hope I can help more with this effort in the future.

FB

[FlipFlop]

Looks like the ReplayTV also has a 512MB threshold for the "No space available" message. I hadn't heard of that before, but I can't say I've checked for it either. But from what you say it does work anyway, so this is good news. You can re-run the patch (just the patch, no copies, and don't format the MPEG partition) on your drive with a 1GB photo setting without losing any shows. (actually there is a slight risk you may lose anything that was written to the last 500MB of the the drive, but for a freshly patched drive it is unlikely that it has yet filled that part of the drive.

[gatomon]

I've been using it on Mac OSX to recover a number of videos off my 300GB Maxtor, 16M cache, drive. I'm planning to use the drive on my Mac for my DVArchive files (once I've recovered what I want). It would be nice to update extract_rtv to help with the process. I have a number of ideas and have written a small perl script to sort the listing.

One question: why does every file seem to have 2 cluster numbers
E.g.,
Valid inode (0x01f8) found at cluster 24312 (1109377798.mpg)
Valid inode (0x01f8) found at cluster 24313 (1109377798.mpg)
Valid inode (0x01f8) found at cluster 24314 (1109381397.mpg)
Valid inode (0x01f8) found at cluster 24315 (1109381397.mpg)
Valid inode (0x01e8) found at cluster 24316 (1109381397.ndx)
Valid inode (0x01e8) found at cluster 24317 (1109381397.ndx)
Valid inode (0x01e8) found at cluster 24319 (1109381397.evt)
Valid inode (0x01e8) found at cluster 24320 (1109381397.evt)
Valid inode (0x01e8) found at cluster 24323 (1109377798.ndx)
Valid inode (0x01e8) found at cluster 24324 (1109377798.ndx)
...
I've check and it seems that both cluster number will produce the same file
E.g,
extract_rtv -p2 -r 24312 and extract_rtv -p2 -r 24313 both recover 1109377798.mpg

Things that would improve the program:
1) fix -d options for 5xxx listings
2) add a "preview" option that would download a portion of an .mpg so that you could figure out what it is.
3) make a recover command that allows you to specify the file number (e.g., 1109377798) and it would recover the 3 files: .mpg, .ndx, .evt
4) write a perl gui to run extract_rtv

any other ideas? Anyone want to help?

-Chris

[FlipFlop]

Originally posted by gatomon
One question: why does every file seem to have 2 cluster numbers
All of the system and directory clusters have 2 identical copies stored on the hard drive, possibly for error recovery. http://rtvpatch.sourceforge.net/omfs.html

[FlipFlop]

Here is version 2.5.3. This is the same as 2.5.2, but you only have to press "exit" once to close the program.