Erasing activity log?

[DssConman]

As a long time "tester" of DSS, i thought I would try my hand on a Directivo unit. I've read a lot of good information on this forum and need a answer to clearup some confusion.

First off let me say I am a virgin to Linux, so be kind. I plan on using Emulation with my directivo. i was going to subscribe to DTV and Tivo so that I would have fully functionality for recording. My plan, like many others before me, is to connect via the phone line once a month and so i keep my recording ability. I also understand there is a log file that will record my actions that occur. Since I'm also emulating all the other time, how do I delete this file? I think I saw some procedure to just delete or erase this file somewhere around here but it was too confusing to me(remember Linux newbie). Is there a procedure (step by step) that will erase this file that a newbie can understand?

Thanks.

[BubbaJ]

since you are planning on subscribing, I have a solution for you.

1) take the drive out of your dtivo and hook it up to a PC (30G in dual drive)

2) move the crypto program to ocrypt (mv /tvbin/crypto /tvbin/ocrypt

3) make a /tvbin/crypto file (joe /tvbin/crypto (don't enter anything just <space> <backspace>))

4) make the crypto file executable (chmod +x /tvbin/crypto)

5) modify the rc.sysinit to not start the log daemons (documented elsewhere, basically comment out (with a #) the lines that have klogd or syslogd in them)

6) delete any existing logs

7) rinse, repeat, backup

notes: This will make your dtivo permenatly believe that it is new account status.. :) this causes no problems as long as you leave the phone line connected. The tivo goes about it's merry way download the guide, yada yada yada, yet never has any clue about what it's service number is, or what you've been watching. tivo, thinking that it's got a whacked user, will schedule an upgrade to 2.01.01 (or maybe something else) either interrupt its attempts or just replace the new image with your backup when that happens.

note2: This is REALLY stealing tivo service, but if you're paying for it, then I don't care and neither should anyone else. This does in fact work on SA Tivos as well, the guide data is delivered on a regular basis, perpetually believing that you are either a new user or a valid user with a whacked system

note3: this'll stop working if everyone starts doing it, I would imagine. (i.e. they won't send guide/tivolution shyte to bogousers)

[DssConman]

BabbaJ,

Thanks for the info.

I took the easy way. I returned the Directivo and bought a UTV. The EMU script out there opens up all functions and channels. I just can't add any storage space at this time.

[superzap]

I thought that if you called TiVo and asked that your viewing habits not be shared that the logs would not even be uploaded. At least that was my understanding for a S/A TiVo. Doesn't it work the same for a DirecTiVo?

[Qyv10]

Superzap, from what I understand Dtivo's don't go through tivo but through DirecTv. Also stopping the logs from starting has NO effect, I know this for a fact. A file called tivoLog.prv has a recording of EVERY key press AND channel and show name you watch. For those who test that means all the illeagle chanels you watch. I tried erasing this file and stopping the logging daemons from starting. I then told it to make a daily call and watched it creat a new tivoLog.prv file that still had everything I had done and watched after I had erased that exact file.
So unless you want to risk it I would suggest finding a different way to do this.

[Venom]

Rather than erasing the log file, has anyone tried to simply chmod it so it can't be written anymore? Maybe that will cause some fatal error, but perhaps it will just move on. :)

[BubbleLamp]

Originally posted by BubbaJ
since you are planning on subscribing, I have a solution for you.

1) take the drive out of your dtivo and hook it up to a PC (30G in dual drive)

2) move the crypto program to ocrypt (mv /tvbin/crypto /tvbin/ocrypt

3) make a /tvbin/crypto file (joe /tvbin/crypto (don't enter anything just <space> <backspace>))

4) make the crypto file executable (chmod +x /tvbin/crypto)

5) modify the rc.sysinit to not start the log daemons (documented elsewhere, basically comment out (with a #) the lines that have klogd or syslogd in them)

6) delete any existing logs

7) rinse, repeat, backup

notes: This will make your dtivo permenatly believe that it is new account status.. :) this causes no problems as long as you leave the phone line connected. The tivo goes about it's merry way download the guide, yada yada yada, yet never has any clue about what it's service number is, or what you've been watching. tivo, thinking that it's got a whacked user, will schedule an upgrade to 2.01.01 (or maybe something else) either interrupt its attempts or just replace the new image with your backup when that happens.

note2: This is REALLY stealing tivo service, but if you're paying for it, then I don't care and neither should anyone else. This does in fact work on SA Tivos as well, the guide data is delivered on a regular basis, perpetually believing that you are either a new user or a valid user with a whacked system

note3: this'll stop working if everyone starts doing it, I would imagine. (i.e. they won't send guide/tivolution shyte to bogousers)

While this sounds pretty ingenious Bubba, I think it'd piss off TiVo big time if they kept getting upgrade requests from a certain phone number every month. (See Moron thread you know where.)

[BubbleLamp]

Originally posted by superzap
I thought that if you called TiVo and asked that your viewing habits not be shared that the logs would not even be uploaded. At least that was my understanding for a S/A TiVo. Doesn't it work the same for a DirecTiVo?

I'm not sure they actually stop uploading the logs SZ. I think they are sent but then filtered out after the fact based on your ID#. I could be wrong, in which case I'm sure someone will correct me.:rolleyes:

[superzap]

Geez, you guys resurrected a 3 month old thread. LOL
Notice what Qyv10 said about the logs. Which makes me think that the null io file method is the best so far for dealing with the logs.

Venom:
I think you mean chattr not chmod, and I tried to chattr the log files and went into a reboot loop.

[Venom]

I think that redirecting the logs will work fine. GOD I wish i wasn't at work today! :)

You could just create the file tivoLog.prv using some linux trickery, i just dont know if "ln" is included with the distros.

Creating a symbolic link to /dev/null is something I do on lots of servers to get rid of logs.

By doing

ln -s tivoLog.prv /dev/null

AFTER you delete tivoLog.prv will create it as a link that dumps all content of that to dev/null, thus erasing it. If you try and create a link with the name of a file already there, it will give you an error, so delete the file then re-make as a link.

All this provided that you can even do LN with a boot cd, but those that have linux boxes sitting around should be able to mount and create symbolic links just fine.

May be way off, but it may pan out.

[superzap]

mknod is the trick.
See my post here ===> http://www.dealdatabase.com/forum/showthread.php?s=post&postid=22003#post22003

[JJBliss]

Originally posted by superzap
mknod is the trick.
See my post here ===> http://www.dealdatabase.com/forum/showthread.php?s=post&postid=22003#post22003

OK.. I did it before I left for dinner. I rebooted, things look cool.

In my rc.sysinit:

I ALSO did the rmdir/mkdir combo as well as the runsyslog=false, AND I tried Venom's suggestion of

ln -s /var/log/tivoLog.prv /dev/null

Everything looks good except the tivoLog.prv file is recreated on reboot and still captures all my keystrokes.... Is something wrong or is that what I was hoping to accomplish ?

How big will this file grow ?

[superzap]

Go to the link in my post above and use the mknod technique. Get rid of all the other stuff and especially don't use the rmdir/mkdir combo. This is working for me.

[1dave1]

Doesnt CCC "claim" that they're units do not keep a log?

If thats so, they fixed the log over load problem.

I've looked over the files that have been posted from a ccc tvo, and I cant see where they've stopped it

[superzap]

CCC doesn't do anything for controlling the logs that I can see except the rm/mkdir in rc.sysinit which, IMHO is not adequate.