Page 5 of 26 FirstFirst ... 3456715 ... LastLast
Results 61 to 75 of 376

Thread: unified mfs_* tools support.

  1. #61
    Join Date
    Jun 2004
    Posts
    147
    Quote Originally Posted by linda
    I used this process:

    Code:
    cp mfs_ftp.tcl mfs_ftp.tcl.original
    patch < mfs_ftp.jbuehl.patch
    patch < mfs_ftp.jamie.patch
    chmod 777 mfs_ftp.tcl
    reboot
    everything seemed to patch fine, but the speeds were worse than before. I had to revert back to the original file. Are there errors with my commands?
    Okay, i got it. In my stupor, i forgot to add the files from the .mips folder. All i did was patch the mfs_ftp.tcl file, without adding the others. Its up and running now.

    660Kb/s -> 2.1Mb/s....not a bad increase i would say......good job fellas...

  2. #62
    Join Date
    Oct 2004
    Posts
    26
    While pulling a short clip from my 4.0 RID unit to my usb drive I get this error

    bedroom:/usr/mfs_ftp$ ./mfs_uberexport -R 973876 -o /mnt/usbdrive/Football.ty

    Can't get RecordingPart:CommercialSkipOffset

  3. #63
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by Walter Mitty
    While pulling a short clip from my 4.0 RID unit to my usb drive I get this error

    bedroom:/usr/mfs_ftp$ ./mfs_uberexport -R 973876 -o /mnt/usbdrive/Football.ty

    Can't get RecordingPart:CommercialSkipOffset
    The code that extracts the xml (originally from mfs_tmfstream) requires the CommercialSkipOffset to be present. I could relax that to make it an optional field. I thought it was always there, even on unscrambled recordings. No? FSID 973876 is Recording object, right? If so, I'd like to see the mfs_dumpobj output for this FSID.

    {Edit: Looks like csoscout.tcl removes CommercialSkipOffset rather than setting it to zero. I'll make it optional in the next build. This should only be a problem if you've run csoscout.tcl to remove your CommercialSkipOffset keys. }
    Last edited by Jamie; 11-28-2004 at 11:34 PM.

  4. #64
    Join Date
    Oct 2004
    Posts
    26
    To clarify

    4.0.1b on RID using superpatch-4all-Nutkase-0.7
    Had to run 51killer on it due to playing with crypto stuff
    Clip is 48 mins of football (from buffer) transfered via mrv and halted during transfer. (just wanted about 5 mins to look into tystudio local indexing problem)

    Let me pull another clip when the unit is again avaliable.

  5. #65
    Join Date
    Aug 2004
    Posts
    4,075
    Here's a mips mfs_uberexport with the CommercialSkipOffset marked as not required.

    {Edit: Actually, I don't understand why the xml code is being called at all if you didn't use -x or -X.}
    Last edited by Jamie; 11-29-2004 at 12:13 AM.

  6. #66
    Join Date
    Sep 2004
    Location
    Los Angeles
    Posts
    71
    Quote Originally Posted by mmoore99
    Jamie,

    I re-copied mfs_ftp.tcl and verified that the md5sum matches yours, but still get the error when attempting the patch.
    My fault. I created the patch against a changed copy of mfs_ftp.tcl instead of the original. I'll try to get it reposted today. You can just leave it out and mfs_ftp should run fine.
    I have 4 Tivos. Is that too many?

  7. #67
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by jbuehl
    My fault. I created the patch against a changed copy of mfs_ftp.tcl instead of the original. I'll try to get it reposted today. You can just leave it out and mfs_ftp should run fine.
    The patch I included in the latest attachments to the FILES post has already been adjusted to work with the original mfs_ftp.tcl on the tivo. I'll double check and post md5sums of everything (patches, original mfs_ftp.tcl, after patch mfs_ftp.tcl).

  8. #68
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by mmoore99
    Jamie,

    I re-copied mfs_ftp.tcl and verified that the md5sum matches yours, but still get the error when attempting the patch.
    Works for me:
    Code:
    bash-2.02# md5sum mfs_ftp.tcl
    c4f63133e7bd9de3ba17f24b2b98b58a  mfs_ftp.tcl
    bash-2.02# patch < mfs_ftp.jbuehl.patch
    patching file mfs_ftp.tcl
    bash-2.02# patch < mfs_ftp.jamie.patch
    patching file mfs_ftp.tcl
    bash-2.02# md5sum mfs_ftp.tcl
    2bacf6678e178438177be4a69bfffe35  mfs_ftp.tcl
    Are you sure you are using the patches from the mfs_noarch-20041123-a.tgz attachment? You must apply the jbuehl patch first with the busybox patch program, since it can't adjust line numbers based on context.
    Last edited by Jamie; 11-29-2004 at 12:06 PM.

  9. #69
    Join Date
    Sep 2004
    Location
    Los Angeles
    Posts
    71
    Quote Originally Posted by Jamie
    The patch I included in the latest attachments to the FILES post has already been adjusted to work with the original mfs_ftp.tcl on the tivo. I'll double check and post md5sums of everything (patches, original mfs_ftp.tcl, after patch mfs_ftp.tcl).
    Ah. I was using the 1121 version.
    I have 4 Tivos. Is that too many?

  10. #70
    Join Date
    Nov 2003
    Posts
    85
    Quote Originally Posted by Jamie
    Works for me:
    .....
    Are you sure you are using the patches from the mfs_noarch-20041123-a.tgz attachment? You must apply the jbuehl patch first with the busybox patch program, since it can't adjust line numbers based on context.
    Very wierd happenings...

    I have two HDVR2's, both configured identically with the same kernels, tivo software versions & hacks. When I attempted the patch on TivoA I got the error discussed in the earlier post. I then attempted to apply the patches on TivoB and they worked successfully. So, I then copied the original, unpatched mfs_ftp.tcl file from TivoB to TivoA (even though the md5sums on both units matched before the copy). I then retried to apply the patches on TivoA, but got the same error. Very wierd!! Then I just copied the patched version of mfs_ftp.tcl form TivoB to TivoA and mfs_ftp is running successfully on both units. I have no idea why the patches would not work on TivoA.

  11. #71
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by mmoore99
    Very wierd happenings...
    Sounds to me like either the patches are different on TiVoA and TiVoB (see md5sums above) or the patch programs are different. Here's mine (from the latest AW AIW package):
    Code:
    bash-2.02# ls -l /tivohacks/bin/patch
    lrwxrwxrwx    1 0        0               7 Jan  2  1970 /tivohacks/bin/patch -> busybox
    bash-2.02# md5sum /tivohacks/bin/busybox 
    0cf599e1f5ed4581ee47ffbd21e6c44a  /tivohacks/bin/busybox
    Last edited by Jamie; 11-29-2004 at 11:06 PM.

  12. #72
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,829
    Quote Originally Posted by Jamie
    {Edit: Looks like csoscout.tcl removes CommercialSkipOffset rather than setting it to zero. I'll make it optional in the next build. This should only be a problem if you've run csoscout.tcl to remove your CommercialSkipOffset keys. }
    Hmm...you know, I originally did it that way b/c the intent was to make the streams look legacy. The truth is that all SW versions prior to 3.x (except for dtivo 2.5.x ) didn't even set a CSO attribute, thus tivoapp would treat them as if they were just old streams that were recorded before tystream encryption was introduced.
    Before PMing me: Iím not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  13. #73
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by AlphaWolf
    Hmm...you know, I originally did it that way b/c the intent was to make the streams look legacy. The truth is that all SW versions prior to 3.x (except for dtivo 2.5.x ) didn't even set a CSO attribute, thus tivoapp would treat them as if they were just old streams that were recorded before tystream encryption was introduced.
    Yeah, it's better to have it optional anyway. I'm putting up a new version now with that change, and one other. Both changes are of limited interest to most people.

  14. #74
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,829
    Yeah, plus it's not worth updating that script anyways, its very obsolete now and nobody should be using it these days. (plus I can't remember where all I have posted it )
    Before PMing me: Iím not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  15. #75
    Join Date
    Feb 2004
    Posts
    152
    Quote Originally Posted by AlphaWolf
    Yeah, plus it's not worth updating that script anyways, its very obsolete now and nobody should be using it these days. (plus I can't remember where all I have posted it )
    Well, actually... You know that posting recently....
    http://www.dealdatabase.com/forum/sh...ad.php?t=39207

    Well, if you intend to transfer (mfs_ftp) shows from that decryption process to another tivo, csoscout is actually required to repair the resulting shows.

    So your old tool has found new uses...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •