Premiere Hard drive upgrade

[puffdaddy]

Technical/complexity/effort problem, I believe (perhaps Spike or others can comment).

Because there is no documentation on TiVo's Media File System (beyond the public fruits of others' reverse engineering efforts), developing tools to do expansion would require a high-level of expertise and might also be fairly time-consuming. It also wasn't needed previous for the vast majority of cases (only for folks attempting to expand an already expanded drive) as MFSadd supported their needs. I believe that Jamie concocted the partition coalesce method while contemplating developing a MFS resize tool (perhaps Jamie can comment).

That said, the development of a tool to resize an existing MFS partition would be undoubted welcomed by all the TiVo Premiere upgraders out there (the thread on TCF bears witness to this).

[comer]

I appreciate your reply, puffdaddy.
I am looking into MFS Tools 1.4 code to see if I can better understand what's required.
I have to say that I hit a snag in the most unxepected place - I don't understand how MFS checksum is computed. For the sake of clarity, here's the code in question:

Code: Select all

01: int
02: mfs_compute_crc (unsigned char *data, unsigned int size, unsigned int off)
03: {
04:    unsigned int CRC = 0;
05:    static const unsigned char deadfood[] = { 0xde, 0xad, 0xf0, 0x0d };
06:    off = off * 4 + 3;
07:
08:    while (size)
09:    {
10:       if (off < 4)
11:       {
12: /* This replaces the checksum offset without actually modifying the data. */
13:         CRC = UPDC32 (deadfood[3 - off], CRC);
14:      }
15:      else
16:      {
17:         CRC = UPDC32 (*data, CRC);
18:      }
19:      data++;
20:      size--;
21:      off--;
22:   }
23:
24:   return htonl (CRC);
25:}


Now, the header size is 280 ("64" variety) if I calculate correctly. Offset - is an offset of the checksum in the header - always 8. So, at line 6 offset becomes 8*4+3 = 35 and governed by the condition at line 10, first 32 bytes are counted into CRC directly, the next 4 are replaced with "deadfood" and the rest (280-4-32=244) are replaced with garbage - beyond the bounds of "deadfood" array.
That seems very strange. Do I understand correctly or I am just blind?
Judging by the comment above this function I think it should be

Code: Select all

06:    // off = off * 4 + 3; - no adjustment
...
10:       if ( (off > -1) && (off < 4) )


I.e. replace the original checksum with "deadfood" and the rest of the data to the byte goes directly.

[puffdaddy]

Unfortunately, I don't know. I haven't looked through that code, which I believe has been unchanged since Tiger's code: http://sourceforge.net/projects/mfstools/files/. You might also look at this thread on DDB: http://www.dealdatabase.com/forum/showt ... hp?t=39487 In post #6, Jamie states "Fix the broken -f (fix crc) option to mfs_info."

Short of that, perhaps Spike or Jamie can answer your question.

[comer]

Gee, I think I was blind All the time I was befuddled - the code obviously works, but I didn't get how Finally, I got it:
1. Offset is in "int" sizes, not bytes. Therefore "*4" (perhaps "*sizeof(int)" would be clearer).
2. It's an unsigned int - hence below 0 comes MAX_INT, not -1

[comer]

Hi All,

It's been a while I dug through the code a bit to better understand the disk structure and I got a couple of ideas that I want to run by you.

First, here's the structure of 320G virgin Premiere disk:

Code: Select all

Partitions (partition number) sorted by start block
------------------
15:         start=         0, size=         0 (  0.00b), type=''                   , name=''
1 :         start=         1, size=        63 ( 31.50K), type='Apple_partition_map', name='Apple'
13:         start=        64, size= 343828320 (163.95G), type='MFS'                , name='MFS media region 2'
2 :         start= 343828384, size=         1 (512.00b), type='Image'              , name='Bootstrap 1'
3 :         start= 343828385, size=     16384 (  8.00M), type='Image'              , name='Kernel 1'
4 :         start= 343844769, size=    524288 (256.00M), type='Ext2'               , name='Root 1'
5 :         start= 344369057, size=         1 (512.00b), type='Image'              , name='Bootstrap 2'
6 :         start= 344369058, size=     16384 (  8.00M), type='Image'              , name='Kernel 2'
7 :         start= 344385442, size=    524288 (256.00M), type='Ext2'               , name='Root 2'
8 :         start= 344909730, size=    262144 (128.00M), type='Swap'               , name='Linux swap'
9 :         start= 345171874, size=   1048576 (512.00M), type='Ext2'               , name='/var'
14:         start= 346220450, size=   6291456 (  3.00G), type='Ext2'               , name='SQLite'
10:         start= 352511906, size=   1638400 (800.00M), type='MFS'                , name='MFS application region'
12:         start= 354150306, size=   1638400 (800.00M), type='MFS'                , name='MFS application region 2'
11:         start= 355788706, size= 269353742 (128.44G), type='MFS'                , name='MFS media region'
------------------

Zones Logical ([zone number] disk:partition) sorted by logical start block
------------------
  [0] 0:10  start=      1121, size=         1 (512.00b), end=      1121      NODE descriptor
  [0] 0:10  start=      1122, size=    524288 (256.00M), end=    525409      NODE data
  [1] 0:10  start=    525410, size=        10 (  5.00K), end=    525419      MEDIA descriptor
  [2] 0:10  start=    525420, size=       130 ( 65.00K), end=    525549      APP descriptor
  [2] 0:10  start=    525550, size=   1112704 (543.31M), end=   1638253      APP data
  [1] 0:11  start=   1638400, size= 269352960 (128.44G), end= 270991359      MEDIA data
  [3] 0:12  start= 270991360, size=         1 (512.00b), end= 270991360      NODE descriptor
  [3] 0:12  start= 270991361, size=    524288 (256.00M), end= 271515648      NODE data
  [4] 0:12  start= 271515649, size=        18 (  9.00K), end= 271515666      MEDIA descriptor
  [5] 0:12  start= 271515667, size=       130 ( 65.00K), end= 271515796      APP descriptor
  [5] 0:12  start= 271515797, size=   1113808 (543.85M), end= 272629604      APP data
  [4] 0:13  start= 272629760, size= 343818240 (163.95G), end= 616447999      MEDIA data
------------------

Zones Physical ([zone number] disk:partition) sorted by physical start block
------------------
  [4] 0:13  start=        64, size= 343818240 (163.95G), end= 343818303      MEDIA data
  [0] 0:10  start= 352513027, size=         1 (512.00b), end= 352513027      NODE descriptor
  [0] 0:10  start= 352513028, size=    524288 (256.00M), end= 353037315      NODE data
  [1] 0:10  start= 353037316, size=        10 (  5.00K), end= 353037325      MEDIA descriptor
  [2] 0:10  start= 353037326, size=       130 ( 65.00K), end= 353037455      APP descriptor
  [2] 0:10  start= 353037456, size=   1112704 (543.31M), end= 354150159      APP data
  [3] 0:12  start= 354150306, size=         1 (512.00b), end= 354150306      NODE descriptor
  [3] 0:12  start= 354150307, size=    524288 (256.00M), end= 354674594      NODE data
  [4] 0:12  start= 354674595, size=        18 (  9.00K), end= 354674612      MEDIA descriptor
  [5] 0:12  start= 354674613, size=       130 ( 65.00K), end= 354674742      APP descriptor
  [5] 0:12  start= 354674743, size=   1113808 (543.85M), end= 355788550      APP data
  [1] 0:11  start= 355788706, size= 269352960 (128.44G), end= 625141665      MEDIA data
------------------


The "Logical" layout is given in terms of zone location on a kind of "Virtual Disk" created on top of all MFS partitions stacked together (10, 11, 12 and 13 in this order). "Physical" is with the positions translated to real disk blocks.
"Zone data" - is the region on the disk pointed to by zone header (i.e. fields 'first' and 'size' of the 'zone_header_...' structure if you want to check the code).

The ideas are similar to "Coalescing" partitions, but do not require new zones or for multiple media zones to be located on the same partition.

Approach 1: No physical change - logical remap
Since partition 11 (i.e. "/dev/sda11" if dealing with a drive designated by "/dev/sda") is located at the end of physical space, it's easy to extend this partition without moving or erasing any of the current data. Note, however, that this region is pointed by Zone 1 is located in the middle of "Virtual Disk" - partitions 12 and 13 are added after that. It means that logical addresses of the zones located following Zone 1 Data will have to change. Imagine increasing the 'size' of the Zone 1 Data region - the next start block will have to move, hence the next start block and so on. The good news is that's only poniter changes - a few numbers here and there - the actual data will stay where it is.

Approach 2: No logical change - physical move
That's almost the reverse of the previous idea. The partition 13 is pointed by the very last Zone segment. So extending partition 13 will not cause logical remap whatsoever except adjusting the 'size' of that one zone. However, physically partition 13 is at the top of the disk, so extending it means moving all the data below it to the new location (current + new extent) and adjusting Partition Map accordingly (again, only a few numbers). Basically it's one 'dd' operation, but a long one. Plus if something happens in the process - the disk is toast - will have to be restored from backup.

Question
Is there any other data that has logical or physical locations? I have not learned enough yet to understand what the "iNode" is and the fucntion of "App" and "iNode" zones. Is there anything else that will have to be adjusted or may render this approaches unusable?

[puffdaddy]

I'll offer up what I can.

I don't know definitively, but I strongly suspect that there is other data that has physical or logical locations that would need to be updated.

If you haven't already read more about indoes, they are a structure of filesystems, and in the example of ext2, all files and directories are represented by an inode. Here's a link to some more info about ext2 inodes: http://www.science.unitn.it/~fiorella/guidelinux/tlk/node96.html The take away point is that the datablock pointers within the inode point to the actual data of that file/directory. If that holds for MFS, then Approach 1 would only work if you adjusted the logical addresses inside each and every inode contained in zones following the "extended" zone. I'm not sure how much trouble that would be.

Approach 2 might be less work as it would not require fiddling with individual inodes (assuming I'm correct about that) and sounds like a refinement of the partition coalesce (which is known to work).

As far as the disk being toast with Approach 2, remember that most folks wanting to accomplish this won't need to move partitions in place on the stock drive. Rather, they would be doing this as part of upgrade to a larger drive (that they want to fully utilize), and thus they would be copying the stock drive over to the larger drive. So most folks would want to use the tools to do a simultaneous "copy and expand". You're right about the danger for folks who had already dd'ed their stock drive to a larger, but such "transition" cases could always roll the dice and start over if something went awry.

I'll note that a combination of both Approaches would allow one to resize (enlarge or shrink) any given partition, perhaps representing the holy grail of mfstools: mfs_resize.

It's been a little while since you posted, have you had a chance to experiment?

*Edit* found a quote from Spike indicating that Approach 1 requires modification of the inodes. Under method number four in this post: http://www.mfslive.org/forums/viewtopic.php?f=11&t=257&hilit=zone&start=120#p5961 he comments that

4. modify existing mfs media partitions 11, 13. no one so far.
This is fairly hard to do since you have to do all sorts inode adjustments but will be plug and play eSATA drive compatible.

[comer]

I'll offer up what I can.
...
Approach 2 might be less work as it would not require fiddling with individual inodes (assuming I'm correct about that) and sounds like a refinement of the partition coalesce (which is known to work).

Thank you puffdaddy. As far as I understand the MFS Tools code (which I may not fully) the inodes will not require adjustments, but bitmaps do and that is kind of a problem for me right now. First of all I compared the Tivo drive structure with what MFS Tools create and the bitmaps are different. The first fspointer in MFS partition is different, then offsets between pointers are the same (which gives me hope, actually, that something works). The "last" member of a bitmap is definitely different (it would actually make more sense to me if it was switched with the next one - "free_blocks" - at least it looks that way). With all that, Approach2 still looks viable, while Approach1 requires too many changes. However, I don't see (don't know - everything is possible) a way to preserve the recordings.
Currently, I am looking into "mfscopy", in hopes to better understand how bitmaps work and their relationship with inodes. "mfscopy" with expand basically does what I wanted to do, albeit requires changes to work with SATA drives and SQLight partition (not too hard). Actually, I am thinking to take out only the part that works with MFS partitions and leave copying the rest to "dd"

EDIT: I should have said "mfscopy" instead of "mfsadd" of course.

[UTA_MAVERICK]

Although I have been around since 2005, upgraded 3 Series One, 1 Series Two, 1 DVD Humax, 1 Series Two DT when it comes to the TiVo Premeire and Linux, well I'm still a noob...

I finally took the plunge and got mine through sellmoretivo and I'm ready to ditch one of the Series 2 boxes and move to the Series 4 box.

I don't want an external HDD with cables and a PS brick to fool with and risk of disconnection or some other such external event mucking up TiVo's health.

I've tried to follow along, still not sure if I should just dd or dd_rescure the stock VIRGIN (subscribed) drive to my new 1.5TB drive and start using that then expand later, attempt to expand it now or the finer points of why I just can't expand the storage areas during a copy to fill the drive like a program such as Arcronis Director would for Windows NTFS volumes but using the Linux tools available.

Does TiVo look for specifics that I'm just not seeing as they relate to expanded drives or resizing of partitions or partition limits. Is there some simple way to just GROW ALL PARTITIONS proportionally that would work and be a simple solution? Sure you would loose some space due to expansion where it's not really needed, but compared to the data areas for recordings that would be minimal, maybe 1-2% of total space (800MB becomes 1.6GB, 350GB becomes 1.05TB), you get a larger swap volume, what am I missing? Yes I'm a Linux noob, I admit it, mostly I use a Mac and a Windows PC. Any good readings that can fill in my miss interpretations that are an easy read that are relative to TiVo issues and sata drives?

Thanks in advance...

[UTA_MAVERICK]

OK, I am treading on thin ice here... OJT for Linux, crash and burn, eeek!!!

Last night started the dd_rescue to migrate the virgin stock image to the new drive, went to bed and woke up to a complete image on the new drive (I know if i was a real die hard I'd have stayed up and watched the whole thing copy over).

Rebooted and checked out the structures of the old and new drive and both show 14 partitions. Attempted to use mfsadd to expand the drive and that seems not to work got some sda11 messages back about not being recognized. So looks like I have a new drive with a bunch of empty unpartitioned space at the end, not the expanded capacity I had hoped for.

My question now is can I manually build partitions and moved things one at a time to same size partitions (like pouring from one cup to another) until I hit the media partition and just give it as much space as I can keeping the partitions in the same physical order and (then just crumple up the old cups and toss them away) push everything back in a neat logical and physical order, delete the old partitions or open them to unformatted space, thus keeping things the same ordering. Or will I just end up with new partition numbers and the old partitions numbers vanish once they are released. Isn't there a dynamic reordering process of some sort that will take effect. Like for attached drives if you have /dev/sda, sdb, sdc remove sdb and then next boot have /dev/sda, sdb where sdb is actually the old sdc drive. Enlighten me...

But wait, why is it so hard to just move ONLY the entire recording data partition on a virgin drive, right now there is a whole 1+TB sitting unallocated (1.5TB drive) at the end of the existing physical partitions? No recordings or files have been saved. Unit has never been booted (by me), but came pre-activated from TiVo.

The stock TiVo drive is safely put away, so I'm ready to experiment with the dd'ed drive.

Any suggestions on my best plan of attack to follow?

[comer]

Hi UTA_MAVERICK,

In short - Tivo partitions are not of any recognized (by anything but specific Tivo tools) type. So regular generic tools won't work for anything including resize, but direct copy block-by-block.
Also, there are data structures on those partitions that reference each other by their position on the disk. So expanding an arbitrary portion of the disk even though it looks like a partition will make those pointers address the wrong places - essentially everything will be corrupted.

That's why software like MFSTools exist - it not only expands the available space on the surface, but makes necessary adjustments to those data structures.

Right now there is a method to expand the space known as "partition coalescing" - described somewhere on the first page of this thread. Eventually, there will be a tool to do it more easily. I personally explored some of the options and they are all doable, just require a lot of work.
However, I wanted to explore the easier methods first - the same mfsadd modified for new Tivo. I am trying to see for myself what spike said in the beginning:

3. Extra partition pair not recognized
Mfstools and Winmfs add extra space by adding partition pairs (app and media) at the end of the factory capacity.
During the boot process, Premiere check for it's partition tables and zone maps. Anything extra beyond it's factory partitions are treated as if they come from external drive.
But the extra partition are on "A" or internal drive and not on "B" or external drive. so, it displays "External storage missing" screen and goes in to reboot cycle.

To me it sounds strange that Tivo would look for "/dev/sda10" on one drive, but "/dev/sda15" on another.
If it works, then we will have the same kind of tool as for other Tivos.

[UTA_MAVERICK]

So if I understand... from comer's comments

1.

Tivo partitions are not of any recognized (by anything but specific Tivo tools) type.

So the type does not use any known for std Linux partition type, which explains why the Linux partition tools don't see valid data. They do report that the information is unknown type or corrupt, some offer to attempt to fix, I of course did not do this.

2.

So regular generic tools won't work for anything including resize, but direct copy block-by-block.

So this explains why dd and dd_rescure made a valid copy of my original virgin TiVo drive. Thats great so I can play, but I'm still as lost as I can be since what Spike said went right in one ear and out the other, got a long way to go on some of that info.

3.

Data structures on those partitions that reference each other by their position on the disk.

Nasty old TiVo, hard coding and wiring from point to point on the disk, "static" vs. dynamic? So even if I could make a partition tool look for a new partition type, treat it just like something it knows, I still could not shuffle things where I wanted to on a new disk?

4.

Right now there is a method to expand the space known as "partition coalescing" - described somewhere on the first page of this thread.

Guess I will start there and go off and read all I can about this topic, eventually I hope some of it sinks in or at least sticks for awhile on the trip between my ears. My goal is a larger internal drive not a two drive system with an external box. But further reading on the info about the Premiere suggests that unlike older TiVos there is enough smarts in the box that it can un-marry an external drive if it's lost, damaged, etc. Sounds like you loose everything and go back to NO SHOWS, start over etc. Not the smarts that we would want to see to access space on an internal drive with the extra partitions. But at least no re-imaging of the main drive is required.

So what we need is something beyond dd and dd_rescure, a kinda forensic editor/tool that can also follow all the places that TiVo is sending us on its disk hunt and can translate or re-map positions for a new drive, would be drive dependent for each brand and model of HDD based on it layout, geometry and size. Or am I just really lost... Trying... Ouch, not much space left up here...

[comer]

So the type does not use any known for std Linux partition type, which explains why the Linux partition tools don't see valid data. They do report that the information is unknown type or corrupt, some offer to attempt to fix, I of course did not do this.

Correct.

So this explains why dd and dd_rescure made a valid copy of my original virgin TiVo drive.

Correct.

Nasty old TiVo, hard coding and wiring from point to point on the disk, "static" vs. dynamic? So even if I could make a partition tool look for a new partition type, treat it just like something it knows, I still could not shuffle things where I wanted to on a new disk?

Correct, except that it's not really a "hard-code", but really complicated (some might say "weird") file system with multiple "virtualization" layers one on top of another. For better understanding - let's take FAT as an example. For each file there's a descriptor record that says the name of the file, attributes and where the file data resides by pointing to blocks on the disk. Same with Tivo, but most of the time blocks are not relative to partition (i.e. the first "layer" you see on the disk), but are numbered in "virtual" space created on top of multiple partitions. So now one can understand that changing the size of any partition participating in that "virtual" space will or must shift all subsequent blocks, otherwise the addresses will point into the wrong place. ... And there is more than one layer...

So what we need is something beyond dd and dd_rescure, a kinda forensic editor/tool that can also follow all the places that TiVo is sending us on its disk hunt and can translate or re-map positions for a new drive,

Correct, that's what MFS Tools do for all other Tivos. They just don't know how to do it for Premiere, yet.

would be drive dependent for each brand and model of HDD based on it layout, geometry and size.

Not really. Block is a block.

[comer]

To me it sounds strange that Tivo would look for "/dev/sda10" on one drive, but "/dev/sda15" on another.
If it works, then we will have the same kind of tool as for other Tivos.

Yes! It worked! In a different way than I expected, but worked!




It did say that external storage is missing and offered to remove it. I agreed and Tivo reformatted the drive, but left the recordings in place! Yippy!
Now I essentially upgraded my standard 320G drive to 1.5T and retained all my recordings!




Now, I did not use mfsadd - as I learned Tivo I wrote my own bits and pieces in Java to quickly examine structures. Bits and pieces came together in time and now I have my own entirely-Java tool.

It won't be hard to adjust mfsadd:

• make it SATA compatible (support /dev/sd*)
• size = size & ~(minalloc - 1); does not work! because in Premiere data chunk is 20480 which is not a power of 2! The correct way is size = size - (size % minalloc); It is in more than one place!
• change FS pointers offset - in Premiere it is 160 instead of 8 as it used to be (zonemap.c: fsmem_base = htonl (*(unsigned int *) (last + 1)) - (sizeof (*last) + htonl (last->num) * 4) + htonl (last->length) * 512 + 512 + 160;)
• check the zone size (it may work, but it's based on pointer size, which may not give the correct result):
  
  now (may or may not work): sizeof (zone_header_64) + 4 + (sizeof (bitmap_header) + sizeof (bitmap_header *)) * (order) + <sizeof ints in bitmaps>; where <sizeof ints in bitmaps> is based on "(bits + 62) / 32" (for the love of God - WHY?)
  
  proposed (proven to give the correct result): sizeof (zone_header_64) + sizeof (bitmap_header) * order + sizeof(int) * order + sizeof(int) * order + <sizeof ints in bitmaps>; where <sizeof ints in bitmaps> is based on "(bits/32) + 1 - (15 / (8 + bits))"

I will backup and examine the structure later. I wonder if Tivo "coalesced" partitions itself or actually combined and created two zones, two partitions as it was but bigger?

EDIT: forgot important point about chunk size

[comer]

I will backup and examine the structure later. I wonder if Tivo "coalesced" partitions itself or actually combined and created two zones, two partitions as it was but bigger?

I examined the upgraded disk structure. Tivo did not remove, move or merge anything - all extra partitions are there, zones too. The added zone is still correctly linked to the previous one. The only thing it did I see is that it removed the extra media data partition from the "superheader" (MFS root that is). I updated it to be "/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13 /dev/sda15 /dev/sda16" (underlined are new added partitons), where /dev/sda15 - is media descriptor ("app" partition) and /dev/sda16 - media data. Tivo replaced it with "/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13 /dev/sda15" - sda16 is missing. Though superblock shows the total number of blocks correctly - including the /dev/sda16.

Here's the layout:

Code: Select all

Disk '/dev/sda'
------------------
1 :         start=         1, size=        63 ( 31.50K), type='Apple_partition_map', name='Apple'
13:         start=        64, size= 343828320 (163.95G), type='MFS'                , name='MFS media region 2'
2 :         start= 343828384, size=         1 (512.00b), type='Image'              , name='Bootstrap 1'
3 :         start= 343828385, size=     16384 (  8.00M), type='Image'              , name='Kernel 1'
4 :         start= 343844769, size=    524288 (256.00M), type='Ext2'               , name='Root 1'
5 :         start= 344369057, size=         1 (512.00b), type='Image'              , name='Bootstrap 2'
6 :         start= 344369058, size=     16384 (  8.00M), type='Image'              , name='Kernel 2'
7 :         start= 344385442, size=    524288 (256.00M), type='Ext2'               , name='Root 2'
8 :         start= 344909730, size=    262144 (128.00M), type='Swap'               , name='Linux swap'
9 :         start= 345171874, size=   1048576 (512.00M), type='Ext2'               , name='/var'
14:         start= 346220450, size=   6291456 (  3.00G), type='Ext2'               , name='SQLite'
10:         start= 352511906, size=   1638400 (800.00M), type='MFS'                , name='MFS application region'
12:         start= 354150306, size=   1638400 (800.00M), type='MFS'                , name='MFS application region 2'
11:         start= 355788706, size= 269353742 (128.44G), type='MFS'                , name='MFS media region'
15:         start= 625142448, size=      1024 (512.00K), type='MFS'                , name='MFS application region 3'
16:         start= 625143472, size=2305133696 (  1.07T), type='MFS'                , name='MFS media region 3'
------------------
Unallocated space: 0 (0.00b)

Found MFS header on /dev/sda10
     MfsHeader64 {
             MfsHeaderHeader {
                     state=0x0000
                     magic=0xEBBAFEED
                     CRC=0x1E939195
              }
             validCRC=TRUE
             sectors=2,921,591,808
             partitions='/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13 /dev/sda15'
             logStart=1
             logStamp=575,272
             logSectors=1,000
     }

Zones Logical
------------------
   [0] /dev/sda10    start=      1121, size=         1 (512.00b), end=      1121      NODE descriptor
   [0] /dev/sda10    start=      1122, size=    524288 (256.00M), end=    525409      NODE data
   [1] /dev/sda10    start=    525410, size=        10 (  5.00K), end=    525419      MEDIA descriptor
   [2] /dev/sda10    start=    525420, size=       130 ( 65.00K), end=    525549      APP descriptor
   [2] /dev/sda10    start=    525550, size=   1112704 (543.31M), end=   1638253      APP data
   [2] /dev/sda10    start=   1638258, size=       130 ( 65.00K), end=   1638387      APP descriptor backup
   [1] /dev/sda10    start=   1638388, size=        10 (  5.00K), end=   1638397      MEDIA descriptor backup
   [0] /dev/sda10    start=   1638398, size=         1 (512.00b), end=   1638398      NODE descriptor backup
   [1] /dev/sda11    start=   1638400, size= 269352960 (128.44G), end= 270991359      MEDIA data
   [3] /dev/sda12    start= 270991360, size=         1 (512.00b), end= 270991360      NODE descriptor
   [3] /dev/sda12    start= 270991361, size=    524288 (256.00M), end= 271515648      NODE data
   [4] /dev/sda12    start= 271515649, size=        18 (  9.00K), end= 271515666      MEDIA descriptor
   [5] /dev/sda12    start= 271515667, size=       130 ( 65.00K), end= 271515796      APP descriptor
   [5] /dev/sda12    start= 271515797, size=   1113808 (543.85M), end= 272629604      APP data
   [5] /dev/sda12    start= 272629611, size=       130 ( 65.00K), end= 272629740      APP descriptor backup
   [4] /dev/sda12    start= 272629741, size=        18 (  9.00K), end= 272629758      MEDIA descriptor backup
   [3] /dev/sda12    start= 272629759, size=         1 (512.00b), end= 272629759      NODE descriptor backup
   [4] /dev/sda13    start= 272629760, size= 343818240 (163.95G), end= 616447999      MEDIA data
   [6] /dev/sda15    start= 616457216, size=        66 ( 33.00K), end= 616457281      MEDIA descriptor
   [6] /dev/sda15    start= 616457282, size=        66 ( 33.00K), end= 616457347      MEDIA descriptor backup
   [6] /dev/sda16    start= 616458240, size=2305126400 (  1.07T), end=2921584639      MEDIA data
------------------


[spike]

change FS pointers offset - in Premiere it is 160 instead of 8 as it used to be (zonemap.c: fsmem_base = htonl (*(unsigned int *) (last + 1)) - (sizeof (*last) + htonl (last->num) * 4) + htonl (last->length) * 512 + 512 + 160;)

Why 160?

I think total sectors reported in SuperHeader and total hours reported under system information are not all lthat reliable way to tell the actual space.
If partition(s) is not listed in devlist then it does not count toward TiVo partition space and your partition table list both 15 and 16 so I'm not sure what you've done worked properly.

Have you recorded any shows after you've expanded? Did you get any GSOD?
Good way to test is it record more than 320GB worth of shows and set them to keep until I delete.