superpatch-67all - (Support)

[jt1134]

superpatch-1.2to1.12.diff.txt
superpatch-1.2to1.13.diff.txt

I typed the following (3) commands (in my Var directory):

./patch -o superpatch-6789all-NutKase-1.13.tcl < superpatch-1.2to1.12.diff.txt

You put 2 diffs in there and used the wrong one. try patch -o superpatch-6789.tcl < superpatch-1.2to13.diff.txt

[vhkounel]

jt1134, thanks for the quick response, I tried that but got the following error:
"bash: superpatch--1.2to13.diff.txt: No such file or directory"
I attached a screen shot of what is in my Var directory. Hope it helps.

[vhkounel]

jt1134, I noticed that I was missing the 1."1"3.diff in the command, I added that and it still did not work. I got that "Invalid option -- o" error. I then redid the command with the "./" in front of it and got the same "not supported error".

[jt1134]

You're misspelling the name of the diff. Do it exactly as the "ls" command shows it.

[vhkounel]

Here is what I did:
patch -o superpatch-6789.tcl < superpatch-1.2to1.13.diff.txt
- This did not work, I got that "patch: invalid option -- o error.
I then redid the command as:
./patch -o superpatch-6789.tcl < superpatch-1.2to1.13.diff.txt
- This produced the statement:
"patching file superpatch-67all-NutKase-1.2.tcl"

I then do the chmod and .superpatch commands but get the same 6.3e software not supported error.

Should I delete my old Diffs, is that screwing it up?

[vhkounel]

I tried some other commands and got a different result, instead of using "6789all" in my commands, I just used "67all" as follows:

./patch -o superpatch-67all-NutKase-1.13.tcl < superpatch-1.2to1.13.diff.txt
chmod 755 superpatch-67all-NutKase-1.13.tcl
./superpatch-67all-Nutkase-1.13.tcl

I got past the software version 6.3e not supported but then got an error:
Checking your tivoapp patch locations...

At offset 0x00587150, expected 0x0c16a600 but got 0x0c16a579
Aborting... You need a virgin tivoapp to patch.

Does this shed any light on what is up?

[BeagleBoy]

At offset 0x00587150, expected 0x0c16a600 but got 0x0c16a579
Aborting... You need a virgin tivoapp to patch.

It appears the values aren't quite correct for some of our tivoapps. I pulled a virgin copy from MFS to make sure, and got the same error.

Just apply the changes from this post. Works like a champ.

-Jim

[diamondsw]

It appears the values aren't quite correct for some of our tivoapps. I pulled a virgin copy from MFS to make sure, and got the same error.

Just apply the changes from this post. Works like a champ.

-Jim

Updated the patch with the corrected expected values. Do you mind checking the other few as well? I don't have access to a 6.3e Tivoapp - I do all of this blind based on the forum posts.

[sucram65]

I generally monte into the current kernel that I've run replace_initrd against. I hadn't done that part yet when I posted the above, I was using an older kernel. Tonight I ran replace_initrd against the current, 9.1 kernel. So, now I'm monteing into the current kernel and now the 30 second skip works.

As always, thank you greatly Shutterfriend!, your efforts are much appreciated.

Interesting. I monte also from 3.1.1c to Jamie's custom kernels. I had been using his Series 7.2 kernel but switched to his 8.x kernel for this update. I have not had much time for messing around with the Tivo lately but I would like to try the 7.2 kernel again to see if the 30 second skip is enabled by default as opposed to the 8.x kernel.

[Jamie]

It is hard for me to see how this could be a kernel issue.

Reports on TCF are that the 30sec skip backdoor remote key sequence is now "sticky" across reboots. Once you set it, you don't have to do it again, even after a reboot. So it must be stored somewhere, perhaps in MFS. It might well be that the old patch doesn't work anymore -- I haven't tried it.

[ocntscha]

It is hard for me to see how this could be a kernel issue.

Reports on TCF are that the 30sec skip backdoor remote key sequence is now "sticky" across reboots. Once you set it, you don't have to do it again, even after a reboot. So it must be stored somewhere, perhaps in MFS. It might well be that the old patch doesn't work anymore -- I haven't tried it.

I'll check it out a little more thoroughly. I thought it was pretty odd that the kernel could make a difference but didn't really delve into it. When 30 second skip wasn't turned on by superpatch I did Google up the 30 second skip remote code and use it. I thought I had turned it off again via the remote though prior to setting up monte and then after I set up monte 30 second skip was enabled and I was attributing it to superpatch. Maybe it's just been the remote code all along, I'll check into it.

[ocntscha]

I did a little testing. I disabled 30 second skip via the remote code and rebooted, it was still disabled. I enabled it and rebooted, it was still enabled. I think the new 30 second skip remote code now surviving reboots feature is what had me believing it was happening via superpatch and the newer kernel I'd switched to. Appears its all due to the remote code and only the remote code.

[ScanMan]

Superpatch port for 9.2a (Series3, TivoHD) has been posted here.

[jkozee]

ScanMan,
I think there might be a missed address update in your port. I posted the specifics in your other thread.

Superpatch port for 9.2a (Series3, TivoHD) has been posted here.

[digdug]

Is there support for version 7.2.0a-oth-01-2-540? I have two units with this version and would love to get MRV working between my DTIVO units running 6.2a and these TCD540080 after spending the last several days getting them "PROM". Or should I just try to find a version supported by SuperPatch?