I don't know what happened here - I mean, I understand the ">" characters being added to the start of every line of a quoted previous entry, but now what then happened to the formatting.

By default in plain mode elog adds ">" to the start of every quoted line, just as quoting an email will do (some mailer programs).

If you're beyond your nteenth reply, word-wrapping of the browser etc makes past comments difficult to read.  Of course it would be equally difficult in in html mode as the boxes would get more and more nested.

Not sure if your link here about html is relivent to the use of the ">" to indicate a quoted reply or not, although that wasn't really my question - which was about date format in the config file.

> > [13 Nov]
> > As my threads have lots of replies, I end up with a forest of ">" characters which makes it difficult to read
> > earlier quoted entries (what with word-wrapping of the browser).
> > I thought to replace the ">"s by a simple date entry prepended to the start of each reply. - much as I have 
> > given at the top of this initial entry.
> > 
> > So this is what I put in the config file:
> > 
> > ....
> > Time format = %a %d %b %y
> > Date format = %d %b
> > Prepend on reply = [$date] \n
> > ...
> > 
> > The time is used in the string for the Thread display.
> > 
> > Only I don't get the date, with the date format, prepended to replies but the time, in the time format, as
> > 
> > [Wed 13 Nov 13]
> > 
> > Now this is hardly a disaster, but any ideas why the date formatting is being ignored?
> 
> Hi David,
> yes, a $date is substituted with the "Time format" in the function build_subst_list().
> I guess that is a bug, but it could break many existing logbooks to change it.
> I leave this to Stefan.
> 
> There is a simple solution for your problem: you can execute a shell command.
> 
> Prepend on reply = $shell(date '+[%d %b]') \n
> Reply string =
> 
> That snipped will do exactly what you want :-) (of course you need to have the "-x" option to start elogd.)
> 
> Kind Regards
> Andreas

Hi Andreas,

Thanks for this, I'll give the solution a go.  
I take the point that if it's a bug, other logbooks may be affected if it were fixed; but perhaps another
parameter - $thedate or something could be created instead?

> > I'm not an expert in debugging web applications. Here are my two cent:
> > We once had a problem when we hosted very large logbooks (several 10 thousands of entries) that the server would run
> > out of real memory and was slowed down by swapping. Therefore my first idea would be to monitor the server: Is
> > the CPU load peaking? What happens with the memory consumption? Any other suspicious process running on the server?
> > But it could be as well a network or browser problem. Did you try different browsers?
> > Did you check the elogd log file?
> 
> The logbook only has a few hundred entries, elogd is using only around 20-30 MB and there is enough free RAM. The load 
> average for the server is around 0.2, elogd only uses 5% CPU at most when it is accessed and the CPU is idle most of the 
> time. 
> 
> Strangely it happens mostly when using Chrome, and almost never with Firefox. I captured the network traffic, but I can't 
> see anything unusual. It just takes very long until the answer is returned by the elogd server.

My tuppance worth.  I have noticed (firefox) that some attachments take rather longer than might be expected to upload.  I
originally thought this was the ghostview program processing say a pdf to make pngs etc, but have more recently started to
question that assumption.  No solution or much clue, just another observation.

 Years ago I had a similar issue, although I cannot remember the exact details now.  The consequence is that I don't leave any spaces in the log book names.  However, I did find that '&' was fine, and the ampersand and %26 are interchangeable in a logbook page, so one logbook is ECP&SIW, and using ampersand or '%26' work interchangably when making llinks from other logbooks to ECP&SIW  (that is elog:ECP&SIW or elog:ECP%26SIW work equally well)..    This is not true of elog.cfg, where only the actual character should be used.  This may be true for some other urlencoded characters.

It may be of note that %20 and '+' are not the same urlencode and character - %20 is a space, '+' is %2B, and a brief bit of playing around shows that elog is not so tolerant of those characters as it is with & and %26, and I crashed mine several times but I was only playing, nothing serious was lost.

 Having written the above and posted it, I see the links for ECP&SIW I wrote here don't work the same as in my local logbook.  I did check!  Result is treat the above posting with caution.  Although this is not the first time when something works fine on my local logbook but not here on the Mother of all elogs.  Different flavour of linux?

Hi Stephen,

I see that you don't allow branching in your threads.  Why do you need to propagate the Status throughtout the thread?  Why not just mark the latest entry and (incase it is necessary) 'collapse to last = 1'

I'm not saying that the bug (if bug it is, rather than a preset limitation) you've found should not be fixed, but I'm puzzled as to why you happen to use the feature.  I can see the point if an initial entry provides a whole tree of branches (and a limit of 10 is rather limiting).  OK, I know if it is historic, it cannot easily be changed because of other users.  Or if some users will primarily be responding to emails rather viewing the logbook via a browser.  I'm a single (ab)user elog system myself, so I'm very tolerant of changing how elog works if it offers an improvement.

Hi Stefan and Andreas,

With the latest incremental version of elog (a738232), I have noticed that when attaching a pdf file, the
.png thumbnail is not generated when the "upload" button is pressed - there is just the usual small line saying
what the latest attachment is.  If this happens, a subsequent attachment will force the generation of the
thumbnail for the *previous* attachment, and again no thumbnail for the latest attachment.

Submitting the comment will also generate the thumbnail.

As of yet, I cannot find any consistent pattern to this.  Also, it's hardly a disaster, but I have been fooled
when attaching a pdf file that subsequently turned out to be damaged and thus unreadable.

Hi Stefan and Andreas,

When I submitted the previous entry, I had an error message about not able to send via psxxxx.psi.ch come up as
a red bar at the top of the elog page - sorry, cannot remember the subdomain name correctly.

The observations I was going to make is firstly the change in layout of the Find section - maybe I'll get used
to it but the change in layout wasn't warmly welcomed.

Also, shame that moving from Subversion means that the increments are no longer in easy numerical order.  So I
believe that I am commenting on the latest possible version available, a738232.

A question.  My logbooks directory is now 1.8GB.  Yes, there are a lot of attachments etc to bulk it out, but
it's all plain text comments.  Is there a limit as to the size, or total number of entries?  Elog takes a
notible amount of time to index it all these days, and I have wondered whether a couple of "instabilities" might
be caused by this.  Anyone any thoughts?

I don't know how I managed it, but I got elog to generate two entries with the identical ID no.  The new entries
were different as well.  The log file faithfully had recorded the two separate replies to the entry having the
same ID no as well.   Unfortunately I went and corrected it by editing the YYMMDDa.log file without keeping a
copy.  I have also had a mysterious entry ID0 appear in threaded display, despite there being no entry 0; and if
it appears, it appears in two or three places within the list of threaded entries.