# MFS Tools 3.2 Development



## jkozee (Jan 13, 2006)

This thread is intended to spur further development of mfstools. Feel free to ask questions and offer patches.


----------



## telemark (Nov 12, 2013)

What's the biggest bug that needs to be fixed on Premiere?
What's the biggest bug that needs to be fixed on Roamio?


----------



## jmbach (Jan 1, 2009)

Currently I am trying to take a Premiere image that has been expanded via the coalesce and expand method and trying to copy it over to another 4TB drive to put it back in a native TiVo format. It currently fails. What I see is that it seems to copy partitions 10 and 12 intact over to the new drive before modifying them for the larger media structure. Since partition 12 is a coalesce of partition 12 and 13 of the original image, it copies that whole coalesced partition over. It needs a way to detect coalesced partitions and separate out the media and app portions when reconstructing the image. 
This maybe only more important when one of the original app partitions are coalesced with a media partition. If we assume only one of the original app partitions are coalesced, then a quick test would be to compare the sizes of partitions 10 and 12 and use the smaller of the two sizes to copy from the beginning of the source partitions 10 and 12 with that size to the target drive. Then hopefully the program can create the new media partitions accordingly and copy the streams over.


----------



## telemark (Nov 12, 2013)

Aren't all Premiere MFS app partitions the same size?

Wasn't it possible to put 10+11+12 -> 10 before? Though I agree that might be an odd one.


----------



## jmbach (Jan 1, 2009)

Yes they all are the same size and yes you can technically, as long as you follow the rules, coalesce any combination of MFS partitions. 

I doubt that TiVo will change the app partition size on the Premiere with any update as that would require a major adjustment of the partition layout of drive. 

The best solution would be to create new MFS app partitions denovo and then transfer information from the old to the new. However, that may take some major rewriting. 

An alternative would be to tease out the MFS app partitions out of the coalesced partitions, use them, and proceed with the normal routine from there. Hopefully just a small patch and not a major rewrite.


----------



## ggieseke (May 30, 2008)

One caveat to watch for when coalescing app partitions is that TiVo expects to find the primary "superheader" in the first sector of the first app partition, and the backup copy in the last sector of that partition. It might run anyway if it can't find the backup, but it won't be happy about it.


----------



## telemark (Nov 12, 2013)

I don't think it's too hard to find the original 10 & 12, but doing so forces the 11 to be the original size 11 too?

What is the target layout you're going to want?


----------



## jmbach (Jan 1, 2009)

The program will take a single expanded Premiere image and create a two app and two media MFS layout. The issue is when it is a coalesced multi expanded Premiere image. I would like to be able to take a multi expanded image and create a 2 app and 2 media partition standard TiVo image.


----------



## jkozee (Jan 13, 2006)

I think mfstools should be able to read the coalesced drive and zones ok. The problem would be that assumes that 10 and 12 are both app partitions and it will count both of them as required space to restore the drive, in addition to the media space also in partition 12. It shouldn't be too hard to force partition 12 to match the size of partition 10 in the case of a coalesced 12/13->12. Creating coalesced partitions and handling a single App partition would require more work though.


----------



## jkozee (Jan 13, 2006)

telemark,

There's really only two issues that come to mind. The first is 64-bit APM creation. TiVo's pdsik64 code allowed for creating both 32-bit and 64-bit APM entries (as does mfstools). Mixing 32-bit and 64-bit doesn't appear to cause an issue, but it's probably better to sort it out now. Another question is when should 64-bit APM's be applied to Premiere restores. So, really it comes down to use cases: when should we use 64-bit APM's (platform, drive size, os version).

The seconds issues is that the small linux distro I was using was not handling large drives correctly (I think the kernel was ok, but not busybox).


----------



## jkozee (Jan 13, 2006)

There are also some wish list items, such as adding additional metadata to the v3 backups (OS version, original drive/swap/var/db size, etc.)


----------



## telemark (Nov 12, 2013)

Remaking a TiVo oriented Linux boot-CD is on my todo list, so I should be able handle that last one.


----------



## jkozee (Jan 13, 2006)

This link seems like a good place to start. I used the pre-built iso, but perhaps the build scripts would allow for better large drive support.


----------



## jmbach (Jan 1, 2009)

jkozee said:


> telemark,
> 
> There's really only two issues that come to mind. The first is 64-bit APM creation. TiVo's pdsik64 code allowed for creating both 32-bit and 64-bit APM entries (as does mfstools). Mixing 32-bit and 64-bit doesn't appear to cause an issue, but it's probably better to sort it out now. Another question is when should 64-bit APM's be applied to Premiere restores. So, really it comes down to use cases: when should we use 64-bit APM's (platform, drive size, os version).
> 
> The seconds issues is that the small linux distro I was using was not handling large drives correctly (I think the kernel was ok, but not busybox).


Some testing done on Premieres with OS 20.3.8 indicated that the TiVo did not like mixing 32/64 bit APM entries and that all partitions needed to be 32bit in size and start within a 32bit address space. The APM entries needed to be either all 32 bit entries or all 64bit entries except for partition 1 which needed to be 32bit.

With OS 20.4.6, partitions could now start outside the 32bit address space but the other limitations still existed.

At this point, the only time 64bit partitions need to be used is when restoring requires placement of a partition beyond the 32bit address space. When it does that, all APM entries except the first one need to be converted to a 64bit APM entry. Might need to consider OS testing the backup before restoring because a boot loop issue would occur if OS version 20.3.8 were to be restored using 20.4.6 criteria. (Having a partition that starts outside the 32 bit address space)


----------



## jmbach (Jan 1, 2009)

jkozee said:


> I think mfstools should be able to read the coalesced drive and zones ok. The problem would be that assumes that 10 and 12 are both app partitions and it will count both of them as required space to restore the drive, in addition to the media space also in partition 12. It shouldn't be too hard to force partition 12 to match the size of partition 10 in the case of a coalesced 12/13->12. Creating coalesced partitions and handling a single App partition would require more work though.


That's good. Since the standard TiVo layout is always 2 app and 2 media partitions, the quick and dirty method would be to assume partition 10 is not coalesced and use that size to create partition 12 on the target drive and copy that portion over to the target drive.

A more elegant way would be to obtain the original partition 10 and 12 size from the MFS and the original partition 12 location from the MFS (Since partition 10 is always the first partition of the MFS we just need its size if it happens to be coalesced as well) and the use those to create the target drive.


----------



## jkozee (Jan 13, 2006)

It's probably safe to assume that anything 4TB and below can be formatted with all 32-bit 

The 64-bit APM issue really only matters on drives larger than 4TB. For 4TB and below, mfstools will size the media partitions to keep them below the 32-bit barrier for start and size. And it's safe to assume that mixing 32-bit with 64-bit was never required (except the first partition which is always 32-bit). So, I'll update the code to use 64-bit for all entries (except the first) if the drive is greater than 4TB.

Currently, mfstools does not work correctly with drives larger than 4TB. I have some local patches that will allow it to create MFS partitions larger than 2TiB, but the TiVo OS does not support them. There are workarounds to creating larger drives, but nothing is implemented in mfstools yet. I'm hoping that a future TiVo SW release will correct the issue and allow us to create a standard two pair (app/media) partition.

It might be possible to use a partition larger than 2TiB by splitting it multiple zones, however I was not successful in my initial attempt.


----------



## jmbach (Jan 1, 2009)

How about adding a switch that can be set to force 64bit APM entries independent of drive size. 

Also, if TiVo does fix adding a pair of partitions to a premiere, then MFSAdd will need to be modified to convert the APM when adding a pair of partitions on large drives. As an aside, they would probably fix the 32bit limit on the media partitions first as that would obviate the need for adding a pair of partitions. When that will happen, who knows. All we can do is work with the cards we are dealt with at this time.


----------



## jkozee (Jan 13, 2006)

We could add a switch, but that seems premature to me. Ideally, we should handle this based on use cases, from observed behavior. Seems more appropriate to sort this out in development thread...

Also, I'm not sure I follow the rest of your post. I don't see anything wrong with the native Premiere drive that needs to be fixed. Adding an additional app/media pair to an existing (SINGLE) drive seems unlikely to occur. Adding a second drive may need some work, as MFSadd has only been tested by adding an additional drive.


----------



## jmbach (Jan 1, 2009)

What I was getting at is that there is no guarantee that TiVo will fix anything on how 64bit APMs are currently handled on the Premiere. So if we are going to attempt to increase the recording size to 6TB on a SINGLE drive, if it going to work, then we have to either add a coalesced partition to a standard 4TB Premiere image (2 app and 2 media partitions) as we cannot just add a standard app/media pair or create an image similar to what mfsr does for the Roamio that is 1 app and 3 media partitions.


----------



## jmbach (Jan 1, 2009)

jkozee said:


> We could add a switch, but that seems premature to me. Ideally, we should handle this based on use cases, from observed behavior. Seems more appropriate to sort this out in development thread...


Isn't this the development thread?



jkozee said:


> Also, I'm not sure I follow the rest of your post. I don't see anything wrong with the native Premiere drive that needs to be fixed. Adding an additional app/media pair to an existing (SINGLE) drive seems unlikely to occur. Adding a second drive may need some work, as MFSadd has only been tested by adding an additional drive.


What I was getting at is that there is no guarantee that TiVo will fix anything on how 64bit APMs are currently handled on the Premiere. So if we are going to attempt to increase the recording size to 6TB on a SINGLE drive, if it going to work, then we have to either add a coalesced partition to a standard 4TB Premiere image (2 app and 2 media partitions) as we cannot just add a standard app/media pair or create an image similar to what mfsr does for the Roamio that is 1 app and 3 media partitions.

If we are able to create a 6TB image by adding space to a 4TB drive via MFSAdd, MFSAdd will have to add that extra space as a 64bit APM entry to the APM and convert all the current APM entries (except the 1st partition entry) to 64bit APM entries.


----------



## jkozee (Jan 13, 2006)

jmbach said:


> Isn't this the development thread?


Snarkyness aside, I thought that was obvious, but perhaps my response was not...

All I meant is that as a developer, it is probably a waste of your time to add a feature to mfstools that is just a way to test use cases for 64-bit APM entries. Adding a flag means a bunch more code changes, usage changes, and would be required in restore, copy, mfsadd, macpart, etc. to yield the results you are after. A simpler way for you to test is to change a single line of code in macpart.c to force everything to 64-bit for any testing you would like to do. I see no reason why we would need to force a drive to 64-bit that does not require it outside of development testing. Do you see a need to have a flag in the general release?

At this point, I cannot see any reason we would need to force a drive to 64-bit APM. As long as all partition start and lengths are less than 32-bits, then a standard APM shuold suffice. If any exceed 32-bits, then all entries should be 64-bit or else the partition could not be accessed correctly. If any testing proves otherwise, we should build that logic into mfstools.

And by sorting out in *this* thread, I just meant lets discuss if further to see if there really is a need for a new feature before doing in work that may prove counterproductive.



jmbach said:


> If we are able to create a 6TB image by adding space to a 4TB drive via MFSAdd, MFSAdd will have to add that extra space as a 64bit APM entry to the APM and convert all the current APM entries (except the 1st partition entry) to 64bit APM entries.


Not sure I see the issue here. If mfstools is changed to create 64-bit partitions when the drive is over 4TB (regardless of -c -m -M flags), then there would be no reason to convert any entries, as they would already be 64-bit entries when the restore/copy was done to the 6TB drive. Sound right?


----------



## jkozee (Jan 13, 2006)

To force all entries (except the first) to 64-bit change this code in macpart.c:

```
if (table->partitions[loop].start <= UINT_MAX &&
					table->partitions[loop].sectors <= UINT_MAX )
```
To this:

```
if (table->partitions[loop].start <= UINT_MAX &&
					table->partitions[loop].sectors <= UINT_MAX && loop == 0)
```


----------



## jmbach (Jan 1, 2009)

jkozee said:


> Snarkyness aside, I thought that was obvious, but perhaps my response was not...


I took your response as there existed another thread in which to discuss this.



jkozee said:


> All I meant is that as a developer, it is probably a waste of your time to add a feature to mfstools that is just a way to test use cases for 64-bit APM entries. Adding a flag means a bunch more code changes, usage changes, and would be required in restore, copy, mfsadd, macpart, etc. to yield the results you are after. A simpler way for you to test is to change a single line of code in macpart.c to force everything to 64-bit for any testing you would like to do. I see no reason why we would need to force a drive to 64-bit that does not require it outside of development testing. Do you see a need to have a flag in the general release?
> 
> At this point, I cannot see any reason we would need to force a drive to 64-bit APM. As long as all partition start and lengths are less than 32-bits, then a standard APM should suffice. If any exceed 32-bits, then all entries should be 64-bit or else the partition could not be accessed correctly. If any testing proves otherwise, we should build that logic into mfstools.
> 
> And by sorting out in *this* thread, I just meant lets discuss if further to see if there really is a need for a new feature before doing in work that may prove counterproductive.


Agreed



jkozee said:


> Not sure I see the issue here. If mfstools is changed to create 64-bit partitions when the drive is over 4TB (regardless of -c -m -M flags), then there would be no reason to convert any entries, as they would already be 64-bit entries when the restore/copy was done to the 6TB drive. Sound right?


It does sound correct if TiVo corrects the 2TB partition limit. If not then my thought process was that if we create a 6TB drive by copying over a 4TB image to a 6TB drive, followed by adding a pair of partitions, then the current 32bit APM will need to be converted to 64bit when MFSAdd is used to add the pair of partitions. However with current limitations, that pair of partitions would have to coalesced into a single partition.


----------



## jkozee (Jan 13, 2006)

jmbach said:


> It does sound correct if TiVo corrects the 2TB partition limit. If not then my thought process was that if we create a 6TB drive by copying over a 4TB image to a 6TB drive, followed by adding a pair of partitions, then the current 32bit APM will need to be converted to 64bit when MFSAdd is used to add the pair of partitions. However with current limitations, that pair of partitions would have to coalesced into a single partition.


Agreed about the need for coalescing for a 6TB drive if greater than 2TiB partitions are not supported, but I still don't see the converting issue.

Once the patch is made, when you copy over the 4TB image to a 6TB drive, the 6TB drive will have 64-bit entries. Remember, mfstools can create the 6TB drive with a standard two pair setup and limit the resulting image size to 4TB. Perhaps you were thinking you would need to dd the 4TB to the 6TB drive instead of using mfstools?


----------



## jmbach (Jan 1, 2009)

I guess if copying the image to a drive larger than 4TB, the program will automatically create a 64bit APM even if the image is not expanded at the same time, then nothing else needs to be adjusted. 

But yes, I was thinking of a dd or a drive duplicator option for the initial copy as I thought it would be faster.


----------



## tivoROCKSme (Jun 24, 2003)

just want to say that it's awesome that you guys are working on this new technology. Good job collaborating and thanks for working on the next gen


----------



## jkozee (Jan 13, 2006)

dd would probably be the slowest option, as it is a block level copy of the entire drive, but would produce an exact replica of the original. Using mfstools has the advantage of being able to skip unused space (especially if you omit the -a and skip recordings). Using v1 format is faster that v3, but only light testing has been done on v1 beyond series 3 units and v1 does not offer the ability to resize MFS media partitions.


----------



## jmbach (Jan 1, 2009)

You can speed up dd by adjusting the block size when copying. Not sure how fast it would be as compared to MFSTools.


----------



## jmbach (Jan 1, 2009)

Testing a modified version of MFSTools to work with a DIY 4TB Premiere image. Looks like about 50 hours to copy the drive. Will see if it works when it is done.


----------



## jkozee (Jan 13, 2006)

Great. Post the results.

The issue with the DIY 4TB drive is that is has a coalesced 12/13 pair. This was unexpected by mfstools. It can read the drive just fine, but when it lays out a new drive it blindly bases the two app partitions on the partition size of the original ones, so it assumes that 10 and 12 are app partitions.

A quick hack was done to workaround this, but we will need to refine it before we put it into the release. There will be similar, but more complex issues if we add support for mfsr created drives. Those drives only contain one app partition, so mfstools would double the app size with the way this workaround was implemented. Additionally, I suspect mfstools will have issues, as it will expect a second app zone, which will be missing.


----------



## jmbach (Jan 1, 2009)

Looks like the copy was a success and functional. It did take nearly 50 hours to copy the drive.

Here is the initial drive layout.

```
---------------------------------------------------------------------
MFS Volume Header (64-bit)
---------------------------------------------------------------------
	state=0 magic=ebbafeed
	devlist=/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13 /dev/sda15
	zonemap_ptr=1121 total_secs=7805352960 next_fsid=4323048

---------------------------------------------------------------------
MFS volume set for /dev/sdd
---------------------------------------------------------------------
The MFS volume set contains 5 partitions
   Partition       Sectors         Size
  /dev/sdd10       1638400          800 MiB
  /dev/sdd11     867125248       423401 MiB
  /dev/sdd12    1076076544       525428 MiB
  /dev/sdd13    1953503232       953859 MiB
  /dev/sdd15    3907009536      1907719 MiB
Total MFS sectors: 7805352960
Total MFS volume size: 3811207 MiB
Total Inodes: 524288

---------------------------------------------------------------------
Zone Maps 
---------------------------------------------------------------------
Zone 0: type=0 logstamp=2207746 checksum=712807302 first=1122 last=525409
	sector=1121 sbackup=1638398 length=1
	size=524288 min=524288 free=524288 zero=0 num=1
	next_sector=525410 next_sbackup=1638364 next_length=34
	next_size=867123200 next_min=20480
Zone 1: type=2 logstamp=2270118 checksum=3801070678 first=1638400 last=868761599
	sector=525410 sbackup=1638364 length=34
	size=867123200 min=20480 free=0 zero=0 num=17
	next_sector=525444 next_sbackup=1638234 next_length=130
	next_size=1112656 next_min=8
Zone 2: type=1 logstamp=2270131 checksum=3208056678 first=525574 last=1638229
	sector=525444 sbackup=1638234 length=130
	size=1112656 min=8 free=174536 zero=0 num=19
	next_sector=868763648 next_sbackup=870402047 next_length=1
	next_size=524288 next_min=524288
Zone 3: type=0 logstamp=2207746 checksum=1650379863 first=868763649 last=869287936
	sector=868763648 sbackup=870402047 length=1
	size=524288 min=524288 free=524288 zero=0 num=1
	next_sector=869287937 next_sbackup=870402013 next_length=34
	next_size=1074421760 next_min=20480
Zone 4: type=2 logstamp=2270079 checksum=2519961598 first=870402048 last=1944823807
	sector=869287937 sbackup=870402013 length=34
	size=1074421760 min=20480 free=0 zero=0 num=17
	next_sector=869287971 next_sbackup=870401883 next_length=130
	next_size=1113776 next_min=8
Zone 5: type=1 logstamp=2269940 checksum=1585851125 first=869288101 last=870401876
	sector=869287971 sbackup=870401883 length=130
	size=1113776 min=8 free=603520 zero=0 num=19
	next_sector=1944840192 next_sbackup=1944840258 next_length=66
	next_size=1953484800 next_min=20480
Zone 6: type=2 logstamp=2270131 checksum=1010620962 first=1944841216 last=3898326015
	sector=1944840192 sbackup=1944840258 length=66
	size=1953484800 min=20480 free=0 zero=0 num=18
	next_sector=3898343424 next_sbackup=3898343554 next_length=130
	next_size=3906990080 next_min=20480
Zone 7: type=2 logstamp=2270131 checksum=1928913909 first=3898344448 last=7805334527
	sector=3898343424 sbackup=3898343554 length=130
	size=3906990080 min=20480 free=331182080 zero=0 num=19
	next_sector=0 next_sbackup=0 next_length=0
	next_size=0 next_min=0

Estimated hours in a standalone TiVo: 4771
This MFS volume may be expanded 3 more times
```
Now the new drive after MFSTools copied it.


```
---------------------------------------------------------------------
MFS Volume Header (64-bit)
---------------------------------------------------------------------
	state=0 magic=ebbafeed
	devlist=/dev/sda10 /dev/sda11 /dev/sda12 /dev/sda13
	zonemap_ptr=1121 total_secs=7803516928 next_fsid=4323092

---------------------------------------------------------------------
MFS volume set for /dev/sdc
---------------------------------------------------------------------
The MFS volume set contains 4 partitions
   Partition       Sectors         Size
  /dev/sdc10       1638400          800 MiB
  /dev/sdc11    3900120064      1904355 MiB
  /dev/sdc12       1638400          800 MiB
  /dev/sdc13    3900120064      1904355 MiB
Total MFS sectors: 7803516928
Total MFS volume size: 3810311 MiB
Total Inodes: 524288

---------------------------------------------------------------------
Zone Maps 
---------------------------------------------------------------------
Zone 0: type=0 logstamp=55264 checksum=3444281576 first=1122 last=525409
	sector=1121 sbackup=1638398 length=1
	size=524288 min=524288 free=524288 zero=0 num=1
	next_sector=525410 next_sbackup=1638268 next_length=130
	next_size=3900108800 next_min=20480
Zone 1: type=2 logstamp=55402 checksum=3770613123 first=1638400 last=3901747199
	sector=525410 sbackup=1638268 length=130
	size=3900108800 min=20480 free=172359680 zero=0 num=19
	next_sector=525540 next_sbackup=1638138 next_length=130
	next_size=1112464 next_min=8
Zone 2: type=1 logstamp=55402 checksum=4087498348 first=525670 last=1638133
	sector=525540 sbackup=1638138 length=130
	size=1112464 min=8 free=408312 zero=0 num=19
	next_sector=3901758464 next_sbackup=3903396863 next_length=1
	next_size=524288 next_min=524288
Zone 3: type=0 logstamp=55264 checksum=2736348916 first=3901758465 last=3902282752
	sector=3901758464 sbackup=3903396863 length=1
	size=524288 min=524288 free=524288 zero=0 num=1
	next_sector=3902282753 next_sbackup=3903396733 next_length=130
	next_size=3900108800 next_min=20480
Zone 4: type=2 logstamp=55402 checksum=3155997472 first=3903396864 last=7803505663
	sector=3902282753 sbackup=3903396733 length=130
	size=3900108800 min=20480 free=171786240 zero=0 num=19
	next_sector=3902282883 next_sbackup=3903396603 next_length=130
	next_size=1113584 next_min=8
Zone 5: type=1 logstamp=55402 checksum=1432644692 first=3902283013 last=3903396596
	sector=3902282883 sbackup=3903396603 length=130
	size=1113584 min=8 free=369912 zero=0 num=19
	next_sector=0 next_sbackup=0 next_length=0
	next_size=0 next_min=0

Estimated hours in a standalone TiVo: 4769
This MFS volume may be expanded 4 more times
```
The command used was mfstool copy -ai /dev/sdd /dev/sdc


----------



## jmbach (Jan 1, 2009)

The final image has a lightly lower MFS sector size by 1836032 sectors. Most of it is because the swap size was increased automatically by the program by 1835008 sectors. The 1024 sectors remaining probably from optimizing the media partitions. I think better behavior would be for the program to copy the swap as is (especially if the flag to copy/backup all non-MFS partitions is used) and only use a flag to trip the "optimized" swap size change.


----------



## jmbach (Jan 1, 2009)

In any event, looks like the modification to the restore.c that forces partition 12 (MFS Application region 2) to use the size of partition 10 (MFS Application region 1) worked. Makes sense since partition 10 and 12 are always the same size on all TiVo layouts that use two app and two media partitions. This only works if partition 10 never gets coalesced with anything else.


----------



## jmbach (Jan 1, 2009)

Also an interesting finding is that after the initial boot up the drive was 37% full. Ran a KS 57. Ran a KS 58 but it seems locked up. Let it run for 10 hours and finally pulled the plug and the ran another KS 57. All this to say, the resultant disk is now stated 26% full which is what it was prior to copying the drive. All recordings appear intact.

Not sure if KS 58 does what we think it does anymore. It displayed the "Update" screen the whole time.


----------



## jmbach (Jan 1, 2009)

Tried to copy the DIY 4TB image with the same code to my 6TB drive with the -M 4000 switch but did not use the -ai switches and the resultant image ended prematurely. Used various combinations of t T and D switches all ending with the same error. Only difference is that with the D switch, it copied 210% and not 130% of the image. Haven't tried any of those images in the TiVo.


----------



## jmbach (Jan 1, 2009)

So I believe I have fixed MFSTools 3.2 to work on copying Bolts up to 4TB drive without breaking any previous functionality. I need a few brave souls who would like to test this version. Whoever tries this at this time runs the risk of losing all recordings so whoever wants to test this, must be okay with that. I say that because for when people used MFSTools to copy their Bolt drive previously and ran it in their Bolt, the Bolt promptly reformatted it. It was the right thing for the Bolt to do because MFSTools did not create the correct partition table. However, when people put their original drive back in, the Bolt I think deleted the recordings as I do not remember anybody having to redo guided setup or lost CableCARD pairings. So try at your own risk. PM me if your are interested and willing.


----------

