ah ok
the 24 hour auto-delete is a feature of newer software, and unrelated to the old school NoPPV patch
Looking to keep my PPV's Like i have with my older T60's. They auto delete after 24 hours.
ah ok
the 24 hour auto-delete is a feature of newer software, and unrelated to the old school NoPPV patch
any way to "disable" this feature?
Do any of the patches have an effect on the Amazon rentals?
Here are tivoapp patches that can be used in place of the current NoCSO patch to disable the encryption of new recordings while still allowing MRV transfers of existing encrypted recordings.
Code:11.0d 0x005d3a10 "92220024 27a40028" 0x005d3a14 "104000aa 0c156fd6" 0x005d3a18 "27a40028 00000000" 0x005d3a1c "0c156fd6 0c477c51" 0x005d3a24 "8fa20020 106000aa" 0x011df11c "27bdfec8 03e00008" 0x011df120 "afb40128 24020001" 0x011df144 "00a0a021 8e230040" 0x011df148 "0c1b6110 10600002" 0x011df14c "00602821 00000000" 0x011df150 "00408021 8c630000" 0x011df154 "1200000a 03e00008" 0x011df158 "00001021 8fa20020"
Last edited by DeusExMachina; 01-27-2010 at 08:15 PM. Reason: Removed errant patch (0x005d9abc)
I finally got around to trying this. The system boots fine, but the first thing I tried for 2 patched tivoHD units, copying an encrypted show from the other Tivo failed and rebooted
It asked if I want to transfer this recording. I clicked it, and 7 seconds later, bam reboot on rcving machine
THis was my patch batch file. I did check every item was the old value using hexdump before attempting patch
#!/bin/sh
#eko patch for 11.0d
#
echo -ne "\x27\xa4\x00\x28" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=1915408
echo -ne "\x0c\x15\x6f\xd6" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=1915412
echo -ne "\x00\x00\x00\x00" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=1915416
echo -ne "\x0c\x47\x7c\x51" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=1915420
echo -ne "\x10\x60\x00\xaa" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=1915428
echo -ne "\x0c\x47\x7c\x49" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=1940156
echo -ne "\x03\xe0\x00\x08" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545180
echo -ne "\x24\x02\x00\x01" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545184
echo -ne "\x8e\x23\x00\x40" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545220
echo -ne "\x10\x60\x00\x02" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545224
echo -ne "\x00\x00\x00\x00" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545228
echo -ne "\x8c\x63\x00\x00" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545232
echo -ne "\x03\xe0\x00\x08" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545236
echo -ne "\x8f\xa2\x00\x20" | dd conv=notrunc of=tivoapp.ptandeko bs=1 seek=14545240
TIVOBDRM:/var/hack#
Now the really bad news
The receiving Tivo rebooted. But now it is in a reboot loop.
It reboots, the welcome startup screen (Powering up, few minutes more) comes up, then the cute startup video, and 3-4 seconds into it, it reboots again.
I am assuming it is something failed in MFS check or something.
So.......
1) How can I find out what is failing?
2) Even if I can find out what is failing, is there any way to fix it?
I remember the kickstart that used to fix it.
Green screen stuff and an mfscheck comes to mind.
Any ideas how to get this working again?
3) Thinking about it, it could be failing over and over in the new patch. If sees an incomplete file and runs through the patch code to resume the transfer and dies again. I have not been able to keep it up long enough to put back the correct tivoapp
Might have to pull the drive to rename them.
Ideas?
kernel log should contain the crash dumps which may hold some clues. tvlog and tverr should also have some information showing where exactly in the code it is failing
there usually is2) Even if I can find out what is failing, is there any way to fix it?
I would humbly suggest to continue troubleshooting in a new thread, to keep the clutter out of this one, though
I know this is late to the party, but, I've had something similar to this. The receiving tivo has the transfer req in the todo list. you need to remove it from there. either quick enough via the tivo ui or with scripting done before it tries to start the transfer. try disconnecting it from the network and see if it still reboots.