Saku,

OK, I have done some more investigation of this problem. I wasn't able to track down a specific event or activity that reliably causes failure, but I have found the means of failure. I used a script running tcpdump to watch communications with xml.qrz.com to look for issues.

The script I used is:

#!/bin/bash
# Captures QRZ traffic, adds timestamps, and highlights Errors
echo "Monitoring QRZ traffic... Logging to file if redirected."

sudo tcpdump -i any -s 0 -l -A 'host xml.qrz.com' 2>/dev/null | \
grep -iE --line-buffered "HTTP/1.1 [0-9]|.*|GET /xml" | \
while read -r line; do
# This adds the [YYYY-MM-DD HH:MM:SS] prefix to every line
printf "[%(%Y-%m-%d %H:%M:%S)T] %s\n" -1 "$line"
done | \
sed --unbuffered 's/HTTP\/1.1 500.*/\x1b[31m[!] SERVER ERROR 500\x1b[0m/' | \
sed --unbuffered 's/\(.*\)<\/Error>/\x1b[33m[!] QRZ API ERROR: \1\x1b[0m/'

The output from this script is attached.

I found that the normal case of API Session Timeout is handled easily, with CQRLog automatically logging in again, and QRZ providing data again. However, if the response from QRZ is something else (specifically: Invalid session key) then nothing happens. I suspect there is a line of code somewhere that handles the timeout that doesn't have a case to handle the invalid API key. I think this might be due to an expired key that is stuck and reused? Not sure, but at least I have some more specifics to report.

Thanks!

73,
Dave, N1KX