# callerID Unresolved Issues Fix/Workaround?



## alert5 (Nov 16, 2003)

Ive tried to keep one of our favorite tweaks from inexplicably failing. Yes, I read and re-read the threads on this subject and did the suggested file changes to keep this problem from recurring. CallerID still quit working every couple of days.

From my experience and from other posts on the subject, a reboot brings callerID back to life. I know you can also restart NCID from a bash prompt, but either option is an irritating process as youve already missed a least one call before you realize the server is stopped or hung. 

I also noted the cidcall log would go missing at some point and would not return even after a reboot. The only way I could get callerID to work correctly again with logging was to do a tweak uninstall and tweak install.

I decided that if a reboot every Sunday and Wednesday was a good thing to do, then doing a reboot every day couldnt hurt. So, I modified the crontabs root file to force a reboot every day based on my time zone. 

I would think it a matter of good practice that the crontab date and time should reflect your time zone and match the system time that your callerID box is using. So I modified all other crontab tasks to reflect the correct time zone as well. On my callerID DTiVo, those tasks include stopping and starting TWP, daily fakecall, cron.test.out deletion, log wiping, and season pass backup.

Since forcing a daily reboot two weeks ago with a match to my system time zone, NCID has not stopped unexpectedly and the cidcall log has not gone away. Tivocid clients are displaying fine as well.

YMMV but this seems to have done the trick for keeping callerID up and running for my setup.


----------



## jlc (Jun 18, 2002)

I am very interested in this. NCID version 0.63 and version 0.64 has code in it to prevent this. There is also a server log file that indicates when ncidd terminates. Could you try NCID version 0.64 and see if ncidd stays up and does not go away?

If the cidcall.log file goes away (this also includes ciddata.log), the server will not create it or try to write to it. If you need to restore it, use the touch command: "touch /var/log/cidcall.log" to create a zero length file that ncidd will populate. Both files are considered optional. They must be present for the server to use them.


----------



## rbautch (Feb 6, 2004)

Fyi, if anyone used my enhancement script to install NCID, it appends a touch command to the author file to create cidcall.log if it ever gets wiped. I haven't yet updated the script to use the newest version of NCID - it's currently using version 6.1 - but it's on my todo list.


----------



## alert5 (Nov 16, 2003)

> I am very interested in this. NCID version 0.63 and version 0.64 has code in it to prevent this. There is also a server log file that indicates when ncidd terminates. Could you try NCID version 0.64 and see if ncidd stays up and does not go away?
> 
> If the cidcall.log file goes away (this also includes ciddata.log), the server will not create it or try to write to it. If you need to restore it, use the touch command: "touch /var/log/cidcall.log" to create a zero length file that ncidd will populate. Both files are considered optional. They must be present for the server to use them.


After almost three weeks of flawless operation, I'm skittish about messing with NCIDD. Not one failure and the cidcall log is always there.

Are you asking me to stop rebooting every night with the 0.64 version installed or just to use the 0.64 without changing crontab?


----------



## jlc (Jun 18, 2002)

I am asking you to use 0.64. It has important fixes over previous versions. I do not expect your system to get in trouble. I am hopping you would stop the rebooting. You could comment out the line in crontab and then replace it if you had to. The prerelease of 0.64 was tested on two systems that had a problem. One was a TiVo. Both systems appear to have the problem solved. As a side benefit, ncidd.log usually indicates what was going on when ncidd went away, so if it happens again the log can help me determine why. The server log file is not optional so ncidd will try to create it if it does not exist.


----------



## starbiker99 (Feb 4, 2005)

Hey jlc I am going to put .64 on my Dtivo later tonight must I replace all of the files or can I leave my old alias info. I have a lot built in there.


----------



## jlc (Jun 18, 2002)

Be sure to save your ncidd.alias file and ncidd.conf file before you install it. Both files changed a bit. The alias file is shipped without aliases, so just add your aliases at the end. The change concerns the new alias and how to use it. The ncidd.conf file also changed and has a new option, so its best to add your changes, if any, to it. Any other *.conf file you changed will need to be saved. 

The alias file is a feature I also use. It's surprising how screwed up the telco CID database is.


----------



## 15968 (Jan 29, 2002)

I have a Zippered DirecTiVo that I decided to try upgrading the ncidd to .64. I did a cd /enhancements/varhacks and then untar'd the file so that it would replace stuff from there down. This all seemed to work fine. I then shutdown the ncidd and tivocid and started them back up. ncidd started fine, but tivocid gave:

BGError: error reading "file0": I/O error

I then tried doing tivocid -V and this worked just fine. Tried going back to a straight tivocid and again the same error. 

I then decided to reboot the box to see if that might clear something up. Now the box just hangs during reboot. On the screen it hangs when trying to aquire sat signal at 9%. Telnet will let me in until that is reached and then it freezes...

Have I killed my DirecTiVo??? Any ideas and help would be appreciated.


----------



## 15968 (Jan 29, 2002)

Well, in an attempt to fix my TiVo, I setup a series of commands that I could quickly execute when I could telnet to the box before it locked up. While my plan worked, I think I messed up permission problems so now my rc.sysint.auth file isn't running on reboot :-(. DirecTiVo works fine, but I can't connect to it via telnet or ftp. Guess I'm going to have to pull the drive and try to mount it on a Linux box I have here and see if I can fix whatever is wrong with rc.sysinit.author and then try to boot again.

Still, for those that are familiar with NCID, I'd be interested in hearing what possibly the error I was seeing in my post above was..


----------



## jlc (Jun 18, 2002)

Your NCID error seems to be a bug in tivosh. I improved the server for the TiVo, but managed to break ncid (also called tivocid). Tivosh is an old version of tclsh, so when message support was added, it broke when it monitored stdin for a message in the background. Tclsh handled this OK.

The easiest way to fix this is to comment out line 574 in ncid, make it: #initMSG 

NCID 0.65 is planned to be released July 1 to get the fix out. In addition, TiVoCID was enhanced to display messages and a line indicator if it receives one. VOIP support was also improved.


----------



## sabu (Jan 29, 2002)

Is there a way in the current NCID to strip the leading 1 from the phone number being supplied? The Vonage box that I have sends numbers as 18005551212 instead of 8005551212. This leads to the display being messed up on the TiVo, etc.

If there isn't, I'd like to request it as a future enhancement.

Thanks.


----------



## jlc (Jun 18, 2002)

You must be running a very old version of TiVoCID. That was fixed in version 0.11. The current NCID should work OK. If you have the server on a computer and upgraded, you must also upgrade the TiVo package. If you open a terminal window and execute "tivocid -V" you should see the version numbers for the server and client on the second and third lines. It the client is version 0.6?, let me know. If not, wait until Saturday and upgrade to NCID version 0.65. 

Incidently, Vonage Caller ID can be optained, over the network, without a modem, if you are using Linux, FreeBSD, or OSX. It should also work on a TiVo if Perl, Net-Pcap, and libpcap are available.


----------



## sabu (Jan 29, 2002)

I checked and the version I'm currently running is .63. I hacked the ncidd code to strip the 1.

I downloaded .64 and tried the VOIP client. My fileserver cannot sniff the traffic from the Vonage adapter. The adapter is currently in the same subnet, but I'm using a switch not a hub, so I'm guessing it never even sees those packets.


----------



## cheer (Nov 13, 2005)

sabu said:


> I downloaded .64 and tried the VOIP client. My fileserver cannot sniff the traffic from the Vonage adapter. The adapter is currently in the same subnet, but I'm using a switch not a hub, so I'm guessing it never even sees those packets.


No it wouldn't. But you might look at the documentation for your switch...some switches will let you put a port in "mirroring" or "sniffer" mode (or somesuch...basically you can designate one switch port to see all the traffic that another port sees).


----------



## jlc (Jun 18, 2002)

> Originally Posted by sabu
> I checked and the version I'm currently running is .63. I hacked the ncidd code to strip the 1.


The ncidd code is not suppose to strip the 1, it is the job of the ncid client. If TiVoCID displays the 1, it is a problem in its tcl code. If the new version is still broken, perhaps you can fix it and send in the patch. NCID version 0.65 was released to fix the broken TiVoCID. It also has an enhanced VOIP feature and client.



> Originally Posted by sabu
> I downloaded .64 and tried the VOIP client. My fileserver cannot sniff the traffic from the Vonage adapter. The adapter is currently in the same subnet, but I'm using a switch not a hub, so I'm guessing it never even sees those packets.


The biggest battle with using SIP is to be able to get it from your adapter. If you do not get it, with the default port (5061) try port 10000. Newer Vonage systems use 10000 instead of 5061. I am using the Linksys RT31P2 Router and was suprised to find the SIP packets on my network. The first link on the NCID web page (for a OSX Pop-up) is a guy that added a hub before his router so he could monitor his SIP packets.

The SIP client is very new and is not out there in more than a couple of places. If you get SIP working and use the client, any fixes,enhances, or suggestions would be very welcome.


----------



## 15968 (Jan 29, 2002)

jlc said:


> The easiest way to fix this is to comment out line 574 in ncid, make it: #initMSG


This worked in fixing my problem with .64


> NCID 0.65 is planned to be released July 1 to get the fix out. In addition, TiVoCID was enhanced to display messages and a line indicator if it receives one. VOIP support was also improved.


I've now upgraded to .65 and it seems to be working just fine. Thanks!


----------



## jlc (Jun 18, 2002)

For those interested, there is a writeup on configuring your home network for SIP-based callerID. Once you are able to obtain the SIP packets, you can use NCIDsip to obtain the Caller ID information from the network.


----------

