# Roamio 4Tb Drive Development Thread



## eboydog

Is anyone working on DIY 4tb drive upgrade and is it worth starting a new thread here ? I must say that after having 3tb of storage in my Roamio, it's somewhat overwhelming and I do see having 4tb of storage as being unmanageable. I would like to figure this out simply as a challenge to overcome but in a practical day to day operation, having that much recording storage is crazy! 

I'm not a hex editor type but with the recent thoughts of the image copy distribution of the drive that came up, I have an idea I would like to throw out to perhaps get things started in a legit manner rather than just copying someone else's work. Can't tell me that there are only one or two people on the Internet (other than Tivo themselves) that can figure this out! 

My out of the blue idea: Has anyone done a sector copy of stock Roamio drive and then applied it to a 4tb drive? I plowed though the big Roamio drive upgrade thread and saw what happens when you put a raw 4tb drive in and the box tries to format it but rejects it but, what would happen if the basic unreadable image of a stock drive was written to the beginning of a 4tb drive, could that possibly overcome that initial rejection? I'm curious what something like Clonzilla could do.... It's my thought that perhaps there is no partition on the Roamio drive and when the box boots up, it looks for the drive and reads raw data off the drive at the beginning of the drive which contains "is this good" drive and if so the OS continues the boot and initialization process until everything is loaded. This is just my thought as unless I'm wrong, all conventional attempts to read the partitions in the conventional manner has failed, there must be a completely new and different file/data structure in place which would indicate a raw, most likely encrypted, data being written to the drive in a Stream like process. 

Another issue which I mention in another thread which is a possible clue, those who have the 4tb drive solution are offering it for each Roamio model, their drive kits they offer don't appear to be a universal solution but each prepared drive only works in the model the buyer intends to install the prepared drive in. DVR Dude is very explicit in his eBay description that his kits can't be installed in a different Roamio model than specified. That implies there is some basic required identifying information on the drive that is required to start a successful identification process when the Roamio boots up. If the drive imaging process of a stock drive doesn't work, is there a utility that can read the raw sector data on a drive, save it and then rewrite such to another drive? Again I'm not describing using one of these prepared drives to accomplish this but to use a initialized stock drive to prepare a 4tb drive. 

I have a extra basic Roamio and I'm pretty sure I going to buy a 4tb drive and start experimenting, in the worse case I can use the 4tb drive for other purposes if it doesn't work out but I'm hoping others might chime in and offer practical ideas. I'm willing to start something with providing the basic hardware and time, however I need assistance from some of you more knowledgeable TiVo hard drive gurus. 

What do you think?


----------



## ggieseke

If you clone a Roamio drive to a 4TB drive it should work, but it won't use any of the extra space. Given the limitations of the 32-bit partition table the trick is to resize the first physical MFS media partition (#13) and move everything else around so that the second physical media partition (#11) starts just short of the 2TB limit. Then you resize that partition to use the rest of the available space.

Resizing MFS partitions is new ground. In the past you just added a "blank" partition to the end but that won't work past 2TB.

I'm working on a program to copy and expand any TiVo to its max, but it's months away.


----------



## eboydog

OK, I had the misunderstanding that there was some mystery "ghost like" partition on the drives that no known utility or OS could read or manipulate. 

The lack of discussion I thought was unusual but I guess most TiVo users are happy with 3tb.


----------



## ggieseke

Roamios use slightly different structures for the partition maps, MFS headers and zone maps than earlier models but they're still recognizeable. The main reason that existing programs like jmfs don't recognize it as a TiVo drive at all is that they switched the byte order.

It's just a matter of time. I know what I want to write and (mostly) how to do it, but I'm swamped at work right now.


----------



## unitron

ggieseke said:


> Roamios use slightly different structures for the partition maps, MFS headers and zone maps than earlier models but they're still recognizeable. The main reason that existing programs like jmfs don't recognize it as a TiVo drive at all is that they switched the byte order.
> 
> It's just a matter of time. I know what I want to write and (mostly) how to do it, but I'm swamped at work right now.


When you say "switched the byte order", are we talking about Series 1 type byte swapping to accommodate the CPU?


----------



## ggieseke

Series 1s just swapped every pair of bytes in the sector something like this:

01 23 45 67 89 AB CD EF...
23 01 67 45 AB 89 EF CD...

You had to read everything in sector size chunks and 'swab' them before you could start to interpret the results.

Roamios use Intel byte order (least significant byte first) in Block0, the APM and MFS data structures instead of the Motorola byte order (MSB first) used by all earlier models. For 2 byte values like the Block0 signature it looks the same as a Series 1 and 14 92 becomes 92 14. Four byte fields like the partition start and size in the APM are completely reversed and you read them right to left. The same goes for 8 byte fields in some of the MFS header structures. For instance, the signature field for a 64-bit MFS volume header is 0xEBBAFEED. In a hex editor it looks like this:

EB BA FE ED (Series 2-4)
ED FE BA EB (Roamio)


----------



## unitron

ggieseke said:


> Series 1s just swapped every pair of bytes in the sector something like this:
> 
> 01 23 45 67 89 AB CD EF...
> 23 01 67 45 AB 89 EF CD...
> 
> You had to read everything in sector size chunks and 'swab' them before you could start to interpret the results.
> 
> Roamios use Intel byte order (least significant byte first) in Block0, the APM and MFS data structures instead of the Motorola byte order (MSB first) used by all earlier models. For 2 byte values like the Block0 signature it looks the same as a Series 1 and 14 92 becomes 92 14. Four byte fields like the partition start and size in the APM are completely reversed and you read them right to left. The same goes for 8 byte fields in some of the MFS header structures. For instance, the signature field for a 64-bit MFS volume header is 0xEBBAFEED. In a hex editor it looks like this:
> 
> EB BA FE ED (Series 2-4)
> ED FE BA EB (Roamio)


But is the change to accommodate the CPU, like the S1s, or for some other reason?


----------



## ggieseke

I suspect that the new Broadcom chips use LSB first, but I don't have any hard data on them.

On Series 1s, I think that the byte swapping may have been inherent in the I/O circuitry. Even back then there were more 32-bit fields in the various headers than 16-bit fields, so matching it to the CPU doesn't really make much sense. It also made a complete hash of string values, requiring even more code for the CPU to run unless it was somehow handled on a lower level.


----------



## telemark

Mips chips are generally endiness flexible, but determined by the board designer. It is odd Tivo chose to make a switch at this point, but it might make sense if their hardware designs are coming from 3rd parties and the industry standard was LSB.

I'm thinking of the Cisco, Samsung, Mini and Stream boxes here which predate the Roamio release. And the Broadcom reference platforms.

I spent a couple nights looking into this 4TB issue.

My initial inclination is that there's a bug in the MFS creation code, so expect this is something Tivo will fix at some point. Has someone tried switching to a 4TB drive after the box was updated to 20.4?

Aside from MFS, the rest looks straightforward to me. One thing that would help down the road is the Roamio linux kernel. Maybe this deserves it's own thread but Tivo has fallen significantly behind in posting it's GPL and OSS code base.

Someone want to go ask them for it?

PS. Is there any reference / good thread on MFS data structures? I couldn't find any beyond generalities.


----------



## unitron

telemark said:


> ...
> 
> PS. Is there any reference / good thread on MFS data structures? I couldn't find any beyond generalities.


Yes, they come as part of the TiVo service manual package.

Unfortunately, that gets delivered by Unicorn Express.


----------



## telemark

I'm getting from a hard drive + hex editor:


Code:


Series 5: feed ebba 
Series 4: baeb edfe

Edit: and that would be because I'm in word mode instead of byte mode. Nevermind.


----------



## jmbach

Here is a link to the newer software. https://www.tivo.com/legal/opensource It has version 2.0 and 2.1 OS for the premiere and 1.0 for the stream.


----------



## telemark

Yah, I looked through that and everything else I could find. I believe there are no Roamio era releases in anything on the Tivo website.

I'd be happier to be wrong here.

The reason I conclude that summarily is the Roamio logs indicate the kernel is Linux 3.3.8, and all the sources I could find on Tivo.com were 2.something. 

It might still be useful to someone. 

There is a program called pdisk64 for example. Has a number of interesting comments. I myself didn't see how to get it built, nor could I tell if it was bi- until it was built. Real C programmers could probably do it, cause I think I was just short 1 include for 1 function call which is probably part of the OS.


----------



## jmbach

The Premiere OS version number on the site I do not believe corresponds to the Linux version. I am wondering though if 2.0 stands for OS 20.x.x. I haven't spent time looking through it to determine if that is the case. It just that there was an OS 19.x.x and the Web site has a version 1.9. So it leads me to think so. But I have not confirmed that in any way.


----------



## ggieseke

I doubt that the Linux kernel would do us much good anyway since it's all in flash memory on a Roamio and the open source code that they do release has nothing to do with MFS.


----------



## jmbach

That is true. Would help premieres more. The previous open source releases had some MFS building and checking tools.


----------



## telemark

I'm at the point that my next step would be to make a test release. 

This would a 4TB whole disk image with large chunks of zero-ed data.

I'm going to start a build tonight, and wanted to know if there's consensus on preferred image formats.

Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?

I've looked at .vhd but the documentation I saw said it only goes up to 2TB. I think some versions of VMware (VMDK) and VirtualBox (VDI) can go to 4TB.


----------



## eboydog

telemark said:


> I'm at the point that my next step would be to make a test release.
> 
> This would a 4TB whole disk image with large chunks of zero-ed data.
> 
> I'm going to start a build tonight, and wanted to know if there's consensus on preferred image formats.
> 
> Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?
> 
> I've looked at .vhd but the documentation I saw said it only goes up to 2TB. I think some versions of VMware (VMDK) and VirtualBox (VDI) can go to 4TB.


So there is no way to exclude.the.zero padded part ?

myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.can you.offer any details.in what.you.did.to allow it to recognize.the 4tb drive?


----------



## telemark

> So there is no way to exclude.the.zero padded part ?

I'm not saying that, but adding that functionality at the same time as the first release would negate the testing data if a bug were ever found. You wouldn't be able to tell if the bug is from Tivo OS, the original image, or an insufficient reimaging process / previous hard drive data. Limiting the initial scope restricts the number of variables to a degree that it could be debuggable if the need arises.

> myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.

Could be possible. But my goal was certain compatibility, which directs me toward a different type of release than that. I think my goal order is Compatibility, followed by [running] Performance, followed by Speed [to image].

My choice, doesn't diminish yours. Projects are not exclusive. The more the merrier.

> details.

forthcoming, after I'm done building and testing (then documenting).


----------



## nooneuknow

telemark said:


> > So there is no way to exclude.the.zero padded part ?
> 
> I'm not saying that, but adding that functionality at the same time as the first release would negate the testing data if a bug were ever found. You wouldn't be able to tell if the bug is from Tivo OS, the original image, or an insufficient reimaging process / previous hard drive data. Limiting the initial scope restricts the number of variables to a degree that it could be debuggable if the need arises.
> 
> > myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.
> 
> Could be possible. But my goal was certain compatibility, which directs me toward a different type of release than that. I think my goal order is Compatibility, followed by [running] Performance, followed by Speed [to image].
> 
> My choice, doesn't diminish yours. Projects are not exclusive. The more the merrier.
> 
> > details.
> 
> forthcoming, after I'm done building and testing (then documenting).


It's worth adding that large, contiguous, blocks of zeroed sectors compress down VERY well, with most compression utilities.

I can compress (zip) down a virgin 2TB .VHD TiVo image file to 1.5GB, or less, and nothing is left out when it is restored, either as a quick restore, or writing all data, including the zeroes (nothing left to chance). The quick restore takes about 2 minutes, at most. The full restore takes as long as writing all zeroes to to whole drive using drive testing tools.


----------



## jmbach

telemark said:


> > So there is no way to exclude.the.zero padded part ?
> 
> I'm not saying that, but adding that functionality at the same time as the first release would negate the testing data if a bug were ever found. You wouldn't be able to tell if the bug is from Tivo OS, the original image, or an insufficient reimaging process / previous hard drive data. Limiting the initial scope restricts the number of variables to a degree that it could be debuggable if the need arises.
> 
> > myself I envisioned.a image of.sorts.that.would contain the intial.byte image signature.instead of an entire.disk image.
> 
> Could be possible. But my goal was certain compatibility, which directs me toward a different type of release than that. I think my goal order is Compatibility, followed by [running] Performance, followed by Speed [to image].
> 
> My choice, doesn't diminish yours. Projects are not exclusive. The more the merrier.
> 
> > details.
> 
> forthcoming, after I'm done building and testing (then documenting).


How are you developing the image? Are you using a Roamio self built image and modding that to get a working 4TB image, building one completely from scratch, or using a 3rd party image and modding that?


----------



## jmbach

telemark said:


> I'm at the point that my next step would be to make a test release.
> 
> This would a 4TB whole disk image with large chunks of zero-ed data.
> 
> I'm going to start a build tonight, and wanted to know if there's consensus on preferred image formats.
> 
> Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?
> 
> I've looked at .vhd but the documentation I saw said it only goes up to 2TB. I think some versions of VMware (VMDK) and VirtualBox (VDI) can go to 4TB.


dd and gzip should be fine. In windows 7z can read gzip files and I believe a program from HDDGuru can read the dd files and write them to a drive.


----------



## nooneuknow

jmbach said:


> dd and gzip should be fine. In windows 7z can read gzip files and I believe a program from HDDGuru can read the dd files and write them to a drive.


HDDGuru's HDD Raw Copy Tool can do .VHD files. I just fired it up and didn't find any options besides drive to drive, VHD to drive, and drive to VHD.

Since .VHD files have that 2TB limit, I'm not sure if it will be of much help here.

I was quite surprised that I overlooked that raw Windows utility for my planned 3TB to 3TB Roamio drive clone (from WD Red NAS to WD AV-GP). Hopefully it won't object to >2TB on a drive-to-drive, and has better speed that GNU dd rescue (what jmfs uses).

I'm wondering if there's a reason that utility never comes up when people ask about, or provide answers about, cloning TiVo drives. Raw is raw, so it should work (theoretically). I'll post again after I try it out.


----------



## jmbach

The HDD Raw Copy Tool saves images with an img extension, which if I remember correctly, I had dd copy back to a drive. At least it used to. My version is several years old. It also can save an image in a compressed format it labels as a dimg.


----------



## nooneuknow

jmbach said:


> The HDD Raw Copy Tool saves images with an img extension, which if I remember correctly, I had dd copy back to a drive. At least it used to. My version is several years old. It also can save an image in a compressed format it labels as a dimg.


The most recent version, which is several years old, works with Windows 7, surprisingly. I haven't tried it with 8/8.1 yet.

Upon further scrutiny, I found it does read raw drives, .vhd files as if they were drives, and *can* write them to *.img* and *.imgc* files. I don't have any of those .img or .imgc files to see if it can read from them to write them to a drive with the program.

I suppose if I created a new blank VHD and had it mounted, the program should be able to write to it.

I've never used dd for disk to file, or file to disk, so I can't comment on what currently will work and what won't, with those file types.


----------



## telemark

> Easiest for me would be, dd and gzip, which I know would support Linux and Mac. Which leaves Windows?

It turns out it would have been easier for me to strip 0's, but it would have been harder to reconstitute, so it's the same situation.

In any case, I have a Linux installer uploaded. Waiting for hash confirmations now. Feel free to PM me if you want to be the first test subject, until I get the documentation ready.  Ideally with access to Linux and a Base Roamio.

> It's worth adding that large, contiguous, blocks of zeroed sectors compress down VERY well, with most compression utilities.

Ya, I got 1,000:1 and 640,000:1

> How are you developing the image? Are you using a Roamio self built image and modding that to get a working 4TB image, building one completely from scratch, or using a 3rd party image and modding that?

In-between option 1 and option 2, approximately.

I haven't seen anyone else's images besides what my Roamio would build to avoid taint, though, having gone through this exercise, I'd be curious to hear of anything they chose differently as I spent extra effort to make what I thought were the best attributes to have.


----------



## jmbach

How much recording space did you end up with?


----------



## telemark

So here's the story. If you put a 4TB drive in a Roamio and leave it to format, the logs shows a crash here:

Formatting MFS partitions (/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13)
/dev/sda has [sectors in 512] blocks
Disk size >= 128 gibibytes (268435456 blocks), using big MFS extents
Disk size >= 140 gibibytes (293601280 blocks), using 64-bit MFS format
Creating 500000 inodes, please wait
assert: Tmk Assertion Failure: 
assert: HPK_Result TivoDiskIOGetBlockSize(HPK_DiskIOInstance*, HPK_UInt32*), line 115 ()
Process fsmake([PID]) killed by signal Unknown signal -2--2
Tmk Fatal Error: Thread fsmake <[PID]> strayed!
Paste the following into a shell to get a backtrace...
bt -t /tvbin/tivoapp <<END_OF_BT
[stuff]
END_OF_BT

And summarily reboots itself.

What this implies is the drive is left with the MFS filesystem never formatted (and whatever else comes after that).

Whether that's a bug vs reasonable check, and whether it will eventually be changed, I can see being debatable.

The conclusions from this though, if you keep that value within an Unsigned Int 32bits, the format would have succeeded. Or if you properly finish the MFS format offline (and what remains of the installation), in any of variety of ways, the drive would be accepted.

Also relevant, after the default partitioning for 4TB, the kernel recognizes / reports this partition list:
sda: [tivo] sda1 sda2! sda3! sda4! sda5! sda6! sda7! sda8! sda9! sda10! sda11![M] sda12! sda13![M] sda14! 

I'm under the assumptions:
- the '!' is used to designate a 64bit format record in the partition table.

The kernel source would contain the exact definition of each symbol.

Edit: This is under 20.3.6, the first OS this box came with.


----------



## telemark

So one cheap and quick method, is set a HPA, but I seriously hope nobody ever runs that way.

My preferred method is:
1) build a partition map by hand
-everything within 32bits
-centered, with the MFS media partitions equal
2) MFS format offline, using whatever combination of tools / hardware
(I know this is the interesting part, but I can not redistribute all the software, and some of the hardware is rare, so I'd rather skip over the details)
3) Check every other partition is set sanely.
4) Confirm the installation continues.

> How much recording space did you end up with? 
I didn't tweak the other partition sizes, the media partitions come to:
3900923680 * 2 * 512 bytes = 3.6TB


----------



## ggieseke

Yeah, it lays out the partition table on a 4TB drive using some 64-bit APM entries, but something else in the autobuild process doesn't recognize it and it's bootloop time.

I haven't seen anyone get the 64-bit APM working on a primary drive yet, but the Weaknees 4TB external does use it.

I haven't actually tried 20.4.1 yet but I don't expect TiVo to fix it until they start selling 4TB Roamios.


----------



## jmbach

telemark said:


> So one cheap and quick method, is set a HPA, but I seriously hope nobody ever runs that way.
> 
> My preferred method is:
> 1) build a partition map by hand
> -everything within 32bits
> -centered, with the MFS media partitions equal
> 2) MFS format offline, using whatever combination of tools / hardware
> (I know this is the interesting part, but I can not redistribute all the software, and some of the hardware is rare, so I'd rather skip over the details)
> 3) Check every other partition is set sanely.
> 4) Confirm the installation continues.
> 
> > How much recording space did you end up with?
> I didn't tweak the other partition sizes, the media partitions come to:
> 3900923680 * 2 * 512 bytes = 3.6TB


So we could get a little more recording space and use up more of the drive. Also ideally you want all the MFS partitions to be a multiple of 1024 sectors. Any extra sector space at the end of a MFS partition (which is usually only the media partitions that would have that property) that is over a multiple of 1024 sectors is not used by the MFS. I have not looked at the numbers yet, you probably can reduce all the placeholder partitions into one 4k block to keep the 4k alignment intact, but if it does not get you the extra sectors needed to allow any of the MFS partitions to get to the next multiple of 1024 sectors, it probably is not worth the mod.


----------



## telemark

ggieseke said:


> I haven't seen anyone get the 64-bit APM working on a primary drive yet, but the Weaknees 4TB external does use it.


You can see it would work on the primary drive too, as long as some partitions are 32. This combination comes up in certain values of HPA. Roughly, if you keep #13 MFS Media 2 and a few successors in 32, you can make #11 MFS Media 1 into 64.

But I saw no point in putting this in until a larger driver shows up and it's actually required.



jmbach said:


> So we could get a little more recording space and use up more of the drive. Also ideally you want all the MFS partitions to be a multiple of 1024 sectors. Any extra sector space at the end of a MFS partition (which is usually only the media partitions that would have that property) that is over a multiple of 1024 sectors is not used by the MFS. I have not looked at the numbers yet, you probably can reduce all the placeholder partitions into one 4k block to keep the 4k alignment intact, but if it does not get you the extra sectors needed to allow any of the MFS partitions to get to the next multiple of 1024 sectors, it probably is not worth the mod.


If anything is wrong with the existing one, i'll have it rebuilt. If it's tweaks, I was thinking of putting all the tweaks together into a 2nd parallel version, if there's enough of them to warrant.

The other thing I learned, is there's a random number (signature) in the bootsector starting at byte 304 (counting from 0). I haven't figured out which component is reading it, but it seems kinda new, as a lot of my Premiere images don't have it.


----------



## ggieseke

telemark said:


> The other thing I learned, is there's a random number (signature) in the bootsector starting at byte 304 (counting from 0). I haven't figured out which component is reading it, but it seems kinda new, as a lot of my Premiere images don't have it.


I think that's a GUID that gets assigned to the drive when it's built. I'm just guessing, but the 16 byte format is the right size and you get a different number every time you put a new drive in.


----------



## telemark

ggieseke said:


> I think that's a GUID that gets assigned to the drive when it's built. I'm just guessing, but the 16 byte format is the right size and you get a different number every time you put a new drive in.


I agree, but since Premiere drives didn't have them back when they were built, did they eventually get them in a SW update?

And if not, then is it important for anything?

I was most interested in whether MFS depends on it as metadata, but I didn't immediately see it when I went looking.


----------



## ggieseke

telemark said:


> I agree, but since Premiere drives didn't have them back when they were built, did they eventually get them in a SW update?
> 
> And if not, then is it important for anything?
> 
> I was most interested in whether MFS depends on it as metadata, but I didn't immediately see it when I went looking.


I see it in Premiere images as far back as 20.3.1, but it wasn't there on 14.5.


----------



## telemark

Hm, I thought I have an unbooted premiere image where it's missing. You're right, it has 14.5. I'll check if it eventually shows up.

I just noticed the jmfs source is available on github. It should be simple to patch this to be bi-endian. Am I missing something? Is this a useful tool to have available?


----------



## jmbach

JMFS patched to work on Roamio series would be useful for people with sub 2TB images to expand larger and still keep their shows.


----------



## ggieseke

There are a few other changes in some of the MFS structures (fields swapped or moved slightly), but they're not that hard to spot. A lot of stuff in Block0, the APM and even the MFS headers isn't used on Roamios and zeroed out.

If I knew much more about Java than how to spell it I'd try to patch it myself.


----------



## telemark

I'm stuck on this minor point. So I'll just think aloud, and hopefully someone will point out what I got wrong.

Assumption - When Tivo makes media partitions, it uses 20,480 sectors as minimum chunk size.

So shouldn't the media partitions be a multiple of 20,480 (x512byte sectors = 10MB), otherwise there will be bits at the end that are never reachable, and so never used?


----------



## jmbach

This is my understanding of how this works. 
The MFS partitions are loaded end to end in clusters of 1024 physical disk sectors. So if the MFS partition on the disk larger than a multiple of 1024 sectors, any space in the MFS partition on the disk that lies outside the last cluster of 1024 sectors is never used by the TiVo. 
The TiVo sees the MFS as one large partition. Assuming the chunk size is as you stated, what ever space at the end of the MFS that is less than the chunk size is not used as you have stated unless the MFS space is expanded via an external drive or a JMFS like procedure. When the MFS is expanded, that left over space is now used as the chunk now becomes the left over space plus the extra space needed in the expanded area to complete the chunk. 
So the last MFS media partition is the one that may have space not being used. All the ones before that would be full.
Maybe ggieseke can comment if my understanding is on par with his knowledge of the MFS structure since he has gone down deeper in the rabbit hole than I have.


----------



## ggieseke

telemark said:


> I'm stuck on this minor point. So I'll just think aloud, and hopefully someone will point out what I got wrong.
> 
> Assumption - When Tivo makes media partitions, it uses 20,480 sectors as minimum chunk size.
> 
> So shouldn't the media partitions be a multiple of 20,480 (x512byte sectors = 10MB), otherwise there will be bits at the end that are never reachable, and so never used?


In a perfect world, yes. There's always some waste even on the factory layout. It has always been that way.

It's slightly less than 16MB in total on your project so I wouldn't sweat it. Coincidently, the layout that a Roamio TRIES to create on a 4TB drive wastes exactly the same amount of space even though it uses a different partition scheme. That's about 9-10 seconds of HD.

The Weaknees 4TB drive only wastes 5MB, so they could probably squeeze out a least 6 more seconds of recording time.


----------



## ggieseke

jmbach said:


> This is my understanding of how this works.
> The MFS partitions are loaded end to end in clusters of 1024 physical disk sectors. So if the MFS partition on the disk larger than a multiple of 1024 sectors, any space in the MFS partition on the disk that lies outside the last cluster of 1024 sectors is never used by the TiVo.
> The TiVo sees the MFS as one large partition. Assuming the chunk size is as you stated, what ever space at the end of the MFS that is less than the chunk size is not used as you have stated unless the MFS space is expanded via an external drive or a JMFS like procedure. When the MFS is expanded, that left over space is now used as the chunk now becomes the left over space plus the extra space needed in the expanded area to complete the chunk.
> So the last MFS media partition is the one that may have space not being used. All the ones before that would be full.
> Maybe ggieseke can comment if my understanding is on par with his knowledge of the MFS structure since he has gone down deeper in the rabbit hole than I have.


The zone maps show that the space less than even 10MB blocks at the end of EACH media partition is unused. There's no overlap, which makes sense since they are separated both logically and physically.

That's what I based my last post on.


----------



## jmbach

Then if one of the media partitions is a multiple of a chunk then more disk would be used and less waste? Even though WK drive has less waste in the partition, does it equal out in the end because they have more free space unallocated in their images?


----------



## ggieseke

The total number of sectors on the drive and the size of the other partitions never works out perfectly with the block size on the media partitions. There will always be unused sectors somewhere.

The Weaknees layout manages to cut the total wasted space down from 15.78125MB to 5MB, but both media partitions still have some slack. If you make one partition perfect the other one will just have additional unused space.

A few seconds of recording space either way isn't going to matter to anyone.


----------



## nooneuknow

jmbach said:


> This is my understanding of how this works.
> The MFS partitions are loaded end to end in clusters of 1024 physical disk sectors. So if the MFS partition on the disk larger than a multiple of 1024 sectors, any space in the MFS partition on the disk that lies outside the last cluster of 1024 sectors is never used by the TiVo.


Just so as not to confuse the rest of the people following this (or trying to), including myself: Are you sure it's physical (4K/4096 byte) sectors, or did you mean the logical emulated ones (512 byte).

Are "blocks" and "clusters" the same thing, or are they different?


----------



## jmbach

Clusters are groups of blocks. 
I am referring to block size of 512 bytes as this is what all the TiVo calculations are based off of.


----------



## mrsean

Anyone notice that Seagate has a new 6GB hard drive out? I wonder if it's possible to get it to work in the Roamio. Imagine 952 hours of HD recording and 6540 SD.


----------



## nooneuknow

jmbach said:


> Clusters are groups of blocks.
> I am referring to block size of 512 bytes as this is what all the TiVo calculations are based off of.


Thanks.

So, your post should say "logical" instead of "physical", then, right?

I know that host devices (like TiVos) often falsely identify emulated sectors as being "physical", but other devices do correctly detect that the physical sector size is 4K/4096 bytes, and the logical (emulated) size is 512 bytes. My laptop's Intel Rapid Storage Technology driver and program does, while Windows 7 seems to see them as 512 byte physical (on the surface, at least).


----------



## jmbach

nooneuknow said:


> Thanks.
> 
> So, your post should say "logical" instead of "physical", then, right?
> 
> I know that host devices (like TiVos) often falsely identify emulated sectors as being "physical", but other devices do correctly detect that the physical sector size is 4K/4096 bytes, and the logical (emulated) size is 512 bytes. My laptop's Intel Rapid Storage Technology driver and program does, while Windows 7 seems to see them as 512 byte physical (on the surface, at least).


Probably be easier if I just define the block size I am referring to and not worry about physical / logical.


----------



## jmbach

ggieseke said:


> The total number of sectors on the drive and the size of the other partitions never works out perfectly with the block size on the media partitions. There will always be unused sectors somewhere.
> 
> The Weaknees layout manages to cut the total wasted space down from 15.78125MB to 5MB, but both media partitions still have some slack. If you make one partition perfect the other one will just have additional unused space.
> 
> A few seconds of recording space either way isn't going to matter to anyone.


Hmmm. As you say it is not going to matter overall. I like seeing things used efficiently and it is not since there is some waste involved. Can't have everything.

If one partition is a multiple of 20480 512 byte blocks then that partition would have zero waste and the other would have about 5MB of waste.


----------



## telemark

Thanks for clarifying all that. I found a combination I was happy enough with, taking into account everything.

I'm finishing off a Linux installer, but I know more people are Windows. Would DvrBARS be able to write a 2.2TB vhd image to a 4TB drive?



mrsean said:


> Anyone notice that Seagate has a new 6GB hard drive out? I wonder if it's possible to get it to work in the Roamio. Imagine 952 hours of HD recording and 6540 SD.


I noticed, but also noticed they're 7200rpm? Maybe the helium type versions have low enough heat and power, I didn't check.

Should be able to make this work. The other idea that's been floating around is supporting an eSATA RAID enclosure.

If someone wants to buy or already has this hardware, let us know, cause I think a few people have been thinking about this.


----------



## ggieseke

telemark said:


> I'm finishing off a Linux installer, but I know more people are Windows. Would DvrBARS be able to write a 2.2TB vhd image to a 4TB drive?


That should work fine. What I would do is to create a dynamically expanding VHD using Windows Disk Manager that's juuusssssst big enough to hold the last byte that you need to write. 1900MB should be more than enough.

Create a VMWare or Windows Virtual PC box, attach that VHD, and run your Linux installer. Instant DvrBARS compatible file. I can do all of that in a few minutes if you don't have virtualization software handy.

P.S. Disk Manager allows you to enter fractions, so you could even make it 1865.91791534423828125MB or whatever value you actually need.


----------



## cykotix

jmbach said:


> JMFS patched to work on Roamio series would be useful for people with sub 2TB images to expand larger and still keep their shows.


I don't have a Roamio so I haven't read up on the differences between it and the Premiere. However, just doing a quick look you guys pointed out that the MFS header is different between a Premiere (0x1492) and Roamio (0x9214). Is that the biggest hurdle with using JMFS? Drive detection? Because if that's the case, we can patch https://github.com/krbaker/jmfs/blob/master/src/tivo/disk/Block0.java and replace:



Code:


public static short APPLE_BLOCK0_SIGNATURE = (short)0x1492;

with



Code:


public static short APPLE_BLOCK0_SIGNATURE = (short)0x9214;

Or am I oversimplifying?


----------



## telemark

That's the idea, but it's every field of bytes longer than 1, that also need to be swapped.

If someone literally copied the JMFS code to x86 C/C++, it would almost work without modification.

Java is feature rich enough, that it should be less work to patch it for a reversed byte order.


----------



## jmbach

You could use the signature in block 0 to toggle between byte order.


----------



## cykotix

jmbach said:


> You could use the signature in block 0 to toggle between byte order.


That's what I was thinking, but the bigger issue here is figuring out what parts of the code need to be reversed. If we know exactly what parts are different (which it seems like we do), java appears to have a lovely function, reverseBytes, that can be used to patch those sections based on the block0 signature.

Also, I'm not a java programmer by any stretch of the imagination. I have no problems reading through code though, patching and subsequently compiling. I don't have a way to test though.


----------



## telemark

There are endianness aware object libraries, if used correctly, would only be a couple lines to patch per class that access the disk. This would be the best way to avoid introducing any new bugs.

ggieske said some fields moved though, which implies to me there's some existing misinterpretations in field length when parsing. It shouldn't be moving, it should be swapping to another position, ideally. So these would have to be fixed at the same time if they exist in JMFS. (another explanation is expanding a field from 32 to 64bits)

Tivo of course can do whatever they want, but probably took the route of least effort which is to change the minimum.

I haven't setup a workstation for java yet, and I've been working on other things I thought should come first.

If you need a test case, parsing a Roamio image (downloaded VHD maybe), would be a decent first milestone. If someone's working on this, let me know and I can make an image better suited to this.

There are more high-level than low-level programmers these days. The Wikipedia article seems to cover a number of the common examples, so maybe that's a time saving starting point. http://en.wikipedia.org/wiki/Endianness

Reminder: 
Premiere is MSB / big / Motorola / java order, 
Roamio is LSB / little / Intel / C order, 
both are actually Broadcom (SiByte) MIPS.

Libraries: http://docs.guava-libraries.googlec...le/common/io/LittleEndianDataInputStream.html
http://niftilib.sourceforge.net/java_api_html/EndianCorrectInputStream.html
http://mindprod.com/jgloss/endian.html
http://my.safaribooksonline.com/book/programming/java/1565924851/data-streams/ch07-22270 / http://jcs.mobile-utopia.com/jcs/10155_LittleEndianInputStream.java

EDIT: a smaller first milestone would be to, replace instances of DataInputStream with a bi-endian aware subclass. Confirm that it works on the Premiere images still, than flip the endianness bit and track down what breaks.

Also, Android is bi-endian friendly and uses Java. I personally think it is probably unnecessary, but if stuck, there might be something useful there.


----------



## telemark

There's 2-3 theories on the purpose of the guid.

Which one is right, might change what's the best practices in restoring drive images.

One is it could be used to generate a Host ID somewhere. Of particular interest is if it's used by the CableCard to recognize whether it's a new host.

Alternatively, it could be more filesystem related. This is common in desktop OS's. The only example I could come up that would effect life, is if it's used in external drive marriages. There should be some mechanism that prevents secondary expander drives from being incorporated into a different Tivo (an extra-marital affair, so to speak). Allowing such a thing, would cause corruption of the original pairing.

Or it could be vestigial. I feel like the marriage is just a bit more likely, but would prefer if it fixed the cablecard pairing, because that's the one that could use some improvement, and it would be harder otherwise.


----------



## jmbach

I don't think it is host ID related as my host ID does not change on my cableCARD pairing screen for my Motorola M-Card only the data ID. Not sure about Scientific Atlanta cards. 

The marriage might be. Would need a couple of scenarios to test. One is to take an image and wipe the guid then see if an external drive can be paired. If it can, look at the image and see if a guid was generated. Two, pair an external drive and wipe the guid a difference see if it remains paired and accessible. 
Looks like we need to get ggieseke's knowledge and cykotik and telemark's coding skills (since all ggieseke does with Java is drink it  ) to get JMFS modified.


----------



## whereisthelimit

If the data id changes, then to me it seems related to the DRM protection for the stored video, to prevent the data on the disk from being playable when hooked up to another host.

Sent from my SAMSUNG-SGH-I747 using Tapatalk


----------



## jmbach

The data ID change does not affect the recordings on the drive (premium or not) just my premium channels I receive.


----------



## nooneuknow

jmbach said:


> The data ID change does not affect the recordings on the drive (premium or not) just my premium channels I receive.


It's possibly a YMMV situation, like I described in this post:

http://www.tivocommunity.com/tivo-vb/showthread.php?p=10137631#post10137631

While my Cox market makes little use of the CCI-bit, the cablecard pairing authentication is tightly locked-down.

Cablecard pairing is lost on sector-by-sector drive clones (all the way back to the TiVo HD), even if the drive model and size is identical.

The CCI-bit protected content is only able to play back if the cablecard that was used to record it is still installed, and authenticated.

None of this was the case a few cablecard firmware revisions back.

I'm very likely in a rare market condition here (just like me being in a full 1GHz RF spectrum market, that still carries analog, which uses SDV). If I can do anything to help, being in this market situation, please don't hesitate to ask me (anybody).

I really want to help. I have an uncle who could probably do what everybody is trying to, and make it work in both Linux and Windows, if he only knew anything, at all, about TiVo. He's willing to tackle any challenge I present to him, provided I can get him to understand the TiVoization factors involved...

He is an actual programmer, at a very large corporation, who often gets told "That can't be done", only to write the program to do exactly that, and make it work company-wide, and cross-platform.


----------



## telemark

Porting JMFS should a straightforward task, which is why I suggested it. I downloaded it just now, and it builds. It should take like a day or weekend to patch it. I honestly never used it before though, so I might have some questions re what it it's intending to do.

> I really want to help. I have an uncle who could probably do what everybody is trying to, and make it work in both Linux and Windows, if he only knew anything, at all, about TiVo. He's willing to tackle any challenge I present to him, provided I can get him to understand the TiVoization factors involved...

You make it sound like he doesn't have any Tivos in his house? There are useful tasks for any skill set, you don't have to be programmer.

> He is an actual programmer, at a very large corporation, who often gets told "That can't be done", only to write the program to do exactly that, and make it work company-wide, and cross-platform.

Ya, I like those stories. Can you say what city?

This probably sounds surprising, but I'm not an actual programmer. Because of my skill set, I get tasked with other things, but I do get to technically manage junior developers.

I have a pretty long list of TODOs, more than I will ever finish, but at the same time I know how to do almost everything I added to the list. Those I don't know how to do, are really hard, unless someone has some specialized skills in some of the tech.

Maybe we should be having the conversation, what larger projects are worthwhile.


----------



## lessd

nooneuknow said:


> It's possibly a YMMV situation, like I described in this post:
> 
> http://www.tivocommunity.com/tivo-vb/showthread.php?p=10137631#post10137631
> 
> The CCI-bit protected content is only able to play back if the cablecard that was used to record it is still installed, and authenticated.
> 
> None of this was the case a few cablecard firmware revisions back.
> 
> .


You can play* any *recorded program on any TiVo that it was recorded on even, if the TiVo now has no service or has no cable card installed. the CCI-Bit has nothing with the play-back, except for some PPV movies that have built in time outs for playback.


----------



## jmbach

lessd said:


> You can play* any *recorded program on any TiVo that it was recorded on even, if the TiVo now has no service or has no cable card installed. the CCI-Bit has nothing with the play-back, except for some PPV movies that have built in time outs for playback.


This has been my experience as well. As such I believe the recordings are attached to the TiVo serial number rather than the cableCARD.


----------



## nooneuknow

jmbach said:


> This has been my experience as well. As such I believe the recordings are attached to the TiVo serial number rather than the cableCARD.





lessd said:


> You can play* any *recorded program on any TiVo that it was recorded on even, if the TiVo now has no service or has no cable card installed. the CCI-Bit has nothing with the play-back, except for some PPV movies that have built in time outs for playback.


*I respect both of you. I'd rather have you loosely "in my corner", than being firmly in the opposite one.*

I've gone out of my way to make sure what I say is as accurate a depiction I can make, using the best possible reasons I can come up with, for what I experience, and can replicate, in my posts.

Perhaps what is being done in my market is (possibly) illegal, and Cox is only trying to verify it works, they can get away with it, and/or plans to take it wide scale, if no legal hurdles come up. Perhaps it's a TiVo bug, manifesting in my "less than usual" Cox Fibre/Coax 1GHz network w/analog, digital, and SDV, all in use, situation.

Unless a person is in my market, using the same infrastructure, same cablecards, same firmware, and replicating the ecosystem of the network, as well as on-the-premise equipment, who are they to say it's not happening, or is not possible to happen?

I've stayed silent on the matter, until telemark came along. I'm looking for fresh eyes, fresh thoughts, and not the Same-Old-Sh*t, I got rained on me the last time I brought this specific matter up, when it first reared its ugly head.

If I have to take all the data points I can provide to PM, or other private back-channel, I can do that. I'm trying to do "the community thing".

I can replicate the results without having to make special effort to make them happen. If I still had my older-than-Roamio platforms, I could replicate the results all the way back to the TiVo HD.

I have never failed to replicate the results I spoke of. I've never had to make everything "exactly just-so", to get/replicate the results.

Perhaps it's just the choices of descriptions I use, the way I say them, or the best-educated-guess reasons I share, for why I can get what I get, and replicate it.

The bottom line is that the few CCI-bit protected recordings I end up with, will playback for years without issue. If I remove the cablecard that was authorized when the recordings were made, they won't playback (TiVo error claims no signal was present at the time of the pre-existing recording). Re-inserting and re-pairing the same card, restores the playback (of a recording that has played-back before, without issue). Inserting another card, and pairing it up (or not pairing), results in the aforementioned error, on a recording that had been playing-back for a year, or more.

I see this as a reason to fully understand the suspected GUID, any linkages to cablecards, any linkages to pairing, and/or any linkages to imaging/cloning.

I feel being able to get to the bottom of this requires my input (no matter how impossible some claim my experiences are), and/or more participation from others in my market, with the right factors present.

A perfect example recording is "The Hitchhikers Guide To The Galaxy" (the movie), always recorded from IFCP (considered a "premium", included in a channel "pak"), which does set the cci-bit. I can count on losing access to playing it back, under the circumstances I describe, and can count on restoring playback of it, if I still have the same drive, same cablecard, all in-place (and I haven't since authorized any other card, than the one used during recording).

So, how I proceed is up to the community (options) :

1. I retreat again, and work with nobody on this.
2. I retreat again, and work in private on this.
3. I continue to work with the community, in the open, and hopefully find some others to join-in, from my market.


----------



## jmbach

noneuknow, I have not said that you were wrong, lying, misleading, etc. I have not accused you of or blamed you for anything. I opened my remark with "my experience" because I know that conditions vary with cable companies, locations, etc. So as not to clutter up this thread I will PM you with a response to your post.

Let us go back to the subject at hand. 

Perhaps telemark, you can list your TODO list and there might something in there that either I or another TCF member can help with. TODO lists go much quicker with multiple people working on it and perhaps can get it done.


----------



## nooneuknow

jmbach said:


> noneuknow, I have not said that you were wrong, lying, misleading, etc. I have not accused you of or blamed you for anything. I opened my remark with "my experience" because I know that conditions vary with cable companies, locations, etc. So as not to clutter up this thread I will PM you with a response to your post.
> 
> Let us go back to the subject at hand.
> 
> Perhaps telemark, you can list your TODO list and there might something in there that either I or another TCF member can help with. TODO lists go much quicker with multiple people working on it and perhaps can get it done.


Yeah, another nooneuknow "nuke", that I pretty much dropped indiscriminately. Sorry about that...

I had brought this unusual "lockdown" of content up in the past, when I first observed it, after a cablecard flash update went out.

It got very ugly, very fast. I was accused of "incorrectly cloning" as I tried to gather data points. I was accused of making things up. It seemed that every comment was pegging me (or my actions) as somehow creating the results, not any part of any system, and so on...

I had to just back-out, and say to myself "It's not worth it, if this is what I'm going to get as a result".

The party that really just wouldn't let up on claiming what I observed, and replicated "was impossible", isn't even present (yet).

I've seen new talent come in, and a new opportunity to possibly get to the bottom of this nagging matter, after having to force myself to not even bring it up all this time.

Then I go and lash-out, at the first inkling that I'm going to just get a repeat of last time. Realistically, I sabotaged myself.

I really think this suspected GUID on the drives that has been found, the cablecard pairing data anomaly I have found, and the future of drive changes and upgrades are all part of a design, that I may be able to provide some necessary data on. I just need some help finding what is relevant, and filtering out the rest.

I'd guess that if the way my market locks-down content wasn't isolated, but was instead the "norm", or became the norm, things would be much different from where I sit, with my POV.

Let's see if I can fix that post, and get back on track...


----------



## nooneuknow

telemark said:


> Porting JMFS should a straightforward task, which is why I suggested it. I downloaded it just now, and it builds. It should take like a day or weekend to patch it. I honestly never used it before though, so I might have some questions re what it it's intending to do.
> 
> > I really want to help. I have an uncle who could probably do what everybody is trying to, and make it work in both Linux and Windows, if he only knew anything, at all, about TiVo. He's willing to tackle any challenge I present to him, provided I can get him to understand the TiVoization factors involved...
> 
> You make it sound like he doesn't have any Tivos in his house? There are useful tasks for any skill set, you don't have to be programmer.
> 
> > He is an actual programmer, at a very large corporation, who often gets told "That can't be done", only to write the program to do exactly that, and make it work company-wide, and cross-platform.
> 
> Ya, I like those stories. Can you say what city?
> 
> This probably sounds surprising, but I'm not an actual programmer. Because of my skill set, I get tasked with other things, but I do get to technically manage junior developers.
> 
> I have a pretty long list of TODOs, more than I will ever finish, but at the same time I know how to do almost everything I added to the list. Those I don't know how to do, are really hard, unless someone has some specialized skills in some of the tech.
> 
> Maybe we should be having the conversation, what larger projects are worthwhile.


Yeah, unfortunately, my uncle does not have any TiVos. I'm in the process of parting-out the last unsubbed TiVo HDs I have, which is the last of any "extra" TiVos I have around...

I'll decline on stating the company he works for, the exact position, etc. It's pretty much nationwide and multinational scale-wise.

I think of him as ggieseke, except linux is his preferred playground, and Windows is just something he has to make his projects work on. 

At one point, before you came around, I'd asked ggieseke if it would make sense for a two-pronged approach, leaving ggieseke to update DVRBARS, and I'd have my uncle bring JMFS up to date. That conversation kind of died.

I also wondered how I could expect my uncle to remake JMFS, with just source-code, and no TiVo Roamio (or other model) to work with. I'm not well-off enough to buy him the hardware platforms and drives, and it's not on his to-do list, either...

I really want to dig into finding any GUIDs that exist on TiVos, and find a way to backup and restore just the data needed to keep the cablecard pairing from being lost, or "zapped". You've already read enough to know the "why" behind this, and my motivations.


----------



## ggieseke

FWIW, I think CableCARD pairing data will always be a black hole that's dependant on your provider. Unless it gets buried somewhere in the tyDb files on the MFS partitions we're screwed there since nobody has come up with a way to read the flash memory on a Roamio yet.


----------



## lessd

nooneuknow said:


> *I respect both of you. I'd rather have you loosely "in my corner", than being firmly in the opposite one.*
> 
> I've gone out of my way to make sure what I say is as accurate a depiction I can make, using the best possible reasons I can come up with, for what I experience, and can replicate, in my posts.
> 
> Perhaps what is being done in my market is (possibly) illegal, and Cox is only trying to verify it works, they can get away with it, and/or plans to take it wide scale, if no legal hurdles come up. Perhaps it's a TiVo bug, manifesting in my "less than usual" Cox Fibre/Coax 1GHz network w/analog, digital, and SDV, all in use, situation.
> 
> Unless a person is in my market, using the same infrastructure, same cablecards, same firmware, and replicating the ecosystem of the network, as well as on-the-premise equipment, who are they to say it's not happening, or is not possible to happen?
> 
> I've stayed silent on the matter, until telemark came along. I'm looking for fresh eyes, fresh thoughts, and not the Same-Old-Sh*t, I got rained on me the last time I brought this specific matter up, when it first reared its ugly head.
> 
> If I have to take all the data points I can provide to PM, or other private back-channel, I can do that. I'm trying to do "the community thing".
> 
> I can replicate the results without having to make special effort to make them happen. If I still had my older-than-Roamio platforms, I could replicate the results all the way back to the TiVo HD.
> 
> I have never failed to replicate the results I spoke of. I've never had to make everything "exactly just-so", to get/replicate the results.
> 
> Perhaps it's just the choices of descriptions I use, the way I say them, or the best-educated-guess reasons I share, for why I can get what I get, and replicate it.
> 
> The bottom line is that the few CCI-bit protected recordings I end up with, will playback for years without issue. If I remove the cablecard that was authorized when the recordings were made, they won't playback (TiVo error claims no signal was present at the time of the pre-existing recording). Re-inserting and re-pairing the same card, restores the playback (of a recording that has played-back before, without issue). Inserting another card, and pairing it up (or not pairing), results in the aforementioned error, on a recording that had been playing-back for a year, or more.
> 
> I see this as a reason to fully understand the suspected GUID, any linkages to cablecards, any linkages to pairing, and/or any linkages to imaging/cloning.
> 
> I feel being able to get to the bottom of this requires my input (no matter how impossible some claim my experiences are), and/or more participation from others in my market, with the right factors present.
> 
> A perfect example recording is "The Hitchhikers Guide To The Galaxy" (the movie), always recorded from IFCP (considered a "premium", included in a channel "pak"), which does set the cci-bit. I can count on losing access to playing it back, under the circumstances I describe, and can count on restoring playback of it, if I still have the same drive, same cablecard, all in-place (and I haven't since authorized any other card, than the one used during recording).
> 
> So, how I proceed is up to the community (options) :
> 
> 1. I retreat again, and work with nobody on this.
> 2. I retreat again, and work in private on this.
> 3. I continue to work with the community, in the open, and hopefully find some others to join-in, from my market.


You are the first person on this Forum (that I have read) that has said that a TiVo recorded playback depends on having the cable card in the TiVo, people have moved from one place to another taking their TiVo(s) with them, then putting a new cable card for their new MSO in the TiVo, they have never reported any loss of playback recordings already on the TiVo, I have seen that I can play any recording on a non activated TiVo without its cable card, no problem, but I can't answer for your area or MSO, it just that if this was the way things worked in parts of the country I just assumed (maybe incorrectly) this Forum would have been talking about this playback issue sometime after sept. 2006 when the first cable cards TiVos went on sale, that almost 8 years ago.


----------



## nooneuknow

ggieseke said:


> FWIW, I think CableCARD pairing data will always be a black hole that's dependant on your provider. Unless it gets buried somewhere in the tyDb files on the MFS partitions we're screwed there since nobody has come up with a way to read the flash memory on a Roamio yet.


I'm not sure if I "doubt" it's in the Roamio's flash, or just really "don't want it to be" there... Even if it is, if no GUID change is detected, shouldn't it stay intact? Basically, trick the Roamio into preserving it, thus negating a need to see the flash contents?

Maybe the guy wanting to know the smallest possible hard drive that a Roamio could prepare (or run, pre-made) was onto something...

Smaller drives make raw disk editors/hex editors less likely to take years off your life as you scan the data on them, looking for crumbs/clues/changes...

I swear, if Apple made these things, they'd have been "jailbroken" the day before they went on sale...


----------



## nooneuknow

lessd said:


> You are the first person on this Forum (that I have read) that has said that a TiVo recorded playback depends on having the cable card in the TiVo, people have moved from one place to another taking their TiVo(s) with them, then putting a new cable card for their new MSO in the TiVo, they have never reported any loss of playback recordings already on the TiVo, I have seen that I can play any recording on a non activated TiVo without its cable card, no problem, but I can't answer for your area or MSO, it just that if this was the way things worked in parts of the country I just assumed (maybe incorrectly) this Forum would have been talking about this playback issue sometime after sept. 2006 when the first cable cards TiVos went on sale, that almost 8 years ago.


Nothing about my market reflects the rest of the country, except that we use coax and cablecards (this is the short version of my point).

I often feel like I'm the only TiVo owner in my market. I get treated like that's the case when I deal with them (Cox).

Who else, except me, is going to be OCD enough to investigate why "The Hitchhiker's Guide to the Galaxy" (and maybe six other recordings) consistently fail to be watchable every time I change the cablecards?

Who else, in my market had eight TiVos and eight cablecards at one time, and would move the cablecards around, or replace them every so often?

Most probably would shrug the loss of a few movies they wanted to hang onto, delete them, and never even know TCF exists, right?

I'm not trying to be argumentative in this. I see this as a logical answer to the question you pose: "Why only hear this from me?"

Who messes around with their TiVos, changes drives, whole configurations, and all these other things never meant to be done, just to replicate the results and come here to report them? That seems to be limited to me, when it comes to my market.

I don't see that as making what I report any less true, or "impossible" and some will flat-out say...

The content and spirit of this whole thread, and all the DIY threads are not what "most people" do when they buy a DVR...

While I feel all this has a part in "best practices" for future drive expansions, I also don't want to hijack the thread, over what is just part of a bigger picture...


----------



## ggieseke

nooneuknow said:


> I'm not sure if I "doubt" it's in the Roamio's flash, or just really "don't want it to be" there... Even if it is, if no GUID change is detected, shouldn't it stay intact? Basically, trick the Roamio into preserving it, thus negating a need to see the flash contents?
> 
> Maybe the guy wanting to know the smallest possible hard drive that a Roamio could prepare (or run, pre-made) was onto something...
> 
> Smaller drives make raw disk editors/hex editors less likely to take years off your life as you scan the data on them, looking for crumbs/clues/changes...
> 
> I swear, if Apple made these things, they'd have been "jailbroken" the day before they went on sale...


YMMV says it all.


----------



## telemark

So I posted 4 LittleEndian object implementations. #3 had an inconvenient web page. #2 was implemented as a subclass, which is slightly different than the others.

The Google one, #1, looks complete, but it didn't have an ant build file, and was large. The OReilly one, #4, was simple, but incomplete. I frankensteined them and added 2 missing functions myself.

I don't know if it's 100% correct but this does build.

On another attempt I'll try a different combination. The Google library should work out of the box, and the subclass might be fine too.

Bad news:


Spoiler



Giving it a 500GB hard drive the ROAMIO freshly produced,
./mfslayout.sh /dev/disk1

java.lang.Exception: No root MFS found
at tivo.Mfs.addDisks(Mfs.java:311)
at tivo.Mfs.<init>(Mfs.java:75)
at tivo.Mfs.<init>(Mfs.java:69)
at jmfs.MfsLayout.main(MfsLayout.java:42)
MfsLayout: done



Good News:


Spoiler



As baseline, I compiled the krbaker and jmbach github jmfs without modification, and ran them against my PREMIERE backups.

About half work, but half of them give me: 
./mfslayout.sh /dev/disk1

java.lang.Exception: No root MFS found
at tivo.Mfs.addDisks(Mfs.java:309)
at tivo.Mfs.<init>(Mfs.java:74)
at tivo.Mfs.<init>(Mfs.java:68)
at jmfs.MfsLayout.main(MfsLayout.java:42)
MfsLayout: done



I could have corrupt images, or a bad build. Or has this been seen before?
32bit vs 64bit formats maybe?


----------



## jmbach

I have had that error in the past. If I recall correctly, it is looking for a valid Partition 10 and cannot find it. There is an environment variable you can set to tell it where its at but it never worked for me. Sometimes when this happens, I found that there was an issue reading the APM. Other times there was some corruption in partition 10. The rest I did not have a clue.

Now JMFS does not recognize a 32bit MFS layout. If you used it on all Premiere images, they are all 64bit MFS, so that should not have been an issue. 

One test would be to see if pdisk from MFSLive CD can read the APM or if dd can recognize the partition by trying to copy it.


----------



## telemark

I'm trying the slax live CD now and it is more consistent. Very odd, I can move the same build from a desktop OS to the CD environment and it'll start working.


----------



## jmbach

You have brought back painful memories. I had no clue that dd would understand a TiVo APM for a long time until reading the forums and seeing that members were using it to copy individual partitions. So when I was working on figuring out how to expand a premiere to 4TB, I thought I would just use dd. I had so many issues using dd to copy partitions that I used iBored instead. In retrospect, it might have been related to me using VirtualBox to run the ISOs and it can only access the drive I was working on via USB2 and not eSata. I figured out that was hdparm's problem but never thought it was dd's issue as well.


----------



## nooneuknow

jmbach said:


> I had no clue that dd would understand a TiVo APM for a long time until reading the forums and seeing that members were using it to copy individual partitions.


I found out by accident, due to sleep-deprivation (a state that often contributes to some of my meandering/long posts).

When using GNU dd_rescue intending a full clone, I typed "dev/sda1 dev/sda2" instead of "/dev/sda /dev/sdb". Big "oops!" then "aha!" moment. Luckily, I'd practiced what I preached and was working with a backup copy of sda.

I don't know the long-term effects of copying the boot sector over the beginning of partition 2 of a Premiere, but it effectively stopped software from installing to that partition via KS52, and didn't kill the unit, even after a KS57&58 failed to fix it (and didn't create a boot-loop). I'd hoped to test if it would "block" a newly downloaded software from installing itself, but never remembered to try it. Another thought was it was a way to take a partition with bad sectors "out of play", letting you limp along on the good alternate.

Not Roamio-related, AFAIK, but maybe it will give somebody an idea on how to do something they hadn't thought of a way to.


----------



## nooneuknow

telemark said:


> I'm trying the slax live CD now and it is more consistent. Very odd, I can move the same build from a desktop OS to the CD environment and it'll start working.


I seem to recall slax being used by Comer for at least few things during the making of JMFS, and it sometimes being the choice of others, over the many distros out there.

I've yet to learn enough about linux to know what distro is best. I'm mostly looking for:

1. Most drivers already included (especially USB3 onboard and add-on card)
2. Up to date device drivers (not necessarily for the newest HW)
3. Best raw copy rate between two USB3 drive docks
4. I like GNU dd_rescue, and like to run the newest release
5. I want it to not be shy about using the RAM and resources available, like for caching disk I/O

I like Live DVDs, or alternately Live USB sticks. Most of my dedicated test systems (guts on a bench) are mid Core2Duo era, with 4-6GB RAM.

What's suggested for my preferences, and also works well with 3 & 4TB drives, if I'm going to start doing more than talk about wanting to try to help find ways to build large images, and find ways to preserve Roamio content when moving to larger drives?

I have to start somewhere... Programming/coding is something I know so little about, that I guess all that is left is working with partitions and layouts, and things that can be done with disk/hex editors.


----------



## telemark

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.


----------



## nooneuknow

telemark said:


> 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.


Since KMTTG is written for Java, perhaps the author may be of some assistance on Java matters?



telemark said:


> 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.


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.



telemark said:


> 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.


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).



telemark said:


> 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.


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...



telemark said:


> 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.


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.


----------



## jmbach

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.


----------



## telemark

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='&#65533;&#65533;', 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  |[email protected]@.....(/|
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?


----------



## jmbach

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.


----------



## ggieseke

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.


----------



## telemark

jmbach said:


> 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.


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  |[email protected]@....|
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


----------



## jmbach

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.


----------



## jmbach

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.


----------



## ggieseke

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.


----------



## telemark

ggieseke said:


> 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.


Ok, I'll look for that.

Was the CRC covering the 512 sector or did you need the 4096 sector?


----------



## jmbach

Traditionally the CRC has been the 512 byte sector.


----------



## ggieseke

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.


----------



## jmbach

I am only close if it was a horseshoe game. Thanks for the correct info.


----------



## telemark

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, [email protected]
	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


----------



## telemark

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


----------



## jmbach

It looks good. Which modules did you end up modifying to get it done.


----------



## telemark

jmbach said:


> It looks good. Which modules did you end up modifying to get it done.


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.


----------



## jmbach

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.


----------



## telemark

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.


----------



## jmbach

Not sure the the mod is important in your edits, but did you make the change in the Apple Disk module to handle images larger than 0xEFFFFFFF?


----------



## telemark

I added a different version of the patch to my repository now and tested. 
mfslayout does work with a 4TB image.


----------



## telemark

Attached is 3 different partition maps using the same offsets.

The all 32bit one is the same as the original used in imaging.
Then there's an all 64bit one.
And an all 64bit, except one.

The results I got on a Base Roamio, running 20.3.8:
All 32bit works
All 64bit, the roamio triggers a reformat.
All but first one, works again.

If someone wants to try this at home, I used the command:
dd if=4TBr1-64.map of=/dev/sdX count=14 seek=1 
to install them.


----------



## jmbach

telemark said:


> Attached is 3 different partition maps using the same offsets.
> 
> The all 32bit one is the same as the original used in imaging.
> Then there's an all 64bit one.
> And an all 64bit, except one.
> 
> The results I got on a Base Roamio, running 20.3.8:
> All 32bit works
> All 64bit, the roamio triggers a reformat.
> All but first one, works again.
> 
> If someone wants to try this at home, I used the command:
> dd if=4TBr1-64.map of=/dev/sdX count=14 seek=1
> to install them.


Similar results Roamio Plus with 20.4.1

All 32bit - works
All 64bit - reformat loop
Mixed with Partition 1 32bit and the rest 64bit - works

Now what would happen if we had an image that:
a) had at least one partition start beyond 2.2TB
b) a partition larger than 2.2TB
c) a combination of the above.


----------



## ggieseke

jmbach said:


> Similar results Roamio Plus with 20.4.1
> 
> All 32bit - works
> All 64bit - reformat loop
> Mixed with Partition 1 32bit and the rest 64bit - works
> 
> Now what would happen if we had an image that:
> a) had at least one partition start beyond 2.2TB
> b) a partition larger than 2.2TB
> c) a combination of the above.


In my experience, 64-bit partition table entries trigger a reformat and boot loop if any of the entries go beyond a 32-bit value (0xFFFFFFFF) for the start or size fields. The partition tables we're talking about here don't need to be 64-bit, so as long ast the first Apple_partition_map entry is 32-bit it seems to work.

I haven't specifically tested a Roamio running 20.4.1, but 20.3.8 still had those limitations and I don't think anything fundamental has changed since then. For now I think 5 & 6 TB drives are still out of the question. A properly prepared 4TB drive with the MFS headers and zone maps already in place seems to work, as telemark's work has shown.


----------

