getting the following error message all the time in all 3 of my dtivos 6.2

[lgkahn]

Oct 29 05:26:50 (none) ApgExprEvaluator[227]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Oct 29 05:27:04 (none) ApgCamInterfaceBase[227]: FindServerObject: scanner found nothing at A00000000, err = 0x0

[w2kr]

Which log do you see that error in. I'll check my 6.2 unit and see if I'm getting it too?

[evade]

I'm getting this too on my just upgraded 6.3a HR10-250.

Did you ever figure out what this was?

[lgkahn]

not really I had to unblock my firewall do a call to the mothership.. re put up my firewall to block the calls and then redo the setmrvname to get mrv working again.

[Cheezmo]

My 6.3b HR10-250's are both doing this tonight...

[dave7101]

another 6.3b hr10-250, getting ton's of them

[Cheezmo]

Now they are coming at the rate of several per second. Probably will fill up the /var partition and cause a reboot after a couple of days.

[RandC]

I thought I would pull the access card, clear the log file, reinsert the card to see if (card reboot) would solve the problem. Pulled the card, cleared the log file, did some other things, checked the logs before I went to reinsert the card, and still have the same error message.

Dec 16 21:36:34 (none) ApgCamInterfaceBase[10185]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Dec 16 21:36:34 (none) ApgExprEvaluator[10185]: DoEvaluate() returned err = 0x30001, setting result to zero

To check my original thought, reinsertion of card does not stop the mesages. Time to set up cron to wipe tvlog every so often.

[LlamaLarry]

I am not getting any spurious entries in tvlog; I wiped my logs via cron at midnight and no entries at all.

[jwciv]

I have it too, var is up to 30%...time to delete logs

I have repeating entries, usually 16 sets of these two:
Dec 17 01:32:22 (none) ApgCamInterfaceBase[227]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Dec 17 01:32:22 (none) ApgExprEvaluator[227]: DoEvaluate() returned err = errDbNotFound, setting result to zero

Followed by one of these
Dec 17 01:32:22 (none) InputState[240]: GetOnNow()->FNeesRefresh Input:0

[Cheezmo]

My tvlog file filled about 30% of /var after 1 day which would imply most Tivo's that this is happening to will fill up /var and reboot every 3-4 days.

[LlamaLarry]

I am not getting any spurious entries in tvlog; I wiped my logs via cron at midnight and no entries at all.Looks like one of my boxes failed to rm the logs this morning and I *do* see these errors, but only on the one box. The other two wiped the logs and don't even have a tvlog.

ETA: Damn, as usual, I am a tool. Looks like /var was wiped completely on the other two boxes. :) Does tivo's crond/crontab support */ so I can try wiping the logs every whatever? How about @reboot and the other periodic entries? I guess I can run it every hour with 0 * * * *.

[saryon]

I am not getting any spurious entries in tvlog; I wiped my logs via cron at midnight and no entries at all.

If you delete a log file and don't restart syslogd it won't make any new entries until the box is rebooted or you restart syslogd.

[jwciv]

If you delete a log file and don't restart syslogd it won't make any new entries until the box is rebooted or you restart syslogd.

good temporary solution, thanks saryon.
I'd still like to get to the root of the problem though.
Anybody have thoughts about what may be causing this? My log file went from zero to 14meg in about 17 hours overnight.
Searches only turn up the two current posts.
thanks

[LlamaLarry]

If you delete a log file and don't restart syslogd it won't make any new entries until the box is rebooted or you restart syslogd.So anyone that has a cronjob to ever wipe the logs in a session should be fine then as well as those that rm them manually or via TWP? I guess it appends to a file and just does nothing (including die) if the output target is missing? Either way this does seem to work for me as well to stop the logs from growing; would be nice to know what the deal is though as it would appear that everyone has this problem.

Once /var fills will the tivo just reboot and recreate /var?

[saryon]

rm'ing the file manually works, a cron to rm would be OK but kind of pointless as the first delete will do it (perhaps in rc.sysinit.author to hose it right after the reboot?), I can't speak to what twp does to the files and whether it restarts syslogd or not.

It's my understanding that if /var gets full the system nukes /var and restarts (or does it just nuke /var?) - either way, anything stored on /var is gone.

I wonder what bug they'll introduce with the software patch that fixes this <sigh>.

[LlamaLarry]

Thanks, I did not know that. I think I have had a cron to wipe the logs since my first mod'd TiVo. May as well just put the command in rc.sysinit.author and get it out of the way with every reboot until 6.3c. ;)

[swspjcd]

FWIW, I am getting the same errors every few seconds on my hr10-250. I tried restoring the original unhacked tivoapp just in case I had a bad patch, but the errors still continue. I am using a killhdinit'ed 3.1.5 kernel. Could the error be because it's not the correct kernel? And if so, where would one get the correct kernel for 6.3b, preferably already killhdinit'ed?

[Cheezmo]

I suspect it is a data related error that will go away over time as guide data migrates through. I really wonder if a C&DE would get rid of it (or even clear guide data and to do list), but not really willing to try it at this point.

[Dmtalon]

well if you don't want to 'kill' the logging, you can always just

cat /dev/null > /var/log/tvlog which will 'empty' out the log without killing it.

And FWIW, I'm getting a crapload of these errors on my recently upgraded 6.3a HR10-250 as well

[jwciv]

I suspect it is a data related error that will go away over time as guide data migrates through. I really wonder if a C&DE would get rid of it (or even clear guide data and to do list), but not really willing to try it at this point.

I have a 6.2 box with no recordings on it, fresh build about 2 weeks ago from Alphwolf's minimal. It's getting the errors too. With no recodings I can try a clear and delete and let you know what happens. Will take a couple days as the box is 100+ miles away but will report what happens.

[Cheezmo]

I did a clear and delete (channel guide and to do) and it didn't fix it.

[swspjcd]

Anyone try using a killhdinit'd correct kernel for 6.3b to see if that fixes it since my guess is most of us are using the 3.15 kernel.
just a thought.

[cheer]

Anyone try using a killhdinit'd correct kernel for 6.3b to see if that fixes it since my guess is most of us are using the 3.15 kernel.
just a thought.

There is no 6.x kernel that is killhdinitrd-compatible. However, if it matters, I am using the 7.2.2-oth-K1 kernel and I see the errors.

[swspjcd]

There is no 6.x kernel that is killhdinitrd-compatible. However, if it matters, I am using the 7.2.2-oth-K1 kernel and I see the errors.

It was the only other thing I could think of. Looks like we'll have to wait for 6.3c I guess. Since this thing is generating errors every few seconds, should we be concerned about the extra overhead it creates on the OS?

[jwciv]

keep in mind that this is occurring in 6.2 too, so I doubt that 6.3c would fix the problem on a 6.3b system

[oakwcj]

I just did a C&DE on my 6.2 box to no avail. Even though I have wipelogs set to run every six hours, I'm still experiencing frequent -- several times a day -- reboots. I doubt this is relevant, but I have a 5 LNB dish and an HR20. The other odd thing I've noticed is that tivoftpd is not being executed through rc.sysinit.author:

Dec 19 18:42:15 (none) kernel: /busybox/tivoftpd: error opening null output device; Read-only file system

I have to start it manually through telnet. My rc.sysnit.author file hasn't been changed in 18 months and I fail to understand why tivoftp won't execute in a read-only file system.

[LlamaLarry]

What would happen if we stop syslogd and klogd from even starting in the Stage script that launches them?

My box has been eating /var and rebooting every other day, despite /var not being full. My box never shows a "Pending Restart", but does anyone know what flag I can check to see if my box is planning an automatic reboot?

Having /var go away every couple of days is a pain, but thankfully they all reboot on different days so I can rebuild it pretty quickly.

[swspjcd]

What would happen if we stop syslogd and klogd from even starting in the Stage script that launches them?

My box has been eating /var and rebooting every other day, despite /var not being full. My box never shows a "Pending Restart", but does anyone know what flag I can check to see if my box is planning an automatic reboot?

Having /var go away every couple of days is a pain, but thankfully they all reboot on different days so I can rebuild it pretty quickly.

I'll bet it would work as I killed syslog on mine and it hasn't rebooted since. I thought my box was rebooting because of the "pending restart" but then found it was rebooting because /var was filling up because of the previously mentioned error.

[SteveT]

....The other odd thing I've noticed is that tivoftpd is not being executed through rc.sysinit.author:

Dec 19 18:42:15 (none) kernel: /busybox/tivoftpd: error opening null output device; Read-only file system
....I had a similar problem a while back. See here (http://www.dealdatabase.com/forum/showthread.php?p=264110#post264110)

[BTUxNine]

re: rebooting.
the log filling shouldn't be the cause of reboots... from what I can tell, syslogd is smart enough to purge logs if it runs out of space

Also, var being full doesn't NECESSARILY mean tivo will wipe it on a reboot... first it's supposed to purge large logs to get more space
(under 6.2, the code is in /etc/rc.d/StageB_PostKickstart/rc.Sequence_150.CleanupVar.sh)

[jwciv]

good point BTUxNine.
One of my 6.2 boxes had var up to 97%, rebooted itself as I watched in horror :eek: (thinking var was going to be wiped), only to come back a couple minutes later to a var at 7% and still fully intact:) .
The log filling up is a mjor pain, it's going to reboot in the middle of recording something sooner or later.
We need to get to the root of the problem.

[oakwcj]

I had a similar problem a while back. See here (http://www.dealdatabase.com/forum/showthread.php?p=264110#post264110)

Thanks Steve -- and Jamie. /dev/null was present, but it was a normal file, not a device node. No idea why it's happened to a bunch of us all of a sudden, but deleting the borked file and creating a new device node has cured the problem, at least for now.

[jwciv]

Thanks Steve -- and Jamie. /dev/null was present, but it was a normal file, not a device node. No idea why it's happened to a bunch of us all of a sudden, but deleting the borked file and creating a new device node has cured the problem, at least for now.
I thoughht the /dev/null file cured a networking problem...are you saying that fixing it cured the logging problem?

[BTUxNine]

good point BTUxNine.
One of my 6.2 boxes had var up to 97%, rebooted itself as I watched in horror :eek: (thinking var was going to be wiped), only to come back a couple minutes later to a var at 7% and still fully intact:) .
The log filling up is a mjor pain, it's going to reboot in the middle of recording something sooner or later.
We need to get to the root of the problem.
I think it may be some other process accessing var that's causing the reboots... my 3 tivos all have uptimes > 40 days, and all 3 have tvlog files that only start today (so they must be getting purged)

[oakwcj]

I thoughht the /dev/null file cured a networking problem...are you saying that fixing it cured the logging problem?

I thought it had when I started typing this reply, but the errors are back. I never lost networking, but I was experiencing frequent reboots, and the absence of a proper /dev/null was causing tivoftpd and endpadplus not to execute from rc.sysinit.author. I still don't know what's causing the error messages, but I do hope that the reboots will stop now. /dev/null is essential to a functioning linux system. Whether the two problems are related in any way, I can't say.

[jwciv]

oakwcj and BTUxNine - - thanks for the replies

just to be clear - I'm not having the reboot problem. I've only had one reboot in the last four days on one of my two boxes. I've been clearing the log manually once per day (need to get cron running!). I misssed a day on one box, the log grew in 48 hours to fill var to 97% and the box rebooted. thankfully, var did not wipe on the reboot, linux just cleaned the log files and reclaimed space that way.
I'm just trying to figure out what process/error is filling the tvlog with these entries:
ApgCamInterfaceBase[227]: FindServerObject: scanner found nothing at A00000000, err = 0x0
ApgExprEvaluator[227]: DoEvaluate() returned err = errDbNotFound, setting result to zero

[BTUxNine]

hmm... wonder if older dtivo s/w versions are seeing anything like this (3.1 or 3.1.5)

[ensor999]

hmm... wonder if older dtivo s/w versions are seeing anything like this (3.1 or 3.1.5)

Yes, I have a DSR6000R at version 3.5-01-1-001 and noticed the problem today (just in time, apparently). I see many repeats of these messages:
ApgCamInterfaceBase[144]: FindServerObject: scanner found nothing at A00000000, err = 0x0
ApgExprEvaluator[144]: DoEvaluate() returned err = errDbNotFound, setting result to zero

Deleting the tvlog file doesn't necessarily stop the problem--right now, while I've deleted and touched the tvlog file (and so now have a new empty one), /var is still losing free space. I'm not familiar with ext2fs, but I know this can happen on other OS/fs combinations. A unix-like OS won't necessarily let you rip an open file out from under an active process, but may happily make this appear to be the case and then finish the deletion later (in the background) after the file is closed. Replacing the contents as others have mentioned may be a safer method.

Browsing a little in MFS, I notice that the ApgBoot item has a field "ServerId = A00001000"; note from the error message that ApgManager is apparently looking for something at A00000000.
Another field is "IndexPath = /ApgBoot /Server/A00001000:76:154:0". A00001000:76:154:0 exists under /Server, but A00000000 does not. BTW, /Server is huge; be prepared if you click/access it.
I'm not really familiar with the APC data structure or what any of these values should be (or were) when functioning correctly. Maybe it will help give someone else an idea.

[oakwcj]

My SD-DVR80 has been up for more than 5 days now. With wipelogs set to run every six hours, /var is around 20%. It did grow to 85% or so a few days ago, mostly in /var/tmp, but pruned its size without a reboot.

[RandC]

Yes, I have a DSR6000R at version 3.5-01-1-001 and noticed the problem today (just in time, apparently). I see many repeats of these messages:
ApgCamInterfaceBase[144]: FindServerObject: scanner found nothing at A00000000, err = 0x0
ApgExprEvaluator[144]: DoEvaluate() returned err = errDbNotFound, setting result to zero

Do you have HMO/HME active? this is why
1. I have one HR10 that I reverted back to 3.1.5f
2. I left one HR10 at 6.3a
3. When 6.3b update came down I copied the new libhpkhl.so into 6.3a. Also activated HMO/HME via tivoapp patches. I have the same error.
4. On my 3.1.5f unit I reinstalled the drive with 6.3a, 6.3b is not in the stream at this time so I copied the new libhpkhl.so into 6.3a as with my other unit. I have NOT patched the tivoapp file for HMO/HME and since 12-20-2006 when I reinstalled the 6.3a drive I have not had any of the errors.

Is it possible that the HMO/HME tivoapp patch is causing this?
I also copied back the tivoapp file before the HMO/HME patch but the errors are still there even though I do not have the tivoapp patched for HMO/HME.
Might be something to look at, of course I would have no idea what to look for. But in my case I have one HR10 with the errors and one without.

[PlainBill]

Do you have HMO/HME active? this is why
1. I have one HR10 that I reverted back to 3.1.5f
2. I left one HR10 at 6.3a
3. When 6.3b update came down I copied the new libhpkhl.so into 6.3a. Also activated HMO/HME via tivoapp patches. I have the same error.
4. On my 3.1.5f unit I reinstalled the drive with 6.3a, 6.3b is not in the stream at this time so I copied the new libhpkhl.so into 6.3a as with my other unit. I have NOT patched the tivoapp file for HMO/HME and since 12-20-2006 when I reinstalled the 6.3a drive I have not had any of the errors.

Is it possible that the HMO/HME tivoapp patch is causing this?
I also copied back the tivoapp file before the HMO/HME patch but the errors are still there even though I do not have the tivoapp patched for HMO/HME.
Might be something to look at, of course I would have no idea what to look for. But in my case I have one HR10 with the errors and one without.
Highly unlikely; the DSR6000 is a Series 1 system. HMO / HME is not possible on Series 1 systems.

PlainBill

[ensor999]

Is it possible that the HMO/HME tivoapp patch is causing this?

No HMO/HME here (Series 1 as PlainBill indicated). I also haven't patched tivoapp (still using noscramble.o). I haven't made any recent changes or received any software update lately (last was in May).

I guess the best hope is probably that a recent mistake in the guide data distribution has triggered a DTivo software bug and that someone will wake up and fix it in the next week or so.

[RandC]

On my 3.1.5f unit I reinstalled the drive with 6.3a, 6.3b is not in the stream at this time so I copied the new libhpkhl.so into 6.3a as with my other unit. I have NOT patched the tivoapp file for HMO/HME and since 12-20-2006 when I reinstalled the 6.3a drive I have not had any of the errors.Disregard this from my earlier post, as of 12-27-2006 6:19am I am now getting the error on both of my machines. Not sure why it would take a week to start getting it on the other unit but it is now fill up the tvlog file.

[PlainBill]

I guess the best hope is probably that a recent mistake in the guide data distribution has triggered a DTivo software bug and that someone will wake up and fix it in the next week or so.

I agree with your analysis, but wouldn't bet on anyone fixing it unless it causes problems for unhacked systems.

PlainBill

[ensor999]

I agree with your analysis, but wouldn't bet on anyone fixing it unless it causes problems for unhacked systems.

This seems very likely; on tivocommunity there are many reports of "random" reboots and scheduling problems on DTivo units. This is actually how I discovered the problem on my unit. The guide indexing process uses temp space on /var, which filled up in the middle of it. When I checked the todo list, most of the programs which had previously been there were missing.

One theory (originated by someone's call to support) is that the problem stems from receiving guide data beyond the year-end boundary. This seems possible given that the problems seem to have started within the last two weeks of December. If that is the issue, then the problem should disappear tonight (or in a couple of days, if the 2006 data will cause problems until it expires).

Next year, same thread? :rolleyes:

[jcbrief]

I'm getting this on all 3 of my tivos (6.2, series 2, hacked). They have been reseting every 3 days because of the /var being full.

Yesturday I setup crond to clear tvlog twice a day because I saw the /var increasing about %25 in about half a day (by TivoWebPlus)

Joe

[Krosis]

One theory (originated by someone's call to support) is that the problem stems from receiving guide data beyond the year-end boundary. This seems possible given that the problems seem to have started within the last two weeks of December. If that is the issue, then the problem should disappear tonight (or in a couple of days, if the 2006 data will cause problems until it expires).

Next year, same thread? :rolleyes:
Well, it's after the first and if anything the problem is getting worse. My tvlog is filling up extremly fast with these errors. I'm also starting to have problems with Tivoweb crashing constantly. That wasn't happened 3 days ago, but I'm not sure if it's connected.

[ensor999]

This appears to have (hopefully) resolved itself recently in my case. The kernel log had 8 hours of "DISCARD AudioPES" messages appear overnight (at about 40/sec, then stopped), but the tvlog has been very calm today. I also no longer have any guide data prior to Jan. 1 (looking with tivoweb).

[Cheezmo]

What about your tvlog? That is the one that I'm still seeing fill up with this junk...


Jan 4 01:27:30 (none) ApgCamInterfaceBase[17393]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 01:27:30 (none) ApgExprEvaluator[17393]: DoEvaluate() returned err = 0x30001, setting result to zero
Jan 4 01:27:30 (none) ApgCamInterfaceBase[17393]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 01:27:30 (none) ApgExprEvaluator[17393]: DoEvaluate() returned err = 0x30001, setting result to zero

[jcbrief]

I get the same things,

Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero
Jan 4 08:06:07 (none) ApgCamInterfaceBase[241]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 4 08:06:07 (none) ApgExprEvaluator[241]: DoEvaluate() returned err = errDbNotFound, setting result to zero


Instead of having crond clear all the logs twice a day I modified the clear /var code to log what file I cleared, and of course like TivoWebPlus I put a header in the log file saying when it was cleared and by what. This runs by crond every hour.

I'm curious how often it will have to clear what file. Now its only tvlog.

Joe

[dave7101]

Try this for a temp* workaround that is far better than wipelog etc etc

Edit /etc/syslog.conf and make the change below, reboot. Bob's your uncle.

From:
local0.info;local0.!err -/var/log/tvlog

To:
#local0.info;local0.!err -/var/log/tvlog

*not really 'temp' per se, as it is a persistant fix. But i expect that DTV/TIvo will have an official fix at some point, and this will do till then.

[ensor999]

Just a followup... I haven't seen any recurrence of the tvlog error messages or any rapidly growing log files since my previous post. The last two days of tvlog is only about 20K. No reboots or software version updates in that time either.

I've seen one post by a person indicating his machine (also a dsr6000) is working, but don't know if that is permanent or it happened to reboot and reindex. Many others appear to report still having problems, but very few seem to be able to examine their logs or determine whether rebooting/reindexing fixes it. It's possible that some of those seeing problems still don't have a valid index because they haven't rebooted. It's also possible that I'm somehow lucky, but I'm not really inclined to believe that.

[Cheezmo]

I'm still getting them (on two machines, both running 6.3b). One of them has been rebooted a couple of times in the last few days, the other hasn't. Glad to hear it is stopping for others, hopefully my time will come soon.

[drpud]

I have been getting the errors continually for all 4 of my D* boxes. I was monitoring the logs of one machine that seemed to stop erring for a few days after clearing the log and rebooting but the errors subsequently resumed. REM'ing out the line in syslog.conf seems to have resolved the issue for me. Thanks for the tip!

Jeff

[ensor999]

Not fixed after all, at least not permanently. The same error messages started appearing in tvlog again this morning, right after the automatic "phone call" (via broadband). There has not been any reboot or software download.

[mstbone67a]

so has someone tied this to the service connection date? my 2 tivo's that are not affected have service connection dates of may and october. the one having sp issues has been making service connections daily

[Krosis]

Hmm, last night I got a bit disgusted and deleted all my log files in /var/log and then rebooted. Now I'm not getting the errors anymore. Coincidence :confused:

[jwciv]

Hmm, last night I got a bit disgusted and deleted all my log files in /var/log and then rebooted. Now I'm not getting the errors anymore. Coincidence :confused:

The error is most likely still happening, there is just no log file for it to be noted on / written to

edit: now that I think about it, the log files should have been recreated on reboot. Give it a couple hours and see what gets writtem

[Krosis]

The error is most likely still happening, there is just no log file for it to be noted on / written to

edit: now that I think about it, the log files should have been recreated on reboot. Give it a couple hours and see what gets writtem

Yeah, that's why I rebooted - to recreate all the logs. I just checked it again, and those errors haven't returned. The tvlog file is only 144,648 bytes and I think it's been going for almost 24 hours now. Veddy interesting. I still have no idea if it's just a coincidence that they stopped immediatly after I deleted *all* the logs.

-- Just checked my uptime, it's at 21h 38m so it didn't sneak a reboot in on me :D

[BTUxNine]

What tivo s/w version are you running?
It's a bit odd that it helped, in that several people have reported reboots with var getting rebuilt, which would have the same effect.

[mstbone67a]

hrmm odd my 2 other machines.. /var seemed to fill up.. no tvlog it was the /var/cache/guidedata stuff that was increasing..
rebooted one.. it cleared var up.

[Krosis]

What tivo s/w version are you running?
It's a bit odd that it helped, in that several people have reported reboots with var getting rebuilt, which would have the same effect.
Tivo software version: 6.2-01-2-351
Kernel version: 2.4.20

[mstbone67a]

r10
tivo 6.1-01-2-521
os 2.4.20

[Krosis]

*Sigh*

Forget everything I said. :o

I just discovered that although I wasn't getting the errors anymore, neither was I getting any recordings! I haven't had the TV on much lately, and even if I did I never watch live TV! So I never noticed that the last time I rebooted the darn thing only got 10% into the acquiring data from satelite phase. It was stuck there all this time. I just rebooted and it re-acquired just fine. I have no idea why it got stuck last time. That never happened before. My signal strength seems fine, 95-100% on most transponders.

So now I have TV again, and the errors have returned :(

I guess this does indicate that it is coming from the satelite feed though :D

Thinking about it some more... I did watch a few minutes of Bush's speech Wednesday night, but I'm not sure if that was before or after I rebooted :confused:

[Cheezmo]

Amidst reports on other forums that DirecTV/Tivo had identified a problem that was causing season pass failures/reboots, it appears that my tvlog stopped filling up with the APG messages sometime today.

[BTUxNine]

Add a "me three" for my 3 dtivos... tvlog is back to normal

[goony]

I re-enabled logging to /var/log/tvlog on my box that was logging the errors the fastest... ditto: no more errors.

[Krosis]

Mine has stopped logging errors as well, and yes, I do have satelite signals now :p

[RandC]

No more APG errors here.

[jwciv]

Amidst reports on other forums that DirecTV/Tivo had identified a problem that was causing season pass failures/reboots, it appears that my tvlog stopped filling up with the APG messages sometime today.


confirmed on both my S2 DTV boxes, logs are calm once again:)

[syphix]

Reports on TiVoCommunity are saying this is simply a reversion to the old style of guide data. D* wants to use the "enhanced guide data" again and will once TiVo writes new code to simply disregard the error that kept building. So, what does that mean for us hackers who don't upgrade when sent the splices??

[PlainBill]

Reports on TiVoCommunity are saying this is simply a reversion to the old style of guide data. D* wants to use the "enhanced guide data" again and will once TiVo writes new code to simply disregard the error that kept building. So, what does that mean for us hackers who don't upgrade when sent the splices??
Splices??? Perhaps you mean slices.

If you have 'upgradesoftware=false' set in the boot parameters, the new software will never be installed, /var will continue to fill up and you will have nightly reboots.

Or you can use the patch posted earlier and the errors will not be logged, /var will not fill up, and you will still get nightly reboots.

The most intelligent approach is to wait until the patch locations are found for the new software, then install the upgrade manually and rehack it. The process is well documented, it takes less than an hour, and you don't even have to pull the drive.

PlainBill

[syphix]

Ouch...yep...I meant "slices". Sorry..:o

[w2kr]

Or you can use the patch posted earlier and the errors will not be logged, /var will not fill up, and you will still get nightly reboots.
PlainBillDid you really mean to say "you will still get nightly reboots". I would have thought they wouldn't happen since /var wouldn't be running out of space.

[playtowin]

I'm also curious about whether PlainBill meant to say this. My DVR40 at 6.2 patched to remove logging to tvlog is still rebooting even though var is not filling up.

I'd like to know if anyone else is experiencing this before I replace the drive.

[BTUxNine]

Unless you see indications in the log files, I wouldn't jump to the conclusion that your reboots are disk-related.

if reboots are happening fairly often, my first suggestion would be to disable all non-essential hacks (just leave telnet running) and see if your system stops rebooting.

[playtowin]

The unit is running 6.2, superpatched and using USB20 backported drivers. No other hacks are running, except telnet of course. I haven't changed anything on it for almost 18 months. Do you suggest I disable anything else? What should I look for in the logs as an indication of disk problems?

I had some rebooting problems (probably unrelated) about 6 months ago after remoting the unit into a closet with an RF IR remote relayer. I switched to a different IR remote relayer and the problems went away until a couple of weeks ago when everyone started getting the reboots.

[PlainBill]

Did you really mean to say "you will still get nightly reboots". I would have thought they wouldn't happen since /var wouldn't be running out of space.

They WILL happen if the TiVo is instructed to install the upgrade in the course of a daily call.

PlainBill

[BTUxNine]

The unit is running 6.2, superpatched and using USB20 backported drivers. No other hacks are running, except telnet of course. I haven't changed anything on it for almost 18 months. Do you suggest I disable anything else? What should I look for in the logs as an indication of disk problems?

I had some rebooting problems (probably unrelated) about 6 months ago after remoting the unit into a closet with an RF IR remote relayer. I switched to a different IR remote relayer and the problems went away until a couple of weeks ago when everyone started getting the reboots.
If your machine is one of those that has IR issues, definitely check for new sources of IR noise... one I've found with my setup is fluorescent replacement bulbs... the ones that replace incandescents. While they are warming up, my IR extender throws out a lot of noise

[playtowin]

My old IR extender picked up noise from my LCD TV for a minute or two after I turned it on. The Tivo remote would not get relayed until it settled down. The new extender uses a module that replaces one of the batteries in the remote, and does not rely on IR pickup. It works reliably with no interference problems.

The Tivo is in a closet with very little light. There is a DSL modem and Linsys router next to it. I wonder if the blinking LEDs from these units could be sending false commands to the Tivo. Seems pretty unlikely.

[Narf54321]

IR issues are a pain to troubleshoot. If you have a CCD-based camcorder or digital camera, you can attempt to scope out and locate interference sources with the LCD viewer. IR broadcasts look like white light on a CCD camera, which you wouldn't see with the human eye.

You can test by pointing the end of the tivo remote at the camera lens and pressing a button or two. You should see what appears to be two blinking white LEDs from the remote.

[playtowin]

I'll try looking for extraneous IR sources, just to rule it out. But the continuing reboots with plenty of space left in /var probably point to a hard disk or some other hardware problem.

[playtowin]

My problem was the IR extender after all. I'm using the one from Next Generation Home Products with the 433 MHz transmitter that replaces one of the batteries. If you put the receiver close to the DVR40, it picks up RFI and generates spurious IR output. I moved the receiver 3 or 4 feet away from the DVR40 and set the switch on the bottom to the low sensitivity position. I have had no reboots for a couple of days.

[BTUxNine]

Glad you found the cause... of course, I REALLY wish they'd fix the bug that's allowing IR noise to trigger a reboot

[playtowin]

I agree. Although it seems doubtfull that they will fix anything that doesn't benefit their DVRs. I imagine they will put out a fix to make TiVos compatible with the new guide data format.