Alpha Tester - Getting hideous reboots

[groovyclam]

A massive 64 reboots overnight after my listing suckdown!!!

It took 9 hours to calm down and is now happy ( or has been for an hour and a half ).

Three possible thoughts:

1) We had an electricity supply interruption yesterday so the TiVo was literally powered off. Is there a different boot process on a power on that might do something to make the database more volatile ?

2) In the late evening I took out a lot of the minority shopping/god/foreign channels from my SKY lineup before the daily call. I did leave some channels that AltEPG still doesn't carry listings for ( about 15 ) in my lineup. However, prior to this culling my TiVo had been running somewhat reboot free ( still did have a few a day ) even with all the minority channels flagged as ON in my lineup. So has taking OUT a lot of minority channels before the daily call caused the volatility to increase ?

3) Was this Sunday evening ( about 11pm ) listings suck a large one compared with the days before ? A bigger listings loading/processing causing more reboots until it has finished the job ?

[poppadum]

I see you are getting the same errors as in viewtopic.php?f=8&t=560

With tivosh getting upset rather than the scheduler

Thinking of tivosh, does that indicate the cause of the error is a third party addon / hack causing the error?

Just to add a few random thoughts to this idea...

My 'official' tivo has not thus far been connected to altepg, but in preparation I've been archiving off some recordings with mfs_ftp. Whilst doing this, tivo has suffered stuttering video/audio and has rebooted several times with the exact same messages in /var/log/tverr:

Code: Select all

Jun  2 09:35:01 (none) TmkAssertionFailure[4755]:  (BlockFailure, line 1771 ())
Jun  2 09:35:01 (none) tivosh[4755]: Tmk Fatal Error: Thread tivosh <4755> died due to signal -2
Jun  2 09:35:01 (none) tivosh[4755]: Tmk Thread Backtrace: 1a344ec 1a32a44 1a2ed70 1b95e0c 1c4d5e8 192271c 1923700 1c77e7c 1c61a10 1c8e4e0 1c77e7c 1c61a10 1c8e4e0 1c77e7c 1c61a10 1c69720 1c77e7c 1c61a10 1c8e4e0 1c77e7c 1c61a10 1c69720 1c77e7c 1c61a10 1c8e4e0 1c77e7c 1c61a10 1c8e4e0 1c77e7c 1c61a10 1c61798 1914914 192131c 1920e58 1c98f2c 1c88c24 1c88f34 1919d90 1c61118 1c77e7c 1c61a10 1c849c0 1c85ec8 1c4d248 1c28cac 1800134 ipe
Jun  2 09:35:01 (none) tivosh[4755]: Tmk Fatal Error: Thread died due to signal -2
Jun  2 09:35:01 (none) tivosh[4755]: Invoking rule 834: rebooting system

Could this indicate that tivo's CPU is being overloaded and it can't keep up with the workload it's being asked to do?

Then I remembered that Dave mentioned seeing processes constantly dying and being respawned while using the altepg image. So I'm just wondering (just thinking out loud here - this is by no means proven) if there's a rogue process on the altepg image which is sucking lots of CPU cycles and possibly contributing to these reboots?

[healeydave]

Then I remembered that Dave mentioned seeing processes constantly dying and being respawned while using the altepg image. So I'm just wondering (just thinking out loud here - this is by no means proven) if there's a rogue process on the altepg image which is sucking lots of CPU cycles and possibly contributing to these reboots?

No, that conversation was related to changes I have made to an updated AltEPG image that has not been posted anywhere.
In fact I was comparing that updated image against an older version of AltEPG that wasn't exhibiting the problem.

[gcobb]

I see you are getting the same errors as in viewtopic.php?f=8&t=560

My 'official' tivo has not thus far been connected to altepg, but in preparation I've been archiving off some recordings with mfs_ftp. Whilst doing this, tivo has suffered stuttering video/audio and has rebooted several times with the exact same messages in /var/log/tverr:
...
Could this indicate that tivo's CPU is being overloaded and it can't keep up with the workload it's being asked to do?

It could be, but I am wondering if the "BlockFailure" reboots are actually real disk errors (is there anything reported in /var/log/messages or /var/log/kdebug?). That would be sort of consistent with you archiving all your programmes, if you have a bad disk block.

The Pointer errors we were getting in other crashes seem more likely to be a software problem -- maybe the empty channels were causing that?

Unfortunately, I haven't been able to provoke my test tivo to crash, even loading in a massive Sky+Digital setup, setting up all sorts of SPs and wishlists and forcing reschedules.

[groovyclam]

I just want to update and say that I am no longer getting the hideous multiple reboots and my TiVo has been stable with 5 days uptime.

I personally think ( but can't prove ) this is due to the "gaps" in the listings in the channels I receive finally falling out the back end of my database ( after my initial setup on AltEPG ) so my database would have "full" listings.

[SolidTechie]

This is interesting.

I have just had a problem with my main TiVo - it started rebooting, say 5 or 6 times a day. This only started on 02/10. Now it may be a combination of things, and I don't have factual evidence to back this up, however:

It rebooted 3 times just before and during the 21-22:00 slot on Monday. It had rebooted 2 or 3 times earlier whilst we were watching a recording and apparently it had fallen over half a dozen times the day before. Previously, it had been working fine. After the 3rd reboot, it came up without sound, so, I ran nosound.tcl and it rebooted it, without curing the problem.

As I had a a spare power supply, I whipped out the box and swapped it, but when I put the TiVo back in, and tried to schedule Doc Martin on ITV +1 (Central) the guide data for the channel had missed the whole day. This was at about 21:40 - the guide was showing a time slot of (IIRC)01:00-01:30 which was for Tuesday and scrolling back through the data, the previous 22:00 showing was for Downton Abbey (Sunday). I confirmed that there was no data for the channel for the day in HiGuide.

Although nobody noticed it did reboot overnight on Tuesday - but touch wood - it seems to be fine now. Unfortunately, I wasn't able to retain the logs - they have all cycled since then.