TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Underground Playground > TiVo Upgrade Center
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 05-26-2014, 01:44 PM   #31
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
Quote:
Originally Posted by telemark View Post
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.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is online now   Reply With Quote
Old 05-26-2014, 03:13 PM   #32
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
Quote:
Originally Posted by ggieseke View Post
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.

Quote:
Originally Posted by jmbach View Post
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.
telemark is offline   Reply With Quote
Old 05-27-2014, 07:08 AM   #33
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,044
Quote:
Originally Posted by telemark View Post
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.
ggieseke is offline   Reply With Quote
Old 05-27-2014, 08:21 AM   #34
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
Quote:
Originally Posted by ggieseke View Post
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.

Last edited by telemark : 05-27-2014 at 08:31 AM.
telemark is offline   Reply With Quote
Old 05-27-2014, 05:41 PM   #35
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,044
Quote:
Originally Posted by telemark View Post
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.
ggieseke is offline   Reply With Quote
Old 05-28-2014, 07:04 AM   #36
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
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?
__________________
Premiere 2 tuner & SiliconDust
on Comcast-CableCard + OTA
telemark is offline   Reply With Quote
Old 05-28-2014, 08:54 AM   #37
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
JMFS patched to work on Roamio series would be useful for people with sub 2TB images to expand larger and still keep their shows.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is online now   Reply With Quote
Old 05-28-2014, 05:27 PM   #38
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,044
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.
ggieseke is offline   Reply With Quote
Old 06-04-2014, 06:59 AM   #39
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
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?
telemark is offline   Reply With Quote
Old 06-04-2014, 08:18 AM   #40
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
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.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton

Last edited by jmbach : 06-04-2014 at 09:13 AM.
jmbach is online now   Reply With Quote
Old 06-04-2014, 09:21 AM   #41
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,044
Quote:
Originally Posted by telemark View Post
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 is offline   Reply With Quote
Old 06-04-2014, 09:32 AM   #42
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,044
Quote:
Originally Posted by jmbach View Post
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.
ggieseke is offline   Reply With Quote
Old 06-04-2014, 10:01 AM   #43
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
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?
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is online now   Reply With Quote
Old 06-04-2014, 11:32 AM   #44
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,044
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.
ggieseke is offline   Reply With Quote
Old 06-04-2014, 03:56 PM   #45
nooneuknow
TiVo User Since 2007
 
Join Date: Feb 2011
Location: Cox Cable Market, NV
Posts: 3,052
Quote:
Originally Posted by jmbach View Post
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?
__________________
Cisco tuning adapters should never be used inline (using the TA coax OUT port) to connect a TiVo, if MoCA is in use. Use a splitter w/PoE filter on leg to TA, use other leg for the TiVo. Enjoy!

Last edited by nooneuknow : 06-04-2014 at 11:31 PM. Reason: Removed off-topic content
nooneuknow is offline   Reply With Quote
Old 06-04-2014, 05:13 PM   #46
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
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.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is online now   Reply With Quote
Old 06-04-2014, 05:17 PM   #47
mrsean
Registered User
 
Join Date: May 2006
Location: New Jersey
Posts: 165
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.
__________________
TiVo Roamio Pro/Lifetime/Verizon FIOS
TiVo Roamio Basic/Lifetime/Comcast
TiVo Mini/Lifetime/Comcast

Retired: DirecTiVo, Series 2 DT, TiVo HD, Premiere, Premiere 4, TiVo Stream
mrsean is offline   Reply With Quote
Old 06-04-2014, 05:27 PM   #48
nooneuknow
TiVo User Since 2007
 
Join Date: Feb 2011
Location: Cox Cable Market, NV
Posts: 3,052
Quote:
Originally Posted by jmbach View Post
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).
__________________
Cisco tuning adapters should never be used inline (using the TA coax OUT port) to connect a TiVo, if MoCA is in use. Use a splitter w/PoE filter on leg to TA, use other leg for the TiVo. Enjoy!
nooneuknow is offline   Reply With Quote
Old 06-04-2014, 05:31 PM   #49
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
Quote:
Originally Posted by nooneuknow View Post
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.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is online now   Reply With Quote
Old 06-04-2014, 05:40 PM   #50
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
Quote:
Originally Posted by ggieseke View Post
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.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton

Last edited by jmbach : 06-04-2014 at 07:16 PM.
jmbach is online now   Reply With Quote
Old 06-07-2014, 06:17 PM   #51
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
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?

Quote:
Originally Posted by mrsean View Post
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.

Last edited by telemark : 06-09-2014 at 11:27 AM.
telemark is offline   Reply With Quote
Old 06-08-2014, 08:17 AM   #52
ggieseke
Registered User
 
Join Date: May 2008
Posts: 3,044
Quote:
Originally Posted by telemark View Post
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.
ggieseke is offline   Reply With Quote
Old 06-09-2014, 09:11 AM   #53
cykotix
Registered User
 
Join Date: May 2014
Posts: 18
Quote:
Originally Posted by jmbach View Post
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...sk/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?
cykotix is offline   Reply With Quote
Old 06-09-2014, 09:43 AM   #54
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
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.
__________________
Premiere 2 tuner & SiliconDust
on Comcast-CableCard + OTA

Last edited by telemark : 06-09-2014 at 11:28 AM.
telemark is offline   Reply With Quote
Old 06-09-2014, 10:46 AM   #55
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
You could use the signature in block 0 to toggle between byte order.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is online now   Reply With Quote
Old 06-09-2014, 11:07 AM   #56
cykotix
Registered User
 
Join Date: May 2014
Posts: 18
Quote:
Originally Posted by jmbach View Post
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.
cykotix is offline   Reply With Quote
Old 06-09-2014, 11:47 AM   #57
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
jmfs

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.googleco...putStream.html
http://niftilib.sourceforge.net/java...putStream.html
http://mindprod.com/jgloss/endian.html
http://my.safaribooksonline.com/book...ams/ch07-22270 / http://jcs.mobile-utopia.com/jcs/101...putStream.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.
__________________
Premiere 2 tuner & SiliconDust
on Comcast-CableCard + OTA

Last edited by telemark : 06-09-2014 at 06:09 PM.
telemark is offline   Reply With Quote
Old 06-09-2014, 12:14 PM   #58
telemark
Registered User
 
Join Date: Nov 2013
Posts: 803
guid theories

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.
__________________
Premiere 2 tuner & SiliconDust
on Comcast-CableCard + OTA

Last edited by telemark : 06-09-2014 at 01:35 PM.
telemark is offline   Reply With Quote
Old 06-09-2014, 03:08 PM   #59
jmbach
Registered User
 
jmbach's Avatar
 
Join Date: Jan 2009
Posts: 833
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 :-P ) to get JMFS modified.
__________________
"Delay is preferable to error" - Thomas Jefferson
"If I have seen further it is by standing on the shoulders of Giants" - Sir Isaac Newton
jmbach is online now   Reply With Quote
Old 06-10-2014, 05:14 PM   #60
whereisthelimit
Registered User
 
Join Date: Jun 2014
Posts: 1
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
whereisthelimit is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVoŽ is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 01:21 AM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |