last step acquiring information

[lilchina]

has xtreme 25 been running for over a month
performed a delete guide data this morning at 9am cnt.
it's been at 90% at last step acquiring information from satellite. that is 4+ hours. Is it supposed to take this long. I don't remember taking this long on a fresh install. I can hear the hard drive just chugging away

Any suggestions?

[r00g]

I would say reboot from the bash promt if you can, if not...pull the plug. My DTivo was stuck at 90% for fifteen minutes the first time I booted after updating to XTreme and I was too impatient to let it churn away any longer. Second time around was fine.

r

[lilchina]

did that still at 90% churning away for 2:26 hr

[xmetalloid]

My DTivo was hanging at 90% as well and seemed to get progressively worse. It also intermittently said it was searching for a signal on one of the inputs or said the two inputs were different. Sometimes it would boot properly, but still acted flakey. In the end I re-pointed my dish and it completely fixed the problem.

The Tivos seem to be really picky about dish alignment. Just because you have good signal strength doesn't mean it will work properly. My Tivo has been working flawlessly for quite some time now.

[kilroy]

If you have any other hacks being called from rc.sysinit, try remarking them out.

I used to wonder why mine would hang at 90% for about 45 minutes. I had the fixdemo.tcl hack in there, and one I removed it, my system boots up ultra quick now.

The only hacks I have in the rc.sysinit are to enable the bash and fixsub.tcl.

-Kilroy

[AlphaWolf]

Actualy theres a better way of fixing this, as I posted in a thread a while ago stating the 90% problem. What you should do is insert a 'sleep 300' line right before the lines that call these hacks. This will allow time for your tivo to boot up first before starting these, reducing the overhead while its acquiring the guide data. Your receiver will start as fast as it normaly should, and you will also still have the added features of your tivotitle, mvchannels, or whatever else you might be running.

BTW: it might be a good idea to remove the fixdemo.tcl anyways, I think the newwer versions of pitou don't cause tivos to go into demo mode anymore (my pitou setup doesnt), and if you arent using pitou at all, you should definitely get rid of it. No good having a script constantly looping when it isn't even needed.

[kilroy]

One would think that adding a 'sleep 300' in the rc.sysinit, before a hack inclusion line would cause the rc.sysinit to sleep for 300 before processing the hack.

This is how traditional scripted languages work, but that probably shows my lack of experience with the TiVo command language.

In the PC scripting languages I work with, you'd do a run or shell depending on whether or not you wanted to wait for the return of the called script before proceeding...

-Kilroy

[AlphaWolf]

Linux shell scripts ;). Bash is called and everything works exactly as normal, it does not freeze the console at all. Only difference here is that the last few lines in the rc.sysinit don't execute until after 5 minutes have passed.

[kilroy]

Makes sense.
I just thought that during bootup, the Acquiring Guide happened after the rc.sysinit finished. I guess what you're saying is that the Guide Acquisition takes place while rc.sysinit is still executing?

[AlphaWolf]

normaly it does, but when you have all of these extra scripts running, it adds aditional overhead to the system. Letting the rc.sysinit idle for 5 minutes is better, that way you keep the overhead to a minimum during the already slow bootup sequence, and have these scripts execute after the fact.