Has anyone compiled any of the TiVo drive upgrade/backup tools for Raspberry Pi? (ARM A6 instruction set)
↧
Raspberry Pi Tools
↧
Premier Memory Upgrade: Is it possible/Worth it?
I got a Premier a few months ago, just before Roamio was introduced of course and noticed that doing anything in the Tivo menu seems slow. Is it possible to upgrade the RAM or is the HD the only item that is upgradeable? If so, is there a got site to get the hardware?
↧
↧
Anyone try the new 'hybrid' 2TB drives in an S3?
There are new 'hybrid' 2TB drives available from Seagate (and I suppose others) that have huge 'SSD' caches, supposedly speeding things up considerably. Newegg currently has one for $99.
Has anyone used one of these in the S3 OLED model and noticed any improvements?
Specifically, I'd like for the guide and menus to load faster (a LOT faster), and Season Passes to register more quickly.
Playback/record performance is just fine as is.
Has anyone used one of these in the S3 OLED model and noticed any improvements?
Specifically, I'd like for the guide and menus to load faster (a LOT faster), and Season Passes to register more quickly.
Playback/record performance is just fine as is.
↧
Should cloning 2TB drive on XL4 take 10-12 hours?
I am in the process of cloning the 2TB drive for my Tivo Premiere XL4 (model 758250). This would be just to have a backup drive in case the original drive fails. I only have about 4-5 hours of programs on the original drive, nothing critically important.
My question is this - will it reduce the drive cloning time if I have "permanenetly deleted" all "deleted" programs on my Tivo? Or will it have to "copy" the full 2TB drive?
The reason I ask is that on my first attempt I used a 1TB drive as the back-up, and found out that the back-up failed since the drive to be cloned has to be equal or larger in size than the original source drive. The copy process for the first TB of copying took almost 5 hours. I have now purchased a 2TB drive and plan to run the clone this week - but am afraid it might take 10-12 hours.
(note - for copying, both sata drives are hooked directly to mother board on Windows system).
My question is this - will it reduce the drive cloning time if I have "permanenetly deleted" all "deleted" programs on my Tivo? Or will it have to "copy" the full 2TB drive?
The reason I ask is that on my first attempt I used a 1TB drive as the back-up, and found out that the back-up failed since the drive to be cloned has to be equal or larger in size than the original source drive. The copy process for the first TB of copying took almost 5 hours. I have now purchased a 2TB drive and plan to run the clone this week - but am afraid it might take 10-12 hours.
(note - for copying, both sata drives are hooked directly to mother board on Windows system).
↧
Use a Premiere 500GB HD in a 320GB Premiere?
I have a Tivo Premiere TCD746320 (320GB HD) with a lifetime subscription. Can I take the hard drive out of a Tivo Premiere model TCD746500 (500GB HD) and use it in my unit? I am looking at this as an alternative to buying a blank hard drive and going thru the software copy/transfer routine.
--thanks--
--thanks--
↧
↧
Expanding 1TB XL to 3TB
For those of you who are interested, a 1TB XL (748) can be expanded to 3TB. Ggieseke discovered that a Premiere XL can boot from a 3TB drive and that the important thing is that the image you need to work from is one of the later iterations of the OS. I have tried booting with older images but they bootloop. So if you have the original image backed up somewhere, you will need an update to it. Also you will need a copy of JMFS.
First copy the updated OS image to a 3TB drive. I used DvrBARS to do a modified backup and a quick restore. However, I believe using a variation of dd will work as well (ie using the copy selection in JMFS).
Once that is done, just use JMFS to expand and supersize the image. Here is a picture of my XL with a 3TB drive.
![]()
I have tried this with the 2TB XL4 (758) image but JMFS fails on expansion. So currently only a 1TB XL (748) can be expanded to the full 3TB drive. For those of you who are adventurous, after copying the 1TB image to the 3TB drive, you can 4k align it manually and then expand and supersize it.
Before someone asks, I don't think a Series 3 1TB HD can be expanded this way as JamieP pointed out in another thread, the kernel of Series 3 TiVo's does not appear to be compiled with large disk support. If someone wants to attempt this and report back on their findings then we would know for sure. Just make sure you use 11.0m when you do this.
First copy the updated OS image to a 3TB drive. I used DvrBARS to do a modified backup and a quick restore. However, I believe using a variation of dd will work as well (ie using the copy selection in JMFS).
Once that is done, just use JMFS to expand and supersize the image. Here is a picture of my XL with a 3TB drive.
I have tried this with the 2TB XL4 (758) image but JMFS fails on expansion. So currently only a 1TB XL (748) can be expanded to the full 3TB drive. For those of you who are adventurous, after copying the 1TB image to the 3TB drive, you can 4k align it manually and then expand and supersize it.
Before someone asks, I don't think a Series 3 1TB HD can be expanded this way as JamieP pointed out in another thread, the kernel of Series 3 TiVo's does not appear to be compiled with large disk support. If someone wants to attempt this and report back on their findings then we would know for sure. Just make sure you use 11.0m when you do this.
↧
4TB DIY in a Roamio Plus yet?
If this is already posted somewhere and I missed it, please feel free to direct me there.
I'm considering the purchase of a Roamio plus and would immediately like to upgrade it. I could go 3TB but if I can go 4tb I'd prefer that. Weakness has upgrade kits but I'm a DIY sort when it comes to these kinds of things. Does anyone have an "official" word (preferably first-hand experience if possible) on what 4tb hard drives will work in a Roamio plus?
Thanks!
I'm considering the purchase of a Roamio plus and would immediately like to upgrade it. I could go 3TB but if I can go 4tb I'd prefer that. Weakness has upgrade kits but I'm a DIY sort when it comes to these kinds of things. Does anyone have an "official" word (preferably first-hand experience if possible) on what 4tb hard drives will work in a Roamio plus?
Thanks!
↧
WinMFS Restore w/Series1 + 1TB problem
I'm trying to use WinMFS to restore a known good Series 1 .tbk to a 1TB drive. This backup worked fine with a 320GB drive previously. The restore to the 1TB appeared to work fine and WinMFS expanded to use unused capacity.
The Tivo comes up fine and goes into Guided Setup, which works fine, connects to tivo to confirm account status (lifetime), sets clock, but when it gets to downloading local phone numbers. it aborts, saying "Failed. Call Interrupted". I confirmed nothing else is using the phone.
Wonder if this is the first step that actually writes to the drive (as opposed to perhaps storing info on NVRAM on the motherboard)?
Was there anything else I needed to do to be able to use 1TB with WinMFS on a Series 1? I thought it automatically handled larger drives with its kernel. Do I somehow need to do a copykern or something like that, or should this have worked?
Thanks!
Sam
The Tivo comes up fine and goes into Guided Setup, which works fine, connects to tivo to confirm account status (lifetime), sets clock, but when it gets to downloading local phone numbers. it aborts, saying "Failed. Call Interrupted". I confirmed nothing else is using the phone.
Wonder if this is the first step that actually writes to the drive (as opposed to perhaps storing info on NVRAM on the motherboard)?
Was there anything else I needed to do to be able to use 1TB with WinMFS on a Series 1? I thought it automatically handled larger drives with its kernel. Do I somehow need to do a copykern or something like that, or should this have worked?
Thanks!
Sam
↧
Upgrading a series 5 Roamio
I'd like to know which drive is the best one to use for upgrading the Roamio, WD30EURS or WD30EURX or any other, just looking for the BEST.
Also can a 4TB drive be used instead?
Thanks.
Also can a 4TB drive be used instead?
Thanks.
↧
↧
MFSLive won't recognize new WD 1TB Drive
I just bought a new WD 1TB drive to replace the dead drive in my Series 3. I have made my bootable MFSLive CD, and booted to it. After it scrolls through all of my system information, I page through it, and there is no mention of my new drive hooked up to my SATA cables. I have verified that my BIOS recognizes the drive, but MFSLive does not. Does the drive have to be formatted prior to using MFSLive?
Any suggestions? Thanks in advance.
Any suggestions? Thanks in advance.
↧
Restore: Unable to open /dev/sdc for writing
I am now attempting to connect my new WD 1TB drive via USB in order to copy my new Image to the drive to replace my Dead Hard Drive in my Series 3.
I am using MFSLive as my Boot CD.
After connecting the USB for my new WD drive I get the following displayed:
Usb 2-1.1: new high speed USB device using ehci_hcd and address 5
USB 2-1.1: configuration #1 chosen from 1 choice
scsi4: scsi emulation for USB Mass Storage devices
scsi 4:0:0:0: Direct Access ASMT 2105 0 PQ: 0 ANSI: 6
sd 4:0:0:0: Attached scsi removable disk sdc
So, after mounting my thumb drive which has the new image I attempt to do the restore command with:
restore -s 128 -xzpi /dos/000001 /dev/sdc
Then I get the message:
Restore: Unable to open /dev/sdc for writing
Does the drive need to be formatted first? Why am I getting this? Any suggestions for me? Thanks in advance!
I am using MFSLive as my Boot CD.
After connecting the USB for my new WD drive I get the following displayed:
Usb 2-1.1: new high speed USB device using ehci_hcd and address 5
USB 2-1.1: configuration #1 chosen from 1 choice
scsi4: scsi emulation for USB Mass Storage devices
scsi 4:0:0:0: Direct Access ASMT 2105 0 PQ: 0 ANSI: 6
sd 4:0:0:0: Attached scsi removable disk sdc
So, after mounting my thumb drive which has the new image I attempt to do the restore command with:
restore -s 128 -xzpi /dos/000001 /dev/sdc
Then I get the message:
Restore: Unable to open /dev/sdc for writing
Does the drive need to be formatted first? Why am I getting this? Any suggestions for me? Thanks in advance!
↧
S3 Consolidation while preserving recordings
I wanted to share some of my experiences with the group, in case it helps other people. With the help of jmbach, and dougdingle, I was trying to consolidate my S3 OLED which has the original internal drive (250GB) and a 1 TB external drive onto a single 2TB drive. The process was reasonably straightforward once I got the source for the mfstools from the MFSLive CD and fixed the code to properly handle drives larger than 1TB. I used the procedure laid out in
http://www.tivocommunity.com/tivo-vb...14#post9915514
which worked successfully.
But dougdingle mentioned that he had a S3 that he had not been able to upgrade because it had already had its internal drive expanded. So I wanted to see if I could understand the process better.
Here is my understanding of how things work. Someone please correct me if I am wrong on any of this stuff... Some of it is obvious and well-trod knowledge, but I'm trying to piece things together here...
The TiVo has multiple media regions on disk (these are typically the "Media Partitions" in the partition map). However, the way the TiVo keeps track of the various partitions and available space is via the zone map data structures. This is a linked list of structures that has the head in the first application zone. (It may be pointed to in the MFS super block; I'm not sure about that, but the TiVo knows how to find the first zone map, and once it finds the first one, the rest chain off from there.) The zone maps come in three different flavors that describe different things (inodes, application regions, media regions). The way that the tivo points to things on the disk(s) is via sectors. However, the sectors are not the same as the sectors on the disk. (They are the same size, but sector X on disk does not necessarily correspond to sector X in the TiVo's idea of sectors.)
The MFS superblock contains a list of partitions (the devlist). The tivo loads each partition in the order given. The way the TiVo addresses things by sector is by making a contiguous "address space" of sectors by just appending each partition's sectors as the are loaded. So if the devlist contains "/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13", and those partitions have 10, 20, 30, and 40 sectors respectively, then the contents of hda10 are sectors 0-9, hda11 is 10-29, hda12 is 30-59, and hda13 is 60-99. These partitions may be anywhere on the disk, and they may be on other disks, but they just get loaded contiguously for the purpose of calculating sector addresses.
The zonemaps work in sector addresses, so when the TiVo goes looking for something at sector X, it figures out which partition that sector lies in, then takes the offset into that partition. So as long as you make sure that the partitions are loaded in order, and they are the right size, they can be anywhere. And also, the partition numbers indexed by their order in the partition map, not their order on disk. For example, on the internal drive for my S3 TiVo, the partition map looks like
Note that the last partition in the map is actually describing a partition thats first on the disk (media region 2, /dev/hda13). TiVo does this so that the OS is physically in the middle of the disk, with big media partitions on either side to keep the average seek distance down.
When TiVo looks at a partition, it actually rounds the sectors in the partition down to the nearest multiple of 1024. So if you look at /dev/hda11 in the above, its a wierd size (216747657), and is not a multiple of 1024 sectors. I'm not sure why TiVo did this; this is the unmodified disk that came with the unit. So even though the partition is a weird size, TiVo will only consider the partition to have 216747008 sectors. There are 649 sectors at the end of the partition that aren't used. This is important, because when TiVo is counting sectors, it uses the rounded-down number, not the actual size of the partition on disk.
You can see the size of the partitions (as used by TiVo) with mfsinfo.
(Note that I'm actually using images of the disks, not the disks themselves. The name of the partitions look a little weird, but everything else is exactly the same.)
So /dev/hda11 is the 11th partition on the internal disk, which from the partition map is 216747657 sectors, but in the MFS volume set is 216747008 sectors. So when TiVo is counting sectors, sectors 0-589823 are on /dev/hda10, then 589824 - 217336831 are on /dev/hda11, then 217336832 - 217926655 are on /dev/hda12, and so on. The partitions on the external disk (/dev/hdc2 and /dev/hdc3) just get loaded sequentially as well; the fact that they happen to be on another disk is just kept track of in the devlist. The list of sectors that TiVo uses is contiguous across all volumes.
So when the TiVo looks at the disks, it loads the partitions in the order listed in the devlist, and builds the mapping of "TiVo sectors" to hard disk sectors. Once that is done, the distinction of where partition boundaries are seems to be lost. This is why the trick of collapsing or coalescing multiple partitions into one (as referenced in the thread mentioned above) works. If you take partitions that are contiguous in load order (meaning their partitions are sequential in the devlist) and you concatenate them, and you increase the size of the entry in the partition map to include the added data, then the whole big block will be loaded and the data in the concatenated partitions will be found just fine. A few things to remember, though. If you are going to concatenate one partition onto the end of another, you need to add the data starting at the end of the active part of the partition, if the partition isn't a multiple of 1024 sectors. Otherwise, the "unused" sectors at the end of the first partition will get included when the partition is loaded which will screw up the sector counts, and will make all of the sector offsets be wrong. (Meaning that the zonemaps will not be where they are supposed to be, and nothing will work.) The other thing is that you can only concatenate partitions if they are sequential in load order. Partitions that are physically adjacent on disk might not be adjacent in load order, so you can't assume that partitions that are adjacent on disk can be combined. Load order is dictated by the devlist.
So as long as you keep these rules in mind, you can move partitions around, change the order in the devlist, reorder the partition map, etc, as long as the result is that the data will all be loaded in the same order.
One other side note: it appears that if the TiVo starts up and finds that some of the partitions in the devlist don't exist, and your TiVo has an external drive, then it will bring up the "I can't find the external drive. Do you want to divorce it?" screen. Then, when you tell it to go ahead, it loads all the partitions in the devlist, then starts looking at all of the shows in the filesystem. It will delete any shows that it doesn't have all of the data for, but keep all of the ones that it does have all of the data for. So in the earlier thread, the idea is that we take the data from the partitions that used to be on the external drive, concatenate them into an existing partition on the internal drive, and change the partition map so that there is one entry that includes the sectors from all three partitions. That way, when the TiVo boots, it will load all of the data (because all of the sectors are now contained in the remaining partitions), but it will see some partitions are missing, and bring up the divorce screen, and do the divorce process. During the divorce process, it won't find any sectors missing, so it will complete successfully, and keep all of the recordings.
So given this knowledge of a set of behaviors, I wanted to see if I could combine a setup like Doug's, with an expanded internal drive and an external drive. I took a couple of 1 TB drive and copied (just using dd) my real internal and external drives onto them. I then ran mfsadd to expand the internal drive, and offered it to the TiVo, and it was perfectly happy with this pair. It found and used the additional partition pair.
So the partition map for the internal disk is
and the partition map for the external disk is
and MFSInfo for the combined pair gives
So you can see how the partition I added with mfsadd got stuck on the end of the load order. If the internal disk had been expanded before the external disk was added, those partitions would have showed up before the /dev/hdc partitions in the devlist.
Note that since I copied everything with dd, the original partition (with odd partition sizes) was retained. If you copy things with MFS backup/restore, that makes partitions without extra sectors on the end.
Also note that I used a slightly tweaked version of mfsadd that allows me to hold back some sectors when adding the new partition. The 2TB drive I was using to test combining on is just a little smaller than the combined size of the two 1 TB drives I was using. So I made the added partition a little smaller so that everything would fit. That's why there is a free partition at the end of the disk. It might or might not be there on other systems.
So for this arrangement on disk, TiVo maps sectors to partitions as follows:
We can re-arrange things as we see fit, as long as the data ends being loaded in the correct order.
I started by copying the contents of the internal drive onto a 2TB drive just using dd. Then the problem was how to copy the contents of the external drive (hdc2 and hdc3) and stuff them into an existing partition. The data needs to get loaded right after hda13. But hda13 is at the start of the disk, so there is no room after that. So I decided to put the data at the front of hda14, and change the devlist to move the references to the external partitions to the end. (Those partition reference will be to the no-longer-existing disk that triggers the divorce. I don't know what TiVo would do if the missing partitions are in the middle of the devlist; I probably wouldn't be happy at all, because if the partitions are missing, partitions that are after it in the devlist can't load properly, since the sector numbers would be all wrong.)
I copied all of the data from the external disk and put it at where hda14 starts, then I copied the data from the real hda14 after the external disk's data. I changed the entry in the partition map to make the size of hda14 big enough to encompass all of this data. I also had to re-copy the data from the real hda15, since that partition got moved on disk to accommodate the data from the external drive. I also had to fix the partition map to create the corrected hda15.
To accomplish these moves/copies, I just used dd:
For me, /dev/sdc was the 1TB internal disk, /dev/sdd was the 1TB external disk, and /dev/sdh was the 2TB target disk.
(As an aside, the commands I actually used were slightly different, because doing the dd with 512B blocks was really slow. Using 8KB blocks was about 10 times faster. So in the above, I just changed the bs=512 to bs=8k, then divided all of the numbers by 16. I could do that since they were all multiples of 8KB.)
The adjusted partition map looks like
So you can see that the "New MFS Application" partition is now huge, since it contains the data from the external disk.
When I run mfsinfo on it, I get
You can see that I've reordered the devlist to move the reference to hdc2 and hdc3 to the end of the list. (You might have to scroll the text box above to the right to see it.) That way the TiVo will see them as missing, but won't give up on other partitions that would otherwise have followed them.
mfsinfo shows /dev/hdc2 and /dev/hdc3 as 0 size because they are missing. If I take the reference to /dev/hdc2 and /dev/hdc3 out of the devlist, mfsinfo is completely happy with the consolidated disk, and reads and validates the zonemaps without a problem. But if I put it into the TiVo like that (with hdc2 and hdc3 not in the devlist), it would complain about an incorrect storage device. But with the references to hdc2 and hdc3 back in the devlist, it figures out that it needs to divorce the disk.
So to test it out, I offered the disk to the TiVo and it did what was expected. It did the divorce (which took 5-10 minutes or so), then rebooted and all of the recordings were still there, and the TiVo reported the correct size.
Looking at the drive post-divorce with mfsinfo shows:
and we can see that the TiVo got rid of the reference to /dev/hdc2 and /dev/hdc3.
So the point of this exercise was to show what you can do if you stay within the rules. I tried to do some of this with MFS backup/restore, but that doesn't seem to deal properly with partitions that have been consolidated (and that required me to modify the source volume). It also doesn't deal well at all with creating a destination volume with more than 16 partitions. (The TiVo can't deal with that disk, but I might have wanted it to just do the copy, and then I would consolidate the partitions post-restore.) MFS restore has the 16 partition limit hard coded in a number of places, so it looked like it was going to be a pain to modify. Its not clear what the backup/restore approach does for you if you're copying all of the video streams. If you're copying all of the data, you can accomplish the same thing with dd. But for normal operations, backup/restore are much easier to use, and a lot more failsafe. And they make nice even partitions.
But you could accomplish all of that (partition aligning, moving, reordering, etc) with dd and pdisk. The only thing magic I used was a quick tool to allow manipulation of the devlist. I did all of the above using Debian 12.04 LTS.
http://www.tivocommunity.com/tivo-vb...14#post9915514
which worked successfully.
But dougdingle mentioned that he had a S3 that he had not been able to upgrade because it had already had its internal drive expanded. So I wanted to see if I could understand the process better.
Here is my understanding of how things work. Someone please correct me if I am wrong on any of this stuff... Some of it is obvious and well-trod knowledge, but I'm trying to piece things together here...
The TiVo has multiple media regions on disk (these are typically the "Media Partitions" in the partition map). However, the way the TiVo keeps track of the various partitions and available space is via the zone map data structures. This is a linked list of structures that has the head in the first application zone. (It may be pointed to in the MFS super block; I'm not sure about that, but the TiVo knows how to find the first zone map, and once it finds the first one, the rest chain off from there.) The zone maps come in three different flavors that describe different things (inodes, application regions, media regions). The way that the tivo points to things on the disk(s) is via sectors. However, the sectors are not the same as the sectors on the disk. (They are the same size, but sector X on disk does not necessarily correspond to sector X in the TiVo's idea of sectors.)
The MFS superblock contains a list of partitions (the devlist). The tivo loads each partition in the order given. The way the TiVo addresses things by sector is by making a contiguous "address space" of sectors by just appending each partition's sectors as the are loaded. So if the devlist contains "/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13", and those partitions have 10, 20, 30, and 40 sectors respectively, then the contents of hda10 are sectors 0-9, hda11 is 10-29, hda12 is 30-59, and hda13 is 60-99. These partitions may be anywhere on the disk, and they may be on other disks, but they just get loaded contiguously for the purpose of calculating sector addresses.
The zonemaps work in sector addresses, so when the TiVo goes looking for something at sector X, it figures out which partition that sector lies in, then takes the offset into that partition. So as long as you make sure that the partitions are loaded in order, and they are the right size, they can be anywhere. And also, the partition numbers indexed by their order in the partition map, not their order on disk. For example, on the internal drive for my S3 TiVo, the partition map looks like
Code:
Partition map (with 512 byte blocks) on '/deskstar/s3-internal-disk.dd'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 1 @ 268618469
3: Image Kernel 1 8192 @ 268618470 ( 4.0M)
4: Ext2 Root 1 524288 @ 268626662 (256.0M)
5: Image Bootstrap 2 1 @ 269150950
6: Image Kernel 2 8192 @ 269150951 ( 4.0M)
7: Ext2 Root 2 524288 @ 269159143 (256.0M)
8: Swap Linux swap 262144 @ 269683431 (128.0M)
9: Ext2 /var 524288 @ 269945575 (256.0M)
10: MFS MFS application region 589824 @ 270469863 (288.0M)
11: MFS MFS media region 216747657 @ 271649511 (103.4G)
12: MFS MFS application region 2 589824 @ 271059687 (288.0M)
13: MFS MFS media region 2 268618405 @ 64 (128.1G)
Device block size=512, Number of Blocks=488397168 (232.9G)
DeviceType=0x0, DeviceId=0x0When TiVo looks at a partition, it actually rounds the sectors in the partition down to the nearest multiple of 1024. So if you look at /dev/hda11 in the above, its a wierd size (216747657), and is not a multiple of 1024 sectors. I'm not sure why TiVo did this; this is the unmodified disk that came with the unit. So even though the partition is a weird size, TiVo will only consider the partition to have 216747008 sectors. There are 649 sectors at the end of the partition that aren't used. This is important, because when TiVo is counting sectors, it uses the rounded-down number, not the actual size of the partition on disk.
You can see the size of the partitions (as used by TiVo) with mfsinfo.
Code:
---------------------------------------------------------------------
Super Header
state=0 magic=abbafeed
devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hdc2 /dev/hdc3
zonemap_ptr=1121 total_secs=2440069120
---------------------------------------------------------------------
MFS volume set for /deskstar/s3-internal-disk.dd and /deskstar/s3-external-disk.dd
The MFS volume set contains 6 partitions
Partition sectors size
/deskstar/s3-internal-disk.dd10 589824 288 MiB
/deskstar/s3-internal-disk.dd11 216747008 105833 MiB
/deskstar/s3-internal-disk.dd12 589824 288 MiB
/deskstar/s3-internal-disk.dd13 268617728 131161 MiB
/dev/hdc2 4096 2 MiB
/dev/hdc3 1953520640 953867 MiB
Total MFS sectors: 2440069120
Total MFS volume size: 1191440 MiB
Estimated hours in a standalone TiVo: 1480
---------------------------------------------------------------------So /dev/hda11 is the 11th partition on the internal disk, which from the partition map is 216747657 sectors, but in the MFS volume set is 216747008 sectors. So when TiVo is counting sectors, sectors 0-589823 are on /dev/hda10, then 589824 - 217336831 are on /dev/hda11, then 217336832 - 217926655 are on /dev/hda12, and so on. The partitions on the external disk (/dev/hdc2 and /dev/hdc3) just get loaded sequentially as well; the fact that they happen to be on another disk is just kept track of in the devlist. The list of sectors that TiVo uses is contiguous across all volumes.
So when the TiVo looks at the disks, it loads the partitions in the order listed in the devlist, and builds the mapping of "TiVo sectors" to hard disk sectors. Once that is done, the distinction of where partition boundaries are seems to be lost. This is why the trick of collapsing or coalescing multiple partitions into one (as referenced in the thread mentioned above) works. If you take partitions that are contiguous in load order (meaning their partitions are sequential in the devlist) and you concatenate them, and you increase the size of the entry in the partition map to include the added data, then the whole big block will be loaded and the data in the concatenated partitions will be found just fine. A few things to remember, though. If you are going to concatenate one partition onto the end of another, you need to add the data starting at the end of the active part of the partition, if the partition isn't a multiple of 1024 sectors. Otherwise, the "unused" sectors at the end of the first partition will get included when the partition is loaded which will screw up the sector counts, and will make all of the sector offsets be wrong. (Meaning that the zonemaps will not be where they are supposed to be, and nothing will work.) The other thing is that you can only concatenate partitions if they are sequential in load order. Partitions that are physically adjacent on disk might not be adjacent in load order, so you can't assume that partitions that are adjacent on disk can be combined. Load order is dictated by the devlist.
So as long as you keep these rules in mind, you can move partitions around, change the order in the devlist, reorder the partition map, etc, as long as the result is that the data will all be loaded in the same order.
One other side note: it appears that if the TiVo starts up and finds that some of the partitions in the devlist don't exist, and your TiVo has an external drive, then it will bring up the "I can't find the external drive. Do you want to divorce it?" screen. Then, when you tell it to go ahead, it loads all the partitions in the devlist, then starts looking at all of the shows in the filesystem. It will delete any shows that it doesn't have all of the data for, but keep all of the ones that it does have all of the data for. So in the earlier thread, the idea is that we take the data from the partitions that used to be on the external drive, concatenate them into an existing partition on the internal drive, and change the partition map so that there is one entry that includes the sectors from all three partitions. That way, when the TiVo boots, it will load all of the data (because all of the sectors are now contained in the remaining partitions), but it will see some partitions are missing, and bring up the divorce screen, and do the divorce process. During the divorce process, it won't find any sectors missing, so it will complete successfully, and keep all of the recordings.
So given this knowledge of a set of behaviors, I wanted to see if I could combine a setup like Doug's, with an expanded internal drive and an external drive. I took a couple of 1 TB drive and copied (just using dd) my real internal and external drives onto them. I then ran mfsadd to expand the internal drive, and offered it to the TiVo, and it was perfectly happy with this pair. It found and used the additional partition pair.
So the partition map for the internal disk is
Code:
Partition map (with 512 byte blocks) on '/dev/sdc'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 1 @ 268618469
3: Image Kernel 1 8192 @ 268618470 ( 4.0M)
4: Ext2 Root 1 524288 @ 268626662 (256.0M)
5: Image Bootstrap 2 1 @ 269150950
6: Image Kernel 2 8192 @ 269150951 ( 4.0M)
7: Ext2 Root 2 524288 @ 269159143 (256.0M)
8: Swap Linux swap 262144 @ 269683431 (128.0M)
9: Ext2 /var 524288 @ 269945575 (256.0M)
10: MFS MFS application region 589824 @ 270469863 (288.0M)
11: MFS MFS media region 216747657 @ 271649511 (103.4G)
12: MFS MFS application region 2 589824 @ 271059687 (288.0M)
13: MFS MFS media region 2 268618405 @ 64 (128.1G)
14: MFS New MFS Application 2048 @ 488397168 ( 1.0M)
15: MFS New MFS Media 865107968 @ 488399216 (412.5G)
16: Apple_Free Extra 600017984 @ 1353507184 (286.1G)
Device block size=512, Number of Blocks=1953525168 (931.5G)
DeviceType=0x0, DeviceId=0x0Code:
Partition map (with 512 byte blocks) on '/dev/sdd'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: MFS MFS application region 4096 @ 64 ( 2.0M)
3: MFS MFS media region 1953521008 @ 4160 (931.5G)
Device block size=512, Number of Blocks=1953525168 (931.5G)
DeviceType=0x0, DeviceId=0x0Code:
---------------------------------------------------------------------
Super Header
state=0 magic=abbafeed
devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hdc2 /dev/hdc3 /dev/hda14 /dev/hda15
zonemap_ptr=1121 total_secs=3305179136
---------------------------------------------------------------------
MFS volume set for /dev/sdc and /dev/sdd
The MFS volume set contains 8 partitions
Partition sectors size
/dev/sdc10 589824 288 MiB
/dev/sdc11 216747008 105833 MiB
/dev/sdc12 589824 288 MiB
/dev/sdc13 268617728 131161 MiB
/dev/hdc2 4096 2 MiB
/dev/hdc3 1953520640 953867 MiB
/dev/sdc14 2048 1 MiB
/dev/sdc15 865107968 422416 MiB
Total MFS sectors: 3305179136
Total MFS volume size: 1613857 MiB
Estimated hours in a standalone TiVo: 2011
---------------------------------------------------------------------Note that since I copied everything with dd, the original partition (with odd partition sizes) was retained. If you copy things with MFS backup/restore, that makes partitions without extra sectors on the end.
Also note that I used a slightly tweaked version of mfsadd that allows me to hold back some sectors when adding the new partition. The 2TB drive I was using to test combining on is just a little smaller than the combined size of the two 1 TB drives I was using. So I made the added partition a little smaller so that everything would fit. That's why there is a free partition at the end of the disk. It might or might not be there on other systems.
So for this arrangement on disk, TiVo maps sectors to partitions as follows:
Code:
hda10: 0 - 589823
hda11: 589824 - 217336831
hda12: 217336832 - 217926655
hda13: 217926656 - 486544383
hdc2: 486544384 - 486548479
hdc3: 486548480 - 2440069119
hda14: 2440069120 - 2440071167
hda15: 2440071168 - 3305179135I started by copying the contents of the internal drive onto a 2TB drive just using dd. Then the problem was how to copy the contents of the external drive (hdc2 and hdc3) and stuff them into an existing partition. The data needs to get loaded right after hda13. But hda13 is at the start of the disk, so there is no room after that. So I decided to put the data at the front of hda14, and change the devlist to move the references to the external partitions to the end. (Those partition reference will be to the no-longer-existing disk that triggers the divorce. I don't know what TiVo would do if the missing partitions are in the middle of the devlist; I probably wouldn't be happy at all, because if the partitions are missing, partitions that are after it in the devlist can't load properly, since the sector numbers would be all wrong.)
I copied all of the data from the external disk and put it at where hda14 starts, then I copied the data from the real hda14 after the external disk's data. I changed the entry in the partition map to make the size of hda14 big enough to encompass all of this data. I also had to re-copy the data from the real hda15, since that partition got moved on disk to accommodate the data from the external drive. I also had to fix the partition map to create the corrected hda15.
To accomplish these moves/copies, I just used dd:
Code:
dd if=/dev/sdd of=/dev/sdh bs=512 seek=488397168 skip=64
dd if=/dev/sdc of=/dev/sdh bs=512 seek=2441921904 skip=488397168 count=2048
dd if=/dev/sdc of=/dev/sdh bs=512 seek=2441923952 skip=488399216 count=865107968(As an aside, the commands I actually used were slightly different, because doing the dd with 512B blocks was really slow. Using 8KB blocks was about 10 times faster. So in the above, I just changed the bs=512 to bs=8k, then divided all of the numbers by 16. I could do that since they were all multiples of 8KB.)
The adjusted partition map looks like
Code:
Partition map (with 512 byte blocks) on '/dev/sdh'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 1 @ 268618469
3: Image Kernel 1 8192 @ 268618470 ( 4.0M)
4: Ext2 Root 1 524288 @ 268626662 (256.0M)
5: Image Bootstrap 2 1 @ 269150950
6: Image Kernel 2 8192 @ 269150951 ( 4.0M)
7: Ext2 Root 2 524288 @ 269159143 (256.0M)
8: Swap Linux swap 262144 @ 269683431 (128.0M)
9: Ext2 /var 524288 @ 269945575 (256.0M)
10: MFS MFS application region 589824 @ 270469863 (288.0M)
11: MFS MFS media region 216747657 @ 271649511 (103.4G)
12: MFS MFS application region 2 589824 @ 271059687 (288.0M)
13: MFS MFS media region 2 268618405 @ 64 (128.1G)
14: MFS New MFS Application 1953526784 @ 488397168 (931.5G)
15: MFS New MFS Media 865107968 @ 2441923952 (412.5G)
16: Apple_Free Extra 599997248 @ 3307031920 (286.1G)
Device block size=512, Number of Blocks=3907029168 (1.8T)
DeviceType=0x0, DeviceId=0x0When I run mfsinfo on it, I get
Code:
---------------------------------------------------------------------
Super Header
state=0 magic=abbafeed
devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hda14 /dev/hda15 /dev/hdc2 /dev/hdc3
zonemap_ptr=1121 total_secs=3305179136
---------------------------------------------------------------------
MFS volume set for /dev/sdh
The MFS volume set contains 8 partitions
Partition sectors size
/dev/sdh10 589824 288 MiB
/dev/sdh11 216747008 105833 MiB
/dev/sdh12 589824 288 MiB
/dev/sdh13 268617728 131161 MiB
/dev/sdh14 1953526784 953870 MiB
/dev/sdh15 865107968 422416 MiB
/dev/hdc2 0 0 MiB
/dev/hdc3 0 0 MiB
Total MFS sectors: 3305179136
Total MFS volume size: 1613857 MiB
Estimated hours in a standalone TiVo: 0
---------------------------------------------------------------------mfsinfo shows /dev/hdc2 and /dev/hdc3 as 0 size because they are missing. If I take the reference to /dev/hdc2 and /dev/hdc3 out of the devlist, mfsinfo is completely happy with the consolidated disk, and reads and validates the zonemaps without a problem. But if I put it into the TiVo like that (with hdc2 and hdc3 not in the devlist), it would complain about an incorrect storage device. But with the references to hdc2 and hdc3 back in the devlist, it figures out that it needs to divorce the disk.
So to test it out, I offered the disk to the TiVo and it did what was expected. It did the divorce (which took 5-10 minutes or so), then rebooted and all of the recordings were still there, and the TiVo reported the correct size.
Looking at the drive post-divorce with mfsinfo shows:
Code:
---------------------------------------------------------------------
Super Header
state=0 magic=abbafeed
devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hda14 /dev/hda15
zonemap_ptr=1121 total_secs=3305179136
---------------------------------------------------------------------
MFS volume set for /dev/sdh
The MFS volume set contains 6 partitions
Partition sectors size
/dev/sdh10 589824 288 MiB
/dev/sdh11 216747008 105833 MiB
/dev/sdh12 589824 288 MiB
/dev/sdh13 268617728 131161 MiB
/dev/sdh14 1953526784 953870 MiB
/dev/sdh15 865107968 422416 MiB
Total MFS sectors: 3305179136
Total MFS volume size: 1613857 MiB
Estimated hours in a standalone TiVo: 2011
---------------------------------------------------------------------So the point of this exercise was to show what you can do if you stay within the rules. I tried to do some of this with MFS backup/restore, but that doesn't seem to deal properly with partitions that have been consolidated (and that required me to modify the source volume). It also doesn't deal well at all with creating a destination volume with more than 16 partitions. (The TiVo can't deal with that disk, but I might have wanted it to just do the copy, and then I would consolidate the partitions post-restore.) MFS restore has the 16 partition limit hard coded in a number of places, so it looked like it was going to be a pain to modify. Its not clear what the backup/restore approach does for you if you're copying all of the video streams. If you're copying all of the data, you can accomplish the same thing with dd. But for normal operations, backup/restore are much easier to use, and a lot more failsafe. And they make nice even partitions.
But you could accomplish all of that (partition aligning, moving, reordering, etc) with dd and pdisk. The only thing magic I used was a quick tool to allow manipulation of the devlist. I did all of the above using Debian 12.04 LTS.
↧
replace/upgrade Premiere HD to 2TB w/o cloning
Hello,
Can someone refer me to a link that explains how to install a larger HD in a base Premiere Tivo? It's an original 2 tuner (50hrs?) that had an Extender attached and the internal HD has failed.
All my google searches seem to include the cloning option which I don't need.
Do I need to obtain an image?
thanks
Can someone refer me to a link that explains how to install a larger HD in a base Premiere Tivo? It's an original 2 tuner (50hrs?) that had an Extender attached and the internal HD has failed.
All my google searches seem to include the cloning option which I don't need.
Do I need to obtain an image?
thanks
↧
↧
Upgrading from 1TB to 2TB TivoHD
Been reading on how to upgrade my TivoHD to a 2TB HD and just want to confirm that I can use WinMFS for the entire process or will I have to use JMFS then WinMFS to Supersize. My Tivo is at current software revision. I found these instructions for WinMFS:
Quote:
|
Use WinMFS to mfscopy your current drive, shows, settings, and all, to the 20EURS. When it finishes, it'll say something about extra space (unless your current drive is also a 2TB), and do you want to expand. Tell it no. I don't know why you need to do it that way, but that's the way that seems to work. After you tell it no, select the new drive, the 20EURS, and click on mfsinfo just to make sure everything looks alright. The partition map will probably show a large Apple Free partition at the end. That's okay. Close mfsinfo, and then click on mfsadd. You should get the "do you want to use a partition bigger than 1.2TB" warning--tell it yes you do want to. |
↧
DIY 4TB Premiere
Well after a lot of trial and error, I finally managed to come up with a way to expand a premiere drive up to 4TB. This was the result.
![]()
I was able to keep all my recorded shows. It took me about 2 days to accomplish this. I will do my best to outline the procedure as soon as I get it written up. It is not for the faint of heart and does require some technical know how. While doing this procedure, I moved the OS to approximately the center of the 4TB drive and 4k aligned the image. It probably was not necessary but I figured if I am maxing out my premiere I want to try to reduce seek times as much as possible. It also requires you to coalesce some partitions and have an extra 2TB drive. Once I feel the write up has the detail needed, I will post it here.
I was able to keep all my recorded shows. It took me about 2 days to accomplish this. I will do my best to outline the procedure as soon as I get it written up. It is not for the faint of heart and does require some technical know how. While doing this procedure, I moved the OS to approximately the center of the 4TB drive and 4k aligned the image. It probably was not necessary but I figured if I am maxing out my premiere I want to try to reduce seek times as much as possible. It also requires you to coalesce some partitions and have an extra 2TB drive. Once I feel the write up has the detail needed, I will post it here.
↧
Arg! VHD Restore Problems
For the life of me, I can't seem to get this recovered to the physical disk. DVRBars bombs and I don't really see another way to restore a VHD to physical disk. I've tried acronis, clonezilla, and VBoxManage. Are there any other methods off accomplishing this task or should I just do the cake thing and pay the $40 and forget about it?
Thanks!
Michael
Thanks!
Michael
↧
Tivo S2 Upgrade from bad hard-drive?
I have a S2 Tivo which started getting stuck on the welcome/powering up screen. It would sit there for a few mins, then the light on the front momentarily goes off and reboots itself again. It's the original drive which I assumed was going bad so I bought a new 500GB drive and just attempted the mfsbackup from the original drive to the new one.
Well, it flagged a bunch of read errors from the original drive during the backup process but it successfully (or so I thought?) completed the restore to the new 500GB drive. However, when I reinstalled the new drive, and powered up the Tivo, it did the same exact thing as before.
Is it possible the original drive had a corrupt OS from the hard drive failing that would cause this? Would the mfsbackup software have anyway of checking this? This hard drive is brand new so I doubt the problem is the HD.
Thanks!
Well, it flagged a bunch of read errors from the original drive during the backup process but it successfully (or so I thought?) completed the restore to the new 500GB drive. However, when I reinstalled the new drive, and powered up the Tivo, it did the same exact thing as before.
Is it possible the original drive had a corrupt OS from the hard drive failing that would cause this? Would the mfsbackup software have anyway of checking this? This hard drive is brand new so I doubt the problem is the HD.
Thanks!
↧
↧
Intelipark
Why does it need to be disabled with the tivo recording 24/7 I would think it would never park anyway.
↧
tivo series 4 drive pairing?
i was wondering a couple things.
1. where on the hard drive is the software stored?
is it near the 0 sector so if i was to downsize the hard drive i would not damage the software?
and how many gig does the software use?
because i am trying a new approach to a problem i have been having is i decided to clone the original 320 gig drive onto a ssd solid state drive i have but the ssd is only 240 gig so i know some data is going to be lost and that's ok as long as it is not the software.
i decided ssd because even though trim management is not going to work since the box does not know how to use trim the drive should be faster than the oem drive.
my problem is corruption of the show when ever there is any overlap and show 1 stops and the next show starts
and unexpectedly aborting the downloads via tivo to go.
so hopefully a ssd will solve that problem.
2. are the tivo hard drives paired to the serial of the box so if i buy a box on ebay that has no hard drive or a bad power supply is the drive then not going to work?
i wonder because i would like to get a broken tivo fix it to use to salvage the shows while i let the ssd continue with the recording without missing anything.
or can i connect the drive externally and salvage the shows
1. where on the hard drive is the software stored?
is it near the 0 sector so if i was to downsize the hard drive i would not damage the software?
and how many gig does the software use?
because i am trying a new approach to a problem i have been having is i decided to clone the original 320 gig drive onto a ssd solid state drive i have but the ssd is only 240 gig so i know some data is going to be lost and that's ok as long as it is not the software.
i decided ssd because even though trim management is not going to work since the box does not know how to use trim the drive should be faster than the oem drive.
my problem is corruption of the show when ever there is any overlap and show 1 stops and the next show starts
and unexpectedly aborting the downloads via tivo to go.
so hopefully a ssd will solve that problem.
2. are the tivo hard drives paired to the serial of the box so if i buy a box on ebay that has no hard drive or a bad power supply is the drive then not going to work?
i wonder because i would like to get a broken tivo fix it to use to salvage the shows while i let the ssd continue with the recording without missing anything.
or can i connect the drive externally and salvage the shows
↧
jmfs live cd options
i noticed there was an option to remove space for advertizements or something like that (i did not check the wording closely since i dont know what it does)
i was wondering does the tivo boxes store the commercials as separate files from the content? if so then would that option allow commercial free content?
i was wondering does the tivo boxes store the commercials as separate files from the content? if so then would that option allow commercial free content?
↧