Hi Andreas,

It was actually easier than that. The time stamps in the old system were in epoch format, so when I created the new record, (my conversion program was written in Python), I simply formatted that value in the format Stefan pointed out below, and defined the Orig Date field as text. Then I was able to munge the logbook file with 2 global editor commands, and it worked perfectly. Thanks again!

Hello, dear ELOG's gurus.
Please help me to understand a problem with mirroring function.
It appears in ELOG V3.1.4-a04faf9f - the last official Windows release, as well as previous 3.1.3 Windows release, which I have checked for comparison.

When I'm using a manual configuration with "mirror server, cron, user" options for one (master) of two servers, it operates well, except the situation, when a new entry is submitted at the second (slave) server.
For example, for a new entry with a real ID#2 at Slave its logfile gives "NEW entry #0", so logfile of the master server gives "MIRROR: Error receiving message: Received wrong entry id "0"".
After that Master deletes this entry at Slave "MIRROR delete remote entry #2".

In case of mirror functions in both .cfg files (Master to Slave, Slave to Master) both servers hung on after the first mirror process.

Now let's imagine, what I want to do. 
Master, as a main-operation global log, is off-operation, Slave automatically becomes a reserv-operation local log with full information from Master due to previous periodic mirroring.
Users work with Slave, submit new entries - all with #0 ID.
After repairing Master starts active mirroring and just deletes all new entries from Slave.

It seems, that the problem is not with mirroring, but with a new entry ID, as was mentioned in https://elog.psi.ch/elogs/Forum/68850
Were these ID#0/mirror problems resolved somehow or may be it is not a problem, but simply my errors in ELOG configuration?
Is there a chance to get an up-to-date Windows-release with working both-sides mirror function and all other addings after V3.1.4-a04faf9f ?

Best regards,
Sergei

The entry ID #0 was a bug in logging routine only, so in the elog logbook the ID is certainly not zero. But the logging bug has been fixed now, so please update your version of elog.

Then I tried to reproduce your problem. I set up two servers, the master listening at port 8080 and the slave listening at port 8081. I created two entries at the master, did manual synchronization, then created one entry on the slave, and did another synchronization on the master. I got both sides correctly transferred, no problem with ID zero. See attached screenshot. I used following elogd.cff on the master side:

[global]
port = 8080
password file = passwd
Mirror server =    http://localhost:8081
Mirror simulate =1

[demo]
Theme = default
Comment = General Linux Tips & Tricks
Attributes = Author, Type, Category, Subject
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
Options Category = General, Hardware, Software, Network, Other
Extendable Options = Category
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type

Hello,

I'm working on new logbook and in one category I'll have many attributes (many more than in attached screenshot).

So here is my question. Is it possible to visually group such attributes with some border, or something like that?

In screenshot you can see what I want to achieve.

Best Regards

Daniel

Nope, this is not possible. Sorry.

Stefan

Hi all,

I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.

In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber).  We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.

What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 5656, 5659, 5657, 5658, 5660, 5661....

Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.

Has anyone else encountered this? 

Thanks,
Frank
 

Hi,

I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file.  It would be very interesting to see what the 200428a.log file looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch or indeed this same order as the screenshot.  If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second entry were created before the "No branches" checking part of the program had been reached.  Not so sure about such an event here unless entry 5658 were already open but not closed?

Regards,

David.

Hi David,

Thanks for the quick response!  Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure. 

This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.

Thanks,
Frank