HR10-250 Rebooting when scanning for OTA channels

[Yazhol]

Wanted to see if anyone has heard of this one. Whenever I go into the settings and have my HR10-250 try to scan for OTA channels (Just put up a new antenna) it reboots. In checking the tverr log the below pasted error is found. This unit is running 3.1.5f with networking, mfs_ftp, tivowebplus 1.2.1, elseed, tivotitle, encryption disabled, sort always on, and busybox hacks all setup. Any help will be greatly appreciated... btw, the unit also reboots when I accidentally change channels to one I don't receive instead of showing the usual blue banner saying the channel isn't available (Noticed this one when I sat on the remote and the unit tried to change to channel 1). Unit has been running fine for months on end.


Error is as follows:

Sep 12 18:54:34 (none) TvVideoManager[210]: Tmk Fatal Error: Thread TvVideoManager <210> died due to signal 11
Sep 12 18:54:34 (none) TvVideoManager[210]: pc 0xaa7c90 status 0xa001d413 cause 0x000008 bva 0x81dbfde8 hi 00000000 lo 0xc3df4f8
Sep 12 18:54:34 (none) TvVideoManager[210]: R00 0x00000000 R01 0xb001d400 R02 0x00000000 R03 0x00000000
Sep 12 18:54:34 (none) TvVideoManager[210]: R04 0x7f5c56f0 R05 0x00000000 R06 0x7fff7538 R07 0x00000000
Sep 12 18:54:34 (none) TvVideoManager[210]: R08 0x00000001 R09 0x7fff74c8 R10 0x00000000 R11 0x00000002
Sep 12 18:54:34 (none) TvVideoManager[210]: R12 0x00de1884 R13 0x63032f68 R14 0x7fff73c0 R15 0x00000000
Sep 12 18:54:34 (none) TvVideoManager[210]: R16 0x7fff74d0 R17 0x7f5c56d0 R18 0x00000000 R19 0x7fff7600
Sep 12 18:54:34 (none) TvVideoManager[210]: R20 0x00000008 R21 0xd68a31c0 R22 0x00000003 R23 0x7fff76d0
Sep 12 18:54:34 (none) TvVideoManager[210]: R24 0x00000000 R25 0x00b9d910 R26 0xd4a51000 R27 0x00000000
Sep 12 18:54:34 (none) TvVideoManager[210]: R28 0x10048590 R29 0x7fff74b8 R30 0x7f5c4d50 R31 0x00aa7b24
Sep 12 18:54:34 (none) TvVideoManager[210]: F00 0x417676a533333334 F02 0x0000000001676a53
Sep 12 18:54:34 (none) TvVideoManager[210]: F04 0xffffffffffffffff F06 0xffffffffffffffff
Sep 12 18:54:34 (none) TvVideoManager[210]: F08 0xffffffffffffffff F10 0xffffffffffffffff
Sep 12 18:54:34 (none) TvVideoManager[210]: F12 0xffffffffffffffff F14 0xffffffffffffffff
Sep 12 18:54:34 (none) TvVideoManager[210]: F16 0xffffffffffffffff F18 0xffffffffffffffff
Sep 12 18:54:34 (none) TvVideoManager[210]: F20 0xffffffffffffffff F22 0xffffffffffffffff
Sep 12 18:54:34 (none) TvVideoManager[210]: F24 0xffffffffffffffff F26 0xffffffffffffffff
Sep 12 18:54:34 (none) TvVideoManager[210]: F28 0xffffffffffffffff F30 0xffffffffffffffff
Sep 12 18:54:34 (none) TvVideoManager[210]: csr 0x001004 eir 0x005410
Sep 12 18:54:34 (none) TvVideoManager[210]: Tmk Thread Backtrace: aa7c90 992804 9b8cb4 99ed10 99b8e8 dbca48 dbd410 dbd378 ded188 e09a98
Sep 12 18:54:34 (none) TvVideoManager[210]: Tmk Fatal Error: Thread died due to signal 11
Sep 12 18:54:34 (none) TvVideoManager[210]: Invoking rule 834: rebooting system

[tekdiveraz]

I am having the same problem, except for that it is consistently doing this on normal satellite only. I have not set up ota channels yet. Seems to be in an endless rebooting loop. Always reboots while downloading the satellite programming. If I unplug the LNB, unit runs fine playing recorded items from dvr list. I have the same log info...

Sep 12 15:44:16 (none) TvVideoManager[234]: pc 0xaa7c90 status 0x8001fc13 cause 0x000008 bva 0x81dbfde8 hi 00000000 lo 0x2af7a628
Sep 12 15:44:16 (none) TvVideoManager[234]: R00 0x00000000 R01 0xb001fc00 R02 0x00000000 R03 0x00000000
Sep 12 15:44:16 (none) TvVideoManager[234]: R04 0x7f5c5d50 R05 0x0fa24c58 R06 0x7f5c5d48 R07 0x00000000
Sep 12 15:44:16 (none) TvVideoManager[234]: R08 0x00000000 R09 0x7fff7440 R10 0x00000000 R11 0x00000002
Sep 12 15:44:16 (none) TvVideoManager[234]: R12 0x00de1884 R13 0xae9cf639 R14 0x7fff7360 R15 0x00000000
Sep 12 15:44:17 (none) TvVideoManager[234]: R16 0x7fff7448 R17 0x7f5c5d18 R18 0x7f612b18 R19 0x7fff75a0
Sep 12 15:44:17 (none) TvVideoManager[234]: R20 0x00000005 R21 0xb672b5e7 R22 0x00000003 R23 0x7fff7670
Sep 12 15:44:17 (none) TvVideoManager[234]: R24 0x00000000 R25 0x00b89778 R26 0xd4a51000 R27 0x00000000
Sep 12 15:44:17 (none) TvVideoManager[234]: R28 0x10048590 R29 0x7fff7430 R30 0x7f5c5390 R31 0x00aa7ba0
Sep 12 15:44:17 (none) TvVideoManager[234]: Tmk Thread Backtrace: aa7c90 992804 9b9cf0 9b8ce0 99ed10 99b8e8 dbca48 dbd410 dbd378 ded188 e09a98
Sep 12 15:44:17 (none) TvVideoManager[234]: Tmk Fatal Error: Thread died due to signal 11
Sep 12 15:44:17 (none) TvVideoManager[234]: Invoking rule 834: rebooting system
Sep 12 15:50:13 (none) TvVideoManager[234]: Tmk Fatal Error: Thread TvVideoManager <234> died due to signal 11

[Yazhol]

Well my issue turned into a constant reboot loop just the other day. I re-imaged the TiVo and went back to stock 3.1.5f un-hacked. I'll run it that way for now and see what happens. This is the second of these units I've had that turned into a constant reboot piece of crap... Apparently no one here knows how to decypher the errors we've been posted.

[tekdiveraz]

Is there any way you could tarball up the associated binary for TvVideoManager off of your unhacked unit? I think that maybe if I replaced it it might fix things.

[Yazhol]

The binary for TvVideoManager doesn't get hacked. That's what's so puzzling...

And of course everyone over at the community only knows how to say "Hard drive failure" so they are of no help. lol

If it were a HD Failure it wouldn't run fine unhacked!

[jrollinson]

Add me to the list. I had my secondary 250gb drive hacked and working fine for a couple weeks so I blessed the original drive and installed a twin breeze. Now I get to 95% on acquiring signal and it reboot. Tried a bunch of different drive and jumper configs and the only way I can get it work is with no OTA or Sat lines attached and only the primary hacked drive installed.

Has anyone figured out why this is happening? I did manage to shock the *!@#* out of myself when I accidentally brushed across the copper square thing next to the drive. Ouch!

Will I have to have Directv replace my Tivo? Do they warranty it if I bought it off eBay?

Thanks for any help

[tekdiveraz]

I ended up having to send my unit back to PTVUpgrade, they erased the drives and rebaked everything I just hope that it all works when I get it back.

[Yazhol]

This has happened to me twice now, getting to 95% and rebooting, and no one has been of any help at all.

Each time I have had to go back to a non-hacked image and re-hack. This time I stayed non-hacked for a week and nothing happened, didn't even reboot at all. I just re-hacked the other day and so far so good.

[jrollinson]

I had to do the same thing. I restored the un-hacked image to my original drive that I had tried to bless to the hacked drive and everything works fine now. I am going to re-hack the original drive and then try again to bless the secondary in.

Is it possible the bless command is messing something up? Should I try taking both drives out and running mfsadd?

Thanks for any suggestions.

[Yazhol]

Using Blesstivo isn't the issue. I always use mfsadd -x...

I left mine un-hacked for a week and re-applied all except for elseed and tivotitle and it's now been running about 2 weeks hacked again. This is what I did before and it happened all over again after a few months so who knows.

[Figure Head]

anyone have a solution for this I am having the same problem.

[Yazhol]

Sorry Figure Head, nothing is new on this issue. Seems like we won't get any help until it happens to someone "important".

[captain_video]

You probably haven't gotten a reply because nobody knows the answer to your problem. I've never seen it myself and I have three HDTivos. Most likely you restored a bad image or something got hosed during the backup/restore process that's causing the glitch to occur. Go back over your process and look for any errors that you may have induced in the command line you entered. There are known issues when restoring images to large hard drives that are not documented in Hinsdale's so I'd start by doing a search on that topic. Some people have had problems when using mfsadd for expanding large images. Also make sure you used the proper switches in the restore process. This post at the TCF may be of some help:

http://www.tivocommunity.com/tivo-vb...&&#post2651665

[Yazhol]

Most likely you restored a bad image or something got hosed during the backup/restore process that's causing the glitch to occur.

Considering the issue comes up months after restoring an image I don't think it's how the image is restored.

Also, this issue has happened when using an unhacked image placed on the drive by InstantCake and then applying the hacks. Also happening a long time after the fact.

[captain_video]

Sorry, I missed that part about it working for months prior to the reboot issue. My first inclination would be a drive failure. A hard drive can apparently work fine but yours may be deteriorating at a slow rate and the reboot may be occurring only when certain things happen like the alignment of the planets. I'd definitely recommend running a non-destructive diagnostic on the drive to see if there's an issue with the drive. If that checks out OK then I'd recommend re-imaging the drive and see how it goes.