1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Roamio 4Tb Drive Development Thread

Discussion in 'TiVo Upgrade Center' started by eboydog, Apr 25, 2014.

  1. Jun 12, 2014 #81 of 105
    telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    Linux dd doesn't understand APM, it only understands block devices and offsets within them. Kernels (or tivopart) with APM-Tivo support will create sub-devices at the partition boundaries. Once/if those exist then you can use those sub-devices with dd to copy partitions.

    jmfs was still rejecting my drive signature, and in tracking it down I discovered another class doing reads, called RandomAccessFile. I'm going to ask a Java friend look at this.

    Other tasks, hmm, it's pretty long. Well, one thing that I'd like to see more of but is not sexy, is tivo monitoring, and first off the logs. When the Roamio came around, and a few people have consistent reboots, the logs have more answers and we had to do a lot of guessing. And I understand the lack of desire, when my Tivo is working I don't care to turn it off. But when it's acting wonky, it still feels like too much work unless I have the data collection completely automated.

    I was going to write something for Windows/Mac users since Linux can already read ext, but I found one already made called testdisk.

    This might be good for nooneuknow's uncle, unless he's into hardware, as it is gpl, is self-contained, doesn't require a Tivo, and it has the description of the basic Tivo drive format to start from.

    Re CableCards, sure it's possible your Tivo's doing that and no-one else's is. Through diligent work, you should be able to document and perhaps understand why, but at then end, you might not be able to do anything about it. It's a locked down platform, the only entities that can change things is Tivo (often uninterested), and maybe few things by your Cable Company (generally inept/unaware). That's also why I would assume any variances you're experiencing is more likely a technical oversight than something maliciously planned.

    Re Flash, at this point, I don't think anything operational is written to Flash, well aside I guess, not any more than some old systems had things written to prom. That of course might change at any time.

    If you want to create a CableCard or Cox-your-market thread, I'll add what I can, but you should probably stick to Series 3 or 4 since the drives are fully readable.
     
  2. Jun 12, 2014 #82 of 105
    nooneuknow

    nooneuknow TiVo User Since 2007

    3,554
    0
    Feb 5, 2011
    Cox Cable...
    Since KMTTG is written for Java, perhaps the author may be of some assistance on Java matters?

    Almost anything is better than having to pull the disk and use a disk editor to view the logs, which is the only method I know aside from TiVo Backdoor. The raw-disk method seems to expose logging not available via TB. The biggest issues I have with scanning the logs with the TiVo operational using TB is having no way to search, other than with my eyes, and no way to capture what I find (to copy, print, share), and the rate at which the logs rotate out, usually before I can scan all the different log sections.

    Very true. He's the software guy. I'm the hardware guy. You'll need to PM me a crash-course on setting up that JTAG-serial link you told me about (if that's possible with a Roamio).

    I'm dropping my specific market parameters from the discussion. I tried to just make a reference to another thread I detailed it in, then wound up infesting the thread when I could feel the doubt about what I said creeping in.

    I'm beginning to think TiVo might have moved the cc pairing data into the flash (at least some/most of it). Changes to most of that data happen at about the same rate as TiVo software updates, less if you never change your cablecard or drive. I'd suspect any data that tends to stay static could be moved into flash, and anything that updates when the cc renews authorization every xx days, or x months, or otherwise is fluid, could be buried/hidden on the hard drive. It makes sense. It doesn't make a goal of being able to find, capture, and restore it easier (which makes such a move make more sense). I've both read about, and experienced, where a Roamio will refuse to detect the cableco has unpaired the card, and retains data that makes re-pairing the same card, or pairing a new one fail. If given time (20 minutes to 3 hours), of just being left without a card present, it finally forgets the data and you can move on. This feels/seems like something one might expect when that "leftover" data is on flash. I never saw this, or heard about this exact scenario, pre-Roamio.

    I'd drop the whole cablecard discussion, if it weren't for the possibility that those working on these projects might need to know what's what, to avoid issues down the road with DIY Roamio drive preparation, and for the goal of being able to upgrade drive sizes, without losing what is on the existing drive...

    When I volunteered my help to ggieseke, I still had TiVo HDs and Premieres. I had enough that I could have easily swapped some out for testing. I've since migrated to three base-Roamios (one is a "hot spare"), and have sold off all the older equipment (nobody was taking me up on my offers to assist). I'm left with just one unsubbed TiVoHD, until somebody buys it, or buys the power supply inside it.

    Any reason I should take that last HD off the market, so I have something older to work with, or should I take the $35 going-rate for a rebuilt power supply (if/when the opportunity presents)? I could always just build a makeshift power supply to use...

    I'm very good at improvising and hardware matters, and have TONS of hardware around, going back decades, if anybody needs anything for building test-rigs or needs to make special-use devices out of parts I have.
     
  3. Jun 13, 2014 #83 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    I don't mind scanning the drive and capturing the logs. I have a non dock USB to SATA adapter that allows me to connect the drive without removing it. All I have to do is leave the cover off if you are wanting frequent logs.
    Now if there was a way to get the logs off the unit via ethernet, then we are more likely to get more logs. TiVo does it.
     
  4. Jun 13, 2014 #84 of 105
    telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    After an absurd amount of typing to do something basic (Java interfaces), this is what I get after adding some debug lines when pointed at a 500GB, Base Roamio HD:
    Code:
    Debug:  5266 ? 5266
    Debug:  Block0 isValid true
    Debug:  Block0 isValid true
    Debug:  0 
    Debug:  1 
    Debug:  2 
    Debug:  3 
    Debug:  4 
    Debug:  5 
    Debug:  6 
    Debug:  7 
    Debug:  8 
    Debug:  9 
    Debug:  10 
    Debug:  11 
    Debug:  12 
    Debug:  13 
    Debug:  storageSize=500107862016, nextFreeBlock=976773168, free=0
    Debug: AppleDisk constructor #3
    Debug: TivoDisk loadHeader
    Debug:  TD isValidRoot MfsHeader64 { MfsHeaderHeader { state=0xEBBAFEED, magic=0x00000000, CRC=0x572822DA }, validCRC=FALSE, sectors=967,859,200, partitions='/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13', logStart=1, logStamp=0, logSectors=1,000}
    Debug:  TD isValidRoot MfsHeader64 { MfsHeaderHeader { state=0xA790A79, magic=0x0A790A79, CRC=0x0A790A79 }, validCRC=FALSE, sectors=754,645,927,544,294,009, partitions='', logStart=754,645,927,544,294,009, logStamp=175,704,697, logSectors=175,704,697}
    Debug:  TD isValidRoot MfsHeader64 { MfsHeaderHeader { state=0x1991F800, magic=0x00000000, CRC=0x19AAF7FF }, validCRC=FALSE, sectors=-6,148,914,691,236,517,206, partitions='��', logStart=-6,148,914,691,236,517,206, logStamp=-1,431,655,766, logSectors=-1,431,655,766}
    Debug:  TD isValidRoot MfsHeader64 { MfsHeaderHeader { state=0x0000, magic=0x00000000, CRC=0x00000000 }, validCRC=FALSE, sectors=0, partitions='', logStart=0, logStamp=0, logSectors=0}
    Debug:  Added TivoDisk from '/dev/sda'
    
    Roamio:
    Code:
    512 bytes (512 B) copied, 0.000880768 s, 581 kB/s
    00000000  ed fe ba eb 00 00 00 00  da 22 28 57 10 00 00 00  |........."(W....|
    00000010  01 00 00 00 40 00 00 00  40 06 00 00 00 c0 28 2f  |....@...@.....(/|
    00000020  60 c1 28 2f 2f 64 65 76  2f 73 64 61 31 30 20 2f  |`.(//dev/sda10 /|
    00000030  64 65 76 2f 73 64 61 31  31 20 2f 64 65 76 2f 73  |dev/sda11 /dev/s|
    00000040  64 61 31 32 20 2f 64 65  76 2f 73 64 61 31 33 00  |da12 /dev/sda13.|
    00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000000a0  00 00 00 00 00 00 00 00  00 5c b0 39 00 00 00 00  |.........\.9....|
    000000b0  01 00 00 00 00 00 00 00  9d 00 00 00 00 00 00 00  |................|
    000000c0  e9 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    000000d0  61 04 00 00 00 00 00 00  fe ff 18 00 00 00 00 00  |a...............|
    000000e0  01 00 00 00 00 00 00 00  00 00 08 00 00 00 00 00  |................|
    000000f0  00 00 08 00 00 00 00 00  78 00 00 00 e8 03 00 00  |........x.......|
    00000100  20 a1 07 00 65 00 00 00  02 00 00 00 cf 02 00 00  | ...e...........|
    00000110  80 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00000200
    ...
    31fffe00  ed fe ba eb 00 00 00 00  da 22 28 57 10 00 00 00  |........."(W....|
    ...
    
    I can see it's broken. Do we know what it is suppose to say, before I attempt to fix it?
     
  5. Jun 13, 2014 #85 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    What is the debug output on a premiere that we know it runs on.

    This probably something more ggieseke can address/answer. The checksum calculations to verify the checksum might have to be adjust for the different endian order.

    Which version of JMFS are you using for your debugging.
     
  6. Jun 13, 2014 #86 of 105
    ggieseke

    ggieseke Active Member

    4,028
    12
    May 30, 2008
    At first glance, the "validCRC=FALSE" lines stands out. TiVo uses an ANSI X366 algorithm to validate several of the MFS headers.

    Where are these logs coming from?

    I've had several beers right now, but if you post at least the hex dump of that entire sector I may be able to spot what's up tomorrow. I have to work in the morning but my afternoon is free.
     
  7. Jun 13, 2014 #87 of 105
    telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    Uh, I guess that's the absurd part. It didn't run on my Premiere backups consistently, unless I make some patches first, so I guess I have to track that down first. Maybe this needs to start from a different codebase.

    The version I'm using, I forked what was on github krbaker, and then added Litle Endian reading modes in 3 ways / reading pathways. Then added some debug lines, and forced it into 64-bit mode since it defaults to 32bit on misreads.

    What looks wrong to me, is why is State EBBAFEED, Magic should be EBBAFEED. But it does that on some Premiere too.

    Edit: moved Roamio first sector dump to prior post. Will add Premiere version here for comparison.
    I found an drive that works with mediafire and krbarker, but not mine, so I have something to track down.

    Looking at them side-by-side. Looks to me the magic number is 64bits long, which makes me question if there's a value called "state".

    Premiere:
    Code:
    Fine:  storageSize=320072933376, nextFreeBlock=625142448, free=0
    Fine:  TD isValidRoot MfsHeader64 { MfsHeaderHeader { state=0x0000, magic=0xEBBAFEED, CRC=0x9A6F5744 }, validCRC=TRUE, sectors=616,457,216, partitions='/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13', logStart=1, logStamp=6,883,168, logSectors=1,000}
    Fine:  Found boot TivoDisk at '/dev/sda'. Boot device is '/dev/sda'
    
    # dd if=/dev/disk1s10 count=1 bs=512 | hexdump -C  
    1+0 records in
    1+0 records out
    512 bytes transferred in 0.022048 secs (23222 bytes/sec)
    00000000  00 00 00 00 eb ba fe ed  9a 6f 57 44 00 00 00 10  |.........oWD....|
    00000010  00 00 00 01 00 00 00 40  00 00 06 40 00 00 00 01  |.......@...@....|
    00000020  00 00 00 01 2f 64 65 76  2f 73 64 61 31 30 20 2f  |..../dev/sda10 /|
    00000030  64 65 76 2f 73 64 61 31  31 20 2f 64 65 76 2f 73  |dev/sda11 /dev/s|
    00000040  64 61 31 32 20 2f 64 65  76 2f 73 64 61 31 33 00  |da12 /dev/sda13.|
    00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    000000a0  00 00 00 00 00 00 00 00  00 00 00 00 24 be 64 00  |............$.d.|
    000000b0  00 00 00 00 00 00 00 01  00 00 00 00 00 69 07 60  |.............i.`|
    000000c0  00 00 00 00 00 00 03 e9  00 00 00 00 00 00 00 00  |................|
    000000d0  00 00 00 00 00 00 04 61  00 00 00 00 00 18 ff fe  |.......a........|
    000000e0  00 00 00 00 00 00 00 01  00 00 00 00 00 08 00 00  |................|
    000000f0  00 00 00 00 00 08 00 00  00 00 00 78 00 00 03 e8  |...........x....|
    00000100  00 07 a1 20 00 0a 2b d4  00 00 00 e8 00 00 00 02  |... ..+.........|
    00000110  00 00 00 80 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    *
    00000200
    
    
     
  8. Jun 13, 2014 #88 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    If you use krbarker version it needs to be patched to handle images larger than 0xEFFFFFFF sectors. I patched mine which is a fork of krbarker but only a few days ago.
     
  9. Jun 13, 2014 #89 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    If "magic" was an 8 byte entry and not a 4 byte entry, then it makes more sense and I agree there is no "state" value. That is assuming the "state" value of 4 bytes near the traditional "magic" value is what JMFS is considering as the "state" value.

    The challenge will be to figure out which entries are 2, 4, and 8 byte entries to correct for the endianness in JMFS. Some of it can be figured out by comparing Roamio and Premiere blocks. If the checksum comes out correctly, then we probably have guessed correctly.
     
  10. Jun 14, 2014 #90 of 105
    ggieseke

    ggieseke Active Member

    4,028
    12
    May 30, 2008
    What you're seeing is one of the changes in the superheader structure that I mentioned before. On a Roamio state and magic are still 32 bit fields, but they are swapped (magic comes first). The logstamp and zonemap_type fields are also swapped.
     
  11. Jun 14, 2014 #91 of 105
    telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    Ok, I'll look for that.

    Was the CRC covering the 512 sector or did you need the 4096 sector?
     
  12. Jun 14, 2014 #92 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    Traditionally the CRC has been the 512 byte sector.
     
  13. Jun 14, 2014 #93 of 105
    ggieseke

    ggieseke Active Member

    4,028
    12
    May 30, 2008
    The CRC is only calculated on the actual size of the structure, which in this case is 280 bytes. I never read in less than 512 byte chunks, so jmbach is also right (I need the whole sector to run my crapware CRC program). I rewrote my program to make it Roamio-aware and it came up with the same checksum as the hex code that you posted earlier.

    I don't know java, but once you change the definition of the structure it should be OK. The problem was that is was seeing the "magic" as 0x00000000 and the "state" as 0xEBBAFEED. Don't forget to swap those other two fields as well or it will crap out on the zonemaps.

    There's some additional weirdness in the inode structures on a Roamio that I haven't completely figured out yet. I don't think it will matter for a basic expansion. The code to read inodes and map them to physical sectors on the drive is there in the jmfs source, but I don't think it's actually used.
     
  14. Jun 14, 2014 #94 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    I am only close if it was a horseshoe game. Thanks for the correct info.
     
  15. Jun 14, 2014 #95 of 105
    telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    Feels like a game of something. Who gives up first? I'm about to lose.

    Fixed the CRC computation. Added two swaps mentioned (4 fields), gives:
    Code:
    java.io.IOException: Logical block is located beyond the current storage: block=1121, view=tivo.view.MfsView@2ce908
    	at tivo.io.Utils.getValidPhysicalAddress(Utils.java:460)
    	at tivo.io.Utils.seekToLogicalBlock(Utils.java:480)
    	at tivo.Mfs.loadZones(Mfs.java:451)
    	at tivo.Mfs.addDisks(Mfs.java:347)
    	at tivo.Mfs.<init>(Mfs.java:76)
    	at tivo.Mfs.<init>(Mfs.java:70)
    	at jmfs.MfsLayout.main(MfsLayout.java:42)
    
    Debug:  5266 ? 5266
    Debug:  Block0 isValid true
    Debug:  Block0 isValid true
    Debug:  storageSize=500107862016, nextFreeBlock=976773168, free=0
    Debug: AppleDisk constructor #3
    Debug: TivoDisk loadHeader
    Debug:  Checksum 0x511ed733 ? 0x572822da
    Debug:  Checksum 0x572822da ? 0x572822da
    Debug:  TD isValidRoot MfsHeader64 { MfsHeaderHeader { state=0x0000, magic=0xEBBAFEED, CRC=0x572822DA }, validCRC=TRUE, sectors=967,859,200, partitions='/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13', logStart=1, logStamp=157, logSectors=1,000}
    Debug:  Found boot TivoDisk at '/dev/sda'. Boot device is '/dev/sda'
    Debug: MFS.java boot.getMfsHeader().getZoneMap()=ZoneHeader64 { startBlockPrimary=1121, startBlockBackup=1638398, length=1, size=524288, min=524288}
    
    PartitionMap:
    Code:
     1 PartitionEntry { number=1, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=1 (byte offset 0x00000200), sizeBlocks=63 (bytes 32,256, next offset 0x00008000), name='Apple', type='Apple_partition_map', logicalStartBlock=0 (physical 1, logical offset 0x00000000, physical offset 0x00000200), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 1, logical offset 0x00000000, physical offset 0x00000200), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     2 PartitionEntry { number=2, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=537225104 (byte offset 0x400ACF2000), sizeBlocks=8 (bytes 4,096, next offset 0x400ACF3000), name='Bootstrap 1', type='Image', logicalStartBlock=0 (physical 537225104, logical offset 0x00000000, physical offset 0x400ACF2000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 537225104, logical offset 0x00000000, physical offset 0x400ACF2000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     3 PartitionEntry { number=3, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=537225112 (byte offset 0x400ACF3000), sizeBlocks=8 (bytes 4,096, next offset 0x400ACF4000), name='Kernel 1', type='Image', logicalStartBlock=0 (physical 537225112, logical offset 0x00000000, physical offset 0x400ACF3000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 537225112, logical offset 0x00000000, physical offset 0x400ACF3000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     4 PartitionEntry { number=4, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=537225120 (byte offset 0x400ACF4000), sizeBlocks=8 (bytes 4,096, next offset 0x400ACF5000), name='Root 1', type='Ext2', logicalStartBlock=0 (physical 537225120, logical offset 0x00000000, physical offset 0x400ACF4000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 537225120, logical offset 0x00000000, physical offset 0x400ACF4000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     5 PartitionEntry { number=5, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=537225128 (byte offset 0x400ACF5000), sizeBlocks=8 (bytes 4,096, next offset 0x400ACF6000), name='Bootstrap 2', type='Image', logicalStartBlock=0 (physical 537225128, logical offset 0x00000000, physical offset 0x400ACF5000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 537225128, logical offset 0x00000000, physical offset 0x400ACF5000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     6 PartitionEntry { number=6, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=537225136 (byte offset 0x400ACF6000), sizeBlocks=8 (bytes 4,096, next offset 0x400ACF7000), name='Kernel 2', type='Image', logicalStartBlock=0 (physical 537225136, logical offset 0x00000000, physical offset 0x400ACF6000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 537225136, logical offset 0x00000000, physical offset 0x400ACF6000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     7 PartitionEntry { number=7, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=537225144 (byte offset 0x400ACF7000), sizeBlocks=8 (bytes 4,096, next offset 0x400ACF8000), name='Root 2', type='Ext2', logicalStartBlock=0 (physical 537225144, logical offset 0x00000000, physical offset 0x400ACF7000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 537225144, logical offset 0x00000000, physical offset 0x400ACF7000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     8 PartitionEntry { number=8, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=537225152 (byte offset 0x400ACF8000), sizeBlocks=1048576 (bytes 536,870,912, next offset 0x402ACF8000), name='Linux swap', type='Swap', logicalStartBlock=0 (physical 537225152, logical offset 0x00000000, physical offset 0x400ACF8000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 537225152, logical offset 0x00000000, physical offset 0x400ACF8000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     9 PartitionEntry { number=9, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=538273728 (byte offset 0x402ACF8000), sizeBlocks=1572864 (bytes 805,306,368, next offset 0x405ACF8000), name='/var', type='Ext2', logicalStartBlock=0 (physical 538273728, logical offset 0x00000000, physical offset 0x402ACF8000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 538273728, logical offset 0x00000000, physical offset 0x402ACF8000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     10 PartitionEntry { number=10, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=546138048 (byte offset 0x411ACF8000), sizeBlocks=1638400 (bytes 838,860,800, next offset 0x414CCF8000), name='MFS application region', type='MFS', logicalStartBlock=0 (physical 546138048, logical offset 0x00000000, physical offset 0x411ACF8000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 546138048, logical offset 0x00000000, physical offset 0x411ACF8000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     11 PartitionEntry { number=11, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=549414848 (byte offset 0x417ECF8000), sizeBlocks=427358320 (bytes 218,807,459,840, next offset 0x7470C06000), name='MFS media region', type='MFS', logicalStartBlock=0 (physical 549414848, logical offset 0x00000000, physical offset 0x417ECF8000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 549414848, logical offset 0x00000000, physical offset 0x417ECF8000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     12 PartitionEntry { number=12, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=547776448 (byte offset 0x414CCF8000), sizeBlocks=1638400 (bytes 838,860,800, next offset 0x417ECF8000), name='MFS application region 2', type='MFS', logicalStartBlock=0 (physical 547776448, logical offset 0x00000000, physical offset 0x414CCF8000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 547776448, logical offset 0x00000000, physical offset 0x414CCF8000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     13 PartitionEntry { number=13, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=64 (byte offset 0x00008000), sizeBlocks=537225040 (bytes 275,059,220,480, next offset 0x400ACF2000), name='MFS media region 2', type='MFS', logicalStartBlock=0 (physical 64, logical offset 0x00000000, physical offset 0x00008000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 64, logical offset 0x00000000, physical offset 0x00008000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
     14 PartitionEntry { number=14, signature=0x504D, signaturePad=0x0000, partitionMapSizeBlocks=14 (bytes 7168), startBlock=539846592 (byte offset 0x405ACF8000), sizeBlocks=6291456 (bytes 3,221,225,472, next offset 0x411ACF8000), name='SQLite', type='Ext2', logicalStartBlock=0 (physical 539846592, logical offset 0x00000000, physical offset 0x405ACF8000), logicalSizeBlocks=0 (bytes 0), status='Invalid,Free,NotInUse,NotBoot,Non-readable,Non-writable,PositionalBoot,', bootStartBlock=0 (physical 539846592, logical offset 0x00000000, physical offset 0x405ACF8000), bootSizeBytes=0, bootLoadAddress=00000000:00000000, bootEntryAddress=00000000:00000000, bootCRC=0x00000000, processorBytes=00000000	00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
    
    Code:
    storage=[
    Info { physical=PartitionExtent { startBlock=546138048, length=0 }, logical=Extent { startBlock=0, length=0 } }, 
    Info { physical=PartitionExtent { startBlock=549414848, length=0 }, logical=Extent { startBlock=0, length=0 } }, 
    Info { physical=PartitionExtent { startBlock=547776448, length=0 }, logical=Extent { startBlock=0, length=0 } }, 
    Info { physical=PartitionExtent { startBlock=64, length=0 }, logical=Extent { startBlock=0, length=0 } }] 
    getSize()=0 logicalBlock=1121
    
     
  16. Jun 15, 2014 #96 of 105
    telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    Guess that's Done.
    [for reading]
    Code:
    Disk '/dev/sda'
    ------------------
    1 :  start=         1, size=        63 ( 31.50K), type='Apple_partition_map', name='Apple'
    13:  start=        64, size= 537225040 (256.17G), type='MFS'                , name='MFS media region 2'
    2 :  start= 537225104, size=         8 (  4.00K), type='Image'              , name='Bootstrap 1'
    3 :  start= 537225112, size=         8 (  4.00K), type='Image'              , name='Kernel 1'
    4 :  start= 537225120, size=         8 (  4.00K), type='Ext2'               , name='Root 1'
    5 :  start= 537225128, size=         8 (  4.00K), type='Image'              , name='Bootstrap 2'
    6 :  start= 537225136, size=         8 (  4.00K), type='Image'              , name='Kernel 2'
    7 :  start= 537225144, size=         8 (  4.00K), type='Ext2'               , name='Root 2'
    8 :  start= 537225152, size=   1048576 (512.00M), type='Swap'               , name='Linux swap'
    9 :  start= 538273728, size=   1572864 (768.00M), type='Ext2'               , name='/var'
    14:  start= 539846592, size=   6291456 (  3.00G), type='Ext2'               , name='SQLite'
    10:  start= 546138048, size=   1638400 (800.00M), type='MFS'                , name='MFS application region'
    12:  start= 547776448, size=   1638400 (800.00M), type='MFS'                , name='MFS application region 2'
    11:  start= 549414848, size= 427358320 (203.78G), type='MFS'                , name='MFS media region'
    ------------------
    Unallocated space: 0 (0.00b)
    
    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=        18 (  9.00K), end=    525427  MEDIA descriptor
      [2] /dev/sda10  start=    525428, size=       130 ( 65.00K), end=    525557  APP descriptor
      [2] /dev/sda10  start=    525558, size=   1112688 (543.30M), end=   1638245  APP data
      [2] /dev/sda10  start=   1638250, size=       130 ( 65.00K), end=   1638379  APP descriptor backup
      [1] /dev/sda10  start=   1638380, size=        18 (  9.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= 427356160 (203.78G), end= 428994559  MEDIA data
      [3] /dev/sda12  start= 428996608, size=         1 (512.00b), end= 428996608  NODE descriptor
      [3] /dev/sda12  start= 428996609, size=    524288 (256.00M), end= 429520896  NODE data
      [4] /dev/sda12  start= 429520897, size=        18 (  9.00K), end= 429520914  MEDIA descriptor
      [5] /dev/sda12  start= 429520915, size=       130 ( 65.00K), end= 429521044  APP descriptor
      [5] /dev/sda12  start= 429521045, size=   1113808 (543.85M), end= 430634852  APP data
      [5] /dev/sda12  start= 430634859, size=       130 ( 65.00K), end= 430634988  APP descriptor backup
      [4] /dev/sda12  start= 430634989, size=        18 (  9.00K), end= 430635006  MEDIA descriptor backup
      [3] /dev/sda12  start= 430635007, size=         1 (512.00b), end= 430635007  NODE descriptor backup
      [4] /dev/sda13  start= 430635008, size= 537210880 (256.16G), end= 967845887  MEDIA data
    ------------------
    
    Zones Physical
    ------------------
      [4] /dev/sda13  start=        64, size= 537210880 (256.16G), end= 537210943  MEDIA data
      [0] /dev/sda10  start= 546139169, size=         1 (512.00b), end= 546139169  NODE descriptor
      [0] /dev/sda10  start= 546139170, size=    524288 (256.00M), end= 546663457  NODE data
      [1] /dev/sda10  start= 546663458, size=        18 (  9.00K), end= 546663475  MEDIA descriptor
      [2] /dev/sda10  start= 546663476, size=       130 ( 65.00K), end= 546663605  APP descriptor
      [2] /dev/sda10  start= 546663606, size=   1112688 (543.30M), end= 547776293  APP data
      [2] /dev/sda10  start= 547776298, size=       130 ( 65.00K), end= 547776427  APP descriptor backup
      [1] /dev/sda10  start= 547776428, size=        18 (  9.00K), end= 547776445  MEDIA descriptor backup
      [0] /dev/sda10  start= 547776446, size=         1 (512.00b), end= 547776446  NODE descriptor backup
      [3] /dev/sda12  start= 547776448, size=         1 (512.00b), end= 547776448  NODE descriptor
      [3] /dev/sda12  start= 547776449, size=    524288 (256.00M), end= 548300736  NODE data
      [4] /dev/sda12  start= 548300737, size=        18 (  9.00K), end= 548300754  MEDIA descriptor
      [5] /dev/sda12  start= 548300755, size=       130 ( 65.00K), end= 548300884  APP descriptor
      [5] /dev/sda12  start= 548300885, size=   1113808 (543.85M), end= 549414692  APP data
      [5] /dev/sda12  start= 549414699, size=       130 ( 65.00K), end= 549414828  APP descriptor backup
      [4] /dev/sda12  start= 549414829, size=        18 (  9.00K), end= 549414846  MEDIA descriptor backup
      [3] /dev/sda12  start= 549414847, size=         1 (512.00b), end= 549414847  NODE descriptor backup
      [1] /dev/sda11  start= 549414848, size= 427356160 (203.78G), end= 976771007  MEDIA data
    ------------------
    
    
    	Size of zones:
    	Used:	8826920 (4.21G)
    	Free:	959015192 (457.29G)
    	Total:	967842112 (461.50G)
    
    	Recordable space reported by Tivo: 967859200 (461.51G), approximately 71 HD hours
    
    
    MfsLayout: done
    
     
  17. Jun 15, 2014 #97 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    It looks good. Which modules did you end up modifying to get it done.
     
  18. Jun 15, 2014 #98 of 105
    telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    It's checked in on github, but will need to be cleaned up.

    There's 2 new classes, BiRandomAccessFile and BiDataInputStream...which took RandomAccessFile and DataInputStream and were reimplemented to support flexible byte ordering. Then any source file using the the old class was modified to reference the new classes. My preference would have been to subclass, but because these were built ins, they were defined as final (and can not be overridden).

    There was another reading method, I guess maybe it's called NIO, that had to have its mode changed, but it had this feature built in.

    Then 4 fields were swapped (2 swaps) as ggieseke directed.
    The Crc function had to be modified, which was some guesswork, but it self confirms that it's right.
    Then Roamio partition map has a lot of zero-ed fields, some of which JMFS was depending on for higher logic, so sane implied defaults had to be put in.

    MLS does not work, probably because it's using inodes, which have not been reexamined yet.

    To get writing to work, BiDataOutputStream, would have to be implemented.
     
  19. Jun 16, 2014 #99 of 105
    jmbach

    jmbach der Neuerer

    1,556
    10
    Jan 1, 2009
    Have you tried it on your 4TB construct yet?

    I'll download your repository and compile it and try it on the one I have hopefully after work if I don't run over too long.
     
  20. telemark

    telemark New Member

    1,544
    1
    Nov 12, 2013
    I gave it a try last night, but I think the USB-SATA adapters I have are not reporting large drive sizes correctly.

    It sounds like you have a compatible one if you never had problems before.

    I'll have to try again after I build a Java+SATA box.
     

Share This Page