callerID Unresolved Issues Fix/Workaround?

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.

 

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.

 

Advertisements

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.

 

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.

 

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.

 

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.

 

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..

 

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.

 

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.

 

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.

 

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.

 

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).

 

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.

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.

 

This worked in fixing my problem with .64

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

 

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.