I think my Tivo is dying

[PhilG]

and I don't think it's the disk :(

I've been getting VERY strange symptoms over the last few weeks. None of them seem remotely likey anything anyone else has reported

Such as:

- A months worth or recordings (whilst I was away) with no sound whatsoever (and Tivo did NOT restart between a recording that had sound and one that hadn't) :confused:
- A week of recordings with mangled sound (like a borg with a cold) :(
- Last week, a single recording that was OK for the first 5 minutes, then pixellated a bit, did not reboot the Tivo and the reminaining 50 minutes were then playing back at the normal fast forward speed :eek:
- And today, a recording of Shaun the Sheep which was "empty" :mad:

I'd be grateful if someone can go "Ah yes, I recognise those symptoms ......" but I am not holding out any hope

My last straw to clutch at is to consider memory related issues so I will cut back on the number of hacks I am running

The first to go is a daily run of loadlogos (I am sick of the logos disappearing) then I may run Dailymail weekly instead of daily

Any other thoughts anyone??

Thanks

[Pete77]

The first to go is a daily run of loadlogos (I am sick of the logos disappearing) then I may run Dailymail weekly instead of daily

Any other thoughts anyone??

I don't think your hacks are the cause of your problems.

But if you really did think that they are you could always set Cron to reboot the box daily at say 7am when nothing worthwhile (apart from perhaps Shaun The Sheep) is normally on air, as most of us don't record breakfast television news programs.

[PhilG]

I've noticed that all my Crontab entries end with

2>&1 (most of them have a valid redirect for standard output like this:

00 06 * * 0 /tvbin/tivosh /var/hack/tracker/trackerupdate.tcl > /var/log/trackerupdate.log 2>&1

Should they have the extra & on the end, as in

00 06 * * 0 /tvbin/tivosh /var/hack/tracker/trackerupdate.tcl > /var/log/trackerupdate.log 2>&1 &

????????

Thanks

[PhilG]

I don't think your hacks are the cause of your problems.

But if you really did think that they are you could always set Cron to reboot the box daily at say 7am when nothing worthwhile (apart from perhaps Shaun The Sheep) is normally on air, as most of us don't record breakfast television news programs.

Since none of these faults themselves need a reboot to "fix" I am not sure what help that would be

EVERY one has appearaed and disappeared again without the help of a reboot

[mikerr]

1. Having had similar problems when having been away on work for a week:
- a week of a telewest frozen "press ok" logo screen recorded, and another time a tivo freeze-up on day 3 of the week.

I now have tivos and digiboxes on mains timer switches to reboot them once a day at 6am - everything has been fine since then.

2. If you still have your original 40GB drive, you could revert to that for a day/week to see if the problems recur - that will prove its not hardware.

3. There is a link between a weak (failing) PSU and sound faults, especially when a cachecard/turbonet is connected. Are you still on the original PSU?
You could remove the cachecard for a while to check that...

Depends on how much time you have and how often the fault is currently happening? I.e. how predictable it is.

[PhilG]

1. Having had similar problems when having been away on work for a week:
- a week of a telewest frozen "press ok" logo screen recorded, and another time a tivo freeze-up on day 3 of the week.

I now have tivos and digiboxes on mains timer switches to reboot them once a day at 6am - everything has been fine since then.

2. If you still have your original 40GB drive, you could revert to that for a day/week to see if the problems recur - that will prove its not hardware.

3. There is a link between a weak (failing) PSU and sound faults, especially when a cachecard/turbonet is connected. Are you still on the original PSU?
You could remove the cachecard for a while to check that...

Depends on how much time you have and how often the fault is currently happening? I.e. how predictable it is.


Hmm - all good ideas, except

1) fails at the first hurdle as all my AV equipment is powered from ONE socket, a reboot of the Sky box would reboot everything (and I always think of that as a sledgehammer/nut solution anyway)

2) Yes I have, but Tivo is buried at the bottom of my A/V cabinet and getting it out and putting it back takes at least a day each time

3) See (2) - I do have a spare PSU, perhaps next time I need to take Tivo out I will change the PSU. On the subject of which, I have just started this (http://www.tivocommunity.com/tivo-vb/showthread.php?p=5210001#post5210001) thread

[Pete77]

I've noticed that all my Crontab entries end with

2>&1 (most of them have a valid redirect for standard output like this:

00 06 * * 0 /tvbin/tivosh /var/hack/tracker/trackerupdate.tcl > /var/log/trackerupdate.log 2>&1

Should they have the extra & on the end, as in

00 06 * * 0 /tvbin/tivosh /var/hack/tracker/trackerupdate.tcl > /var/log/trackerupdate.log 2>&1 &

????????

Thanks

All my Crontab entries call a script .sh file and just have & at the end of the line calling the script file. But then the script files have 2>&1 & at the end of each line.

I used the script file solution because previous reading regarding cron had revealed that calling commands directly from crontab, instead of just telling crontabl to run a script that then calls the coammnd tends to cause problems.

[TCM2007]

I've seen the sound disappearing apprently unprovoked on one of my Tivos. The sound chip is know to be sensitive to fluctuatuions in power (which is why the extra warble of a cachecard in its original incarnation could make it fail to initialise). So PSU is worth a try for that one.

Pixellation then FF sounds like the descriptor of a Part of the video is corrupted. It's that descriptor which lets tiVo do trick play (FF, RW, slo mo) and (I think) deals iin lipsync too. Corruption could be HD related...

[futureechos]

FYI,


From a unix p.o.v the last '&' at the end of the command line will background the whole line.

As this is running from cron, and not in a shell this should be irrelevant. basically the
1> is a redirect which pushes all standard output to the logfile specified. The '2>&1' redirects standard error output to the same place as '1>' i.e. the same log file.

If running in a shell script on boot the you might need the last '&' otherwise the script won't continue until the process being run has terminated. By specifying it the program will run in the background, return control the shell script, and your system will continue to boot.

HTH

Mark

[Pete77]

All I can say is that the current arrangement works.

I have found with crontab you have to have a blank line at the end after the last event line or cron doesn't like it and sulks.