PDA

View Full Version : bufferhack 4.x Development Thread



JJBliss
04-02-2005, 01:30 PM
This thread is for discussion and development of bufferhack 4.x ONLY. Non-development posts go in the Support Thread (http://www.dealdatabase.com/forum/showthread.php?t=42812)

JJBliss
04-02-2005, 01:30 PM
Place Holder

JJBliss
04-02-2005, 01:30 PM
Place Holder again

oakwcj
04-02-2005, 03:19 PM
I think there is a syntax error in lines 232 & 233.

Since "mv" and "cp" are linux commands, the lines should read:


exec mv /tvbin/tivoapp /tvbin/tivoapp.orig
exec cp /tvbin/tivoapp.orig /tvbin/tivoapp

Note that I changed the name of the backup file to something shorter.

JJBliss
04-02-2005, 03:20 PM
I think there is a syntax error in lines 232 & 233.

Since "mv" and "cp" are linux commands, the lines should read:


exec mv /tvbin/tivoapp /tvbin/tivoapp.orig
exec cp /tvbin/tivoapp.orig /tvbin/tivoapp

Note that I changed the name of the backup file to something shorter.

Thanks.

Already been fixed in 4.0a released a little while ago. Check the files thread for the update

mike_s
06-16-2005, 04:41 PM
This change should fix the problem of busybox echo not supporting escapes, which causes a problem if busybox is earlier in the PATH than /bin. (described here.) (http://www.dealdatabase.com/forum/showpost.php?p=226400&postcount=21)

puts_txt "Patching brf.." 0
if [file exists ./buffhack.original.brf ] {
puts_txt "Backup of brf file already exists." 0
} else {
puts_txt "Backing up brf file to ./buffhack.original.brf" 0
set cmd "cp ./buffhack.brf ./buffhack.original.brf"
set res ""
$do { catch {exec bash -c $cmd} res}
puts_txt $res 0
}
set cmd "builtin echo -ne \"\\x$c0\\x$b1\" | dd count=2 conv=notrunc of=buffhack.brf bs=1 seek=[expr $addrC]"
puts_txt $cmd 0
set res ""
$do {exec bash -c $cmd}
puts_txt $res 0
Exec'ing with bash seems to fix the problem (even though sh is a symlink to bash! I'm guessing that because sh doesn't have an echo builtin it only uses the builtin as a fallback when called as sh), and forcing "builtin" is a dose of redundancy. "builtin" will also only work with bash, not sh. The "count=2" will keep it from overwriting stuff it shouldn't be touching even if something else goes awry.

(edited to fix an error in the echo command, s/$b0/$c0)

mike_s
07-30-2005, 05:48 PM
After moving from 2x 120G drives to a single 250G, I had occasion to use bufferhack again, with unexpected results. I started with a relatively clean system - the original 40G was dd'd directly to another drive, that was installed in the Tivo, and the upgrade to 7.1b-01-2-240 accepted. I then did an mfstool backup/restore to the 250G, installed hacks, and everything was good.

Before upgrading, I had noticed that with each reboot I would see a line like
Jul 30 19:40:10 (none) ShmemdLoader[136]: Loading Resource pvr/lib/resources/PvrConstantsDocument.brf from FsId 84898 in /var/log/tverr after each reboot. I didn't know where this came from.

Using the new disk/system, I no longer received these log messages.

Today, I ran bufferhack40b.tcl (modified with the changes above), and a reboot resulted in continual reboots. I connected serial, did a "handcraft=true" to get to a bash shell, and then restored the original brf file. The Tivo now boots again.

BUT, the tverr log messages are back. I also discovered that each time the brf is re-inserted into MFS, the id changes (right now, it's 84928). The log message changes to match.

To re-insert the original brf, I made some minor changes to bufferhack. I added a menu item which sets a flag to do a restore, and then changed this section of code:
if { $restore == 0 } {
puts_txt "Patching brf.." 0
set cmd "builtin echo -ne \"\\x$b0\\x$b1\" | dd count=2 conv=notrunc of=./buffhack.brf
} else {
puts_txt "Retrieving original brf.." 0
set cmd "cp ./buffhack.original.brf ./buffhack.brf"
}so the reinsertion is using exactly the same mechanism as bufferhack normally uses to make a change.

Aside from the fact that a modified brf now causes reboots (I did check, and the two bytes @113 are being changed correctly), it appears that something doesn't like the brf having a different id. (?) Or at least it doesn't like _something_ about reinserting an unchanged brf.

I won't try and pretend I know enough about MFS, tivosh or TCL to go much further.

darrin75
07-30-2005, 07:59 PM
I have been try also to play around with replacing brf files, and I pretty much get the same as you once i reinsert, reboot etc. I think maybe without patching the tivo app itself, to modifiy the brf files. We are wasting our time. But thats just my two cents. Good luck :cool:

mike_s
07-30-2005, 09:50 PM
Chasing far and wide for info. Maybe mfs_import would work to change the brf in place?

Learning MFS, I'm guessing there's something which tries to access that brf using the original fsid.

Searching through MFS, I found the pvr/lib/resources/PvrConstantsDocument.brf... at /TuikRes/Holder/010603/pvr~20050405160509-240/lib/resources. There, the TuikResource 36618/11 in turn points to the brf file and IndexPath, but there's also a File 36619 which isn't there (tivoweb gets a "no such object" error). Perhaps that was the original fsid? If you look at the other items listed at the same level as PvrConstantsDocument.brf..., they follow that pattern. (i.e. file fsid = TuikResource+1), and the TuikResource points to the same file fsid. i.e. here's lib/resources/PvrDateDocument.brf:
TuikResourceHolder 38201/11 {
ServerVersion = 2
AxisSpecification = /38201/12/
ImportIteration = 20050405160509-240
ImportProcess = pvr
MimeIndex = 09
PathBase = lib/resources/PvrDateDocument.brf
TuikResource = /36620/-1/
ServerId = 47225310
Version = 1
IndexAttr = /38201/13/ /38201/14/
MimeType = application/octet-stream
File = /36621/
IndexPath = /TuikRes/Holder/010603/pvr~20050405160509-240/lib/resources/PvrDateDocument.brf:010101:0900008f0d /Server/47225310
} note it points to File 36621, here's the TuikResource /36620/-1/:
TuikResource 36620/11 {
ServerVersion = 1
ContentHash = 0B2DAFFBF9684DDEDCC7ADD067F834E61FE0D47F
File = /36621/
MimeType = application/octet-stream
ServerId = 16659468
Version = 1
IndexPath = /TuikRes/SHA1/0B2DAFFBF9684DDEDCC7ADD067F834E61FE0D47F:00008f0c /Server/16659468
} which also points to 36621. That's not the case with the pvr/lib/resources/PvrConstantsDocument.brf after bufferhack inserts the modified brf. The fsid there is now non-existant.

Who knows MFS? Can we simply re-insert with the original fsid 36619? I'm thinking not, from the looks of things. So, how would one change the TuikResourceHolder to point to the new fsid? Something like this in bufferhack?
#insert brf
set db [dbopen]
RetryTransaction {
set brf [db $db open $tuik/$nameFinal]
set brfid [dbobj $brf get File]
set newbrf [ToMfs buffhack.brf]
dbobj $brf set File $newbrf
}
dbclose $db
set db [dbopen]
RetryTransaction {
#fix PvrConstantsDocument
#38197/11 is the fsid for PvrConst...TuikResourceHolder on my box
set pvr [db $db openid 38197/11]
dbobj $pvr set File $newbrf
}
dbclose $dbI think that's close, but tried it and it didn't work.

<just keeping my head above water here>

darrin75
07-30-2005, 09:55 PM
There, the TuikResource 36618/11 in turn points to the brf file and IndexPath, but there's also a File 36619 which isn't there (tivoweb gets a "no such object" error). Perhaps that was the original fsid?

<just keeping my head above water here>



That was the brf, the same thing happen to me when trying to change it. It nuked that file all together, but did not replace it, or renamed the object ID. Looks like we are together on the same track here.

mike_s
07-31-2005, 09:27 AM
I fixed my reboot problem (made a typo in the modified echo statement - doh! - code in above post was edited to correct).

No luck eliminating the complaints in tverr about the replaced brf. mfs_import won't change it in place. This may be a bug in mfs_import dealing with small files.

Attached is a diff to bufferhack40b.tcl. This fixes the potential busybox dd bug mentioned above, adds support for brf backup/restore and extraction of the brf/testing of brf patching without actually making changes to MFS.

Jamie
07-31-2005, 01:09 PM
... mfs_import won't change it in place. This may be a bug in mfs_import dealing with small files.The issue is that for small files in MFS, the data is actually stored in the inode rather than in "runs". I added a special case a while back to deal with this in mfs_uberexport, but I didn't do mfs_import at that time. I'll fix it and post an update in a few days.

Note that mfs_import can overwrite a file with a another file of the same length, but not change its size. Also, mfs_import is writing to MFS behind the back of tivoapp/tivosh/mfsd. When writing to non-tystream ty files, I'd do that cautiously, and reboot right after the change.

Overwriting brf files with mfs_import would have the advantage that the fsid of the file would not change, which would avoid the dangling fsid reference that bufferhack 4.x leaves now.

TivoWare
08-05-2005, 04:53 PM
I have finally found how to update the File attribute in the TuikResourceHolder so it matches the TuikResource. This is a way to fix the dangling fsid reference and get rid of the mesage in tverr Loading Resource pvr/lib/resources/PvrConstantsDocument.brf from FsId 84898

All you have to do is reset the TuikResource attribute in the TuikResourceHolder and it will fix the File attribute for you.

I found this while playing with other brf files and either putting my Tivo in a reboot loop or Tmk errors. This was the final fix for all my pains. To use this in Buffer hack we would have to change how we are finding the PvrConstantsDocument.brf file to use /TuikRes/Group or /TuikRes/Holder so we are starting at the TuikResourceHolder object for it. (No easy task)



#!/tvbin/tivosh
#This is from my machine, the path changes for each model.
set ResPath "/TuikRes/Holder/010404/pvr~20050215170308-351/lib/resources/PvrConstantsDocument.brf:010101:090000066a"
set db [dbopen]
RetryTransaction {
set TRH [db $db open $ResPath ]
set TR [dbobj $TRH get TuikResource]
dbobj $TRH set TuikResource $TR
}
dbclose $db

ronnythunder
08-05-2005, 09:34 PM
I have finally found how to update the File attribute in the TuikResourceHolder so it matches the TuikResource.didn't work for me. i changed the path of the resource to match mine, ran the script and rebooted a couple of times, but the messages are still there.

fortunately, i've never had the reboot problems, so i guess the messages are somewhat benign for me...

ronny

TivoWare
08-05-2005, 10:23 PM
didn't work for me. i changed the path of the resource to match mine, ran the script and rebooted a couple of times, but the messages are still there.
fortunately, i've never had the reboot problems, so i guess the messages are somewhat benign for me...
ronny

Buffer hack never caused me a reboot loop, just other brf's. So this is only for clean up. Are you sure you picked the right path? Because if you have many different versions under /SwSystem there will be a path for each one.

darrin75
08-05-2005, 10:30 PM
Have you tried to replace to the Main Menu on 6.2 to include standby. I have been working on this some, but with no luck? ;)


Moved Discussion here: http://www.dealdatabase.com/forum/showthread.php?t=44308

ronnythunder
08-05-2005, 11:27 PM
Buffer hack never caused me a reboot loop, just other brf's. So this is only for clean up. Are you sure you picked the right path? Because if you have many different versions under /SwSystem there will be a path for each one.oops! my bad, i didn't catch the vendor suffix (mine's a hdvr2, hence "-151" for me) before; i changed it, reran the deal and rebooted, and the message is indeed gone.

so tell us :) what other brfs have you been toying with? i've tried to muck with TivoCentralDocument.brf to change the title of the np screen to something other than "directv central". would this same technique help that change to "take"?

ronny

Jamie
11-12-2005, 10:01 PM
Here's a patch to bufferhack40b.tcl.

Changes:
Add support for 7.2.1-{elm,oth,tak}. Only the oth version has been tested, but I have high confidence the other versions will work too.
Use "builtin echo" rather than "echo" as suggested by mike_s. This avoids obscure problems if you happen to have a deficient (e.g. busybox) echo on your path.
Update the PvrConstants.brf in place rather than creating a new fsid. This avoids dangling MFS fsid references.


To apply:
Verify that you are running TiVo software version 7.2.1, not 7.2.0.
Be sure you have a current version of AlphaWolfs all in one package (http://www.dealdatabase.com/forum/showthread.php?t=37602). Older versions had a broken patch program.
Transfer bufferhack40b-to-c.patch.txt and bufferhack40b.tcl to your tivo. Be sure you transfer in a way that doesn't convert the unix line feeds to dos line feeds.
Move bufferhack40b.tcl to bufferhack40c.tcl: mv bufferhack40b.tcl bufferhack40c.tcl
Apply the patch: patch <bufferhack40b-to-c.patch.txt
Run bufferhack: ./bufferhack40c.tcl

shutterfriend
11-13-2005, 01:17 PM
Here's a patch to bufferhack40b.tcl.

Changes:
Add support for 7.2.1-{elm,oth,tak}. Only the oth version has been tested, but I have high confidence the other versions will work too.
Use "builtin echo" rather than "echo" as suggested by mike_s. This avoids obscure problems if you happen to have a deficient (e.g. busybox) echo on your path.
Update the PvrConstants.brf in place rather than creating a new fsid. This avoids dangling MFS fsid references.


How do I get the patches into the bufferhack40b.tcl file. Is there a command to add these changes to the original file?

Thanks.

Jamie
11-13-2005, 02:12 PM
hoist the application instructions up to previous post.

Moderators: I suggest post 19-21 be deleted as they are not appropriate for a development thread.

shutterfriend
11-13-2005, 03:03 PM
Jamie thanks for the help. I applied the bufferhack with 120 minutes and everything seems to be fine.

Thanks again for the quick response to my question, it is much appreciated.