11.0k starting to roll out

[psxboy]

You're missing the point... it ignores the SIGNATURE. Once you get it to do that, you can then modify/remove values from the DRM object without causing tivoapp to object. Otherwise, it would compare the values to the signature and invalidate the recording if they don't match. But simply causing the signature to be ignored without making any changes does nothing at all.

Also, stuff you download from other sources (Amazon, VOD, etc) has an additional layer of encryption & rules applied to it that your regular recorded stuff does not. I've not examined the effect of changing DRM values on those types of recordings.

And finally, on another note... I don't know why people are so keen to remove the Tivo drive or otherwise connect it to a PC in order to complete an upgrade. You can do the same thing from a telnet session while the Tivo is running without ever touching the drive. I posted a high-level overview of how I handle upgrades here.

-psxboy

[Soapm]

Hmm. Wait a minute, that is byte-swapped: 10 40 00 aa vs. 40 10 aa 00

That looks to me like the wrong version of the code was run. On an x86 platform, the script needs to do the following to convert from the "human readable" file format to hexadecimal code to be inserted into the tivoapp binary:.

I knew it was something I was doing since I thought I was using the same file you previously used. I guess it wasn't...

[Soapm]

And finally, on another note... I don't know why people are so keen to remove the Tivo drive or otherwise connect it to a PC in order to complete an upgrade. You can do the same thing from a telnet session while the Tivo is running without ever touching the drive. I posted a high-level overview of how I handle upgrades here.

-psxboy

Maybe it's a good excuse to blow the dust out with canned air

Seriously, after reading your steps I can confidently say I don't have your skill set (especially modifying the partition table???)..

[jmartz]

I did the tivoapp hacks by renaming the file in telnet, creating a copy of that file with the tivoapp name, editing that new file and rebooting. (being that I pretty much use windows, it's not normally possible to rename a working file while it's active... then creating a copy of the working file with the old name [now inactive so it can be edited], just never crossed my mind!) The hacks work fine.

I needed to pull the drive because I had no way to load MFS_FTP or Tivotools. Once I had the .RAR files in the proper places, I booted the tivo and went back into telnet and did the rest from there. I can now FTP into the tivo root and download/upload and modify the files that way.

I also "kind of" have MFS_FTP working. I can connect, list, but the second I try to download it kills the connection. So I have to figure out what is wrong with that. But that's for another topic, I think I am getting closer to the solution. This morning I couldn't even connect. Once I get that working and can download shows, I want to try and install TivowebPlus. But progress in small steps. And at least next time I can use the terminal to get the shell access, and FTP to edit/upload whatever needs to be edited.

And yes, being that I haven't worked in the Linux environment for nearly a year probably made things a bit more challenging.

[lrhorer]

You're missing the point... it ignores the SIGNATURE. Once you get it to do that, you can then modify/remove values from the DRM object without causing tivoapp to object. Otherwise, it would compare the values to the signature and invalidate the recording if they don't match. But simply causing the signature to be ignored without making any changes does nothing at all.

OK, I see.

Also, stuff you download from other sources (Amazon, VOD, etc) has an additional layer of encryption & rules applied to it that your regular recorded stuff does not. I've not examined the effect of changing DRM values on those types of recordings.

...and even if you had, talking about it here would be verboten.

And finally, on another note... I don't know why people are so keen to remove the Tivo drive or otherwise connect it to a PC in order to complete an upgrade.

Well, before I employed mike_s' fine methods for scripted upgrades, I used to pull the drive for several reasons:

1. It was easier. With the primary drives being external to the TiVos and a tarball with all the hacks just sitting and waiting to transfer, it only took a minute to re-hack the Tivo by pulling the drive, plus boot times, of course.

2. Sometimes /var gets wiped. In or outside of an upgrade, having a ready-and-waiting tarball made replacing /var oh so much easier, and increased the attractiveness of #1 as a side benefit.

3. Before I increased the size of the partitions in order to implement mike_s' suggestions, it was not uncommon for me to run out of space on the root partition when upgrading, especially when hacking tivoapp.

4. It is fairly difficult to over-estimate the value of having a full blown Linux machine managing the drive when upgrading it rather than the highly limited OS found on the TiVo.

You can do the same thing from a telnet session while the Tivo is running without ever touching the drive.

Of course. Indeed, the changes I just made to the hack_tivoapp script make that proposition considerably easier, I would hope.

[lrhorer]

Seriously, after reading your steps I can confidently say I don't have your skill set (especially modifying the partition table???)..

Using tivopart, it's really not very difficult, at all, just tedious and a bit nervewracking. When expanding and moving the partitions on my three TiVos, I know I must have wiped one or more partitions at least five times on each TiVo before I had it rght. Even then, it wasn't "right". I forgot to increase the size of the swap partition on all three TiVos.

[psxboy]

Well, before I employed mike_s' fine methods for scripted upgrades, I used to pull the drive for several reasons:

Hehe... I know. We've had this argument before. But no matter how you slice it, doing the upgrade via telnet with a single reboot at the end is always gonna be faster (and for me, easier) than pulling the drives and doing it from a PC. But to each his own - whatever works for you.

2. Sometimes /var gets wiped. In or outside of an upgrade, having a ready-and-waiting tarball made replacing /var oh so much easier, and increased the attractiveness of #1 as a side benefit.

You're right, and that's why I keep my /var backup tarballs in my custom hda1. Just mount it, restore /var & you're done. All on the Tivo via telnet. And btw, /var only gets wiped if it exceeds 40% capacity (or something close to that - I'm going from memory) or if it fails the fsck twice at boot time.

-psxboy

[lrhorer]

Hehe... I know. We've had this argument before. But no matter how you slice it, doing the upgrade via telnet with a single reboot at the end is always gonna be faster (and for me, easier) than pulling the drives and doing it from a PC. But to each his own - whatever works for you.

Surely, and of course now what I do myself is a scripted upgrade from the running TiVo, so there's no way I am arguing pulling the drive is inherently better. It's just there can be valid reasons one might choose to hack by pulling the drive.

You're right, and that's why I keep my /var backup tarballs in my custom hda1.

Yeah, me too, except I keep it and the scripts, etc. in /dev/hda2 with an identical copy in /dev/hda5, just in case.

Just mount it, restore /var & you're done. All on the Tivo via telnet. And btw, /var only gets wiped if it exceeds 40% capacity (or something close to that - I'm going from memory) or if it fails the fsck twice at boot time.

Right, and since I moved all the hacks out of /var itself and into a mounted filesystem under /var, there is less chance of filling up or corrupting /var. Maybe one of these days I should expand /var a bit, too:

HD_Theater:/# pdisk -l /dev/hda

stat: mode = 060660, type=Block
size = 0, blocks = 0
HDIO_GETGEO: heads=255, sectors=63, cylinders=46593, start=0,  total=748516545
Partition map (with 512 byte blocks) on '/dev/hda'
 #:                type name                              length   base       ( size )
 1: Apple_partition_map Apple                                 63 @ 1          (  31.5K)
 2:                Ext2 Hack 1                            524288 @ 64         ( 256.0M)
 3:               Image Kernel 1                            4096 @ 524352     (   2.0M)
 4:                Ext2 Root 1                            524288 @ 528448     ( 256.0M)
 5:                Ext2 Hack 2                            524288 @ 1052736    ( 256.0M)
 6:               Image Kernel 2                            4096 @ 1577024    (   2.0M)
 7:                Ext2 Root 2                            524288 @ 1581120    ( 256.0M)
 8:                Swap Linux swap                        262144 @ 2105408    ( 128.0M)
 9:                Ext2 /var                              524288 @ 2367552    ( 256.0M)
10:                 MFS MFS application region            589824 @ 2891840    ( 288.0M)
11:                 MFS MFS media region               216747008 @ 3481664    ( 103.3G)
12:                 MFS Second MFS application region     589824 @ 220228672  ( 288.0M)
13:                 MFS Second MFS media region        268617728 @ 220818496  ( 128.0G)
14:                 MFS New MFS Application                 1024 @ 489436224  ( 512.0K)
15:                 MFS New MFS Media                 1465647104 @ 489437248  ( 698.8G)
16:          Apple_Free Extra                         1951944816 @ 1955084352 ( 930.7G)

[Heartbreaker]

Is there an 11.0L?I noticed my Tivo isn't connecting to the Tivo Central anymore...

[lrhorer]

No, 11.0k is the most recent.