Page 7 of 14 FirstFirst ... 56789 ... LastLast
Results 91 to 105 of 198

Thread: Series1 3.1.0c Update: support, discussion, and tools

  1. #91
    Join Date
    Jan 2002
    Posts
    1,777
    Quote Originally Posted by Deven
    Sounds like it would probably be a fairly safe test, but if the 5505 is the MPEG decoder chip, would it help with this freezing problem? The problem occurs in the recording, not just during playback -- would this be a wild goose chase?
    The IBM CS22 chip is the MPEG decoder on a Series1. The MPEG decoders on the 5505 chips are not used.

    What sort of "recovery shell" did you have in mind? Bash running on the serial port?
    Yes. Build a serial cable and start the shell early, in the foreground.

    What sort of patcher do you need? I'd be willing to try to write one once I've had a chance to relearn TCL. (Or I could maybe write one in C, but that would require compiling for each CPU...)
    The patch only runs on PPC.

    I would need an original piece of code which patches/unpatches binary strings at two different locations in the tivoapp executable. It should verify first that it is overwriting the correct string, in case somebody runs it on the wrong version or on a binary that has already been patched. It should also provide helpful error messages to respond to common mistakes.

  2. #92
    Join Date
    Apr 2004
    Posts
    36
    Quote Originally Posted by alldeadhomiez
    The IBM CS22 chip is the MPEG decoder on a Series1. The MPEG decoders on the 5505 chips are not used.
    Interesting. I did a quick Google search on the STi5505 and saw the MPEG decoding capability and assumed that's what it was used for. If it's not used for MPEG decoding, what it is used for? Again, is it something that could explain the symptoms we've seen (something related to the tuner?)
    Yes. Build a serial cable and start the shell early, in the foreground.
    Shouldn't it work equally well to initialize the network drivers earlier and start telnetd early instead? When does tivoapp (myworld) get launched? Very last in the boot sequence?
    The patch only runs on PPC.
    Good point. Since only the Series 1 models use 3.1.0b, the CPU architecture is not a concern. I guess a compiled C binary would be fine then.
    I would need an original piece of code which patches/unpatches binary strings at two different locations in the tivoapp executable. It should verify first that it is overwriting the correct string, in case somebody runs it on the wrong version or on a binary that has already been patched. It should also provide helpful error messages to respond to common mistakes.
    Do you have to change the length of the executable, or simply modify certain bytes in place? In any event, this sounds like very straightforward code in C. (It would be trivial in Perl, but that's not on most TiVo units it seems.) If you want to spec out the requirements in detail, I'd be happy to write a patcher program in C for the purpose. Obviously, I'd need to know not only the bytes to replace (and at what offset), but what the original bytes being replaced should be as well as whatever error conditions you'd want handled... (It might be worth including other tivoapp patches as well...)

  3. #93
    Join Date
    Apr 2004
    Posts
    7
    Quote Originally Posted by johnny
    My S1 unit with 3.1.0c gets the video freeze but audio plays fine problem about 24 hours or so after a reboot. Using the menu options to reboot is all I do. But what a pain.
    For anyone who's tracking this. Just wanted to report that My SAT-T60 rebooted with the 3.1.0c update on Thursday night (wee hours of 7/9). I pulled the disk, reinstalled the cachecard drivers, reinstalled the disk, and restarted TivoWeb 1.9.4. (it's what was on that copy, I had reboot issues with TivoWebPlus) I extract with TyTool, and haven't had any audio/video/reboot issues for the last 4 days since I did all that.

    I start the 30-second skip, and SORT feature from the TiVo remote.

    Just wanted to state all that in case folks who are having trouble are having a conflict with something other than the above that they are running.

    Scott

  4. #94
    Join Date
    Apr 2004
    Posts
    7
    Oops, forgot to mention that I used the AlphaWolf hack (with the 4678664 offset) to turn off encryption. I've never used any of the other methods on this box.

    Scott

  5. #95
    Join Date
    Nov 2002
    Posts
    26
    I was thinking out aloud (on the other forum) about the video blanking problem with 3.1.0c.

    I vaguely recall reading somewhere about how dtv only scrambled the video. Since the access card is intimately involved in calculating the decryption keys and we know that the tivo/dtv folks have commented that the 'lost favourites/channels' problem on series 1 boxes is a timing problem with the older P4 (light blue) access cards. I seem to recall that folks suffering that problem were told that the 'c' update might fix it.

    Perhaps they Really Fixed It(TM) this time?

    Didn't somebody mention that the microcode for the microcontroller that talks to the access card had also been updated in the 3.1.0c update? (boot299.btl?) Perhaps the decryption keys coming from the access card are getting hosed and that causes the video to black out? (Assuming I was correct above, that might explain the dead-video, working audio in recordings.).

    Are folks seeing the lost video problem using the older P4 (light blue) cards, or the newer dark blue/silver stripe cards (aka P5)? Or both?

    And I'd be fascinated to know if removing/reinserting the access card during a blackout has any effects.

    I'd blocked the updates on my dtivos so that I could take the update when I was ready to reinstall the hacks.. In hindsight, damn, am I glad I did that! :-)

  6. #96
    Join Date
    Jan 2002
    Posts
    1,777
    Quote Originally Posted by DarkHelmet
    we know that the tivo/dtv folks have commented that the 'lost favourites/channels' problem on series 1 boxes is a timing problem with the older P4 (light blue) access cards.
    I do not believe that their statement has any basis in reality. The access card in a DirecTV system has only a very limited bearing on the program guide. If it is indeed true, it is a symptom of poor error handling.

    Didn't somebody mention that the microcode for the microcontroller that talks to the access card had also been updated in the 3.1.0c update? (boot299.btl?) Perhaps the decryption keys coming from the access card are getting hosed and that causes the video to black out? (Assuming I was correct above, that might explain the dead-video, working audio in recordings.).
    I am eagerly awaiting reports from trials of the 3.1.0b btl on 3.1.0c, and the 3.1.0c btl on 3.1.0b. Since this is an intermittent issue, it helps to have as many people as possible trying to isolate the problem.

    Edit: for anyone curious about what the 5505s are doing, the datasheets for some STi55xx ICs can be found here. Keep in mind that they just send the PES to tivoapp; they are not involved in video output on the TiVo.
    Last edited by alldeadhomiez; 07-13-2004 at 10:41 AM.

  7. #97
    Join Date
    Feb 2003
    Posts
    155
    FYI,
    Had 310c a couple of days. Last night some recordings played back with audio only. The video was just the red smokey background with a yellow bar at the bottom. Further investigation revealed that when two tuners were recording at the same time, one channel would have no video. Tried another set of shows and the problem repeated itself. Rebooted the unit and all is OK for now. Note the video wasn't frozen, it was just a red screen.
    While recording, I COULD scroll back through the live buffer on either channel with no problem. However if I viewed the recording through NowPlaying, only one channel had video, the other was red screen. Rebooting cured the problem, but programs recorded during the failure were still red screen.
    Did anybody else with the video problem notice any relation to dual tuner recording?
    Last edited by Tiros; 07-13-2004 at 10:29 AM.

  8. #98
    Join Date
    Apr 2004
    Posts
    36
    Scott326, it's unlikely that the video freezing problem has anything to do with hacks installed, because it's also been reported to occur on stock, unmodified systems.

    DarkHelmet, as I mentioned, boot299.btl is very different between 3.1.0b and 3.1.0c -- the new one is about 60% of the size of the old one! However, I have no idea what this code is used for. Is this related to talking to the access card? If so, it might be suspicious. Could they have caused this video problem while trying to fix the guide problem? I don't know...

    How did you prevent your system from upgrading 3.1.0b to 3.1.0c? I might be interested in trying to revert my systems to 3.1.0b if necessary, and I would need to know how to lock the version there...

    alldeadhomiez, I haven't tried using the 3.1.0b version of boot299.btl on 3.1.0c yet, because I don't know how often to expect the problem to recur. Or should I just hope it's a fix, switch the files, and report if I ever see the video problem again? (So far, I've seen it only once, on my DSR6000 -- haven't seen it on my SAT-T60 yet, though I imagine it's vulnerable too.)

    (BTW, you didn't tell me more about that patcher you wanted...)

    DarkHelmet, if you still have 3.1.0b, maybe you could try running the 3.1.0c version of boot299.btl and see if the problem thereby exhibits itself on 3.1.0b? Of course, it sucks to take this risk, since you might lose recordings, but it could help determine whether or not boot299.btl is the file at fault or not...

    Tiros, the way the video gets corrupted, the MPEG decoder gets "wedged" and just shows whatever was already on the screen, which might be a black screen, or the background from your menus, or whatever. Also, this isn't specifically a dual-tuner issue -- the problem has been reported to occur on a system operating in single-tuner mode as well. However, it's been previously reported to be exhibiting the problem on one tuner, while the other tuner is functioning normally -- this DOES suggest that the bug is somehow related to the tuner handling...

  9. #99
    Join Date
    Sep 2003
    Posts
    35
    Reading the thread on the video freeze issue in AVS Forums I saw someone who posted the problem happend with a 3.1.0b unit. Surprising to me - since all of this started being reported following the 3.1.0c update. If it is happening to 3.1.0b I'd expect there to be more responses on the forums.

    In my case I've only had the problem on 1 unit and it hasn't recurred since a reboot. Certainly feel like the Tivo's are a bit less reliable with this issue lurking around.

  10. #100
    Join Date
    Apr 2004
    Posts
    36
    You know, it just occurred to me -- what if the problem isn't with the tuner handling, but with the encryption process? Perhaps those of us hacking tivoapp to avoid scrambling the shows would never see the problem again?

  11. #101
    Join Date
    Feb 2003
    Posts
    155
    Quote Originally Posted by Deven
    Tiros, the way the video gets corrupted, the MPEG decoder gets "wedged" and just shows whatever was already on the screen, which might be a black screen, or the background from your menus, or whatever. Also, this isn't specifically a dual-tuner issue -- the problem has been reported to occur on a system operating in single-tuner mode as well. However, it's been previously reported to be exhibiting the problem on one tuner, while the other tuner is functioning normally -- this DOES suggest that the bug is somehow related to the tuner handling...
    But since I can scroll back through the live TV buffer, that would seem to rule the tuner out. It looks to me like actual video recording is the problem. The error on the recordings themselves persists after a reboot, they are recorded wrong.
    I am using the Tivoapp patch.

    I have not seen the problem since reboot last night. My fingers are crossed!

  12. #102
    Join Date
    Nov 2002
    Posts
    26
    Quote Originally Posted by alldeadhomiez
    I do not believe that their statement has any basis in reality. The access card in a DirecTV system has only a very limited bearing on the program guide. If it is indeed true, it is a symptom of poor error handling.
    Perhaps I didn't describe what I meant clearly enough. The card is used for flagging which tiers are enabled, what channels there are, etc. The actual guide data, as you point out, is a different data stream. The problem with channels/favourites was that one of two things happens.

    1) suddenly, the tivo believes that *lot* of channels went away, and a short time later it believes they are all back again. The tivo responds to this by deleting the obsolete channels from the 'channels you receive' and 'favourites' list. And when they return, the "new" channels get added back. The user visibie result is that favourites and channels you recieve is suddenly fully reset. This is seperate to directv removing the shopping channels from the lineup for a few hours here and there.

    2) like 1 above, but suddenly the tivo believes there are only 5 channels left in the lineup and does not recover.

    My son's T60 has #2 happen every 3 to 6 months. My hughes S1 dtivo has something like #1 happen every few weeks. My wife's hughes S1 dtivo doesn't have either happen.

    My understanding of how the access card is handled in a S1 dtivo is there is an atmel "security controller" on the tivo motherboard for interfacing with the access card. The boot299.btl/ndsboot299.btl files are the microcode that is downloaded to the motherboard based controller. This is the device that processes all the card events, receives the decryption keys, etc.

  13. #103
    Join Date
    Nov 2002
    Posts
    26
    Quote Originally Posted by Deven
    DarkHelmet, as I mentioned, boot299.btl is very different between 3.1.0b and 3.1.0c -- the new one is about 60% of the size of the old one! However, I have no idea what this code is used for. Is this related to talking to the access card? If so, it might be suspicious. Could they have caused this video problem while trying to fix the guide problem? I don't know...

    How did you prevent your system from upgrading 3.1.0b to 3.1.0c? I might be interested in trying to revert my systems to 3.1.0b if necessary, and I would need to know how to lock the version there...
    Yes, that code is the exclusive gateway to the access card. All messages, access control, satellite stream decryption keys, etc go via this chip running this code.

    I prevented an upgrade by applying a sledgehammer to the update entries in rc.sysinit
    Code:
    # Check for software upgrade
    swupgrade=false   <<<
    if [ "$swupgrade" = true ]; then
      /tvlib/tcl/updateSoftware.tcl
    fi
    ...
    upgradesoftware=false  <<<
    if [ "$upgradesoftware" = false ]; then
      echo "Not upgrading software"
    else
    # TODO... Find another way to do this...
    tivosh /etc/rc.d/finishInstall.tcl
    export -n EMERGENCY_REINSTALL
    fi
    Its kinda brutal, but it worked. Note that this will NOT stop the nightly reboot.

    DarkHelmet, if you still have 3.1.0b, maybe you could try running the 3.1.0c version of boot299.btl and see if the problem thereby exhibits itself on 3.1.0b? Of course, it sucks to take this risk, since you might lose recordings, but it could help determine whether or not boot299.btl is the file at fault or not...
    I can try it on this weekend when I can check on it regularly. I wish I had a spare dtivo for this.

    Tiros, the way the video gets corrupted, the MPEG decoder gets "wedged" and just shows whatever was already on the screen, which might be a black screen, or the background from your menus, or whatever. Also, this isn't specifically a dual-tuner issue -- the problem has been reported to occur on a system operating in single-tuner mode as well. However, it's been previously reported to be exhibiting the problem on one tuner, while the other tuner is functioning normally -- this DOES suggest that the bug is somehow related to the tuner handling...
    Not necessarily.. If there are two sets of decryption keys coming out of the asic on the access card, then it is plausible that just one set got out of sync or hosed. The Omega D&S 5505's do the satellite stream decoding and descrambling, right? They hand the decoded data to tivoapp, which re-scrambles it as it records it to disk using the CSO keys that it generated itself. BTW; turning off the CSO scrambling is completely unrelated to unscrambling the inbound satellite signal. Tivo added a scrambler to the mediaswitch fpga network in the 2.5 update, right next to the ide controller.

  14. #104
    Join Date
    Jan 2002
    Posts
    1,777
    Quote Originally Posted by DarkHelmet
    Perhaps I didn't describe what I meant clearly enough. The card is used for flagging which tiers are enabled, what channels there are, etc. The actual guide data, as you point out, is a different data stream. The problem with channels/favourites was that one of two things happens.
    The CAM makes an internal pass/fail decision based on tiers, blackouts, purchases, current date/time, etc. for every ~8 seconds of a program. It does not reveal in advance which channels are available, and thus has no influence over which channels show up in the guide (with three narrow exceptions: locals, parental controls (sometimes), and an 8-bit guide mask which is mostly used for locals).

    "Channels you receive" need to be set by hand.

    My understanding of how the access card is handled in a S1 dtivo is there is an atmel "security controller" on the tivo motherboard for interfacing with the access card. The boot299.btl/ndsboot299.btl files are the microcode that is downloaded to the motherboard based controller. This is the device that processes all the card events, receives the decryption keys, etc.
    The STi5505 is not a secure IC. The Atmel crypto chip is used to store TiVo-specific secrets which allow your box to authenticate itself during the daily TiVo call, decrypt .slice.bnd files, and such.

  15. #105
    Join Date
    Apr 2004
    Posts
    36
    Perhaps the problem lies in decrypting the satellite stream before tivoapp gets it? Is there some level of independence in processing each tuner that it would make sense for one tuner to fail while the other keeps working?

    As for staying on 3.1.0b -- is there any way to suppress the nightly reboot? If I went back to 3.1.0b and it started rebooting nightly, that would have to be a temporary solution...

    As for the report of this problem happening on 3.1.0b -- I didn't see that in the AVS thread -- reference?

    As for "channels you receive", it's absurd that it must be set by hand. The TiVo can tell when you tune to a channel that you don't receive at (at least at the moment) -- there should be an option to scan every channel to see which ones you don't receive to initialize the list. If that requires actually tuning to each channel in the process, so be it. (TVs do that.) I usually have to do this sort of manual scan the hard way, and it sucks. I don't know which unrecognized channels are ones I don't receive and which are ones I don't pay much attention to. Also, to keep the list up-to-date, when you tune to a channel that you don't receive, it could either be automatically removed from the list, or prompt the user as to whether to remove it from the list. Unfortunately, nobody at TiVo gave a second thought to the usability (that is, severe lack thereof) of the "channels you receive" list.

Posting Permissions

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