Is it possible to delete clips in "Reserved Space"

[ryan94z]

I have an HDTivo, and I've noticed that the reserved space is unacceptably large because of the 250GB hard drive. After reading this (http://www.tivocommunity.com/tivo-vb/showthread.php?s=&postid=1255290#post1255290) post by Lightn it makes sense. I tried to figure out a way to delete the clips that were recorded, and/or a way to prevent the tivo from scheduling more Teleworld recordings, but I was unsuccessful. I tried using the delete procs that exist in TiVoWeb Plus (http://tivo/confirmdelete/2/<fsid>) and plugging in the fsid I found from searching through the MFS DB in /Clips/auth/0/ but that only returned "Deletion of 'Teleworld Paid Program' Failed". I was wondering if anyone else has figured out a way to delete these clips so that the extra space can be used for recordings I choose.

[Jamie]

I have an HDTivo, and I've noticed that the reserved space is unacceptably large because of the 250GB hard drive. After reading this (http://www.tivocommunity.com/tivo-vb/showthread.php?s=&postid=1255290#post1255290) post by Lightn it makes sense. I tried to figure out a way to delete the clips that were recorded, and/or a way to prevent the tivo from scheduling more Teleworld recordings, but I was unsuccessful. ....
See this (http://www.dealdatabase.com/forum/showthread.php?t=38331) thread for some ideas. Some TiVo software versions have a /Config/DiskConfigurations/Active object that controls the allocation to TiVo Clips. If you don't have that object, then it's controlled by a table compiled into tivoapp. Follow the thread to alt.org for more info on the tivoapp table.

[ryan94z]

So after doing some reading and poking through the MFS, I see the objects you mention in the linked post, but I still need a bit of clarification. The objects on my TiVo are as follows:


DiskConfiguration 3630/11 {
ServerVersion = 4
DiskPartitions = 3630/12 3630/13
Id = 250GigPhoenix
MaxDiskSize = 251000000
MinDiskSize = 248000000
ServerId = 15271136
Version = 2
Active = 1
IndexPath = /Config/DiskConfigurations/250GigPhoenix /Config/DiskConfigurations/Active /Server/15271136
}

DiskPartition 3630/12 {
Id = 11
SizeInKb = -1
}

DiskPartition 3630/13 {
Id = 10
SizeInKb = 210000000
}


DiskPartition 3630/12 is the object of interest to me, I assume this to be partition 11 (hda11?). In order to limit the amount of clips saved, is it sufficient for me to change the SizeInKb from "-1" to "102400" to limit it from saving more than 100MB worth of Advertising Clips, or is there something I am overlooking.

[Jamie]

So after doing some reading and poking through the MFS, I see the objects you mention in the linked post, but I still need a bit of clarification. The objects on my TiVo are as follows:...
Note that the "DiskPartition" objects refered to here don't correspond to disk partitions in the pdisk sense (/dev/hda10 etc). They're really more logical allocations within MFS. I've never heard a report that the HDTivo's have a capacity lock, so I'm not at all sure this object is actually being used in your software version.

If this object is actually being used, then you could "lock" the TiVo clips allocation by replacing the SizeInKb value of -1 with something else in the DiskPartition object with ID 11 (TiVoClips). 100000000 is the typical value used, but you could try something smaller. Then you could "unlock" the User allocation by replacing the fixed SizeInKb (210000000) with -1. Note that -1 means to use all remaining space, and only one allocation area can use it. As it turns out, this is exactly what the sd-h400_unlock utility does, so you could simply run it to modify the object appropriately.

Alternatively, you could do the "RubbishObjectByFsid" solution which would cause tivoapp to fall back to the table compiled into the app itself. I've never examined a 3.1.5 tivoapp, so I'm not sure if it matches the tables laid out in the MuscleNerd alt.org post.

I caution you that you're breaking new ground applying this to a software version where it hasn't been tested before, so I'd be sure you are willing to lose anything you have on the disk.

I'd be cautious about shrinking the Clips allocation too small. It could mess up showcases, and other things (background animations?) Also, I notice the first time I changed it that the TiVo went into a lengthy garbage collection process purging old clips since it was over the new allocation.

[ryan94z]

I ran an objdump of 3.1.5 of tivo and looked for the table MuscleNerd mentioned. I only looked at the first half of the table before going on to something else, but the part that I looked at matched up perfectly with the posted table.

I have quite a few shows that I'd like to watch, so I think I will do so before trying the unlock utility you mentioned. I'll report back once I do try. Thanks for your help.

[ronnythunder]

there's an update on the alt.org thread. any comments? jamie? :)

i'm tempted to try the rubbish thing on a hd tivo that i have, but i don't give it great chances of success. rather, i think, from the threads here, the allocation is already set for the factory config (250gb drive), and since i haven't expanded, i don't think that rubbishing the object will give me back that space.

ryan94z, did you ever try this?

ronny

[Jamie]

there's an update on the alt.org thread. any comments? jamie? :)Modifying the table within tivoapp probably won't have an effect if it is actually using the DiskConfiguration object in MFS.i'm tempted to try the rubbish thing on a hd tivo that i have, but i don't give it great chances of success. rather, i think, from the threads here, the allocation is already set for the factory config (250gb drive), and since i haven't expanded, i don't think that rubbishing the object will give me back that space.I'd run the sd_h400_unlock utility, as its effect is reversible. You can set whatever sizes you want for the USER and TIVO clips allocations and revert them back if changing them causes any problems. Once you rubbish the object, I'm not sure if there is a good way to get it back again (though I'm no expert on tivosh builtins).

[ronnythunder]

i've also got a 250gb hdvr2 and see the same thing in the hserver.send. i do have a diskconfigurations object, but it seems to be from the stock 40gb config:% dumpobj -depth 2 33
DiskConfiguration 33/11 {
Active = 1
DiskPartitions = 33/12 33/13 33/14
DiskPartition 33/12 {
Id = 12
SizeInKb = 102400
}
DiskPartition 33/13 {
Id = 11
SizeInKb = -1
}
DiskPartition 33/14 {
Id = 10
SizeInKb = 35191000
}
Id = 30HourLCT40Combo
IndexPath = /Config/DiskConfigurations/30HourLCT40Combo /Config/DiskConfigurations/Active /Server/4178108
MaxDiskSize = 38700000
MinDiskSize = 37000000
ServerId = 4178108
ServerVersion = 1
Version = 2
}
i wonder if there's a calculation in tivoapp for configs that don't fit the disckconfigurations or that fall into the catch all tivoapp table?

ronny

[Jamie]

i've also got a 250gb hdvr2 and see the same thing in the hserver.send. i do have a diskconfigurations object, but it seems to be from the stock 40gb config:
...
i wonder if there's a calculation in tivoapp for configs that don't fit the disckconfigurations or that fall into the catch all tivoapp table?
Well, this does have -1 for the TivoClips allocation, Id=11. I still wonder if you locked it to a fixed size with sd-h400_unlock if that might constrain its size the way you want.

Note that the DiskConfiguration object does have a min and max disk size that might affect how tivoapp interprets it when applied to a larger disk. It looks like in the original 40GB configuration it was allocating ~ 10% to TiVoClips at the MaxDriveSize. Maybe it's just scaling that 10% up for a 250GB drive? Doesn't quite make sense. We didn't see that effect on the sd-h400. Could be another TiVo Software 5.X difference.

[ronnythunder]

so, perhaps i should try hacking the diskconfigurations object to something that seems to match my config? maybe even change the min and maxdisksize in addition to the clips and media numbers (i'm thinking use a fixed clips number and a -1 media number)?

ronny

[Jamie]

so, perhaps i should try hacking the diskconfigurations object to something that seems to match my config? maybe even change the min and maxdisksize in addition to the clips and media numbers (i'm thinking use a fixed clips number and a -1 media number)?
Yep. That sounds worth trying. I'm not up on all the tivosh mfs functions for object creation, but if you could create a new one and link it to Active, keeping the old 30HourLCT40Combo around in case you need to revert, it might be an action that would be easy to revert if it caused problems.

Another option might be a tivoapp binary patch to make it just skip over looking for the Active object.

[ronnythunder]

which, i suppose, brings up an interesting question: if a machine has a /config/diskconfigurations/active entry that matches in totmedia, will it always be obeyed? if so, perhaps the solution (barring a tivoapp patch) would be to create a purpose-made diskconfigurations object when an expansion is done to "catch" the totmedia that results, and force it to a low clips amount.

hmmmm...

ronny

[Jamie]

which, i suppose, brings up an interesting question: if a machine has a /config/diskconfigurations/active entry that matches in totmedia, will it always be obeyed? if so, perhaps the solution (barring a tivoapp patch) would be to create a purpose-made diskconfigurations object when an expansion is done to "catch" the totmedia that results, and force it to a low clips amount.

hmmmm...

ronny
Worth trying. Make sure Min and Max DiskSize are broad enough to work with any large disk....

[ronnythunder]

well, "curiouser and curiouser", it would seem...

i changed my active diskconfigurations object to look like this:% dumpobj -depth 2 33
DiskConfiguration 33/11 {
Active = 1
DiskPartitions = 33/12 33/13 33/14
DiskPartition 33/12 {
Id = 12
SizeInKb = 102400
}
DiskPartition 33/13 {
Id = 11
SizeInKb = 266240
}
DiskPartition 33/14 {
Id = 10
SizeInKb = -1
}
Id = 30HourLCT40Combo
IndexPath = /Config/DiskConfigurations/30HourLCT40Combo /Config/DiskConfigurations/Active /Server/4178108
MaxDiskSize = 850000000
MinDiskSize = 37000000
ServerId = 4178108
ServerVersion = 1
Version = 3
}so, basically, a miserly 266mb for clips and the rest for media. i then crossed my fingers and rebooted. after a call attempt, here's the excerpt from hserver.send:IDB_MFS_TOTMEDIA: 485361664
IDB_MFS_AVAILMEDIA: 11376640
IDB_MFS_TOTCLIPS: 266240
IDB_MFS_AVAILCLIPS: -23314432
IDB_MFS_TOTRBACKS: 102400
IDB_MFS_AVAILRBACKS: 102400
doh! a negative number for availclips! the machine seems to function normally, but tivoweb (at least) still shows the old clips figures. perhaps i should try scheduling some shows (the machine is almost full) and see what happens?

jamie, you mentioned a "garbage collection" process on one of your machines when you shrunk the space; what did that look like?

ronny

[Jamie]

doh! a negative number for availclips! the machine seems to function normally, but tivoweb (at least) still shows the old clips figures. perhaps i should try scheduling some shows (the machine is almost full) and see what happens?I think it makes sense that availclips is negative since used exceeds the total allocatation.jamie, you mentioned a "garbage collection" process on one of your machines when you shrunk the space; what did that look like? This was on a S2SA (5.1.1b), and I believe the daily call triggered it. I just remember a bunch of GC related messages in tvlog. Didn't save the log, and I no longer remember exactly what they were. I also remember high load (dbgc-mcp?) for an hour or so.

Let us know what it settles out to after a day or two.

[ryan94z]

there's an update on the alt.org thread. any comments? jamie? :)

i'm tempted to try the rubbish thing on a hd tivo that i have, but i don't give it great chances of success. rather, i think, from the threads here, the allocation is already set for the factory config (250gb drive), and since i haven't expanded, i don't think that rubbishing the object will give me back that space.

ryan94z, did you ever try this?

ronny

I have not tried anything yet; the power supply in my HD Tivo took an unexpected and unrelated dump Monday night. DirecTV is shipping a replacement on Monday.

From reading the other posts in this thread I see you've tried this already, please keep us up to date on the effects.

I assume GC would take place when a daily call is attempted, not conditional on a successful daily call, say if you didn't have the phone line plugged in?

[ronnythunder]

well, i've tried both unsuccessful and successful calls, nothing changes.

now, if i could just get up the nerve to try something like this on my loaned hd tivo... :)

ronny

[rc3105]

dbgc-mcp -fg-gc

[ronnythunder]

well, we have movement. sometime during the night, over 3gb of the 22gb clips space seems to have been released to the user pool. the hserver.send values seem to reflect this as well as tivoweb.

also, i'm running the garbage collection command that riley suggested; i'll report back after it completes.

ronny

[ronnythunder]

update: the garbage collection finished, i did a daily call, rebooted, did another call, rebooted. no change after any of these, but the drop from ~22 to ~19 earlier is encouraging. maybe it'll just take a few days as jamie suggested.

however, even with just partial success thus far, i think we can conclude that clips usage can be controlled by having a /config/diskconfigurations entry that matches your setup. i'd further propose a tcl script that creates an all-inclusive entry with the minimal clips space and a recognizable name, then we link the active entry to it. perhaps this could be it (would cover anything from 5gb to 400gb drives; the min/max disk sizes are in sectors):DiskConfiguration 33/11 {
Active = 1
DiskPartitions = 33/12 33/13 33/14
DiskPartition 33/12 {
Id = 12
SizeInKb = 102400
}
DiskPartition 33/13 {
Id = 11
SizeInKb = 266240
}
DiskPartition 33/14 {
Id = 10
SizeInKb = -1
}
Id = AnyHourHackedUnit
IndexPath = /Config/DiskConfigurations/AnyHourHackedUnit /Config/DiskConfigurations/Active /Server/4178108
MaxDiskSize = 850000000
MinDiskSize = 10000000
ServerId = 4178108
ServerVersion = 1
Version = 3
}the only trick that i can forsee is that the object has a serverid and such in it; i'm not sure if those are needed for something or not.

a more straightforward approach might be to just alter the active config, but that means that it's destroyed and couldn't be reverted to if need be.

thoughts?

ronny

[Jamie]

i'd further propose a tcl script that creates an all-inclusive entry with the minimal clips space and a recognizable name, then we link the active entry to it.
...
a more straightforward approach might be to just alter the active config, but that means that it's destroyed and couldn't be reverted to if need be.

thoughts?Seems reasonable. If you wanted to do this on the PC side as part of initial imaging or during drive expansion, it might be easiest to overwrite the existing "Active" object rather than creating a new one. Creating new objects on the PC side is beyond my current capabilities, but it's not hard to modify existing ones.

[ronnythunder]

well, no apparent change in clips space today. i tried the daily call, reboot, daily call, reboot thing, but no change.

i've got a 160gb that i might try putting a fresh backup on, mod the diskconfigurations object, then expand it and see what happens. at this point, i'm thinking perhaps the best idea is to take a mostly stock backup, restore it, change the diskconfigurations object to a "all inclusive" one like i listed above, then do a backup of that and use it as the "canonical" backup.

ronny

[ronnythunder]

update: still no change in clips usage as of 6:00pm eastern today. just for kicks, i'm trying the garbage collection again, but i'm beginning to think it's either going to take a long time, or that i've got all of the "give back" i'm going to get.

i'll stop posting updates on this unit unless something else happens; in the meantime, i'll try to get that 160gb config going and report what happens with it.

ronny

[ryan94z]

I wonder if the trick to this would be to make the modification before the space has filled up, i.e. a fresh image. Did you, by any chance, get to try this on the HR10-250?

[ronnythunder]

ryan - not yet. however, i fear that the space is already allocated for clips in the hdtivo, and that the diskconfigurations trick would meet the same fate as it has in my hdvr2.

however, i'm contemplating trying to make a "from scratch" backup for the hdtivo (as documented in adh's thread), in which case there is no diskconfigurations object, which should make it defer to the tivoapp table. maybe. :)

at the moment, i'm trying a 160gb drive with the "from scratch" config, and i'm going to see how it goes on clips.

ronny

[nams]

Well I upgraded my hdtivo to 500GB this weekend and my reserved space is now enormous.

IDB_MFS_TOTMEDIA: 973090816
IDB_MFS_AVAILMEDIA: 410978304
IDB_MFS_TOTCLIPS: 64554540
IDB_MFS_AVAILCLIPS: 29776428


I did the yellow star tivoapp patch, nosc.tcl and the rubbish routine and I still have Used Reserved Space of 33702 MB

I hope you guys have some success with this as I would really like to reclaim some of this reserved space for additional recording time.

[Jamie]

I did the yellow star tivoapp patch, nosc.tcl and the rubbish routine and I still have Used Reserved Space of 33702 MBCan you elaborate what you mean by the "rubbish routine"? Did you rubbish the Active disk configuration object, but it didn't have an effect?

[nams]

Can you elaborate what you mean by the "rubbish routine"? Did you rubbish the Active disk configuration object, but it didn't have an effect?

Sorry this is what I did

tivosh
MfsRubbishTree /Showcase
MfsRubbishTree /ShowcaseIndex
MfsRubbishTree /ShowcaseIndex.temp
MfsRubbishTree /Clips

from this post...

http://www.dealdatabase.com/forum/showpost.php?p=200793&postcount=3

[hayreass]

Sorry this is what I did

tivosh
MfsRubbishTree /Showcase
MfsRubbishTree /ShowcaseIndex
MfsRubbishTree /ShowcaseIndex.temp
MfsRubbishTree /Clips

from this post...

http://www.dealdatabase.com/forum/showpost.php?p=200793&postcount=3

I posted the stuff in that link while trying to get rid of showcases and clip lineup from my menu in 4.0.1b
I hope I didn't imply that it would free up reserved space.
I was just trying to clear up some menu entries, not get more space for recordings.

[nams]

I posted the stuff in that link while trying to get rid of showcases and clip lineup from my menu in 4.0.1b
I hope I didn't imply that it would free up reserved space.
I was just trying to clear up some menu entries, not get more space for recordings.

I wanted to get rid of the showcase menu also but was hoping that it would take care of the 33GB of Clips too.

[hayreass]

I wanted to get rid of the showcase menu also but was hoping that it would take care of the 33GB of Clips too.
Damn, no wonder you want to free up that space.
33 gigs is quite a bit.

[nams]

Damn, no wonder you want to free up that space.
33 gigs is quite a bit.

It’s even worse that that… Tivo reserve 63GB in total

IDB_MFS_TOTCLIPS: 64554540

[nams]

I have a working backup image of my Tivo before the upgrade to 500GB and I backed up all my recordings last night... I would be willing to try some more drastic measures (even at the risk of reverting to the backup image if I hose my settings) to reclaim this space if anyone have any good ideas,

[Jamie]

I have a working backup image of my Tivo before the upgrade to 500GB and I backed up all my recordings last night... I would be willing to try some more drastic measures (even at the risk of reverting to the backup image if I hose my settings) to reclaim this space if anyone have any good ideas,I'd suggest you try RubbishObjectByFsid on the /Config/DiskConfigurations/Active object and see what happens. That will still leave a 10GB allocation for TiVo clips, if it falls back to the table built into tivoapp. You can follow the steps outlined here (http://www.dealdatabase.com/forum/showthread.php?p=188230#post188230).

[ronnythunder]

I'd suggest you try RubbishObjectByFsid on the /Config/DiskConfigurations/Active object and see what happens. That will still leave a 10GB allocation for TiVo clips, if it falls back to the table built into tivoapp. You can follow the steps outlined here (http://www.dealdatabase.com/forum/showthread.php?p=188230#post188230).
either that, or create/modify the object as i outlined in an earlier post. i'm still not convinced that the tivoapp table is used if the total size falls into the "xxx and up" table entry (last one in the table).

however, try it out for us and let us know :)

ronny

[nams]

either that, or create/modify the object as i outlined in an earlier post. i'm still not convinced that the tivoapp table is used if the total size falls into the "xxx and up" table entry (last one in the table).

however, try it out for us and let us know :)

ronny

Do you mean the sd_h400_unlock script?

[nams]

I'd suggest you try RubbishObjectByFsid on the /Config/DiskConfigurations/Active object and see what happens. That will still leave a 10GB allocation for TiVo clips, if it falls back to the table built into tivoapp. You can follow the steps outlined here (http://www.dealdatabase.com/forum/showthread.php?p=188230#post188230).


will try that after I modify the DiskConfiguration

[nams]

So I got some test results but I did not test this with my live system... Instead I used my friend unsub HR10-250 that had a recent clear and delete everything.

Before I started:

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 994304
IDB_MFS_TOTMEDIA: 484702208
IDB_MFS_AVAILMEDIA: 167057408
IDB_MFS_TOTCLIPS: 32351104
IDB_MFS_AVAILCLIPS: 32083840
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Using sd-h400_unlock I set TivoClips to 9000000 KB
sd-h400_unlock -c 9000000 -w /dev/hda
After a reboot and a failed test call:

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 994304
IDB_MFS_TOTMEDIA: 484702208
IDB_MFS_AVAILMEDIA: 167057408
IDB_MFS_TOTCLIPS: 9000000
IDB_MFS_AVAILCLIPS: 8732736
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

I then decided to try Jamie suggestion and try RubbishObjectByFsid on the /Config/DiskConfigurations/Active object
/tvbin/tivosh
% mls /Config/DiskConfigurations
Directory of /Config/DiskConfigurations starting at ''

Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----
250GigPhoenix tyDb 3630 03/03/04 21:46 280
Active tyDb 3630 03/03/04 21:46 280

% RubbishObjectByFsId 3630
0
% mls /Config/DiskConfigurations
Directory of /Config/DiskConfigurations starting at ''

Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----

% reboot

After a reboot and a failed test call:

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 994304
IDB_MFS_TOTMEDIA: 484702208
IDB_MFS_AVAILMEDIA: 167057408
IDB_MFS_TOTCLIPS: 10000000
IDB_MFS_AVAILCLIPS: 9732736
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

So it seems like both option works but I could not test if I can fill up the Tivo with recording to 10GB less than TOTMEDIA... this weekend (if I can spare the time) I will restore my backup image on a 250GB drive change my settings and proceed to fill up the Tivo with HD recordings.

[ryan94z]

either that, or create/modify the object as i outlined in an earlier post. i'm still not convinced that the tivoapp table is used if the total size falls into the "xxx and up" table entry (last one in the table).


I'm willing to bet that the modified object will be obeyed provided the space hasn't already been filled. This of course doesn't help those who already have 20GB or more of clips already stored.

My replacement HR10-250 should arrive on Friday. I think I'll pick up a 300GB drive, add it to the stock 250GB and start from scratch. At the same time I'll modify the diskconfiguration object and see if it'll be obeyed. In my opinion the 10GB allocated to the clips in the tivoapp table is still too much, so I deleting the object completly isn't a sound solution. I really hope this works.

[ryan94z]

So it seems like both option works but I could not test if I can fill up the Tivo with recording to 10GB less than TOTMEDIA... this weekend (if I can spare the time) I will restore my backup image on a 250GB drive change my settings and proceed to fill up the Tivo with HD recordings.

I would also be interested to see how low you could set TOTCLIPS to before you notice ill effects. 1GB? 500MB? 100MB?

[nams]

I'm willing to bet that the modified object will be obeyed provided the space hasn't already been filled. This of course doesn't help those who already have 20GB or more of clips already stored.

My replacement HR10-250 should arrive on Friday. I think I'll pick up a 300GB drive, add it to the stock 250GB and start from scratch. At the same time I'll modify the diskconfiguration object and see if it'll be obeyed. In my opinion the 10GB allocated to the clips in the tivoapp table is still too much, so I deleting the object completly isn't a sound solution. I really hope this works.

I will go ahead and try to use mfs_ftp to fill the drive up overnight.

[Jamie]

Using sd-h400_unlock I set TivoClips to 9000000 KB
Good to see some more results.

Note that sd-h400_unlock does not change MinDiskSize and MaxDiskSize in the DiskConfiguration object. That didn't seem to matter with 5.1.1b, but it might with other software versions, based on other data in this thread.

It's easy to change the program to set those too. Or you can create a new DiskConfiguration and make it the Active one in tivosh as Ronny did.

[nams]

Is there a way to copy a recording in mfs? I am trying to take a single recording and make multiple copies so I can fill up the Tivo user space?

[rc3105]

http://www.dealdatabase.com/forum/showthread.php?p=121400&highlight=fill#post121400

[nams]

Thanks Riley

[ronnythunder]

Note that sd-h400_unlock does not change MinDiskSize and MaxDiskSize in the DiskConfiguration object. That didn't seem to matter with 5.1.1b, but it might with other software versions, based on other data in this thread.i suppose that makes sense; if there's an active object, maybe it would be used regardless of size. however, it doesn't seem to explain my hdvr2 which obviously disobeyed both the diskconfigurations and the tivoapp table at some point.

it may also be worth nothing that my nearly 23gb clips space (and what's left of it now) is all listed as "expired", suggesting that, at one time, it was all used. maybe this is why my space isn't getting released?

ronny

[Jamie]

it may also be worth nothing that my nearly 23gb clips space (and what's left of it now) is all listed as "expired", suggesting that, at one time, it was all used. maybe this is why my space isn't getting released?Have you used Riley's trick to full up the user space allocation? If all the data in the clips allocation is expired, it might get purged when something else comes along that wants the space.

[ronnythunder]

:) this tivo has been "slap-a$$" full on a daily basis for over a year.

good thought, though :)

ronny

[nams]

http://www.dealdatabase.com/forum/showthread.php?p=121400&highlight=fill#post121400

I used TyFileSplit.exe instead of tysplit on my windows box but when I upload the chunk mfs_ftp reports the size of 0 (zero)

[nams]

I used TyFileSplit.exe instead of tysplit on my windows box but when I upload the chunk mfs_ftp reports the size of 0 (zero)

Okay I got this working now, but it's still taking some time... I think the Tivo is under too much load to allocate mfs space so after 10 files or so the session start to time out.

[nams]

Well I run into another stone wall... I manage to upload 180870 MB total (most of it using Riley msf_ftp trick) but can’t seems to upload beyond that and since this box is not subscribed I can't do any real recordings. I am not sure what the problem is... as soon as I try to upload more my ftp session gets disconnected. :confused:

If I get the time this weekend I will try to use my subbed hdtivo backup image and try this again... I am hoping I don’t have to test with my subbed box and someone can come up with a way to record OTA with my friends’ unsubbed box that I am using to test.

By the way since I made the change System Information shows:

Recording Capacity: Variable, up to 35 HD or 234 SD hours

[ronnythunder]

pretty sure you won't be able to record with an unsubbed box. in such a state, the "dvr service" is disabled, so it won't even allow you to record ota.

as for the mfs_ftp sessions timing out, i assume you did try restarting mfs_ftp, right? did anything show up in the mfs_ftp.log that might point to a problem?

ronny

[ronnythunder]

holy cow!!!!!!!

today was a big day! sometime early this morning, my hdvr2 started doing something:Jan 6 09:54:49 (none) Recorder[213]: Live cache size 2097152
Jan 6 09:54:49 (none) Recorder[213]: Live cache size 786432
Jan 6 09:54:49 (none) Recorder[213]: Recording Id 2032839 size 0
Jan 6 09:54:49 (none) Recorder[213]: User recording 239428608 free 19877248
Jan 6 09:54:49 (none) Recorder[213]: TivoClip total 266240 free -19810304
Jan 6 09:54:49 (none) Recorder[213]: DeleteSomething fUserSaidOk=1
Jan 6 09:54:49 (none) Recorder[213]: allocate: 12:00000000:41dd0af4 rec 2032839
Jan 6 09:54:49 (none) Recorder[213]: live cache: 17:00000000:00000000
Jan 6 09:55:12 (none) Recorder[213]: candidate: 10:00000000:41679fa8 1731742
Jan 6 09:55:12 (none) Recorder[213]: deleting rec 1731742
Jan 6 09:55:12 (none) Recorder[213]: Abr--Now: rec 1731742this message block repeated a few dozen times over the course of about 30 minutes, and each time, a big chunk of that -19gb clips free space went away, until it was down to the allocation of 266mb that i set in the diskconfigurations object!!!

i'm so thrilled; that, coupled with some old shows that i extracted, have me up to over 50gb free on this machine.

i think i'm going to have to try it on my loaned hd tivo, also.

death to excessive tivo clips space! :)

ronny

[ryan94z]

Ronny,

That's great! Any idea, based on your logs, how to force the tivo to give up the space?

[ronnythunder]

ryan, nothing in any of the logs suggests anything key about that time.

ronny

[nams]

pretty sure you won't be able to record with an unsubbed box. in such a state, the "dvr service" is disabled, so it won't even allow you to record ota.

as for the mfs_ftp sessions timing out, i assume you did try restarting mfs_ftp, right? did anything show up in the mfs_ftp.log that might point to a problem?

ronny


Restarted mfs_ftp and the box several times... tried different versions of mfs_ftp and different ftp clients... same results.

bash-2.02# tail -f port.3105.log
11:57:38:PM - 250 Directory change successful.
11:57:38:PM - 257 "/ty" is current directory.
11:57:38:PM - 227 Entering Passive Mode (192,168,168,149,12,32).
11:57:38:PM - 150 Opening ASCII mode data connection for file list.
11:57:45:PM - updating cached recording info
.................................................................................................... .................................................................................................... .................................................................................................... ...........

.................................................................................................... .................................................................................................... .................................................................................................... ...........

11:57:59:PM - 226 Transfer complete.
11:58:20:PM - 200 Type set to I
11:58:20:PM - 502 Command not implemented "SIZE ste512.ty"
11:58:20:PM - 227 Entering Passive Mode (192,168,168,149,12,32).
bgerror invoked with error

" commit failed (0x70009)
"

re-initializing mfs_ftp

close the current ftp connection and simply open another

"core dump" :p

info(version): 1.2.9p-Jamie
info(tswv): 3.1.5-01-2-357
info(dbl): 0
info(ithrottle): 2
info(insert_priority): 10
info(multithreaded): 0
info(saveuntil): suggestion
info(name_detail): 5
info(bjuggle): 0
info(active): 0
info(ac_interval): 1800
info(gatewayip): 127.0.0.1
info(gatewayport): 3105


catch close lastsock val ""
11:58:31:PM - 220 Mfs_Ftp ver 1.2.9p-Jamie - {sock18} from "192.168.168.25:38400"
11:58:31:PM - 331 User name okay, need password.
11:58:31:PM - 230 Running in TiVo Mode.
11:58:31:PM - 215 UNIX
11:58:31:PM - 350 Restart okay, awaiting file request.
11:58:31:PM - 350 Restart okay, awaiting file request.
11:58:31:PM - 257 "/" is current directory.
11:58:31:PM - 250 Directory change successful.
11:58:31:PM - 257 "/ty" is current directory.
11:58:31:PM - 200 Type set to I
11:58:31:PM - 502 Command not implemented "SIZE ste512.ty"
11:58:31:PM - 227 Entering Passive Mode (192,168,168,149,12,32).
bgerror invoked with error

" commit failed (0x70009)
"

re-initializing mfs_ftp

close the current ftp connection and simply open another

"core dump" :p

info(version): 1.2.9p-Jamie
info(tswv): 3.1.5-01-2-357
info(dbl): 0
info(ithrottle): 2
info(insert_priority): 10
info(multithreaded): 0
info(saveuntil): suggestion
info(name_detail): 5
info(bjuggle): 0
info(active): 0
info(ac_interval): 1800
info(gatewayip): 127.0.0.1
info(gatewayport): 3105


catch close lastsock val ""

07:35:17:PM - 220 Mfs_Ftp ver 1.2.9p - {sock18} from "192.168.168.75:1070"
07:35:17:PM - 331 User name okay, need password.
07:35:17:PM - 230 Running in TiVo Mode.
07:35:17:PM - 215 UNIX
07:35:17:PM - 350 Restart okay, awaiting file request.
07:35:17:PM - 350 Restart okay, awaiting file request.
07:35:18:PM - 250 Directory change successful.
07:35:18:PM - 257 "/ty" is current directory.
07:35:22:PM - 200 Type set to I
07:35:22:PM - 502 Command not implemented "SIZE {Alias}{2005-01-05}{Authorized Personnel Only}{09.01 PM Wed Jan 05, 2005}{ABCE}.ty"
07:35:24:PM - 227 Entering Passive Mode (192,168,168,149,12,32).
bgerror invoked with error

" commit failed (0x70009)
"

re-initializing mfs_ftp

close the current ftp connection and simply open another

"core dump" :p

info(version): 1.2.9p
info(tswv): 3.1.5-01-2-357
info(dbl): 0
info(ithrottle): 2
info(insert_priority): 10
info(multithreaded): 0
info(saveuntil): suggestion
info(name_detail): 5
info(bjuggle): 0
info(active): 0
info(ac_interval): 1800
info(gatewayip): 127.0.0.1
info(gatewayport): 3105


catch close lastsock val ""

[nams]

http://www.dealdatabase.com/forum/showthread.php?p=121400&highlight=fill#post121400

Thanks again

[nams]

I end up changing my TivoClips setting to 9GB last night, undelete all previously deleted recordings available and uploaded about 100GB of "fake recording" with mfs_ftp. I have been recording all HD content on both tuners since about midnight to fill up my 500GB.

Unfortunately when the Tivo run out of space for new recording it just purge previous recordings to create more space (all my recording was set to Save until I delete) instead of deleting the expired TivoClips.

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 839184
IDB_MFS_TOTMEDIA: 973090816
IDB_MFS_AVAILMEDIA: 23359488
IDB_MFS_TOTCLIPS: 32554540
IDB_MFS_AVAILCLIPS: -3165652
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

I sure hope someone smarter than me figures out how to purge Tivo Clips from reserved space.

[ronnythunder]

nams, something isn't taking. your totclips is still >32gb, and it's never going to get smaller than that number. what did you end up doing with the diskconfigurations object? did you rubbish it, or did you change the allocations in it?

either way, it's still reserving 32gb. note that, on my hdvr2 with the 250gb drive, the totclips dropped to my target of 266mb immediately; it was the availclips that was slow to work itself out.

what does the tivoweb info screen say?

ronny

[nams]

nams, something isn't taking. your totclips is still >32gb, and it's never going to get smaller than that number. what did you end up doing with the diskconfigurations object? did you rubbish it, or did you change the allocations in it?

either way, it's still reserving 32gb. note that, on my hdvr2 with the 250gb drive, the totclips dropped to my target of 266mb immediately; it was the availclips that was slow to work itself out.

what does the tivoweb info screen say?

ronny

I notice that too... I don't know if that have to do with the fact that this is a dual drive system.

AVAILCLIPS is showing -3165652 but TOTCLIPS dropped from 64554540 to 32554540

[ronnythunder]

i don't think the dual drive has anything to do with it, but i guess anything is possible. you didn't say what you did with the diskconfigurations object, though... :)

ronny

[nams]

i don't think the dual drive has anything to do with it, but i guess anything is possible. you didn't say what you did with the diskconfigurations object, though... :)

ronny

I just edited it with the sd-h400_unlock utility... I did not want to “rubbish” it since I don’t know how to recreate it.

[ronnythunder]

can you do a "dumpobj -depth 2" on the fsid for the object? you can do "mls /Config/DiskConfigurations" to see the fsid; you want the "ACTIVE" one. i'd be interested to see what it says.

ronny

[nams]

can you do a "dumpobj -depth 2" on the fsid for the object? you can do "mls /Config/DiskConfigurations" to see the fsid; you want the "ACTIVE" one. i'd be interested to see what it says.

ronny

what package do I need to install to get the dumpobj utility?

[Jamie]

what package do I need to install to get the dumpobj utility?These are built in commands in tivosh. Run tivosh and you'll get a % prompt where you can type tivosh commands like mls /Config/DiskConfigurations and dumpobj -level 2 FSID.

Here's my theory on when the overallocation of TivoClips gets purged: only when a new TivoClip comes done the pike and needs to be stored. There's no reason the tivo software needs to do garbage collection on the TiVoClips allocation any other time: it wasn't written with the intention that the clip allocation would ever be reduced.

[nams]

These are built in commands in tivosh. Run tivosh and you'll get a % prompt where you can type tivosh commands like mls /Config/DiskConfigurations and dumpobj -level 2 FSID.

Here's my theory on when the overallocation of TivoClips gets purged: only when a new TivoClip comes done the pike and needs to be stored. There's no reason the tivo software needs to do garbage collection on the TiVoClips allocation any other time: it wasn't written with the intention that the clip allocation would ever be reduced.

Sounds like a good theory...

I end up deleting the DiskConfigurations object and now my TOTCLIPS defaults to 10GB

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 848672
IDB_MFS_TOTMEDIA: 973090816
IDB_MFS_AVAILMEDIA: 62156800
IDB_MFS_TOTCLIPS: 10000000
IDB_MFS_AVAILCLIPS: -25720192
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

[ronnythunder]

ok, so that's the tivoapp table's default (10gb). still a little large, imho :) however, it's a darn sight better than 64gb or whatever.

jamie, i hadn't thought about it that way, but you may indeed be correct on the clips gc. the time that all the fun started happening on my box would have been the time a clip was coming down.

ronny

[ryan94z]

I have my HR10-250 back and I was ready to try setting the TivoClips to 100MB or so, but I've noticed that I don't have a /tmp/HServer.send file to see how much is allocated to TivoClips. I though it might need download the service data first, but that happened at 2:00AM last night and didn't resolve the problem. My DiskConfiguration object looks exactly same as the one i posted at the beginnng of this thread. I see the following line in my /var/log/tvlog


Jan 8 18:03:57 (none) Recorder[219]: TivoClip total 32351104 free 32083840


So I assume that the same 32GB is allocated to clips as before. I haven't done a daily call yet because I don't have a phone line to it. Does anyone know if that might trigger it to get created? I need to get 3.1.5e, so I'll probably hook the phone line up today and see what happens.

[ronnythunder]

ryan, the call doesn't have to succeed. just try a daily call, and the file is created before the line is even picked up.

as you said, though, it seems that you have 32gb of clips.

ronny

[mbellot]

Great thread, I would like to know if its possible to do something like this for my S1SA.

A quick check of HServer.send shows I currently have 10GB allocated, but less than 250MB actually used.

Since the unit is currently unsubbed (so unlikely to get new clips), it sure would be nice to reclaim 9GB of storage and use it for manual recordings...

However, if I am following this thread and several others like it, I think my problem might be difficult to solve.

If I run "mls /Config/DiskConfigurations" from inside tivosh I get an error message "can't scan path (errNmNameNotFound)", which leads me to believe the entry does not exist (duh!).

It seems that there is no way to insert this object, only modify it if it already exists, correct? If so then I think I'm screwed unless I can directly patch the tivoapp executable (not exactly my idea of fun).

Can anyone confirm my thoughts?

[Jamie]

It seems that there is no way to insert this object, only modify it if it already exists, correct? If so then I think I'm screwed unless I can directly patch the tivoapp executable (not exactly my idea of fun).I believe it can be created via tivosh. Ronny can probably fill in the details. It's not clear that the software running on a S1 will pay any attention to it though. Patching tivoapp might be more likely to pay off.

[mbellot]

I believe it can be created via tivosh. Ronny can probably fill in the details. It's not clear that the software running on a S1 will pay any attention to it though. Patching tivoapp might be more likely to pay off.

OK, I got brave (or stupid, you make the call). :eek:

I ftp'd tivoapp over to the PC and following the table from alt.org I modified my MaxClips value from 00989680 (10GB) to 00080000 (512MB).

Sent it back and rebooted and it appears we have success, but with some oddities.

My recording time went from 312 hours to 325 hours (very nice), but now when I look in the /tmp/HServer.send file most of the actual values are missing (this is after a test call).

Before I had
IDB_MFS_TOTAPP: 785136
IDB_MFS_AVAILAPP: 728296
IDB_MFS_TOTMEDIA: 487763968
IDB_MFS_AVAILMEDIA: 291166208
IDB_MFS_TOTCLIPS: 10000000
IDB_MFS_AVAILCLIPS: 9782912
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Now it shows
IDB_MFS_TOTAPP:
IDB_MFS_AVAILAPP:
IDB_MFS_TOTMEDIA:
IDB_MFS_AVAILMEDIA:
IDB_MFS_TOTCLIPS:
IDB_MFS_AVAILCLIPS:
IDB_MFS_TOTRBACKS:
IDB_MFS_AVAILRBACKS:

I saved the original tivoapp, so just to be sure its not the patch I swapped tivoapp's around and rebooted. It still shows blank values...

Any ideas? Any chance this might clear up if I force a "real" call even though the unit is not subbed?

It does appear to be working OK, its just a bit bothersome that everything went blank.

Thanks again.

[ronnythunder]

mbellot, can you snarf a copy of your tivoapp from the box and see if it has the string "DiskConfiguations" in it? here's what i did:# strings tivoapp | grep DiskConf
ProgramSourceDiskConflict
DbDiskSpaceAllocation::FindActiveDiskConfiguration
DiskConfiguration
/Config/DiskConfigurations
/Config/DiskConfigurations/Activethis is on a series 2 tivoapp of some flavor (a quick suggests a 3.1.5d hd tivo version), but if your series 1 is going to honor the object, i'm almost certain that you'll get a hit in tivoapp for it.

either way, i'd agree with jamie that you should focus on the tivoapp table. i'd change all of the entries to the contents of the smallest config; this will yield a clips space of 266mb. i'm loathe to go lower than that, because that's the smallest a factory tivo would come with, and there may be functionality that depends on at least that much.

ronny

[mbellot]

mbellot, can you snarf a copy of your tivoapp from the box and see if it has the string "DiskConfiguations" in it? here's what i did:# strings tivoapp | grep DiskConf
ProgramSourceDiskConflict
DbDiskSpaceAllocation::FindActiveDiskConfiguration
DiskConfiguration
/Config/DiskConfigurations
/Config/DiskConfigurations/Activethis is on a series 2 tivoapp of some flavor (a quick suggests a 3.1.5d hd tivo version), but if your series 1 is going to honor the object, i'm almost certain that you'll get a hit in tivoapp for it.

either way, i'd agree with jamie that you should focus on the tivoapp table. i'd change all of the entries to the contents of the smallest config; this will yield a clips space of 266mb. i'm loathe to go lower than that, because that's the smallest a factory tivo would come with, and there may be functionality that depends on at least that much.

ronny

I don't have strings on the TiVo, so I did a quick search of the file on the PC for "DiskConf".

I found

ProgramSourceDiskConflict
DbDiskSpaceAllocation::FindActiveDiskConfiguration
DiskConfiguration
/Config/DiskConfigurations
/Config/DiskConfigurations/Active


Do you think this means it will check for those database entries before using the tivoapp table?

Patching tivoapp does seem to have worked, I'm just perturbed by the HServer.send file (see previous message).

Thanks

[ronnythunder]

i was actually talking about the s1 tivoapp; was that what you were talking about?

as for the blank values, i think forcing another call will fill those in. i encountered this today when i was experimenting with finding the largest mfs partition size (that thread is in the newbie forum); a second forced call fixed it.

ronny

[nams]

i was actually talking about the s1 tivoapp; was that what you were talking about?

as for the blank values, i think forcing another call will fill those in. i encountered this today when i was experimenting with finding the largest mfs partition size (that thread is in the newbie forum); a second forced call fixed it.

ronny

And the call doesn’t have to succeed… just make sure you wait until the call fails.

[nams]

I believe it can be created via tivosh. Ronny can probably fill in the details. It's not clear that the software running on a S1 will pay any attention to it though. Patching tivoapp might be more likely to pay off.

I would like information on recreating this object if it’s possible.

If I can't do that or get it to work properly then I will try to find the offset to patch my tivoapp to lower the clips allocation to 1GB or so.

[mbellot]

i was actually talking about the s1 tivoapp; was that what you were talking about?

as for the blank values, i think forcing another call will fill those in. i encountered this today when i was experimenting with finding the largest mfs partition size (that thread is in the newbie forum); a second forced call fixed it.

ronny

Ronny, yes I was referring to the tivoapp from my S1. I copied (ftp) it to my Windoze PC to do the hex editing. Since I didn't have strings on my tivo I just used my Windoze hex editor to search for them.

Also, I found the problem with the HServer.send file.

I was forcing test calls, not daily calls. Forcing a daily call did indeed fill out the information. It must have something to do with housekeeping...

IDB_MFS_TOTAPP: 785136
IDB_MFS_AVAILAPP: 709584
IDB_MFS_TOTMEDIA: 487763968
IDB_MFS_AVAILMEDIA: 291166208
IDB_MFS_TOTCLIPS: 524288
IDB_MFS_AVAILCLIPS: 307200
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

I have 512 MB of clip space now and just over 300MB unused.

I think I can live with that kind of wasted space on a 250GB drive.

Thanks again guys, this is real sweet.

[ryan94z]

Ok, a good day. Forcing the daily call created the HServer.send file like you said ronny. I checked it and found that I did have the 30GB+ allocated for TivoClips. I ran

sd-h400_unlock -c 204800 -w

to set the clips object at 200MB, then rebooted.

I wanted to make sure that the tivo would write beyond 210,000,000KB, so I used Riley's suggestion to copy the first part of a ty file generated with TySplit to the drive repatedly to quickly fill up 512MB at a time. After 255 objects where in my Now playing list, mfs_ftp wasn't able to transfer or list the files (through searching I found that other people have seen this, so I assume it's a known error). This method filled up half the drive, so I set both tuners to the highest bandwidth channels (DicoveryHD and HDNet) and begain taping for 6-7 hours each.

filled it up past 90% of the drive, did a daily call and looked at the Hserver.send:


IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 834600
IDB_MFS_TOTMEDIA: 484702208
IDB_MFS_AVAILMEDIA: 116736
IDB_MFS_TOTCLIPS: 204800
IDB_MFS_AVAILCLIPS: -62464
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0


Everything looks good. I didn't run into any problem, it was as simple as using the sd-h400_unlock utility. I'll update when another ad is scheduled to record and see if the clips get purged.

I wonder how easy it would be to add Jaime's code to mfs tools to modify the active object when doing a restore of a backup image?

[alldeadhomiez]

I used the same technique as mbellot to patch the allocation table on 4.0 to reduce my clip size from ~5GB to 256MB on a DTiVo:

offset da66c0: 00989680 -> 00080000

I also deactivated the active DiskConfiguration object by hand.

During the next call attempt, IDB_MFS_AVAILCLIPS showed about -10M sectors. I then rubbished /Clips, /Showcase, and /MenuItem. /Clips took a while to delete and apparently contained dozens of videos; it had advertisements dating back to at least August of 2004.

Currently, IDB_MFS_AVAILCLIPS still shows a large negative value, but based on the amount of crap removed from /Clips, I expect that to become positive next time the GC runs.

Edit 2005/01/10:

I forced garbage collection with the command Riley posted. It churned for a while but that didn't affect IDB_MFS_AVAILCLIPS reported when forcing a call. I also saw it recording a suggestion yesterday, which it had not done since I filled the drive several months ago.

~18 hours after the initial patch, everything has been cleaned up:

IDB_MFS_TOTCLIPS: 524288
IDB_MFS_AVAILCLIPS: 88064

The space wasted by the clips was returned to IDB_MFS_AVAILMEDIA.

[nams]

Looks like the next Teleworld program is scheduled for next Thursday:


Thu 1/20 4:02 am DSC Teleworld Paid Program
Thu 1/20 4:22 am DSC Teleworld Paid Program

I am hoping that my AVAILCLIPS drops to a positive number or at least zero instead of the negative number I have now.

[ryan94z]

I don't seem to have that scheduled to record. This is on your HR10-250, correct?

[nams]

I don't seem to have that scheduled to record. This is on your HR10-250, correct?

This is scheduled to record on all my Tivos (SD & HD).

[nams]

This is scheduled to record on all my Tivos (SD & HD).

Actually one of my SD Tivo have this scheduled for this Thursday too... is there a way to copy the schedule information from the sd Tivo to the hd Tivo?

[Jamie]

I would like information on recreating this object if it’s possible.
Here's a couple of little tivosh scripts I wrote to manipulate the Active DiskConfiguration object. One simply deactivates it. That's easier to reverse than rubbishing it. The other deactivates the current DiskConfiguration and sets up a new "Frugal" one and makes it active. I've verified that tivoapp in 4.0.1b, 5.1.1b and 7.1 all seem to honor the Active DiskConfiguration object. I'm not sure about the 3.X family.

These are intended as boilerplate sample code rather than finished products. I believe they work, but YMMV. I'd suggest you try to read and understand them rather than just using them as black box scripts.

I'm new to tivosh/tcl, so I may not be doing these the best possible way. Feel free to critique.

[ronnythunder]

jamie, i can confirm that at least 3.1.1c and up obey the diskconfigurations object.

ronny

[ryan94z]

I can confirm that 3.1.5 obeys the diskcoinfiguration object, although I haven't tested your new tivosh scripts, I used your sd-400_unlock utility to set the object's values.

[mbellot]

Does not seem to work for 3.0 - oh well...


bash-2.02# ./mkDiskConfig.tcl
No Active DiskConfiguration to deactivate
Created object /Config/DiskConfigurations/Frugal
Filling in User DiskPartition sub object
Filling in TivoClips DiskPartition sub object
Creation failed: can't read "DiskPartitionId::TivoClips": no such variable
Finished.

[Jamie]

Does not seem to work for 3.0 - oh well...
I can probably fix that. I liberally used facilities I found in the tcl libraries in /tvlib. The oldest version I have is 4.0.1b, so I'm not sure what might have been new in that release and not in the 3.X versions.

Could you check to see if /tvlib/tcl/tv/DbEnum.tcl exists in your software version? If so, grep it for DiskPartition and see if you get any hits. If you do, I'm interested in the section bracketed below "namespace eval DiskPartitionId".

If I have to I can just hardcode those Id values (User is 10; TivoClips is 11).

{edit: try the attached version with the DiskPartitionId's hardcoded.}

[nams]

I can probably fix that. I liberally used facilities I found in the tcl libraries in /tvlib. The oldest version I have is 4.0.1b, so I'm not sure what might have been new in that release and not in the 3.X versions.

Could you check to see if /tvlib/tcl/tv/DbEnum.tcl exists in your software version? If so, grep it for DiskPartition and see if you get any hits. If you do, I'm interested in the section bracketed below "namespace eval DiskPartitionId".

If I have to I can just hardcode those Id values (User is 10; TivoClips is 11).

{edit: try the attached version with the DiskPartitionId's hardcoded.}


# Enumerated type: DiskPartitionId
#

namespace eval DiskPartitionId {
variable ReplaceableBG 12
variable TestPartition0 0
variable TestPartition1 1
variable TestPartition2 2
variable TestPartition3 3
variable TestPartition4 4
variable TestPartition5 5
variable TiVoClips 11
variable User 10
}

#
# Enumerated type: DisplayFormat
#

[Jamie]

# Enumerated type: DiskPartitionId
#

namespace eval DiskPartitionId {
...
# Is this from a TiVo software version where the previous script failed? Does the newest one (with the hardcoded DiskPartitionId's) work?

[Montaño]

Simply awesome Jamie !!!! I ran mkDiskConfig.tcl on my DSR7000 running 4.0.1b and I went from 171 hours to 193 hours on a 200GB drive !!! Free Space went from 59 hours to 78 hours :)

Thanks

Wow!! Ran it on my 250GB SD-DVR80 and went from 216 hours to 243 hours !!

[nams]

Is this from a TiVo software version where the previous script failed? Does the newest one (with the hardcoded DiskPartitionId's) work?

I never tried the previous scrip... but I just ran the hard coded script on my HR10-250 and it works perfectly.

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 843120
IDB_MFS_TOTMEDIA: 973090816
IDB_MFS_AVAILMEDIA: 25675776
IDB_MFS_TOTCLIPS: 500000
IDB_MFS_AVAILCLIPS: -34433760
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

I had previously rubbish my disk configuration.

% mls /Config/DiskConfigurations
Directory of /Config/DiskConfigurations starting at ''

Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----
Active tyDb 472072 01/12/05 03:21 224
Frugal tyDb 472072 01/12/05 03:21 224

My 500GB hdtivo now reports up to 73 HD or 490 SD hours.

Thanks Jamie!

[ronnythunder]

ah, now who's going to be the first to have a 100 hour hd machine? sounds like it's going to take a 300gb+400gb config for that. :eek:

ronny

[nams]

seems like my SD directivo running 4.0.1b don't honor the disk configuration.

I tried setting it to 500000KB with the sd-h400_unlock utility but this is my results after a reboot:

IDB_MFS_TOTAPP: 1047248
IDB_MFS_AVAILAPP: 825784
IDB_MFS_TOTMEDIA: 156919808
IDB_MFS_AVAILMEDIA: 8417280
IDB_MFS_TOTCLIPS: 4475990
IDB_MFS_AVAILCLIPS: -2600874
IDB_MFS_TOTRBACKS: 102400
IDB_MFS_AVAILRBACKS: 102400

[nams]

ah, now who's going to be the first to have a 100 hour hd machine? sounds like it's going to take a 300gb+400gb config for that. :eek:

ronny
I would love to have one of that... but 73 hours is fine for now.

[Jamie]

seems like my SD directivo running 4.0.1b don't honor the disk configuration.
...

Try the tcl script. The sd-h400_unlock utility doesn't modify MinDiskSize and MaxDiskSize, which might be an issue with 4.0.1 when the DiskConfiguration is applied to a disk that's outside the bounds.

[nams]

Try the tcl script. The sd-h400_unlock utility doesn't modify MinDiskSize and MaxDiskSize, which might be an issue with 4.0.1 when the DiskConfiguration is applied to a disk that's outside the bounds.

The tcl script works perfectly... (I changed the script to 400MB for clips)

IDB_MFS_TOTAPP: 1047248
IDB_MFS_AVAILAPP: 825712
IDB_MFS_TOTMEDIA: 156919808
IDB_MFS_AVAILMEDIA: 7368704
IDB_MFS_TOTCLIPS: 400000
IDB_MFS_AVAILCLIPS: -6676864
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Thanks again.

[mbellot]

I can probably fix that. I liberally used facilities I found in the tcl libraries in /tvlib. The oldest version I have is 4.0.1b, so I'm not sure what might have been new in that release and not in the 3.X versions.

Could you check to see if /tvlib/tcl/tv/DbEnum.tcl exists in your software version? If so, grep it for DiskPartition and see if you get any hits. If you do, I'm interested in the section bracketed below "namespace eval DiskPartitionId".

If I have to I can just hardcode those Id values (User is 10; TivoClips is 11).

{edit: try the attached version with the DiskPartitionId's hardcoded.}

This is from my 3.0 machine where the original script failed.


#
# Enumerated type: DiskPartitionId
#

namespace eval DiskPartitionId {
variable ReplaceableBG 12
variable TestPartition0 0
variable TestPartition1 1
variable TestPartition2 2
variable TestPartition3 3
variable TestPartition4 4
variable TestPartition5 5
variable TiVoClips 11
variable User 10
}


And the new script produces this...


bash-2.02# ./mkDiskConfigHC.tcl
No Active DiskConfiguration to deactivate
Created object /Config/DiskConfigurations/Frugal
Filling in User DiskPartition sub object
Filling in TivoClips DiskPartition sub object
Filling in /Config/DiskConfigurations/Frugal DiskConfiguration object
Finished.


A quick reboot and (failed) daily call reveals that 3.0 also honors the DiskConfigurations database entries (woo-hoo!!!) - I am now down to 300MB for clips (after a quick edit to your second script), with a fallback to 512MB hacked into tivoapp directly in case something happens to the DiskConfig settings.

Awesome work.

[nams]

Jamie this is going the hottest hack since 4.x on RID.

[Jamie]

This is from my 3.0 machine where the original script failed.variable TiVoClips 11Sigh. 4.0.1b spells this TivoClips and tcl is case sensitive. I now see that the earlier posted version was like that too. The hardcoded version of the script should be fine.

[nams]

A quick reboot and (failed) daily call reveals that 3.0 also honors the DiskConfigurations database entries (woo-hoo!!!) - I am now down to 300MB for clips (after a quick edit to your second script), with a fallback to 512MB hacked into tivoapp directly in case something happens to the DiskConfig settings.

Awesome work.


Where can I find the patch settings for 4.01b and 3.1.5e? I want to hard code mine too as added insurance.

[AhoyMatey]

Where can I find the patch settings for 4.01b and 3.1.5e? I want to hard code mine too as added insurance.
Haven't implemented this yet, but the offset for 4.0.1b is 0xdac570:
offset dac570: 00989680 -> 00080000

[mbellot]

Where can I find the patch settings for 4.01b and 3.1.5e? I want to hard code mine too as added insurance.

I can't give you exact offsets, but if you follow this thread (http://alt.org/forum/index.php?t=msg&th=82&start=0&rid=307&S=bc3dad9e504b424add0971b3ad17d6ef&SQ=f7aee24c1e98afbd833f23c31510c1b6) it shows you the format of the table.

Its not too hard to find inside tivoapp with a decent hex editor.

Then you just change the last TivoClips value from 00989680 (10GB) to whatever value toots your fancy (I liked 00080000, 512MB) for a fallback.

[nams]

I can't give you exact offsets, but if you follow this thread (http://alt.org/forum/index.php?t=msg&th=82&start=0&rid=307&S=bc3dad9e504b424add0971b3ad17d6ef&SQ=f7aee24c1e98afbd833f23c31510c1b6) it shows you the format of the table.

Its not too hard to find inside tivoapp with a decent hex editor.

Then you just change the last TivoClips value from 00989680 (10GB) to whatever value toots your fancy (I liked 00080000, 512MB) for a fallback.

Thanks will try to figure it out.

[nams]

Well my SD Tivo that had the teleworld program scheduled for this morning went from:

IDB_MFS_TOTAPP: 1047248
IDB_MFS_AVAILAPP: 825712
IDB_MFS_TOTMEDIA: 156919808
IDB_MFS_AVAILMEDIA: 7368704
IDB_MFS_TOTCLIPS: 400000
IDB_MFS_AVAILCLIPS: -6676864
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

to:

IDB_MFS_TOTAPP: 1047248
IDB_MFS_AVAILAPP: 827360
IDB_MFS_TOTMEDIA: 156919808
IDB_MFS_AVAILMEDIA: 16390144
IDB_MFS_TOTCLIPS: 400000
IDB_MFS_AVAILCLIPS: 170624
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

[Montaño]

Just ran the script on a brand new 200GB install on a DSR704 running 4.0.1b. I now have 195 hours of record time! That's awesome :)

Thanks again Jamie !!

[nams]

Here's a couple of little tivosh scripts I wrote to manipulate the Active DiskConfiguration object. One simply deactivates it. That's easier to reverse than rubbishing it. The other deactivates the current DiskConfiguration and sets up a new "Frugal" one and makes it active. I've verified that tivoapp in 4.0.1b, 5.1.1b and 7.1 all seem to honor the Active DiskConfiguration object. I'm not sure about the 3.X family.

These are intended as boilerplate sample code rather than finished products. I believe they work, but YMMV. I'd suggest you try to read and understand them rather than just using them as black box scripts.

I'm new to tivosh/tcl, so I may not be doing these the best possible way. Feel free to critique.

Jamie,

I ran your script to create the Frugal DiskConfigurations and set it active on 3 of my directivo but after a few days the 2 systems with drives grater that 80GB revert to 10GB and my 40GB system revert to 3.7GB

All systems are now missing the DiskConfigurations in mfs.

My hdtivo is running 3.1.5 and my sdtivos are running 4.0.1b

:confused:

[Jamie]

Jamie,

I ran your script to create the Frugal DiskConfigurations and set it active on 3 of my directivo but after a few days the 2 systems with drives grater that 80GB revert to 10GB and my 40GB system revert to 3.7GB

All systems are now missing the DiskConfigurations in mfs.

My hdtivo is running 3.1.5 and my sdtivos are running 4.0.1bInteresting. Mine are gone too. Maybe becuase they don't have a ServerId?

[Jamie]

Interesting. Mine are gone too. Maybe becuase they don't have a ServerId?
Here's a version that includes a ServerId. I "borrowed" the one from an obsolete 14 hour unit. I'm running this version now and will watch carefully to see if this one gets cleared too.

[ronnythunder]

jamie, could you make the script either clone an existing entry, or perhaps copy the serverid from an existing entry to create the "frugal" object? i realize that this wouldn't work with units that didn't have a diskconfigurations object at all, but perhaps on those units, it's best to just rely on the tivoapp patch?

ronny

[Jamie]

jamie, could you make the script either clone an existing entry, or perhaps copy the serverid from an existing entry to create the "frugal" object? i realize that this wouldn't work with units that didn't have a diskconfigurations object at all, but perhaps on those units, it's best to just rely on the tivoapp patch?Let's wait and see what happens with the objects that have a valid ServerId. At least on 4.01b, 5.0.1b, and 7.1, /DataSet/DiskConfigurationVersion/Data is a list of a bunch of FSIDs with DiskConfiguration objects. If the actual FSID number is important, I could modify one of these instead of making a new one.

[Montaño]

Do we need to wait for DiskConfigurations to come back? Trying to run the latest mkDiskConfig.tcl and I get errors.

[Jamie]

Do we need to wait for DiskConfigurations to come back? Trying to run the latest mkDiskConfig.tcl and I get errors.odd. It works fine for me on 4.0.1b on a S2SA. I don't think waiting is going to help.

[Montaño]

I ran the original tcl with out any problems. The error was whe I ran the tcl with the added ServerId.

[Jamie]

I ran the original tcl with out any problems. The error was whe I ran the tcl with the added ServerId.The only thing I can think of is that there is already a /Server/4178100 object and that creating a new object with the same ServerId is causing a conflict.

[nams]

Here's a version that includes a ServerId. I "borrowed" the one from an obsolete 14 hour unit. I'm running this version now and will watch carefully to see if this one gets cleared too.

New script ran fine on all my tivos.

[Jamie]

New script ran fine on all my tivos.Mine still got wiped, even with a valid ServerId. Next thing I plan to try is snagging one from the list in the Data field of /DataSet/DiskConfigurationVersion. I'm not sure if all software versions have that, but all of mine do (4.0.1b, 5.1.1b, 7.1).

[nams]

Mine still got wiped, even with a valid ServerId. Next thing I plan to try is snagging one from the list in the Data field of /DataSet/DiskConfigurationVersion. I'm not sure if all software versions have that, but all of mine do (4.0.1b, 5.1.1b, 7.1).

I can confirm that 3.1.5e has /DataSet/DiskConfigurationVersion too.

[Jamie]

Here's a version of the mkDiskConfig.tcl script that hijacks an existing DiskConfiguration object rather than making a new one. It grabs the first one listed in the Data attribute of /Dataset/DiskConfigurationVersion. I ran this script several days ago on all my machines, and the objects haven't gone away yet. I think this version may also fix the commit error that Montaño saw.

It's clear that I don't have a full understanding of how MFS garbage collection works. All the DiskConfiguration objects on the Data list in /Dataset/DiskConfigurationVersion are marked as rubbish, yet they never go away. It seems like besides having objects marked as rubbish or not, there is some sort of reachability analysis being done, and objects that aren't reachable from certain key MFS paths are purged, rubbish or not. I speculate that a DiskConfiguration object must be in the Data list in /Dataset/DiskConfigurationVersion if it is to be preserved.

[Montaño]

Ran the new script, but I'm not sure if it wokred or not. Can you check for me Jamie?

Thanks

[Jamie]

Ran the new script, but I'm not sure if it wokred or not. Can you check for me Jamie?Yes. That's the expected output. The FSID of the DiskConfiguration object it hijacked is pretty low. Mine are up in the 4-5000 range. If you want to see what's in the active DiskConfiguration, look at /Config/DiskConfigurations/Active either with TW/TWP or with dumpobj in tivosh. You might keep an eye on it to make sure it persists.

[Montaño]

I will keep an eye on it, thanks ;)

[mbellot]

Something must be missing on my SAS1 3.0...


bash-2.02# ./mkDiskConfig_2.tcl
No Active DiskConfiguration to deactivate
Object modification failed: can't open object (errDbNotFound)

Finished.
bash-2.02#


The error msg appears to be a catchall at the end, is there any way to determine which object it can't find?

[Jamie]

The error msg appears to be a catchall at the end, is there any way to determine which object it can't find?Likely "/DataSet/DiskConfigurationVersions". Can you check if you have that object, and if so, what is in the Data field?

[nams]

Here's a version of the mkDiskConfig.tcl script that hijacks an existing DiskConfiguration object rather than making a new one.

Script works fine on 3.1.5e and 4.0.1b

[mbellot]

Likely "/DataSet/DiskConfigurationVersions". Can you check if you have that object, and if so, what is in the Data field?

It looks like it does not exist...


% dumpobj /DataSet/DiskConfigurationVersions
can't open object (errDbNotFound)


and


% mls /DataSet
Directory of /DataSet starting at ''

Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----

%


There *is* a DataSet object listed if I run "mls /", so does this mean there is nothing in the DataSet object?

[Jamie]

There *is* a DataSet object listed if I run "mls /", so does this mean there is nothing in the DataSet object?Seems so.

Perhaps for the S1 machines the tivoapp binary patch is still the best bet.

[mbellot]

Seems so.

Perhaps for the S1 machines the tivoapp binary patch is still the best bet.

Yup, good thing I had already hacked mine for a 512MB max alloc.

Still, its some nice work you've put together.

[nams]

Well it look like the teleworld programs from early this morning free up all the extra spaced previously used by tivoclips on my 500GB HR10-250

Last week:

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 843120
IDB_MFS_TOTMEDIA: 973090816
IDB_MFS_AVAILMEDIA: 25675776
IDB_MFS_TOTCLIPS: 500000
IDB_MFS_AVAILCLIPS: -34433760
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

Today:

IDB_MFS_TOTAPP: 1047024
IDB_MFS_AVAILAPP: 850784
IDB_MFS_TOTMEDIA: 973090816
IDB_MFS_AVAILMEDIA: 11825152
IDB_MFS_TOTCLIPS: 500000
IDB_MFS_AVAILCLIPS: 89376
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

[Montaño]

Interesting sidenote Jamie. When I did a fresh install of 4.01b on my DSR704, the very first thing I did was run the mkDiskConfig.tcl. That was about 2 minutes after it completed guided setup. The TWP Info page has always shown this units Reserved Space: 0 MB. This has never changed. This unit also never has DVR Showcase scheduled to record on it, while my other 3 units have DVR Showcase recordings scheduled about once a week or so. It makes me almost want to slap a fresh install on all my other units !!!

[AhoyMatey]

Interesting sidenote Jamie. When I did a fresh install of 4.01b on my DSR704, the very first thing I did was run the mkDiskConfig.tcl. That was about 2 minutes after it completed guided setup. The TWP Info page has always shown this units Reserved Space: 0 MB. This has never changed. This unit also never has DVR Showcase scheduled to record on it, while my other 3 units have DVR Showcase recordings scheduled about once a week or so. It makes me almost want to slap a fresh install on all my other units !!!
I'm wondering if a CDE might have the same effect...

[Montaño]

I'm wondering if a CDE might have the same effect...
I can give it a shot on my daughters Tivo.

[ronnythunder]

montano, what are you seeking to accomplish? if you just want the showcases to go away, there are tivoapp patches for that. if you want to release clips space, run the script and just wait a few days or a week; it'll be gone.

a c&de is pretty harsh...

ronny

[Montaño]

montano, what are you seeking to accomplish? if you just want the showcases to go away, there are tivoapp patches for that. if you want to release clips space, run the script and just wait a few days or a week; it'll be gone.

a c&de is pretty harsh...

ronny

Not trying to accomplish anything :) The script works great, but as I posted above, when run on a fresh install (and perhaps a CD&E), my Tivo did not set aside ANY 'reserved space'. Nor does it download any Showcases. My daughters Tivo is my 'experimental' unit, and she's used to me 'blowing it up' :D

[Montaño]

I'm wondering if a CDE might have the same effect...

YES. It had the same effect :) My daughters Tivo shows a 'Reserved Space of 0MB.

User Space
Single 1 36 MB 0.0% 0:02:17
Live Cache 2 408 MB 0.3% 0:09:34
Used User Space 3 444 MB 0.3% 0:11:51
Reserved Space
Used Reserved Space 0 0 MB 0.0% 0:00:00
Space Summary
Total Space - 156033 MB 100.0% -
Total Used 3 444 MB 0.3% 0:11:51
Total Free - Best - 155589 MB 99.7% -

A 160GB drive shows 160 hours of record time :)

[nams]

YES. It had the same effect :) My daughters Tivo shows a 'Reserved Space of 0MB.

User Space
Single 1 36 MB 0.0% 0:02:17
Live Cache 2 408 MB 0.3% 0:09:34
Used User Space 3 444 MB 0.3% 0:11:51
Reserved Space
Used Reserved Space 0 0 MB 0.0% 0:00:00
Space Summary
Total Space - 156033 MB 100.0% -
Total Used 3 444 MB 0.3% 0:11:51
Total Free - Best - 155589 MB 99.7% -

A 160GB drive shows 160 hours of record time :)


What does your HServer.send looks like?

[Montaño]

IDB_MFS_TOTAPP: 785104
IDB_MFS_AVAILAPP: 681272
IDB_MFS_TOTMEDIA: 319555584
IDB_MFS_AVAILMEDIA: 312498176
IDB_MFS_TOTCLIPS: 500000
IDB_MFS_AVAILCLIPS: 452896
IDB_MFS_TOTRBACKS: 0
IDB_MFS_AVAILRBACKS: 0

EDIT: I was doing it wrong ;)

[nams]

command not found
That's strange.

[pdawg17]

Do you have to reboot the tivo after running the script?

[Montaño]

Both machines still show 0 for reserved space. And as my 2 other units have DVR Showcases scheduled to download, these 2 do not :) So I guess all is well.

[AhoyMatey]

Haven't installed 6.2 yet, but the offset for 6.2 is 0x108B9B0:
offset 108B9B0: 00989680 -> 00080000
Question for mods: Could one of you please put the patches in this thread in the tivoapp patches thread in the General TiVo Development forum? (As well as the ones in this (http://www.dealdatabase.com/forum/showthread.php?t=30881&page=1&pp=15) thread?)

[ThurstonX]

Haven't installed 6.2 yet, but the offset for 6.2 is 0x108B9B0:
offset 108B9B0: 00989680 -> 00080000
Question for mods: Could one of you please put the patches in this thread in the tivoapp patches thread in the General TiVo Development forum? (As well as the ones in this (http://www.dealdatabase.com/forum/showthread.php?t=30881&page=1&pp=15) thread?) Just used your info to patch my 6.2 tivoapp. Worked like a champ.

[bnm81002]

so it is possible for 6.2 then? thanks

[OrionsHunter]

What is the proper script to run to increase the hard drive space for a 6.2 DTiVo with HMO enabled? I tried the FIRST mkDiskConfig.tcl in this thread and my space increased from 120 hours to 133 with a 160GB hard drive. Shouldn't I see more space than this?

Orion

[EvilJack]

Just used your info to patch my 6.2 tivoapp. Worked like a champ.

... what does this do exactly?

jack

[OrionsHunter]

It changes partition sizes and frees up space for recordings. My problem was that I formatted the hard drive without LBA48 support. I reformatted and ran the script. My 160GB drive now has 160 hours.

Orion

[h8aohell]

offset 108B9B0: 00989680 -> 00080000
I decided to patch my 6.2 tivoapp to squeeze a few extra GB out of my stock 40G drive in the bedroom. It looks like the above patch will only affect drives over ~56GB, according to the table at alt.org (http://alt.org/forum/index.php?t=msg&th=82&start=0&rid=307&S=bc3dad9e504b424add0971b3ad17d6ef&SQ=f7aee24c1e98afbd833f23c31510c1b6) . Instead, I patched it so the second range would be from 500000KB to 2147483647KB. So unless your drive(s) are under 500MB or over ~2TB, you will use the second entry in the table. This is 266240KB for Clips and 0KB for Replaceable Backgrounds, with the remainder allocated to the user. If your interested, this is the patch I used:
offset 108b82c: 00bac480 --> 7fffffff
This freed up 7GB of space on my puny 40GB drive! If you want to use a value for clips other than 266240KB, you can just edit this at offset 108B834 to 1088B837. I was going to patch the previous table entry, but I wasn't sure how happy the TiVo would be with zero Clip space, plus this keeps it simple.

David

Edit: I just had to try patching the first entry, I could not sleep. Looks like the tivo wasn't so keen on my editing the 1st entry in the table, it just ignored it and reverted to the old values based on the rest of the table. I even tried changing the Clips from 0MB to 128MB, and it was still ignored. Maybe the tivo skips this first entry? I really can't say. The above patch to the second entry seems to work fine.

[AbMagFab]

So I ran the script on my 3.1.5d HD Tivo, it seemed to work, but TivoWebPlus still shows 60GB being used for reserved space. Will this eventually go away, or did something go wong?

Here's the output:
bash-2.02# ./mkDiskConfig.tcl
Deactivating Active DiskConfiguration
Created object /Config/DiskConfigurations/Frugal
Filling in User DiskPartition sub object
Filling in TivoClips DiskPartition sub object
Filling in /Config/DiskConfigurations/Frugal DiskConfiguration object
Finished.
bash-2.02#

[Jamie]

So I ran the script on my 3.1.5d HD Tivo, it seemed to work, but TivoWebPlus still shows 60GB being used for reserved space. Will this eventually go away, or did something go wong?

Here's the output:Look at /tmp/HServer.send right after forcing a daily call (the call doesn't have to succeed). e.g. bash-2.02# tr \& \\n </tmp/HServer.send | grep MFS
IDB_MFS_TOTAPP=785024
IDB_MFS_AVAILAPP=667072
IDB_MFS_TOTMEDIA=466382848
IDB_MFS_AVAILMEDIA=2435072
IDB_MFS_TOTCLIPS=500000
IDB_MFS_AVAILCLIPS=198944
IDB_MFS_TOTRBACKS=0
IDB_MFS_AVAILRBACKS=0IDB_MFS_TOTCLIPS is the "TivoClips" allocation, in my case ~500MB. IDB_MFS_AVAILCLIPS is the amount of clip space that is available. If this is negative, it means the clip space is overallocated. It will eventually be cleaned up next time a clip is recorded. If TOTCLIPS is still 60GB, then something went wrong, and the script didn't work. Start polking around in MFS based on the earlier posts in this thread.

See this (http://alt.org/forum/index.php?t=msg&th=82&start=0&rid=307&S=bc3dad9e504b424add0971b3ad17d6ef&SQ=f7aee24c1e98afbd833f23c31510c1b6) thread and this (http://www.dealdatabase.com/forum/showthread.php?t=38331) for some background.

[HDorBust]

Ya gotta love the work everyone puts in here. After coming back from a long VA my HD tivo box (3.1.5d) was full. However TWP had a different report. So, after a little searching, finding this thread and implementing the script, I have recovered additional space.
But, forcing the daily call didn't create a HServer.send and I haven't figured out why yet. Still, 24 hours later everything seems to be okay.

I have this in my tvlog but the user recording 'free' seems to be wrong, *if* this means free space for recording.

Nov 9 03:05:53 (none) Recorder[181]: User recording 419785171 free 6399443
Nov 9 03:05:53 (none) Recorder[181]: TivoClip total 64554540 free 64287276


Nov 10 15:35:35 (none) Recorder[181]: User recording 480163552 free 64152288
Nov 10 15:35:35 (none) Recorder[181]: TivoClip total 500000 free 232736

I was hoping someone would let me know if I should be concerned that HServer.send did not get created and I should continue debugging.

thanks

[chris22]

I know this is 8 months old, but I got it to work on my SD-DVR40 w/ 6.2

[wdwms]

I executed the mkDiskConfigHijack.tcl on my Series 1 SA, but I can't clear the 9gb out of the expired clips.. Anyone know how to do that? We dont' have the extra menus that you are referring to.

[ronnythunder]

edit: nevermind, something weird going on in a hr10 that i'm looking at.

ronny