1.0d locking out / crashing / freezing in general use

[martinveasey]

I've an old and venerable Tivo that I've just re-imaged with AltEPG 1.0d.

I'm now finding that I get intermittent daily lockups of the unit which I can't recover without power off (telnet / TivoWeb don't work and the picture freezes). My situation is unusual compared to others on the forum as this definitely doesn't happen during dial-ins but during normal usage.

Here's a log extract from tvlog:

May 22 13:27:00 (none) Recorder[331]: Adding check schedule task
May 22 13:27:10 (none) Recorder[331]: CheckSchedule: creating action for: rec 490009
May 22 13:27:10 (none) Recorder[331]: Creating normal action
May 22 13:27:10 (none) Recorder[331]: Creating normal action
May 22 13:27:10 (none) Recorder[331]: CheckSchedule: next creation at 15482 47646: rec 490010
May 22 13:27:10 (none) Recorder[331]: InitialAction rec 490009
May 22 13:27:10 (none) Recorder[331]: InitialAction RecId 490009
May 22 13:27:10 (none) Recorder[331]: Item 490009: estimate kb per second: 1247
May 22 13:27:10 (none) Deadline[331]: Task RequestTuner started late by 3609ms
May 22 13:27:10 (none) Recorder[331]: RequestTuner rec 490009
May 22 13:27:10 (none) TvVideoPolicy[331]: RecordingTunerRequest on 9
May 22 13:27:10 (none) VideoGuts[331]: RecordingTunerResult DENIED 9
May 22 13:27:10 (none) Deadline[331]: Task RequestTuner ran late by 2615ms
May 22 13:27:10 (none) Recorder[331]: Got EVT_VIDEO_SESSION 5
May 22 13:27:10 (none) Recorder[331]: DeniedTunerLock event received
May 22 13:27:10 (none) Recorder[331]: DeniedTunerLock event received
May 22 13:27:10 (none) Recorder[331]: Abr-- recording 490009 reason DeniedTunerLock event in recording engine
May 22 13:27:10 (none) Recorder[331]: Adding check schedule task
May 22 13:27:19 (none) mempool[324]: MyWorld block: 601kB/723kB chunk: 129kB/140kB unused: 2778kB search: 1 (size=3731424)
May 22 13:27:19 (none) mempool[324]: Osd block: 36kB/42kB chunk: 940kB/940kB unused: 1994kB search: 0 (size=3051488)
May 22 13:27:33 (none) TmkMediaswitch::Trace[330]: Drift = 1
May 22 13:31:22 (none) TmkMediaswitch::Trace[330]: Lost VBI lock
May 22 13:31:23 (none) last message repeated 5 times
May 22 13:34:56 (none) Recorder[331]: Adding check schedule task
May 22 13:40:43 (none) TmkTransform::Trace[330]: ClipCache 0x3000fc28 Secondary Reset
May 22 13:40:43 (none) ClipCache[326]: 0x3000fc28 in Entry(), thread 326
May 22 13:44:40 (none) TmkMediaswitch::Trace[330]: Lost VBI lock
May 22 13:45:05 (none) last message repeated 194 times
May 22 13:45:39 (none) mempool[324]: MyWorld block: 584kB/723kB chunk: 129kB/140kB unused: 2778kB search: 1 (size=3731424)
May 22 13:45:39 (none) mempool[324]: Osd block: 36kB/42kB chunk: 940kB/940kB unused: 1994kB search: 0 (size=3051488)
May 22 13:46:27 (none) TmkMediaswitch::Trace[330]: Lost VBI lock
May 22 13:48:03 (none) last message repeate
May 22 13:48:03 (none) last message repeated 259 times
May 22 13:49:04 (none) last message repeated 547 times
May 22 13:50:14 (none) last message repeated 163 times
May 22 13:51:15 (none) last message repeated 548 times
May 22 13:52:16 (none) last message repeated 551 times
May 22 13:53:44 (none) last message repeated 101 times
.
(I admit the 13:46:27 TmkMediaswitch message worries me). I've redone Delete All / Guided Setup a couple of time to ensure the AltEPG program data is clean.

Has anyone any ideas that I can try next?

Cheers

Martin

[mrtickle]

It could be so many things, but just to reassure you, that TmkMediaswitch is perfectly normal. It relates to the teletext decoding that is done in software to decode 888 subtitles and re-produce them on playback. Teletext is/was in the VBI (vertical blanking interval) (top) part of the picture and it's normal for it to lose the 'lock' for a long time - you could have tuned to a channel which doesn't have the 888 subtitles for example (very likely these days). My logs are full of them:

Code: Select all

/var/log # grep "VBI lock" *tvlog | wc -l
   5542


your tivo might be overheating. use

Code: Select all

cat /proc/therm

from the command line, or check tivo's menus. You could try running it with the case open for a few days and see if that makes any difference (but be very careful not to touch the PSU).

[martinveasey]

Many thanks for the reassurance re logs.

The temp is running at a steady 39 (normal) which is the level I've been used to with the unit before.

I have a lingering suspicion about the hard drive. I reimaged due to a GSOD episode and, despite a clean bill of health with Spinrite, I am considering a complete swap out and replacement.

Cheers

[a_tivo_noob]

if you want random suggestions then hear I am

are you networked? if so, are you sure there are no IP address conflicts on your network?

[martinveasey]

if you want random suggestions then hear I am

are you networked? if so, are you sure there are no IP address conflicts on your network?

Thanks - I am networked and the addresses are all clean so no problem there. I've subbed in a new larger disk (supplied by Dave!) and we'll see how it goes.

[nick1austin]

When you re-imaged did you do so to a new drive?

It could be the new hard drive has different power supply requirements and the power supply in the TiVo can't cope, especially if you've also added a network card somewhere along the line.

[martinveasey]

When you re-imaged did you do so to a new drive?

It could be the new hard drive has different power supply requirements and the power supply in the TiVo can't cope, especially if you've also added a network card somewhere along the line.

The original re-image (that seemed to cause my problem) was to the original and venerable drive. The new re-image ( which seems to have resolved the problem) was to a new 1TB SATA.

Seems to be running fine so far ...