Unitrunker crashing

[rkorchensky]

I have been using Unitrunker for quite some time now, and on several different computer/radio combinations.

Lately it seems to hang for no apparent reason. As an example when I came into the shack this morning one of the systems was hung, with no apparent way of restarting it short of a cold boot.

This has happened on several occasions lately.

The annoying part is when this happens I lose all of the RID's. The GID's stay ok, but the RID's all disappear. This is very annoying when you have hundreds (even thousands) of RID's stored and you have to start all over from scratch. This is the third time in a week this has happened.

Nothing has changed on any of the computers as each one is solely dedicated to one specific radio system and is not used for any other use.

Is there any way that the system can be set up so it automatically make a .bak file periodically, then if it crashes you can just go back to the last .bak file and only lose a few days of logging?

Any comments/ideas appreciated.

Thanks, Ralph VE3EUK

 

[SCPD]

Hi Ralph!

Lately it seems to hang for no apparent reason. As an example when I came into the shack this morning one of the systems was hung, with no apparent way of restarting it short of a cold boot.

Not good.

The annoying part is when this happens I lose all of the RID's. The GID's stay ok, but the RID's all disappear. This is very annoying when you have hundreds (even thousands) of RID's stored and you have to start all over from scratch. This is the third time in a week this has happened.

Interesting. That's a significant clue.

Is there any way that the system can be set up so it automatically make a .bak file periodically, then if it crashes you can just go back to the last .bak file and only lose a few days of logging?

It would have to copy half-dozen files - perhaps to a time/date stamped folder. In principle, the ".bak" file trick doesn't work if you don't catch the failure on the first round-trip. Usually your .bak file ends up as toast too.

Let's see where this goes. I may have to implement an archive mechanism if this issue isn't solved easily. I need some general info ... for starters, which version and what system(s) were you monitoring?

-rick

 

[rkorchensky]

Hi Rick,

Thanks for the reply and your comments.

I am presently using version 0.1.0.41. I also had the same problem with the last version.

I am not saying the problem is the software, it could quite easily be a problem at my end. I've learned not to point fingers too quickly!!!

I used to run Trunker, and one of the features was it periodically made a .bak file. I can't remember if it made it on a timer or each time you shut down gracefully, but there were times that I had to resort to it and it was sure appreciated.

Presently I have 2 computers running. One monitors the Region of Waterloo EDACS system (this is the one that has recently crashed) and the other one monitors the Provincial Fleetnet system.

The reason I get a bit ticked when it crashes, is because presently I am concentrating on the Fire Departments on the Waterloo Region EDACS system in this area. I have about 450 RIDS of fire apparatus, and I can tell you about 90% of the actual units that the radios are in. Makes monitoring very nice when you know exactly which radio is "Pumper 7" or "Portable C on HAZMAT 1" etc.

When it crashes I have to retype each and every one in again....this sure takes time.

Anyway...still open for comments/ideas/suggestions.

Thanks, Ralph VE3EUK

 

[bonus1331]

Using newest version of Unitrunker and WIN98. Turned autosave on last night. This morning had fatal error with the program. Will see if it continues with autosave off.

 

[slicerwizard]

When it crashes I have to retype each and every one in again....this sure takes time.

After entering your ID's, why don't you shut down the program and back up your data?


Rick, re the risk of trashed backups, you could do a quick and dirty hack for now:

Once an hour (or whatever interval you like):

MKDIR "UT-nnn" (where nnn = 001 to 999; stop when the MKDIR doesn't fail due to the directory already existing)

Dump the current system's files into the newly created directory.


It's a hack, but most users have plenty of disk space and they can delete old folders whenever they want. They'd also be able to recover from most any failure.

You could also just go with MKDIR "subdir name based on date and time"...