# Purpose of tvlog file?



## ForrestB (Apr 8, 2004)

I'm having some reboot problems with my zippered DirecTivo - though it's only happening on 1 of my machines. I checked the logs on the problem Tivo, from TivoWebPlus 1.2.1 and the tvlog file it's over 48 MB - and seems to consist mostly of error messages. Could this be the cause of the reboots?


----------



## dlmcmurr (Mar 2, 2006)

I saw a couple of threads, one here and another on DDB, speculating that there might be an end-of-year problem in the guide data causing the errors that might work itself out in the next few days.

As for me, I modified my cron entry to run wipelogs every night instead of once a week. Plus, I've been occasionally looking in TWP and clicking on the clear link on that one log. I hope it settles down soon.

Dave


----------



## Krosis (May 10, 2004)

This problem seems to not only not been fixed by the date rollover, for me it seems to have gotten a lot worse. My TvLog has been growing at a ridiculous rate. Almost 500 meg in 1 hour! I'm also starting to have problems with TivoWeb crashing but I'm not sure if it's related. It was working fine before the first.


----------



## SteelersFan (Sep 7, 2004)

Not sure if you missed this thread. It has a couple of ideas for work-arounds.


----------



## ForrestB (Apr 8, 2004)

I cleared the Program Guide and ToDo List last night to try and fix the problem. It didn't fix the problem - tvlog is still growing like crazy but Season Passes seem to be working. It's been 12 hours since I cleared tvlog from TWP 1.2.1, and it's already up to 18 MB with the same two errors repeated over and over:

Jan 3 11:45:13 (none) ApgCamInterfaceBase[227]: FindServerObject: scanner found nothing at A00000000, err = 0x0
Jan 3 11:45:13 (none) ApgExprEvaluator[227]: DoEvaluate() returned err = errDbNotFound, setting result to zero

It's get's stranger - my second zippered DirecTivo isn't having any problem and TWP 1.2.1 doesn't show the tvlog file!


----------



## jcorbin121 (Sep 16, 2006)

I too am having the issue, my tvlog is growing to between 110-120gig before it fills /var... I modified the syslog.conf to stop logging into the tvlog for now until someone finds out wtf is causing this, I have 3 series 2 DTivo's all doing the same, all built from InstantCake and had the enhancement script run. Funny how it just started......


----------



## Krosis (May 10, 2004)

I still haven't taken any action other than to manually delete it every day or two. I always check my Tivo at least twice a day a day and that extra check of the log is no big deal. I'm more concerned about the extra HD activity it's generating. Another poster on another forum claimed his seems to have fixed itself in the last day or two, so I'm still excersising patience. If this continues after another week or so I will probably just disable logging to the Tvlog file and be done with it. 

I have not noticed this to cause my Tivo to reboot, the standard var cleanup routine just seems to jump in and delete it. At least I've had uptimes of 14+ days and I know it can't go that long at this rate of growth (that was before I started manually deleting it).

The issue I mentioned with TivoWeb seems to have been a fluke as I've had no further problems with it.


----------



## ForrestB (Apr 8, 2004)

OK, this is getting stranger. Both of my DirecTivo's rebooted precisely 15 hours and 30 minutes ago and now they both have huge tvlog files - which I cleared at lunch time today. 8 hours later and they're up to 10 MB.


----------



## doconeill (Dec 13, 2002)

I've set up cron entries on all three of my zippered/enhanced DTV units to zero the files. All three have tvlog files that grow out of control and would cause a reboot otherwise.

There are reports of reboot issues on non-zippered units. I wonder if there is a widespread flaw?


----------



## BTUx9 (Nov 13, 2003)

I very much doubt this logging problem is happening to only hacked dtivos... no empirical evidence, just an educated guess


----------



## ForrestB (Apr 8, 2004)

Currently I'm using TWP to clear the tvlog on a daily basis and both of my Zippered DirecTivo's have been running for 3 days without a problem. Right now I'd say users with hacked DirecTivo's are in a better position - as they can easily clear tvlog before the file get's too big causing an unscheduled reboot.


----------



## BTUx9 (Nov 13, 2003)

Yes and no... I don't think this problem is causing all that many reboots on unhacked tivos
I think that running certain hacks that use var are causing more reboots for some hacked tivos (my 3 haven't reboot yet, and the logs have cycled many times now)


----------



## bengalfreak (Oct 20, 2002)

This problem is definately causing reboots on unhacked DTivos. Once /var gets too big, the Tivo is rebooted and /var is rewritten from scratch. Yesterday, I commented out the line in syslog.conf that writes to tvlog and now my DTivos are all behaving normally. If you have a hacked DTivo, you don't want to have /var rewritten and lose all of your hacks.


----------



## temp357 (Feb 18, 2004)

Anyone else having their tvlog filling up with this? My entire log file is full of them and i have no idea what to do about it. I'm currently recording everything in pcm.

Jan 7 13:32:25 (none) DigitalTuningUtils[196]: Could not get std audio SCID for channel ...Looking for AC-3 audio SCID
Jan 7 13:32:25 (none) DigitalTuningUtils[196]: Could not get audio SCID for channel
Jan 7 13:32:26 (none) DigitalTuningUtils[196]: Could not get std audio SCID for channel ...Looking for AC-3 audio SCID
Jan 7 13:32:26 (none) DigitalTuningUtils[196]: Could not get audio SCID for channel
Jan 7 13:32:28 (none) DigitalTuningUtils[196]: Could not get std audio SCID for channel ...Looking for AC-3 audio SCID
Jan 7 13:32:28 (none) DigitalTuningUtils[196]: Could not get audio SCID for channel
Jan 7 13:32:29 (none) DigitalTuningUtils[196]: Could not get std audio SCID for channel ...Looking for AC-3 audio SCID
Jan 7 13:32:29 (none) DigitalTuningUtils[196]: Could not get audio SCID for channel
Jan 7 13:32:30 (none) DigitalTuningUtils[196]: Could not get std audio SCID for channel ...Looking for AC-3 audio SCID
Jan 7 13:32:30 (none) DigitalTuningUtils[196]: Could not get audio SCID for channel
Jan 7 13:32:31 (none) DigitalTuningUtils[196]: Could not get std audio SCID for channel ...Looking for AC-3 audio SCID
Jan 7 13:32:31 (none) DigitalTuningUtils[196]: Could not get audio SCID for channel
Jan 7 13:32:32 (none) DigitalTuningUtils[196]: Could not get std audio SCID for channel ...Looking for AC-3 audio SCID


----------



## BTUx9 (Nov 13, 2003)

bengalfreak said:


> This problem is definately causing reboots on unhacked DTivos. Once /var gets too big, the Tivo is rebooted and /var is rewritten from scratch. Yesterday, I commented out the line in syslog.conf that writes to tvlog and now my DTivos are all behaving normally. If you have a hacked DTivo, you don't want to have /var rewritten and lose all of your hacks.


No, as I wrote before, that isn't happening on all dtivos... I have 3 hdvr2's, and the only time they've rebooted in the last 2 months was yesterday when I did a manual reboot to check something. They are all filling tvlog and clearing it automatically without a reboot. 2 of them have no programs running from var and one does.


----------



## mas99 (Jan 9, 2007)

> Originally posted by *BTUx9*
> No, as I wrote before, that isn't happening on all dtivos... I have 3 hdvr2's, and the only time they've rebooted in the last 2 months was yesterday when I did a manual reboot to check something. They are all filling tvlog and clearing it automatically without a reboot. 2 of them have no programs running from var and one does.


From the reading I've done tonight on the forums, it seems to be more widespread than hacked units. The only hack I have on my D* HR 10-250 is an added hard drive. It's been having the same problem -- rebooting and occassionally locking up. All this since the 6.3a upgrade and largely since christmas, including twice tonight. I can't tell you whether it's been happening on our HDVR2, as we aren't watching it much.

I don't have telnet access, so I can't see the logs.

The hard drives in the HR 10-250 are less than 6 months old.

---------------------
1- HR 10-250
1 - HDVR2
2- D10


----------



## temp357 (Feb 18, 2004)

Looks like after the cron job runs the log files don't reinialize until after you reboot the unit.


----------



## BTUx9 (Nov 13, 2003)

depends on how you clear the logs... if you delete them then you're right... they won't reinitialize until the next boot.


----------



## bengalfreak (Oct 20, 2002)

BTUx9 said:


> No, as I wrote before, that isn't happening on all dtivos... I have 3 hdvr2's, and the only time they've rebooted in the last 2 months was yesterday when I did a manual reboot to check something. They are all filling tvlog and clearing it automatically without a reboot. 2 of them have no programs running from var and one does.


I didn't say that it was happening on ALL DTivos, merely that having a hacked unit is not stopping it from happening.


----------



## goony (Nov 20, 2003)

I suspect that only some guide data entries are corrupted (by some change that DirecTV made to the guide data format) - if you have no season passes or wishlists that match the guide entries then you probably don't see the problem at all.

Thus, a wide variety of reboots or missed recordings ranging from "often" to "never".


----------



## doconeill (Dec 13, 2002)

Size of season passes or presence of wishlists are irrelevant. 

I have three TiVos, all are now hacked. One six months ago, one a few weeks ago, and one a week and a half ago.

One has 21 season passes, one has 8, and one has 2. None have wishlists.

All have a tvlog file that grows at the same rate. All three are over 5MB after 3.5 hours. I'm zeroing it out every 4 hours just to be safe.

I've removed the two season passes from the one that had only two. No difference yet, but I'll let it go overnight and report back sometime tomorrow. I doubt there will be a difference.

And as far as hacked vs. unhacked - I tossed the original virgin TiVo drive from the one I did a week and a half ago. Sure enough, the tvlog file showed the same growth rate - 14MB after around 9.5 hours. syslogd restarted that morning, probably to clear space. So hacking has nothing to do with it either.

Does it cause reboots? Well, I believe its supposed to try and clear space before rebooting, but I believe it can also reboot and rebuild /var if necessary. At any rate, with the standard 124MB /var partition with a nominal 10MB normal usage, at the growth rate of about 1.43MB/hr, it would just short of 80 hours to fill /var and cause SOME sort of action.

Assuming no change in the tvlog growth rate, I'll disable all scheduled reboots and see what happens in 80 hours.

Of course, this will mean nothing, since no one at DTV or TiVo will care what data we can come up with...but perhaps there will be less speculation about season passes, hack, et. al...

Also, I'm willing to try a CD&E test as well, if someone can tell me what I'll need to fix afterwards  Just rerun tweak.sh from serial console?


----------



## doconeill (Dec 13, 2002)

No change in tvlog growth without any season passes. 

I've disabled reboots, log wipes, etc.

Something should happen at about 7pm ET on Monday when the log gets too big.


----------



## BTUx9 (Nov 13, 2003)

Thanx for giving more concrete data on some of these speculated issues... someone in another thread reported his problem stopped after deleting logs and rebooting (very suspicious in that others had var wiped and that didn't help)... turned out that after his reboot, his tivo was stuck in the acquiring satellite stage, and that's why the logging stopped!

I wonder how many s2 dtivos AREN'T having logging issues.

a personal p.s.: what do you think of this (non) winter in the Boston area? January and my kids were out in shirtsleeves the other day!

EDIT: guess it's not all s2 dtivos... someone running 6.1 on an r10 reported a var problem in a thread on DDB, but it was just /var/cache growing... not tvlog


----------



## temp357 (Feb 18, 2004)

On my zippered drive, the tivo stopped logging after the cron job to archive the logs was run. the system has been running rock solid since the cron job ran and the logs haven't been reinitiated. I'm pretty sure the problem will come back the next time I reboot the tivo.


----------



## BTUx9 (Nov 13, 2003)

then cron is clearing the logs in a bad way, IMHO... even though you can't see the file, the tivo s/w is still logging to it and it's still growing... this may be more likely to trigger a var cleanup on reboot (not 100% sure of that, but it makes some sense)


----------



## doconeill (Dec 13, 2002)

You cannot simply remove the file. If you do, syslog will still have it open and continue writing - you just can't see it any more. "df" will show you that you didn't recover any space.

If you want to zero the file, then "cp /dev/null /var/log/tvlog" is the most effective way, but that will simply start the logging over.

Edit: Forgot - if you remove the file, restarting syslog (or perhaps a "kill -HUP" - depending on this version) will close the file, freeing the space, and then start a new one as well.

If you want to eliminate the logging altogether, removing/commenting out the appropriate line in /etc/syslog.conf is the correct thing to do. As the file is generally useless, after all is said and done I plan to do that and eliminate the overhead of actually processing all that garbage. 

FYI, I have not been having any season pass or (known) reboot issues, although my HD-DVR80 did reboot randomly while I was watching it, and it was not for a full /var (I was already resetting the file). I'm keeping an eye out though.

Test status: tvlog growth is right on schedule, perhaps a little ahead. 72.75 hours to go. 

As for weather, I was barbecuing in shorts last week. This week, my office was about 45 degrees due to HVAC problems...


----------



## jporter12 (Mar 10, 2006)

I'll add my experience with the tvlog in here.

I had no idea what was causing the reboots on my zippered TiVo's, but I do see the tvlog growing like crazy, with the same message, over and over....

On one of my TiVo's, I get some weird lockup problems. Last night, out of the blue, the picture just hung up, and the unit would not respond to anything other than pulling the plug. All seems to be fine since. I had cleared the tvlog a short time (maybe 10 minutes?) before the lockup. Also, on the same one, it will occasionally lockup and the network activity light will be going crazy.

Anyway, I thought I'd add my bit in, maybe there's a clue in there that someone may be able to figure out what's going on!


----------



## BTUx9 (Nov 13, 2003)

couple questions:
how did you clear the log?
how full was /var when you cleared the log?


----------



## jporter12 (Mar 10, 2006)

BTUx9 said:


> couple questions:
> how did you clear the log?
> how full was /var when you cleared the log?


Oops, forgot to say I cleared it through TWP, and the log had grown to something like 40 MB I think, so not all that huge. This was on the DSR7000 with the 300 G B drive, according to TWP I have about 60 hours free on it, most of the time....


----------



## BTUx9 (Nov 13, 2003)

it was space on var I was actually talking about... in any case, it's unlikely a 40MB log file would fill up var given the amount of free space the tivo normally reserves there.

You may want to edit syslogd.conf to disable logging, to see if stability improves, but it seems a bit unlikely

Switching to TWP2 may help stability, also


----------



## dlmcmurr (Mar 2, 2006)

jporter12,

A bit off topic for this thread, but regarding your system locking up, I had the exact same symptoms on one of my two zippered systems about every two weeks or so, usually within 24 hours of a reboot and while it was in standy while I was at work. The only difference I could think of between the two units was that I was running the ncid stuff on the one with problems. Since I never could get that to work without having problems with it picking up the phone to call home all the time, I turned the programs off and haven't seen a problem since.

Excuse me while I go knock on some wood  

Back on topic, would using TWP Info and looking at the %Capacity for /var be one of the simplest ways of monitoring for problems?

Dave


----------



## BTUx9 (Nov 13, 2003)

UPDATE: looks like D* may have thrown a switch... the bombardment has stopped... my 3 dtivos are no longer getting bombarded with tvlog messages


----------



## ForrestB (Apr 8, 2004)

It looks like DirecTV solved the problem - there's no repeating error messages in tvlog on both of my Zippered DirecTivo's!


----------



## doconeill (Dec 13, 2002)

Two of my three units rebooted this morning so far, including the one I was running my var full test on. None of the three are logging the errors any more. So much for the test...

I don't know why two of the three rebooted, since it appears that a reboot was not necessary to correct the problem on the third.

D'oh...for some reason one of them rebooted a second time within about 15 minutes...can't find anything in the logs as to why though...both times it was in the midst of a transfer from one of the other units though...


----------



## jporter12 (Mar 10, 2006)

Mine has stopped the logging nonsense also! Now I can get down to the lockup issue, if it indeed still exists!

I can just take a guess that the problem was something in the guide that has expired, seeing that it started sometime about 2 weeks ago???


----------



## jporter12 (Mar 10, 2006)

Oh, neither of mine rebooted in the las day and a half.


----------



## BTUx9 (Nov 13, 2003)

jporter12 said:


> Mine has stopped the logging nonsense also! Now I can get down to the lockup issue, if it indeed still exists!
> 
> I can just take a guess that the problem was something in the guide that has expired, seeing that it started sometime about 2 weeks ago???


From timing and whatnot, I think it much more likely that it was something within the satellite stream, rather than guide data.


----------

