PDA

View Full Version : Toshiba sd-h400 and recording space allocation



Jamie
10-06-2004, 03:20 PM
I'm begining to look into why the Toshiba sd-h400 (TiVo software 5.1.1b-01-2-264) prevents expansion beyond 80 hours. This thread (http://alt.org/forum/index.php?t=msg&th=82&start=0&rid=307&S=bc3dad9e504b424add0971b3ad17d6ef&SQ=f7aee24c1e98afbd833f23c31510c1b6) seems to have some good information that appears be relevant.

I've located the DiskConfigurations table in the 5.1.1b tivoapp dump. Looks the same as 4.X.

With the stock 80GB hard drive, I'm seeing these values in Hserver.send:


bash-2.02# grep MFS /tmp/HServer.send
IDB_MFS_TOTAPP: 785024
IDB_MFS_AVAILAPP: 632424
IDB_MFS_TOTMEDIA: 157446144
IDB_MFS_AVAILMEDIA: 6123520
IDB_MFS_TOTCLIPS: 13623072
IDB_MFS_AVAILCLIPS: 2512928
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Judging from the last entry in the DiskConfigurations table, I was expecting IDB_MFS_TOTCLIPS to be 1000000. It's looking to me like MaxUser is locked for large disks and any additional available space is going to MaxClips (aka IDB_MFS_TOTCLIPS). The DiskConfigurations table doesn't seem to have an entry that does this, so it's probably in the tivoapp code. I'm starting to dig into the code sections of tivoapp that access the DiskConfigurations table, looking for where this occurs.

Has anyone else been down this path already?

Jamie
10-07-2004, 08:43 PM
I dug around a little more.

MaxUser =
IDB_MFS_TOTMEDIA (sectors) -
- IDB_MFS_TOTCLIPS (KB)
- IDB_MFS_TOTRBACKS (KB)
= 65100000 KB.

This is the total number of KBs allocated to User streams.

I went searching for this constant, and the equivalent in sectors, in the tivoapp code. I didn't get a hit on that constant value, but I did happen across an interesting MFS path: /Config/DiskConfigurations/Active.

Examining this MFS object with TWP, I see that it holds two "DiskPartitions". One of them has Id=11 and SizeInKb=-1. I'm guessing that's the TiVoClips partition and the -1 means expand to fill available space. The other one has Id=10, and SizeInKb=65100000. There's our magic number from before. This looks like the partition for User streams.


DiskConfiguration 5245/11 {
ServerVersion = 6
DiskPartitions = 5245/12 5245/13
Id = 80Gig80HourJyounetsu
MaxDiskSize = 825000000
MinDiskSize = 79000000
ServerId = 13830056
Version = 2
Active = 1
IndexPath = /Config/DiskConfigurations/80Gig80HourJyounetsu /Config/DiskConfigurations/Active /Server/13830056
}
DiskPartition 5245/12 {
Id = 11
SizeInKb = -1
}
DiskPartition 5245/13 {
Id = 10
SizeInKb = 65100000
}



I'm wondering if setting the User partition size to -1, and the TiVoClips partition size to some fixed value (e.g. 10000000 - the maximum it would ever get from the table in tivoapp) might allow the user partition to expand to fill the available space. Or will the values just get overwritten if we try to modify them?

/DataSet/DiskConfigurationVersion/* has a bunch of other DiskConfiguration objects for different TiVo models.

Is this stuff already well understood? I haven't seen anything about unlocking the sd-h400 capacity limit. Please let me know if I'm treading near taboo ground.

alldeadhomiez
10-07-2004, 10:15 PM
I would expect that the DiskConfiguration objects affect the way the drive is initially partitioned by TiVo. In MFS, zones (not partitions) are used to figure out where to put things.

From what I can tell, the partitions mirror the zone layout so that they can be rearranged strategically (e.g. putting the application zones near the center of the disk to reduce thrashing). Nothing keeps you from arranging the data contiguously on the disk, and then cramming all of the zones into hda10.

Jamie
10-07-2004, 10:44 PM
Thanks for the tips. I'm still learning MFS.

I'm not convinced that the "DiskPartitions" objects refered to above have anything to do with Partitions in the pdisk sense. They seem to be dividing up the media region. On my stock disk, the sum of the "MFS media region" pdisk partitions is almost the same as than the IDB_MFS_TOTMEDIA value. The User and TiVoClips "Partitions" described in the MFS data structures above seem to be logical subdivisions of the total media region. Maybe these are what you are describing as zones?

I had the impression from MuscleNerd's alt.org post that the subdivisions of the media region could be dynamically altered, but this could be incorrect. He described patching the DiskConfigurations table in tivoapp to change the allocation.

I need to buy yet-another-disk so I have a scratch disk I can play with this stuff on.

alldeadhomiez
10-07-2004, 11:26 PM
I'm not convinced that the "DiskPartitions" objects refered to above have anything to do with Partitions in the pdisk sense. They seem to be dividing up the media region. On my stock disk, the sum of the "MFS media region" pdisk partitions is almost the same as than the IDB_MFS_TOTMEDIA value. The User and TiVoClips "Partitions" described in the MFS data structures above seem to be logical subdivisions of the total media region. Maybe these are what you are describing as zones?

You might be right - I'm not sure. Anyway I'd look at the sizes of partitions 10 and 11, since that could be what the Id refers to.

You can run mfs_info (tridge utility) to list the MFS zones and the sector ranges they use. IIRC they're separated into inode zones, application zones, and media zones.

alldeadhomiez
10-08-2004, 03:59 PM
At the risk of hijacking yet another one of your threads, here are a couple more data points which may or may not be useful:

My drives are all prepared using something resembling this method (http://www.dealdatabase.com/forum/showthread.php?t=29775). As such, they were expanded from a "synthetic" blank ~2GB image and have never contained DiskConfiguration objects. The only things I used off the original drive were the loopsets.

Here is the HServer.send info from a 200GB SA 4.0 box:

IDB_MFS_TOTAPP: 785168
IDB_MFS_AVAILAPP: 751056
IDB_MFS_TOTMEDIA: 386490368
IDB_MFS_AVAILMEDIA: 28475392
IDB_MFS_TOTCLIPS: 10000000
IDB_MFS_AVAILCLIPS: 9948800
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Here is the HServer.send info from an 80GB 5.1.1b Toshiba box (original drive but reimaged using my scripts). This image reports 82 hours in system information.

IDB_MFS_TOTAPP: 785168
IDB_MFS_AVAILAPP: 591048
IDB_MFS_TOTMEDIA: 154787840
IDB_MFS_AVAILMEDIA: 23969792
IDB_MFS_TOTCLIPS: 10000000
IDB_MFS_AVAILCLIPS: 9971328
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Here is the HServer.send info from a freshly installed 80GB 5.1.1b. This image reports 24 hours in system information on an HDVR2, and 82 hours on a TCD540040.

IDB_MFS_TOTAPP: 785168
IDB_MFS_AVAILAPP: 740056
IDB_MFS_TOTMEDIA: 154787840
IDB_MFS_AVAILMEDIA: 153053184
IDB_MFS_TOTCLIPS: 10000000
IDB_MFS_AVAILCLIPS: 9919104
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Here is the HServer.send info from a freshly installed 120GB 5.1.1b SA2. This image reports 37 hours in system information on an HDVR2, and 129 hours on a TCD540040 or SD-H400.

IDB_MFS_TOTAPP: 785168
IDB_MFS_AVAILAPP: 740032
IDB_MFS_TOTMEDIA: 229146624
IDB_MFS_AVAILMEDIA: 227416064
IDB_MFS_TOTCLIPS: 10000000
IDB_MFS_AVAILCLIPS: 9921152
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Edit: glancing through earlier (http://www.dealdatabase.com/forum/showthread.php?t=35953) threads (http://www.dealdatabase.com/forum/showthread.php?t=33080&page=3&pp=40), I'm not clear on whether anyone has reset the defaults after the upgrade. What I would try after expanding the drive is MfsRubbishTree /State to see if the 80-hour default is stored in there someplace. This should not erase season passes, guide data, or unscrambled recordings. (But this is not on a "production" drive anyway...right?)

Also, my trial with the 200GB drive should be disregarded, as we now can deduce that the recording time estimate on a DTiVo under 5.1.1b is way off (~12 hours per 40GB).

Jamie
10-08-2004, 05:26 PM
At the risk of hijacking yet another one of your threads, here are a couple more data points which may or may not be useful:
Thanks for the additional info. It *looks* to me like your installations are all unlocked and not subject to the 80 hour lock we see on the factory shipped drives.

It's interesting that you're seeing IDB_MFS_TOTCLIPS: 10000000 in all cases. That makes me think it's using the DiskConfigurations table in tivoapp rather than what I see on my system in MFS /Config/DiskConfigurations/Active. Perhaps leaving the DiskConfigurations object out of MFS is a good thing.

I hope to free up a scratch disk I can play with in the next few days to examine this further.

alldeadhomiez
10-08-2004, 06:27 PM
Here is the DiskConfiguration object from an 80 hour Pioneer DVR810 @ 5.2-01-2-275, which AFAIK does not suffer from the expansion issue:


DiskPartition 5644/12 {
Id=11
SizeInKb=-1
}
DiskPartition 5644/13 {
Id=10
SizeInKb=67500000
}
DiskConfiguration 5644/11 PRIMARY {
ServerVersion=7
DiskPartitions=5644/12 5644/13
Id=80Gig80HourTakara
MaxDiskSize=825000000
MinDiskSize=79000000
ServerId=13067576
Version=2
Active=1
IndexPath=/Config/DiskConfigurations/80Gig80HourTakara /Config/DiskConfigurations/Active /Server/13067576
}

Jamie
10-09-2004, 01:59 PM
I did an mfstools backup|restore to a 250GB disk. This process preserved all my settings and recordings. After the initial boot, the System Information screen still showed 80 hours. After a daily call, HServer.send showed all the additional space allocated to TiVoClips.

So I booted a minimal environment for running tivosh/MFS, poked around a bit, and finally decided to do a "RubbishObjectByFsId" on the /Config/DiskConfigurations/Active object. Then I rebooted to the full myworld, and now I see 291 hours on the System Information screen. Several daily calls and reboots later, and it seems to be holding.

While I'm optomistic, I know this may not last forever. A daily call could choose to refresh the DiskConfigurations object at any time, sending me back down to 80 hours. It also remains to be seen what happens as I start to fill up the space.

I'll post more details later. Busy today with other things.

Just in case this isn't obvious: this is highly experimental. I'm not recommending anyone try this on an original disk or a disk with recordings they care about.

alldeadhomiez
10-09-2004, 02:49 PM
While I'm optomistic, I know this may not last forever. A daily call could choose to refresh the DiskConfigurations object at any time, sending me back down to 80 hours.

Given what I've seen of the daily calls, I don't consider this likely, but then again I am still at a loss to explain why the active DiskConfiguration object (present on many/most images) only limits the capacity on 5.1*. Maybe it's just another screwy version 5 misfeature.

Good find, at any rate.

Jamie
10-11-2004, 03:26 PM
So far so good. It isn't full yet, but it's well past the 80hour mark, and everything seems to be fine. I don't think I've crossed the 137GB boundary yet, but that shouldn't be a problem with 2.4.20.

I'd like to make this a little more accessible to the broader user community that might have a hard time following my sketchy description above. My sd-h400 is back in production, and I can't really experiment on it anymore without risking the wrath of a TiVo deprived family. I'm not sure if booting a minimal MFS environment was really necessary. Could the offending MFS entry be deleted when myworld is running without causing problems? Is a reboot after necessary?

If someone with an sd-h400 feels like playing guinea pig, let me know and we can try to work out a streamlined process for taking out the 80hour limit. A reasonable prerequisite is that you've already expanded your MFS onto a larger disk, and you've got a bash prompt on a serial console. Also, we might well trash MFS when experimenting, so having your original disk as a backup is important. Some experience with tivosh/tcl wouldn't hurt, but probably isn't required.

wen1
10-11-2004, 06:51 PM
I have my SD-h400 on the network and it was expanded to a 120GB drive. Currently i am below the 80 hour mark.
Ready to try the commands.
If it trash it i can restore it again since most of my recordings are not on until wednesday.
Please let me know what i have to do.

Here is what it looks like right now

tivo:/$ grep MFS /tmp/HServer.send
IDB_MFS_TOTAPP: 785024
IDB_MFS_AVAILAPP: 558232
IDB_MFS_TOTMEDIA: 232058880
IDB_MFS_AVAILMEDIA: 83167232
IDB_MFS_TOTCLIPS: 50929440
IDB_MFS_AVAILCLIPS: 40485920
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Jamie
10-11-2004, 07:49 PM
I have my SD-h400 on the network and it was expanded to a 120GB drive. Currently i am below the 80 hour mark.
Ready to try the commands.
If it trash it i can restore it again since most of my recordings are not on until wednesday.
Please let me know what i have to do.

Here is what it looks like right now

tivo:/$ grep MFS /tmp/HServer.send
IDB_MFS_TOTAPP: 785024
IDB_MFS_AVAILAPP: 558232
IDB_MFS_TOTMEDIA: 232058880
IDB_MFS_AVAILMEDIA: 83167232
IDB_MFS_TOTCLIPS: 50929440
IDB_MFS_AVAILCLIPS: 40485920
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

First a sanity checks:

TOTMEDIA=23205880 sectors. This is 116029440 KB, which makes sense for a 120GB drive.

MaxUser = TOTMEDIA sectors - TOTCLIPS KB - TOTRBACKS = 65100000 KB.

This is the same magic 80 hour number that I had. So it still looks like the allocation between user and TiVo clips is the problem.

The "fix" is to locate the /Config/DiskConfigurations/Active object in MFS and delete it. I did this on a system that wasn't running myworld. I hacked up a special rc.sysinit that just brought up enough to run MFS. If you are up to it, you can try deleting it while the TiVo software is fully running (i.e. myworld is running). This could crash your system, and/or corrupt MFS. I don't think the latter is likely, but I haven't tried it and don't know for sure. Eventually we'd probably want to package this up in a tcl script, but for now, you can just do it from the tivosh prompt.

From the bash prompt run /tvbin/tivosh. This should come back with a "%" prompt for the tcl shell. tivosh is just a tcl interpreter with extra TiVo commands, some to access MFS. For the curious, look in /tvlib/tcl/tv for some of the support libraries. mfslib.tcl has some of the MFS commands available.

The first tivosh command to run is "mls /Config/DiskConfigurations". This will list the contents of this "directory" in MFS. You should see an object called "Active" and one other ("80Gig80HourJyounetsu"). They'll both have the same FsId. Make a note of that FsId. Mine was 5245, but it might be different on different boxes.

The next command will delete that Active object: "RubbishObjectByFsId <FSID>" where <FSID> is the FsId you noted before. I should be a four digit integer.

The "exit" command will get you out of tivosh and back to bash. Don't try cntrl-D; it seems to crash the tivo.

At this point, before you reboot, check the "System Information" screen on the tivo to see if it still shows 80 hours. I suspect it will, but I'm not sure. Let me know.

Reboot, check the "System Information" screen again. Force a daily call, check again.

At this point the 80 hour lock should be gone. Of course, it could come back after a software update, but like all hacks, you'll have to be prepared to do a little work when the software updates come in.

Please report back your results.

I can walk you through the minimal setup for MFS, if that turns out to be necessary.

wen1
10-11-2004, 10:59 PM
Your hack works great!!!.

I followed the commands you described exactly.

Connected to Tivo via Telnet

tivo:/var/tmp$ /tvbin/tivosh
% mls /Config/DiskConfigurations
Directory of /Config/DiskConfigurations starting at ''

Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----
80Gig80HourJyounetsu tyDb 5245 09/17/03 20:13 296
Active tyDb 5245 09/17/03 20:13 296

% RubbishObjectByFsId 5245
0

Once the above was done Tivo was already showing 131 hrs recording time in system information.
However the recording settings were still showing 24,38,60,131 hrs respectively. Seems like only the basic setting was updated on this screen

Then i did a forced connect. It still remained at 131 hours.

Then i did a reboot. Now all recording quality settings are showing the new times. 40,60,80,131 (Aprox) respectively.

Thank you for your help. Let me know if you want me try anything else.

Jamie
10-11-2004, 11:34 PM
Your hack works great!!!.
...
Thank you for your help. Let me know if you want me try anything else.

Thanks. I'll wrap it up in a tcl script. People can run it after they've expanded MFS (e.g. mfsbackup|mfsrestore) and done what's necessary to get a bash prompt (e.g. killhdinitrd, etc).

Jamie
10-12-2004, 12:10 PM
I am sure that I am not the only SD-H400 owner who is thrilled to be reading this thread! Congratulations and thanks for all of your hard work. I am curious - does a hacked Toshiba unit max out at 137GB, or will a larger drive work? I would love to get a larger drive into mine. Thanks in advance for any advice that the group can offer.
The sd-h400 with TiVo software 5.1.* has a 2.4.20 kernel which has built in support for lba48. This means it doesn't have a 137GB constraint. I put a 250GB drive in mine using the stock kernel (compromised to allow hacks, of course).

Let's move further "support" discussions to a thread in the support category, here (http://www.dealdatabase.com/forum/showthread.php?t=38519).

Development discussions should remain here, of course. If you have further insight, or a better way to accomplish the same goal, this is the place to post.

Jamie
10-16-2004, 10:47 PM
Here's the developer package with source for a new PC side program to remove the SD-H400 capacity lock. There's a matching binary only posting in the support thread (http://www.dealdatabase.com/forum/showthread.php?t=38519). If you just want the x86 binary and its instructions, get that instead.

The advantage of this program over the previously described tivosh method is that it runs entirely on the PC side. This means you don't have to hack the TiVo to get shell access in order to use it. It's just a program you run on the PC side after doing an mfstool restore expansion.

I heard one report in a PM that some software versions for the Pioneer 810H also have a capacity lock. If that's the case, it's possible this program will work there too. If you try it on a Pioneer, please let me know the results and what the TiVo software version was.

This package includes source in two forms. Yes this is redundant, but I couldn't decide which form people would prefer. One form is a source patch against the vplay sources from samba CVS. To build this version you'll have to pull vplay from cvs and apply the patch. The other version is a standalone source directory that includes only the parts of the vplay distribution necessary to build sd-h400_unlock. This directory also includes compiled mips-tivo and i386 binaries. In addition to my source additions and changes, both packages include the series 2 improved util.c that ADH posted in this (http://www.dealdatabase.com/forum/showthread.php?t=34943&highlight=util.c) thread.

The packaged is licensed under the GPL v2. That was the license on the vplay sources, and this is a derived work.

Please see the README_sd-h400_unlock.txt file for further information.

bnm81002
05-31-2005, 01:54 AM
will this work on the 6.2 software?

Jamie
05-31-2005, 05:23 AM
will this work on the 6.2 software?Does 6.2 include a capacity lock? News to me.

jdelapena
11-08-2005, 07:01 PM
Does this work for 7.2? I have a Toshiba SD-H400 running on 7.2 with a 120 GB hard disk.

I ran the "RubbishObjectByFsId 5261" command and I only jumped from 83 GB to 88 GB (basic recording mode).

After doing so, when I run again the "mls /Config/DiskConfigurations" I only get the header (Name Type FsId Date Time Size) with no information about the hard drive.

Is there a different procedure to get the full capacity after 7.2 upgrade?

Thanks in advance for your suggestions…

Jdelapena

Jamie
11-08-2005, 07:11 PM
Does this work for 7.2? I have a Toshiba SD-H400 running on 7.2 with a 120 GB hard disk.

I ran the "RubbishObjectByFsId 5261" command and I only jumped from 83 GB to 88 GB (basic recording mode).

After doing so, when I run again the "mls /Config/DiskConfigurations" I only get the header (Name Type FsId Date Time Size) with no information about the hard drive.

Is there a different procedure to get the full capacity after 7.2 upgrade?

Thanks in advance for your suggestions…

JdelapenaDid you expand (-x) when you restored to the 120GB drive? Did you reboot after rubbishing the object?

You could run the script here (http://www.dealdatabase.com/forum/showthread.php?p=205747#post205747) to set an explicit tivoclips allocation.

jdelapena
11-08-2005, 07:32 PM
Thanks Jamie for your response. All your posts across these forums have been very helpful to me.

Regarding your questions, I did not make my backup using mfsrestore. Instead, I copied the entire disk using dd if=/dev/hdc of=/dev/hdd. So I stored the original disk and made all the hacks on the backup hard drive, which is a full functional 7.2 copy plus telnet and ftp. I think this is similar to have expanded (-x) the mfsrestore command (or not???).

After rubbish the object I immediately got a small increase in capacity from 83 to 88 GB. After 2 reboots capacity still remains at 88 GB.

Thank you very much for your help.

Jdelapena

Jamie
11-08-2005, 07:40 PM
Regarding your questions, I did not make my backup using mfsrestore. Instead, I copied the entire disk using dd if=/dev/hdc of=/dev/hdd. So I stored the original disk and made all the hacks on the backup hard drive, which is a full functional 7.2 copy plus telnet and ftp. I think this is similar to have expanded (-x) the mfsrestore command (or not???).Nope. A dd clone still has the capacity of the original drive it was cloned from.

Run pdisk on the drive and you'll either see it shows up as an 80GB drive, or you'll see the full 120GB with a large unallocated region at the end. In the later case, you just have to pull the drive and run mfsadd -x on it on the PC. In the former, you need to record the exact contents of the partition table, then clear it and set it up again, with exactly the same partition bases and sizes. Then you can do the mfsadd.

jdelapena
11-08-2005, 10:03 PM
OK Jamie. I am in the second scenario, where my HD only shows 80 GB. I have 13 partitions with the following info:

# /type /name /length /base /(size)
1: Apple_partition_map Apple 63 @ 1
2: Image Bootstrap 1 1 @ 88047639
3: Image Kernel 1 8192 @ 88047640 (4.0M)
4: Ext2 Root 1 524288 @ 88055832 (256.0M)
5: Image Bootstrap 2 1 @ 88580120
6: Image Kernel 2 8192 @ 88580121 (4.0M)
7: Ext2 Root 2 524288 @ 88588313 (256.0M)
8: Swap Linux Swap 262144 @ 89112601 (128.0M)
9: Ext2 /var 262144 @ 89374745 (128.0M)
10: MFS MFS application region 524288 @ 89636889 (256.0M)
11: MFS MFS media region 69401063 @ 9068546 5 (33.1G)
12: MFS MFS application region 2 524288 @ 90161177 (256.0M)
13: MFS MFS media region 2 88047575 @ 64 (42.0G)


Now, what is the next step? In your previous response you said that I should clear the partition table and set it up again and after that, run mfsadd –x. Well, to be very honest, I am not sure how to do it. Can you provide some advice on this matter?

Thanks again for all your valuable help!!!

Jdelapen

Jamie
11-09-2005, 01:11 AM
Now, what is the next step? In your previous response you said that I should clear the partition table and set it up again and after that, run mfsadd –x. Well, to be very honest, I am not sure how to do it. Can you provide some advice on this matter?Run pdisk /dev/hda. ? gives you usage instructions. i initializes the partition map (deletes all existing partitions and makes a new empty partition table spanning the full disk). C creates new partitions. You need the starting block and length, as well as the name and type. Use the information you pasted above and fill it in exactly as it was before. Put quotes around the partition names if they have embedded blanks. Once you get it right, w writes the partition table to disk. You can do all this on the tivo. If you can find an mfsadd compiled for the tivo, you could probably do that there too, but it might be safer to pull the drive and do that part on a PC.

More details here (http://www.tivocommunity.com/tivo-vb/showthread.php?p=629559&&#post629559).

jdelapena
11-09-2005, 01:48 AM
Thanks a lot Jamie. Everything is working great now. I ran mfsadd –x using the PC, added a couple or partitions and then put back the drive into the Tivo. From there, I ran the RubbishObjectByFsId 5261 command (using Telnet and Tivosh) and surprise!!! Now the Tivo is reporting 141 hours on my 120 GB hard drive. Also individual times for Best, High, Medium and Basic quality recordings are correctly updated and displayed.

Not bad for a newbie…

Thanks again for all your help!!!

Jdelapena

chewychewytoo
01-18-2009, 07:15 PM
Here's the developer package with source for a new PC side program to remove the SD-H400 capacity lock. There's a matching binary only posting in the support thread (http://www.dealdatabase.com/forum/showthread.php?t=38519). If you just want the x86 binary and its instructions, get that instead.

The advantage of this program over the previously described tivosh method is that it runs entirely on the PC side. This means you don't have to hack the TiVo to get shell access in order to use it. It's just a program you run on the PC side after doing an mfstool restore expansion.

I heard one report in a PM that some software versions for the Pioneer 810H also have a capacity lock. If that's the case, it's possible this program will work there too. If you try it on a Pioneer, please let me know the results and what the TiVo software version was.

This package includes source in two forms. Yes this is redundant, but I couldn't decide which form people would prefer. One form is a source patch against the vplay sources from samba CVS. To build this version you'll have to pull vplay from cvs and apply the patch. The other version is a standalone source directory that includes only the parts of the vplay distribution necessary to build sd-h400_unlock. This directory also includes compiled mips-tivo and i386 binaries. In addition to my source additions and changes, both packages include the series 2 improved util.c that ADH posted in this (http://www.dealdatabase.com/forum/showthread.php?t=34943&highlight=util.c) thread.

The packaged is licensed under the GPL v2. That was the license on the vplay sources, and this is a derived work.

Please see the README_sd-h400_unlock.txt file for further information.

I am trying to unlock the space on my Pioneer 810H, I expanded the drive using PTVUPGRAD LBA48 disk, using the Hinsdale guide to expand a single drive to a single larger drive, which seemed to go fine, it reported 281 hours available at the prompt when the expand completed, and it booted fine after placing the drive back in the tivo, however, it only shows 89 meg of recording time in the system settings on the tivo.

Trying this sd-h400_unlock command from the i386 folder from the archive, and it gives the error ./sd-h400_unclock: No such file or directory

I am running it from a floppy disk after booting from the LBA48 CD. I need to copy this over to the tivo drive or the linux environment somehow? I am a PC person and although fairly comfortable a command prompt, I am not sure what to do to get this working.


Any help or pointers to getting this to run to unlock the space on my newly expanded 250 gig drive would be greatly appreciated.

Jamie
01-18-2009, 07:43 PM
...

Trying this sd-h400_unlock command from the i386 folder from the archive, and it gives the error ./sd-h400_unclock: No such file or directoryIt's unlock, not unclock.

I think most of the upgrade cds ship with that tool on it, these days, so you probably don' t need to use a floppy. If the one you are using doesn't, you could look at mfslive (www.mfslive.org), winmfs (http://www.mfslive.com/winmfs/index.html), or the weaknees instructions and iso (http://tivo.upgrade-instructions.com/index.php).

chewychewytoo
01-18-2009, 08:10 PM
Thanks for quick response. yes I misspelled it in my post, I ended up getting it to work from the CD, did not realize it was already on there :) I had used the CD to upgrade a Dtivo a while back it was on there all along. I may have been typing the command line incorrectly, someone posted that this should work:
/cdrom/toshiba_unlock/sd-h400_unlock -w /dev/hda and it kept failing with the error I mentioned

"./sd-h400_unclock: No such file or directory"

I ended up changing to the /cdrom/toshiba_unlock directory, and the command ran directly with a success, so once I changed to the toshiba_unlock directory at the prompt, I ran this:
sd-h400_unlock -w /dev/hda

and it came back with a success (commited)
response.

Booting it up again in the tivo to check the space.. it now shows "Up to 325 hours variable" this was with a 250 gb drive (actually it's really 232 gib) marketed as a 250 gb :) I still don't see how drive manuafactures still get away with calling 1000 bytes a meg, they use the wrong math to call it a larger drive, but thats another thread altogether.

This worked, thanks a ton, for all who worked on the toshiba_unlock tool, and all the other tools that let us use our tivos to their fullest potential, pun intended.

So is it possible this workaround will be lost if the software is updated by tivo ? I guess the worst case scenario is I have to patch it again.

Thanks again Jaime for the very quick reponse...

Jamie
01-18-2009, 08:30 PM
...

So is it possible this workaround will be lost if the software is updated by tivo ? I guess the worst case scenario is I have to patch it again.
Hasn't happened to anyone yet.

Jamie
02-02-2009, 11:47 PM
Delete -- wrong thread.