Page 3 of 7 FirstFirst 12345 ... LastLast
Results 31 to 45 of 94

Thread: 7.1 software update: support thread (was: Monte on SA S2 with 7.1)

  1. #31
    Join Date
    Sep 2001
    Posts
    458
    Quote Originally Posted by alldeadhomiez
    No, 6916c4 is a nop on 7.1a. The instruction you want to change is 0320f809; NutKase's patch looks correct.
    6916C4 is the location posted for the 7.1 patch, Nutcase posted the location for 7.1a as 691284, which contains 1100FFFC. I thought he may have posted it as decimal instead of hex, and converted it to 0A8C54. That location does contain 0320F809.

    I have done both of the posted 7.1 and 7.1a edits individually, and neither have disabled CSO for my 7.1a tivoapp.

  2. #32
    Join Date
    Jan 2002
    Posts
    1,777
    Are you using VMAs? This is 7.1a, straight from objdump -d:

    Code:
      691270:       8fbc0010        lw      gp,16(sp)
      691274:       ae300000        sw      s0,0(s1)
      691278:       8f9981f8        lw      t9,-32264(gp)
      69127c:       00000000        nop
      691280:       2739f81c        addiu   t9,t9,-2020
      691284:       0320f809        jalr    t9
      691288:       00000000        nop
      69128c:       8fbc0010        lw      gp,16(sp)
      691290:       10400018        beqz    v0,0x6912f4

  3. #33
    Join Date
    Sep 2001
    Posts
    458
    *Sticks foot firmly in mouth*

    NutKase's patch is fine, I'm the ***** applying it wrong.

  4. #34
    Join Date
    Sep 2004
    Posts
    30

    need help to eliminate "pending restart"

    I have a SAS2 (not 2.5) hacked running 4.01b-02-2-240
    and I have the bootpage thing to stop upgrade BUT
    in MFS/swsystem I now have a 4.01 entry, a 7.1 entry
    and the active entry (which is the same object as the 4.01 entry)
    Now every day the status is "pending restart" and its rebooting
    every day at 2AM (and reboots into 4.01b). What I want todo
    is just stop the "pending restart". Has anyone figured this out?

    OR, hows it going on the front of letting it upgrade and then
    adding hacks to 7.1?

    PS I do have a SAS2.5 (silver) that was running 5.3, and after waiting
    3 weeks on the priority list and getting nowhere I just repeated guide
    setup and voila its now 7.1 with tivotogo running fine.

  5. #35
    Join Date
    Jan 2005
    Posts
    127
    Quote Originally Posted by grossman
    What I want todo is just stop the "pending restart". Has anyone figured this out?
    Just say "no thanks"!

    OR, hows it going on the front of letting it upgrade and then
    adding hacks to 7.1?
    A NoCSO patch was posted. mfs_ftp works for extraction, but to do inserts the "event" code needs to be updated. HMO-superpatch, TWP, and other hacks will need significant work to port.

    PS I do have a SAS2.5 (silver) that was running 5.3, and after waiting
    3 weeks on the priority list and getting nowhere I just repeated guide
    setup and voila its now 7.1 with tivotogo running fine.
    In a mixed environment with 7.x and 4.0.1b, pending an HMO superpatch release, you can either run encrypted (no hmo patches, and no nocso patch) and do all your extraction via TTG on the 7.1 unit, or run unencrypted and give up MRV between the units.

  6. #36
    Join Date
    Aug 2003
    Posts
    2,149
    Quote Originally Posted by spaceranger
    I may be wrong, but I don't think a 4.x kernel will work in a series2.5.
    I forgot you had a 2.5. I don't have one so, no idea.


    NutKase
    "God, and DealDataBase, help those that help themselves." --Shamelessly stolen from psxboy
    ------------------------------------------------
    2 each, SA S2 287hr 7.2.1a's with Lifetime.
    Hacks: 1 Manually Monte'd -140, Bash,Telnet,FTP,TivoWebPlus,
    Superpatch-67all Unscrambled/HMO,MFS_FTP Ver. N,TyTools, tivoserver
    Fully hacked SA S1

  7. #37
    Join Date
    Sep 2001
    Posts
    458
    BTW- TTG does work on noCSOed recordings. I don't think I've seem that mentioned anywhere yet.

  8. #38
    Join Date
    Aug 2004
    Posts
    8
    I having a little trouble transferring shows to the pc using mfs_ftp and tytools. After the 7.1a upgrade, all my hacks disappeared so I had to re-hack the box by using the killhdinitrd'd 3.1.5 kernel. I then changed the iptables and everything worked out fine. I then started on the process of applying the nocso patch for v7.1a with the seek on 2691716. Everything went fine. After this, I installed all hacks back into my tivo and now I get error messages from mfs_ftp and tserver. I can't get mfs_ftp nor tserver to work properly. I'm guessing its probably the nowshowing.tcl and tzoffset.tcl files which are now incompatible with the new 7.1a upgrade. Is there a patch or anything that will fix this? Anything I can do to change or patch the timezone to make this work? or am I just missing something here. Has anyone else gotten extraction to work here?


    ------------------------------------------------------------------------
    Using TYTOOLS, I GET THIS MESSAGE

    SERVER: We got a message! buf = 'SHOWING'
    invalid attribute: TimeZone
    while executing
    "dbobj $setup get TimeZone"
    invoked from within
    "if {$version4} {
    set lconfig [db $db open /State/LocationConfig]
    set tzval [dbobj $lconfig get TimeZoneOffset]
    set dstpolicy [dbo..."
    ("uplevel" body line 2)
    invoked from within
    "uplevel $body"
    invoked from within
    "transaction {uplevel $body}"
    (procedure "RetryTransaction" line 5)
    invoked from within
    "RetryTransaction {
    if {$version4} {
    set lconfig [db $db open /State/LocationConfig]
    set tzval [dbobj $lconfig get TimeZoneOffset]
    ..."
    (procedure "GetConfig" line 25)
    invoked from within
    "GetConfig"
    (file "/var/mfs_ftp/NowShowing.tcl" line 266)
    Waiting for an incoming connection!

    ----------------------------------------------------------------------
    USING MFS_FTP I GET THIS MESSAGE

    child process exited abnormally
    while executing
    "exec $info(path)/tzoffset.tcl 2>/dev/null"
    (procedure "get_tzoffset" line 10)
    invoked from within
    "get_tzoffset"
    (procedure "init_procs" line 7)
    invoked from within
    "init_procs"
    (file "/var/mfs_ftp/mfs_ftp.tcl" line 1534)
    Last edited by tomjones99; 02-17-2005 at 06:48 AM.

  9. #39
    Join Date
    Aug 2004
    Posts
    4,075
    The tserver in this package works fine with 7.1 (and I assume 7.1a). It has built in code for NowShowing and doesn't need a NowShowing.tcl script.

    The timezone issue with mfs_ftp is well covered. The easiest solution is to manually make your tzoffset.txt file, which will avoid ever calling the tzoffset.tcl code. Alternatively, fix the tzoffset.tcl for 7.x. I believe that 4.x and above all store the timezone info the same way.

    I should point out that insertion with mfs_ftp isn't going to work without some changes to the mfs_ftp.tcl script.

  10. #40
    Join Date
    Aug 2004
    Posts
    8
    Thanks Jamie

    The new tserver worked perfectly

  11. #41
    Join Date
    Mar 2004
    Location
    Santa Cruz, CA
    Posts
    18
    I had set the "upgradesoftware=false" bootpage param (verified with bootpage -p), but the the 7.1 upgrade installed anyway. Anybody successfully stop the upgrade? Did you patch tivoapp?

    http://www.dealdatabase.com/forum/sh...1&postcount=45

    I'm going to mfs_restore my last 4.01b backup and re-killhdinitrd, but I want to to stop upgrades forever!
    S2 SA 7.2/Killhdinitrd'ed/LBA-48 kernel/160GB HD
    Xbox/Xecuter chip/200GB HD/616T DVD/Crystal case

  12. #42
    Join Date
    Aug 2003
    Posts
    2,149
    Quote Originally Posted by trowt
    I had set the "upgradesoftware=false" bootpage param (verified with bootpage -p), but the the 7.1 upgrade installed anyway. Anybody successfully stop the upgrade?
    I don't think so. If you had successfully placed 'upgradesoftware=false' as a bootpage parameter, your box would not have upgraded.

    No way, no how.

    If about 1500 other users all of a sudden start saying that they got upgraded also with 'upgradesoftware=false' applied we'll worry and if that happens we'll get to work. Until then you can reinstall 4.x and ensure the proper parameter is set.

    You can perform the patches from your linked thread before or after (I recommend after, just in case you want to get at the slices one day) 7.1x downloads to your tivo, to prevent the pending restart the 'upgradesoftware=false' parameter will result in after an attempted upgrade and stop the overwriting of your HMO/MRV name/keys.


    NutKase
    Last edited by NutKase; 02-22-2005 at 09:05 PM. Reason: speling :)
    "God, and DealDataBase, help those that help themselves." --Shamelessly stolen from psxboy
    ------------------------------------------------
    2 each, SA S2 287hr 7.2.1a's with Lifetime.
    Hacks: 1 Manually Monte'd -140, Bash,Telnet,FTP,TivoWebPlus,
    Superpatch-67all Unscrambled/HMO,MFS_FTP Ver. N,TyTools, tivoserver
    Fully hacked SA S1

  13. #43
    Join Date
    Aug 2004
    Location
    Chicago Metro
    Posts
    49
    I was just getting into the swing of things: removed monte, killhdinitrd among other things, then BAM, my 240004a downloads the 7.1 software. Fortunately, my hacks are preserved as my bootparms include the upgradesoftware=false parameter. If this was my only unit I wouldn't be too concerned, but I also have an unhacked 5400040 running 7.1.

    My 240004a now has a DVR name of <Name this DVR on tivo.com> and as a result cannot utilize MRV features.

    I've tried using the set_mrv_name.tcl script (in hindsight, I am thinking this will only work if I had two units using this technique) and was going to followup with the "No Thanks" technique published here. Didn't work.

    Is there any other way to revert back to the 4.01b MRV keys? I was thinking about changing the value of /State/ServiceConfig/SwSystemName from 7.1a-02-2-240 to 4.0.1b-02-2-240.

    Any ideas?

    ljvk61
    DSR708 - LBA28 - 3.1.1e -30ss, backdoors, NoCSO, NoPPV
    DSR708 - LBA48 - 6.2 - 30ss, backdoors, NoCSO, NoPPV, MRV/HMO not enabled yet

  14. #44
    Join Date
    Jan 2002
    Posts
    1,777
    Quote Originally Posted by ljvk61
    Is there any other way to revert back to the 4.01b MRV keys?
    Your Series2.0 unit remains listed in the Series2.5 unit's MRV group certificate. Therefore, you may be able to apply some subset of the superpatch fixups to the Series2.0 box such that transfer encryption and CSO are not disabled, but your bogus MRV key (from set_mrv_name.tcl) is accepted by the local machine. I would start by killing all of the blowfish patches, and making note of any tverr messages logged by either box if transfers still fail.

    I doubt that you can get the keyserver to continue producing 4.0.1b MRV certs. If you cannot, then your last cert will probably only last about 90 days.

    Or, you can just port the superpatch to 7.1. It seems that the beggars:workers ratio on this patch is still extremely high.

  15. #45
    Join Date
    Jan 2005
    Posts
    127
    Quote Originally Posted by ljvk61
    Is there any other way to revert back to the 4.01b MRV keys? I was thinking about changing the value of /State/ServiceConfig/SwSystemName from 7.1a-02-2-240 to 4.0.1b-02-2-240.

    Any ideas?
    If you had applied the "No Thanks!" patches before you received 7.1, you would still have your 4.0.1b MRV keys. Still, they'd expire in 30 days or so, IIRC. Actually, the old keys might still be in your Rubbish.

    I don't know of a way to convince the headend to send you 4.0.1b MRV keys rather than 7.1 keys. If you look at your /tmp/HServer.send file, you'll see you are already telling the headend what version you are running, but it's choosing to use the version it thinks you should have.

    set_mrv_name_ADH.tcl will generate new keys, but they'll only be usable with an HMO superpatched tivoapp. And an HMO superpatched tivoapp can only talk to another HMO superpatched tivoapp, leaving your 7.1 machine out. So I'd say you are out of luck for now unless you want to spend some time figuring out some patches of your own. If you can port the HMO superpatch to 7.1, you'll be home free. Alternatively, if you can figure out how to patch your 4.0.1b tivoapp to accept the 7.1 MRV keys, that might work too, but you'll have to stick with encrypted streams if you want to MRV with your 7.1 machine.
    Last edited by 7.1; 02-22-2005 at 09:03 PM.

Posting Permissions

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