[George Be]

(1) Does anyone know how to contact the main developer for RTVPatch? Or if you're watching this forum, would you please reply or PM me?


(2) I don't know if this is an OK place to be looking for support for RTVPatch, but I've tried posting on the SourceForge Support forum for RTVPatch, and haven't gotten any response yet. Here's my problem:


I have a 4320 that has a problem with one (or both) of the two 160 Gb disks. I have been sent a replacement 4320 from Replay, and now I want to transfer all my shows from the old Replay to the new one. Unfortunately, I have a lot of shows! The Replay shows only about 50 hours (at lowest quality) left. So I have data on BOTH disks. Even if I blow off shows until I have less than 160 hours, I'm assuming that programs recorded on the second disk will not get reshuffled onto the first disk.


Replay suggested using RTVPatch to do the data transfer, but I'm not sure if it will work, for a number of reasons. So, my questions are:

(1) Given that everything else is set up right, can I use RTVPatch to transfer the data from master(old) to master(new), and slave(old) to slave(new)? At one point, their documentation says that RTVPatch will NOT work with "second" drives, but I'm not sure if that applies in this situation, or if it has perhaps been fixed in newer releases. If so, could somebody describe this process in detail (i.e. what are the tricks, jumper settings, etc. to make it work?)


(2) This will sound very newbie, but... I am assuming I'll have to use the XP version of RTVPatch in order to accommodate the 160 Gb drives. I have a laptop available with XP installed, but like all other computers sold today, they don't provide an XP install/boot CD! Can I create a "bootable floppy" or "bootable CD" from the XP operating system? (You don't have to go through every detail, just let me know how this works, IF it works, and maybe point me in the right direction.)


(3) Anybody got any BETTER ideas as to how to accomplish this transfer I have in mind? It seems like the transfer facility would have to be "aware" of the file system used on the Replay disks, since even a "bit-for-bit" copy would have to be aware of bad sectors on the "destination" disk, and account for sector placement accordingly.


Thanks,

George

 

[Mikeyboy]

 [email protected] is the man!


To use RTVPatch with your laptop there is a firewire version available at http://sourceforge.net/project/showf...group_id=17245


If the hard disk data is intact on your broken replay swap the drives or do sector to sector clone.


If the operating system is corrupt (maybe the reason you RMA'd the unit) you are out of luck. The operating system and the MPG's must be copied from the same drive (RTVPatch copies the MPGs to the same location on target disk) or the MPGs will not be pointed to. As far as I know RTVPatch will not copy MPGs from the second drive of a dual drive system.


The typical way to save replay recordings from a non functional replay is mirroring to PC with extract_rtv http://www.geocities.com/flipflop7146/#extract_rtv

 

[sfhub]

Quote:

Originally posted by Mikeyboy To use RTVPatch with your laptop there is a firewire version available at http://sourceforge.net/project/showf...group_id=17245

When I tested, it appears to work with USB also.

 

[George Be]

Hi, Mikeyboy,


Hate to ask "duhhh..." questions, but at the risk of sounding dumber than I am:

(1) What good would a Firewire (or for that matter, USB) version do me? The Replay box has neither, and the drives are an IDE interface.


(2) When you say "sector to sector transfer", how would I accomplish that? What software, procedure, etc? And wouldn't the software have to be "aware" of the Replay file-allocation system? (translation: have you ever actually done this and had it work? ) Would there be any problems doing this on the "second" drive, as opposed to the first? (Theoretically, I could use RTVPatch for transferring the info between the "first" drives.)


To give you a little more info:

The problem I am experiencing is seeing several rows of green dots flashing up on the screen, maybe 10 dots by 15 rows, for just an instant - maybe a single frame's worth of image. If I do an "Instant Replay" or play the program again, the dots will NOT be there (i.e. they are not recorded on the drive.) This happens maybe once a day (or at least, that's about how often I SEE it.)


My initial assumption was that the problem was in the buffer RAM in the Replay unit; however, I have now swapped drives (old drives in new unit), and the problem has followed the drives! So about the only thing left would be a defect in the buffer memory resident on one (or both) drives. Or else, it's a problem somewhere ELSE in the chain of connections that are specific to the Replay, in which case I'll scream and tear my remaining hair out!!!! But I'm not seeing this problem on any of my other video sources, so the Replay seems to be the most likely culprit.


Thanks,

GB

 

[Mikeyboy]

Quote:

Originally posted by George Be Hi, Mikeyboy, Hate to ask "duhhh..." questions, but at the risk of sounding dumber than I am: (1) What good would a Firewire (or for that matter, USB) version do me? The Replay box has neither, and the drives are an IDE interface. Remove the drive(s) from the replay and connect into an external USB carrior. The drive can function through USB or fire wire with the laptop. http://www.pricegrabber.com/search_g...3c5839dc326705 (2) When you say "sector to sector transfer", how would I accomplish that? What software, procedure, etc? And wouldn't the software have to be "aware" of the Replay file-allocation system? (translation: have you ever actually done this and had it work? ) Would there be any problems doing this on the "second" drive, as opposed to the first? (Theoretically, I could use RTVPatch for transferring the info between the "first" drives.) I would use linux DD commands with a linux boot disk. You would have to have a new PC so the full 160 gigs is recognized by the motherboard. ATA controller cards may not work with linux boot disk. The "DD if" statement carries the format with it so you end up with a duplicate. Same as your bit by bit idea. To give you a little more info: The problem I am experiencing is seeing several rows of green dots flashing up on the screen, maybe 10 dots by 15 rows, for just an instant - maybe a single frame's worth of image. If I do an "Instant Replay" or play the program again, the dots will NOT be there (i.e. they are not recorded on the drive.) This happens maybe once a day (or at least, that's about how often I SEE it.) My initial assumption was that the problem was in the buffer RAM in the Replay unit; however, I have now swapped drives (old drives in new unit), and the problem has followed the drives! So about the only thing left would be a defect in the buffer memory resident on one (or both) drives. Or else, it's a problem somewhere ELSE in the chain of connections that are specific to the Replay, in which case I'll scream and tear my remaining hair out!!!! But I'm not seeing this problem on any of my other video sources, so the Replay seems to be the most likely culprit. Your green dot problem has a familiar ring. I wonder if you'll find a few posts about that using this web sites search engine. Thanks, GB

 

[Mikeyboy]

 http://www.avsforum.com/avs-vb/showt...ght=green+dots

http://www.avsforum.com/avs-vb/showt...268#post801268

http://www.avsforum.com/avs-vb/showt...230#post791230

 

[Mikeyboy]

What I know about LINUX wouldn't fill a thimble. Anyway this code works with the LINUX boot disk available at RTVPatch web site. It will create a duplicate of hda drive to hdc drive including the format, data and partitions. Example - if you copy a 60 gig to a 100 gig you end up with only 60 gigs accessible on the 100 gig.


dd if=/dev/hda of=/dev/hdc


hda is the drive attached to primary IDE ribbon jumper set to "Master".


hdc is the drive attached to Secondary IDE ribbon jumper set to "Master".

 

[sfhub]

Quote:

Originally posted by Mikeyboy Remove the drive(s) from the replay and connect into an external USB carrior. The drive can function through USB or fire wire with the laptop. http://www.pricegrabber.com/search_g...3c5839dc326705

If you choose to go this route, make sure your enclosure chipset

supports > 137GB if you are using the 160gb disks.


I've found the following enclosure is relatively inexpensive, has been

tested with 250GB maxtor, has highly rate oxford 911 ieee1394 chipset

and ali usb 2.0 chipset. Use coupon code TECHBARGAINS for 10% off,

only 3.5" drives though. ($53+shipping)
http://www.compgeeks.com/details.asp?invtid=ME-320U2F


If you just need usb 2.0, this unit is slightly cheaper, will support >137GB,

ALI USB 2.0 chipset, and will fit 3.5 and 5.25 drives ($40):
http://www.dealsonic.com/bytidetousb2.html

 

[George Be]

Thanks, all, for the information!


(1) It never OCCURRED to me to search this Forum for "green" (dots or grid)! I guess that IS a bit of a "duh", but in my own defense, I had asked Replay Support about this problem, and they said they weren't aware of this being a known problem and did not know of a cause for it! Should have KNOWN better than to trust Support!


So I may be chasing my tail on this whole thing!! Maybe I should do a poll to see how many people see the green dots? (My SO watches lots of shows with me, and she NEVER notices the green dots, even when I say "there! Did you see them just now?")


(2) I'm at about the same point YOU are with Linux, Mikeyboy! I've rubbed elbows here and there with a few Unix-based systems, but that's about all. I had a suggestion from someone to use Knoppix ( www.knoppix.net ) to do the transfer, using "dd" as you suggested, but the correct switches for the command-line interface were too cryptic for me to figure out. (Knoppix seems to be a Linux-type Unix variant, which can boot from a CD, and has lots of user-friendly auto-detection stuff.) If I decide to proceed with this transfer, I'll try the switches as you suggested.


(3) sfhub, thanks for the USB/Firewire info! I can see how the various RTVPatch versions would work if I had those adaptors, but I'm trying to minimize the additional $$$ I'm expending on this process (I'm already going to have to plunk down for an IDE adaptor which will handle the large drives!)


Thanx,

GB

 

[sfhub]

Quote:

Originally posted by George Be ... (3) sfhub, thanks for the USB/Furewire info! I can see how the various RTVPatch versions would work if I had those adaptors, but I'm trying to minimize the additional $$$ I'm expending on this process (I'm already going to have to plunk down for an IDE adaptor which will handle the large drives!)

Not sure if you have plans to buy more large drives, but many of the

160+GB retail kits still include free promise IDE controller in the package.


Also if you are paying $10-20 for IDE controller that is probably the best

route in terms of $ spent, but if you are in the $20-30 range for IDE

controller just to read larger drives, then you might as well get an

enclosure instead of IDE controller. Gives you more flexibility to use

drives on desktop and laptop.

 

[cweb]

When shopping for Maxtor drives some were listed as "raw". What is raw and is this the type we should be using?

 

[George Be]

Generally a "raw" drive means a drive without mounting brackets, cables, screws, software, etc. Depending on what you're doing with the drive, this may or may not be fine (i.e. if you're replacing an existing drive, you probably don't need the extras.) However, it's always a good idea to check with the seller to see what "raw" means to THEM.

 

[BaysideBas]

Other terms used for them are "bare" and "OEM", never heard "raw" applied in this manner. Must be something new.

 

[toots]

I'll echo the suggestion to boot Linux off something and use "dd" to image the second drive. This obviously assumes that the old and new drives have the same number of sectors, of course, or at least the new drive is greater than or equal to the old drive in size.


In fact, if you're just going from two 160s to two 160s, you could probably image both of them with dd and skip RTVPatch entirely.


The "green grid" thing has been observed ever since the 4000 series was released. I saw it on day 1 with my 4080 and 4040.

 

[George Be]

Thanks, Toots. In fact, I have now accomplished the transfer, using Knoppix (a variant of Linux which runs off 1 CD and will boot off the CD or with a floppy "boot disk" which finds and references the CD.) I'm going to write up the gory details of the process in a few days and post them here. (There were a few wrinkles involved!)


It's unfortunate that RTVPatch doesn't handle "second" drives. It would have been a lot easier with that nice clean GUI interface; plus, I'm sure they could figure out a way to allow you to upgrade to a larger second drive in the process. FlipFlop said that they had no plans to add this feature, but maybe if enough people ask him for it....


The interesting part is that even after transferring all the data to the new drives, I'm STILL seeing the green dots!! I was surprised when Mikeyboy pointed out the number of other people who have seen this problem (see above.) So apparently, this is a problem that is inherent in certain lines of Replay machines, but not everybody notices them (my SO has NEVER seen them, even when I say "there! Did you see that???")


I'm a bit stalled as to what to do next. I guess I need to drop a line to ReplayLyndon and let him know what's going on. Maybe he'll want to do a poll here in this Forum. Any other suggestions?


GB

 

[toots]

Funny.


I thought ReplayLyndon once explained why these things happen.


The explanation, as I remember, is largely due to a transient data starvation in the MPEG decoder, I think.

 

[toots]

And, yes, technically, it's a not-too-complicated feature to add to RTVPatch, but nevertheless, so far no one's found it to be important enough to implement it. You volunteering?


Of course, 'til now (and external USB/Firewire drives), the primary issue would be how the heck you boot your system with two pairs of ReplayTV drives hooked up.


I could've done it on my SCSI system (which has no IDE hard drives attached), and others with extra IDE controllers might, but it's a bit out of the range of the usual PC to be able to accomodate that many extra hard drives.

 

[Creech]

I'm curious as to why SB sent a hard drive rather than you sending the whole unit for repair. Surely this means you have to break the warrantee seal essentially making the unit hands off for ever by DNNA...

 

[Jeff D]

That's what I was thinking Creech, including the refrence to RTVPatch... odd.



Bummer the rtvpatch source files in cvs are out of date on sourceforge. Flipflop doesn't want to update? =(


OT on the green dots, can you single step through and see them? If you see them remember the spot, IR and play til just before the spot. Pause and use FF to step through the frames, or is this a transfer rate problem from data getting from the disk to the decoder? (toots comment)

 

[Ghoul]

dd if=/dev/hda of=/dev/hdc


I believe dd is included on the Linux RTVPatch floppy. It would be easy to just write a script "copy" that dupes a disk using dd.


I never understood why anyone would feel better about using a hard disk patching utility on a live OS boot. My recomendation to everyone is to remove all HDs that you might have in your computer and hook up only the ReplayTV drives. Then use the linux boot disk.


BTW...


if = input file

of = output file


file in this case is /dev/hda[something]


/dev is the device tree under unix.

hda[something] is the specific instance of the drive


Some people think dd means disk duplicate