# Does fakecall block a manual Connect to DVR Service?



## markis (Mar 1, 2005)

I have a rebooting HR10 running a zippered 6.3c, so I'm trying to force a call to get the 6.3e files into my /SwSystem.

I plugged in my phone line, but when I go the Settings > Phone > Connect to DVR Service Now, I get an error while "Negotiating."

Do I have to comment out fakecall.tcl from rc.sysinit.author and remove the network routing changes preventing normal phoning home to get a manual forced call with "Connect to DVR Service Now" to work?

I also ran add6x.tcl in case that will help me get the updates.

I've been searching for a comprehensive list of steps to upgrade a zippered 6.3c to 6.3e while retaining hacks (and shows and season passes, etc.), but I haven't had much luck. I currently only have 6.3c-01-2-357 showing in my /SwSystem.

Any other advice or links on moving from 6.3c to 6.3e would be greatly appreciated.

Thanks.


----------



## tall1 (Oct 12, 2004)

markis said:


> I have a rebooting HR10 running a zippered 6.3c, so I'm trying to force a call to get the 6.3e files into my /SwSystem.
> 
> I plugged in my phone line, but when I go the Settings > Phone > Connect to DVR Service Now, I get an error while "Negotiating."
> 
> ...


Nicdd will cause a conflict with the modem and calls out will fail. Comment out the start command for ./ncidd in your author file and reboot.

You can use slicer to preserve your hacks but that will require a purchase from dvrupgrade.


----------



## markis (Mar 1, 2005)

tall1 said:


> Nicdd will cause a conflict with the modem and calls out will fail. Comment out the start command for ./ncidd in your author file and reboot.


Thank you, that's exactly what I needed to know.


----------



## robn77 (Oct 26, 2001)

tall1 said:


> Nicdd will cause a conflict with the modem and calls out will fail. Comment out the start command for ./ncidd in your author file and reboot.
> 
> You can use slicer to preserve your hacks but that will require a purchase from dvrupgrade.


Thanks!

I was looking for this also. Mine would reboot when I tried to make the call.

I also had to comment the route lines in the author file as well as set the DEBUG_BOARD=true to get the call to go out.


----------



## markis (Mar 1, 2005)

Well, I didn't see ./ncidd in rc.sysinit or rc.sysinit author.

I edited:

/etc/rc.d/StageD_PreMfs/rc.Sequence_150.CheckForDebug.sh

and changed:

DEBUG_BOARD=true

(from false)

And commented out fakecall and the two route lines from rc.sysinit.author

Then I rebooted.

After that, I ran add6x.tcl for good measure.

Then I went into settings and tested the phone connection. It worked.

The I did "Connect to DVR Service Now" and that also worked. It went through all the stages, through Connecting and Loading... up to 100%. Now my Phone/Network status says "Pending Restart."

I telneted in again, and now I finally do have 6.3e-01-2-357 showing up when I do *echo mls /SwSystem | tivosh*.

So, these edits and the forced call did successfully download the 6.3e update to my machine. Now, I just hope I can following the other guides to update without losing my network connection and other hacks.


----------



## Da Goon (Oct 22, 2006)

markis said:


> Now, I just hope I can following the other guides to update without losing my network connection and other hacks.


You could try this. It's customizable and should work well in your case. I've used it for all my 6.3x upgrades.


----------



## markis (Mar 1, 2005)

Da Goon said:


> You could try this. It's customizable and should work well in your case. I've used it for all my 6.3x upgrades.


Thanks for the link. I believe I've just managed a manual upgrade.

I think I've successfully upgraded and things seem to be working as before (telnet, TWP and streaming video). The real test will see if I can get through a few days of CBS primetime without any reboots and hopefully 6.3e won't introduce any new problems.

I'll put some of my notes down here, in case they can help anyone else. My system is an HR10-250 6.3c which I upgraded to 6.3e.

This is not a complete guide and you'll have to do some thinking for yourself, depending on your hacks and directories. These are just notes, NOT a complete step-by-step of every single command. I disavow any responsibility if you screw things up.

I started with this old (and slightly outdated) DDB guide as a template:

xxxxxxxxxxxx.com/forum/showthread.php?t=51121 (thanks to cokekid)

The step numbers below refer to the steps in the link above

1) I got the 6.3e into my /SwSystem by forcing a call as explained in my earlier post (above). After the 6.3e file was on my system, I undid all the edits to block calls again.

2) add these changes if they are not already in your existing file

3) *installSw.itcl 6.3e-01-2-357*

4) do this

5) do this

6) On this step I made a lot of changes based on my system. You'll have to look at your directories and figure out what you need to do.

Basically, I found 6 directories that had hacks and created then on the new boot partition, then copied them over. DO NOT just copy these commands if you have different directories.

mkdir /mnt/busybox
mkdir /mnt/enhancements
mkdir /mnt/hacks
mkdir /mnt/var/hack
mkdir /mnt/var/mfs_ftp
mkdir /mnt/var/TWP

cd into each of these directories on the old partition and:

cp -r * /mnt/busybox
cp -r * /mnt/enhancements
cp -r * /mnt/hacks
cp -r * /mnt/var/hack
cp -r * /mnt/var/mfs_ftp
cp -r * /mnt/var/TWP

chmod 755 all copied directories

I followed the renaming of *iptables* and *dhclient*, but then instead of his echo command, I did the following:

cp /sbin/iptables /mnt/sbin/iptables

chmod 755 iptables

7) I skipped this step. I think my copied rc.sysinit.author was fine as-is.

8) Do the first 4 commands to make a backup of tivoapp, but *DO NOT* do any of the echo commands. The patch locations are changed in 6.3e. These are the new ones for 6.3e that I found in another thread (thanks to the original poster):

6.3e tivoapp patches

#No encryption
*echo -ne "\x3C\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=1601872*

#30-second skip
*echo -ne "\x10\x40\x00\x2b" | dd conv=notrunc of=tivoapp bs=1 seek=6717416*

#Backdoors
*echo -ne "\x24\x10\x00\x01" | dd conv=notrunc of=tivoapp bs=1 seek=2804964*

#HMO/HME
*echo -ne "\x34\x11\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=903776
echo -ne "\x24\x10\x00\x01" | dd conv=notrunc of=tivoapp bs=1 seek=1118188
echo -ne "\x10\x00\x00\x14" | dd conv=notrunc of=tivoapp bs=1 seek=5704588*

9) do all these steps (and cross your fingers)

That's it. Good luck!


----------



## Da Goon (Oct 22, 2006)

/var is always mounted on /dev/hda9. An upgrade won't change this. If you have hacks located in /var, you shouldn't have to touch them. The tivo does of course decide to wipe /var sometimes, so you may want to make a backup of anything in there before the upgrade, but you shouldn't need to copy anything.


----------



## markis (Mar 1, 2005)

Da Goon said:


> /var is always mounted on /dev/hda9. An upgrade won't change this. If you have hacks located in /var, you shouldn't have to touch them. The tivo does of course decide to wipe /var sometimes, so you may want to make a backup of anything in there before the upgrade, but you shouldn't need to copy anything.


Hmm, I see. Thanks. Anyway, I did go through the copy process, and actually I forgot to copy the /var/mfs_ftp directory and now it's gone. I tried to mount the old partition and look in /var, but it's empty. I believe what you're saying, but if that's the case, I'm not sure why my mfs_ftp disappeared and only the hack directories that I specifically copied are still there. I don't really use mfs_ftp much though, so I probably won't bother putting in on and patching and everything unless I really need to use it someday.


----------



## msiple (Oct 17, 2001)

My two HR10-250s have been rebooting while recording CBS OTA (see here). Following markis' directions, I successfully updated both to 6.3E and maintained my hacks (Thanks markis!).

One possible gotcha: When copying /busybox to /mnt/busybox, the destination filesystem (/dev/hda7) filled up. Why? /busybox contains mostly links (think: Windows shortcuts) to the /busybox/busybox binary. Using the cp command copies the link targets (ie the actual binary) instead of the links, eating up a lot of space. Luckily, the tar command can fix after emptying the target directory:

1. rm /mnt/busybox/*
2. cd /busybox
3. tar cvf /mnt/busybox/bb.tar ./*
3. cd /mnt/busybox
4. tar xvf bb.tar

Or... find the busybox installer on that other forum and reinstall.

As always, please don't attempt this unless you understand the possible outcomes of your actions.


----------



## Da Goon (Oct 22, 2006)

Or you could just use *cp -a* to preserve symlinks.


----------



## msiple (Oct 17, 2001)

That's even a better idea. I forgot to check cp's help to see if it had that switch. It's the same as: cp -dpR so the recursive is included as well.



Da Goon said:


> Or you could just use *cp -a* to preserve symlinks.


----------

