HR10-250 Rebooting when scanning for OTA channels

[Yazhol]

Does the error manifest immediately, like after first reboot, or does it take a period of usage before the errors begin? I've definitely changed to channels I don't get while trying to figure out why this box is so god awful slow at twp and tytool extractions.

To be honest when I first started experiencing the aquiring data > 95% > reboot deal is when I first noticed the OTA or channel you don't get reboot deal so I don't know if it was there from the original hacking or not. The aquiring > 95% > reboot thing took a few weeks to show up.

[Lord-dogbert]

Lessons learned:

• This has nothing to do with the backport drivers. It's simply the result of applying a tivoapp patch for the wrong tivoapp version.
• You can fix this by restoring the stock tivoapp and re-patch with the correct patch locations.[/url]

Thanks Jamie,

I repatched my tivoapp and all has been stable for a week now. I'm not sure what happened since my box was stable for months after upgrade and I don't remember touching this. I restarted cron as well. Will advise in a few more weeks.

Thanks again.

[xjphil]

I don't know if its related, but I got the same "rule 834":

Mar 3 20:54:52 (none) tivosh[279]: Tmk Fatal Error: Thread tivosh <279>: assertion failure
Mar 3 20:54:52 (none) tivosh[279]: Tmk Fatal Error: Thread died due to signal -2
Mar 3 20:54:52 (none) tivosh[279]: Invoking rule 834: rebooting system

This was on a SD-DVR40 6.2 superpatched tivoapp (no 'echo|dd') and it appeared as I restarted tivowebplus. Also I applied the backported drivers just 2 days ago.

[Jamie]

I don't know if its related, but I got the same "rule 834":

"rule 834" is a generic message. It's what you get anytime tivoapp crashes.

This is a known issue with restarting tivowebplus on 6.2 See this post.

[mrwalker66]

I don't know if its related, but I got the same "rule 834":

Mar 3 20:54:52 (none) tivosh[279]: Tmk Fatal Error: Thread tivosh <279>: assertion failure
Mar 3 20:54:52 (none) tivosh[279]: Tmk Fatal Error: Thread died due to signal -2
Mar 3 20:54:52 (none) tivosh[279]: Invoking rule 834: rebooting system

This was on a SD-DVR40 6.2 superpatched tivoapp (no 'echo|dd') and it appeared as I restarted tivowebplus. Also I applied the backported drivers just 2 days ago.

it doesn't , jamie u are kind to answer....

[Lord-dogbert]

Still doing the exact same thing, just checked the log today and reboot has occurred three times in the last 3 days.

I'm going to transfer shows off to my PC and restore from backup and then apply the hacks one at a time and see what happens.

[Jamie]

Still doing the exact same thing, just checked the log today and reboot has occurred three times in the last 3 days.

I'm going to transfer shows off to my PC and restore from backup and then apply the hacks one at a time and see what happens.

Post the complete crash output from your logs. I'm mainly interested in the register dump like the one in the first post in this thread.

[leres]

• Never blindly apply echo|dd style patches unless you are certain they are correct for your tivoapp version

Good advice! Back in June when my Series 1 DirecTiVo (Sony T60) picked up 3.5-01-1-011, I tried to disable encryption but the resulting tivoapp would crash on bootup. I finally figured out that the builtin echo in the tcsh binary I built works very differently than the one in bash:

timmy 8 # tcsh -c 'echo -ne "\x48\x00\x00\x38"' | od -x
0000000 2d6e 6520 5c78 3438 5c78 3030 5c78 3030
0000020 5c78 3338 0a00
0000025
timmy 9 # bash -c 'echo -ne "\x48\x00\x00\x38"' | od -x
0000000 4800 0038
0000004

I'd suggest that in the future, people posting patches include before and after signatures (e.g. md5). This would help with the problem I had but also with the more general problem of using a patch with the against the wrong version of the binary.