UniTrunker logs

[nocpire]

Upgraded from 11 to 17. S00000<however many 0's>1 has todays log and 0029.zlog from yesterday. Is there a setting to cache logs indefinitely without deleting them? Seems to be the same way in the R0000001 directory too. Program created S<blah>2, 3, etc... directories but they're empty.

p.s. The CC chase is great, now I don't have to get up to manually change the radio.

Thanks UT!!!

 

[SCPD]

Upgraded from 11 to 17. S00000<however many 0's>1 has todays log and 0029.zlog from yesterday. Is there a setting to cache logs indefinitely without deleting them?

Logs are not deleted, only archived (gzip compressed) at midnight local time.

When a new site is created, logging is not turned on by default. Some sites exist only for a few seconds while the program is determines whether the control information matches a previously recorded site. The empty S folders are likely residual from this process. The R folders are one per receiver - no more.

 

[nocpire]

I just bounced the host and the 0029.zlog file is gone from the r00000001 subdir. And was nonexistent (before the bounce) in the s00000001 folder. Yes, the checkboxes are (still) set under the control and decode sections in the radio control window, and the history is set as well under the ad-hoc 0 window. Fortunately I saved the r-log to an upper level dir. before the bounce. So yes, somehow the logs are getting wiped out. I'll check after midnight to confirm that the s-logs are still showing up.

 

[SCPD]

The program creates a daily log file whose name starts as UniTrunker-YYYYMMDD.LOG.

The previous day's log is compressed and renamed to end with ".log.Z".

Any file ending in zlog, such as compress.zlog or 1234.zlog is a temporary file; not a permanent log file.

 

[nocpire]

Yesterday, I stopped UniTrunker and the r-level log disappeared. After I bounced the host, the s-level log was gone. Today, I did the same, and the r-level log survived the program shutdown, but not the bounce. The s-level log was not to be found at any point in time. I did this at 01:3x local time. The logs are not getting written in the traditional format as described, but as 0029.zlog on every day. I'm going to blast the program and reinstall.

 

[nocpire]

Deleted and reinstalled UT. Still getting temp logs (0029.zlog) in the r and s level directories. They were still there at 12:00 (noon) local after I stopped the program. Restarted the machine and they were gone. Also noticed but failed to mention that before I reinstalled, there were 20 UniTrunker.xml files in the UT directory. UniTrunker.xml, UniTrunker.xml.1 -thru- UniTrunker.xml.19. Might just roll-back to 16 after this weekend.

 

[SCPD]

Deleted and reinstalled UT. Still getting temp logs (0029.zlog) in the r and s level directories. They were still there at 12:00 (noon) local after I stopped the program. Restarted the machine and they were gone.

I have no idea why your files disappear after a reboot. Are you low on disk space? Do you have some program that looks for and deletes log files at start up?

Also noticed but failed to mention that before I reinstalled, there were 20 UniTrunker.xml files in the UT directory. UniTrunker.xml, UniTrunker.xml.1 -thru- UniTrunker.xml.19.

This is normal. Look at the Archive tab. The progressively numbered xml files are backups of your data. The unnumbered XML file holds the current data.

 

[nocpire]

Free space good, 68GB of 74GB free. No program running to delete log files. Can't understand it especially since they don't have a 'log' suffix in the name. Unless UT treats it differently since it's a temp file according to you. When I upgraded, I deleted the UT folder (directory) and everything under it. Then installed UT17 new. Are there registry values that could have been left from the previous install that is affecting the logging? Fundamentally, 0029.zlog temp files ARE being written, but not saved in the traditional UniTrunker-<date>.log format. Any idea where 0029.zlog comes from in the first place? And why it's prefixed with 0029?

 

[SCPD]

At local midnight ...

1. Prior day's open log file is closed.
2. New day's log file is opened (so program can continue logging)
3. Prior day's log file is zip compressed as (XXXX.zlog)
4. If step 3 succeeds,
a. the XXXX.zlog file is renamed to Unitrunker-YYMMDD.log.Z
b. prior day's log file (the plain text file) is deleted.
5. if step 3 fails (disk space, file permission, whatever)
a. the XXXX.zlog file is deleted (the original plain text log file remains)

Either way you're left with a usable log file.

The four digit "XXXX" number is random so that multiple logs can be compressed in the same folder at once (decode and tuner logs for example).

The file created in step 3 exists only temporarily. It is either renamed or deleted. The only way to have one of these files left lying around is the program exited during compression.

The program does not use the registry.

 

[clenhart]

To nocpire: Just curious if you were able to resolve this issue... I am seeing the exact same problem with system logs. The logging seems to work fine unless it is allowed to run overnight. In the morning I have a .log file with data from local midnight to current time and a 0029.zlog file with a file timestamp of midnight, but all data previous to midnight is lost. There are no .log.z files being created.

Any issue with the fact that the date/time stamp on the logs is GMT while the file rollover and creation is happening at midnight GMT -6 (in my case) ?

 

[nocpire]

Log problem

Other than getting up after midnight to manually rotated the logs, no. Never had the problem when I originally installed UT. I think it has to do with the way I deleted the old program (v11) before I installed th update.

 

[clenhart]

Other than getting up after midnight to manually rotated the logs, no. Never had the problem when I originally installed UT. I think it has to do with the way I deleted the old program (v11) before I installed th update.

Thanks for the response... I am having to manually save my slog files daily as well. I also noticed some odditites when I upgraded from ver. 17. It appears that files are installed in a couple different locatons. /program files/Unitrunker/S0000001 etc. and also /user/application data/Unitrunker/S0000001 etc. and I also wound up with 2 different sets of shortcuts... One ran the program and found the existing config data and one that would run the program but did not see the existing config data.

Sure wish I could get the system logging to work correctly. Maybe "Unitrunker" can chime in with some additional ideas.

BTW... I am running Windows XP SP3 using a radio w/discriminator output and also a BCD996XT for control/voice monitoring Mot. type 2 and P25 systems.

Thanks

 

[SCPD]

It appears that files are installed in a couple different locatons. /program files/Unitrunker/S0000001 etc. and also /user/application data/Unitrunker/S0000001 etc.

This was likely caused by an errant shortcut. See below. Post-install - the program shouldn't be putting anything into a Program Files folder.

I also wound up with 2 different sets of shortcuts... One ran the program and found the existing config data and one that would run the program but did not see the existing config data.

Delete the shortcut that doesn't work for you (right-click and delete).

nocpire and clenhart - let me know if release 20 works for you.

 

[clenhart]

Performed a clean install with release 20 today. Will see tomorrow if the system logs rotate as they should...

 

[nocpire]

Hot Damn!!!

Worked like a charm, thanks UT!!! Even the tuner log (which had not been getting compressed) worked!

 

[SCPD]

Worked like a charm, thanks UT!!! Even the tuner log (which had not been getting compressed) worked!

Glad to hear it. Take note of the updated release.

 

[clenhart]

Worked like a charm, thanks UT!!! Even the tuner log (which had not been getting compressed) worked!

Log creation and rotation working great for me as well... Thanks UT for the excellent support.

 

[nocpire]

log update

Now the opposite, 0029.zlog remains after midnight and now through reboot. But better to have regular logs back. Will probably be overwritten at midnight. Will confirm on next post.

 

[nocpire]

0029.zlog seems to be an artifact from .19. Date modified had been updated, but I think this is simply because it existed. Removed file, no more logs being written as this name. Thx again UT!