ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66424
|
Fri Jun 26 08:15:16 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.6 | Re: attached picture size changed |
weiluo wrote: |
Hello everyone.
Here I found a problem recently with attaching screen-shot to the elog.
I am using "elog -f xxx/xxx.gif" to make elog entry. Recently I found my attached pictures were scaled to the half of the original size horizontally appearing in the log entry, the other half of the picture was filled with black. I need to click it once to magnify the picture to see it.
Does anyone know how to solve this problem? It bugs me a lot.
By the way, I saw some pictures were produced with the name "xxx.gif.png" in the logbook directory.
Thanks, and one of the modified picture is attached.
|
When you submit a picture, elogd calls the ImageMagick package to generate a thumbnail out of it, therefore you get the "xxx.gif.png" file (which represents the thumbnail). If you create your GIF images with the ROOT package, ImageMagick will give problems because ROOT does not use standard GIF encoding, therefor the black border on your pictures. You can turn off the thumbnail generation completely by specifying
Thumbnail size = 0
in the configuration file. This option was just introduced recently, so please update to SVN revision 2227 for this option to work. |
66425
|
Fri Jun 26 14:27:27 2009 |
| lance | lance1.hayward@yahoo.com | Question | Windows | 2.7.2 | Re: synchronization |
Stefan Ritt wrote: |
lance wrote: |
lance wrote: |
We are running elog across two sites and synchronizing every four hours on change only. There are about 100 entries per day of which most are just one line entries. However this is taking up to 9 mins and during the replication process the server gives us an "unavailable" error. We are using a T1 across the sites so bandwidth should not be an issue, I am confused as to why this takes so long.
The issue for us is not how long the sync takes, providing this was happening in the background, and doesnt lock out the server while the replication was taking place. We are operating under a 24 hour call center type environment so the server being available all the time is of paramount importance.
We use version 2.7.2 and I know there have been several changes made since this version. Would changing to the latest version have any impact on this?
Cheers,
Lance
|
Stefan,
I have been running logging and I think I have found the problem however I do not know how to resolve it.
Here is where it is going wrong:
19-May-2009 04:02:48 [] {NSS} MIRROR: ID21268: Local entry submitted
19-May-2009 04:07:34 [] {AMC} MIRROR: send entry #31056
It seems that when it has finished replication on one logbook there is a significant time before the next logbook replication starts. During this time the server is not avalable. I have noticed that the time between ending one logbook and starting the next differs betwee 2 and 5 minutes. Again the server is not available when this happens.
Do you have any idea?
Cheers,
Lance
|
Hi,
I need more information to narrow down the problem:
- does this only happen on automatic mirroring or also when you do a manual synchronize?
- does this happen on both sides, like when you make the "other" elog server the master?
- if the server is inresponsive, does the CPU on that machine go to 100% or to 0%?
- do you have very long attachments in your logbooks?
- do you have the same problem on a "tiny" logbook like it comes with the distribution?
- are you using any Apache proxy in between?
I'm afraid that in the end you have to debug this yourself, since it will be very hard for me to reproduce exactly your problem (unless you send me all your files).
Cheers,
Stefan
|
Stefan,
Thanks for the reply.
This happens on automatic mirroring and by manual sync. However only the site initializing the mirror is locked out the remote seems to still be able to function.
The CPU jumps from very little usage to 50%+ being used by elogd.exe as soon as you start the mirroring/sync process
I have attached a file that that is in three parts and its pretty big. When I start up the elogd -v it takes over two minutes to scroll through hundreds of files. I have attached the last of those entries in the first part of the attached PDF, the second part of the PDF shows a manual sync and the third part shows the same sync on the same logbook a few mins later. It seems to take about 3 minutes even when there has been no new log entries. In addition if you are mirroring more that one log book through the automated cron job it can take about 3-5 mins before the second logbook starts its replication. I have also added a screenshot of the completed replications on both runs.
If there is a way to redirect the output of the cmd window when running elogd -v I would capture all the data for you but the standard redirect ">> elog.txt" only creates a blank file.
We are running several logbooks and it does look like the smaller logbooks still take several minutes to start up. I have attached the PMCLogfile and if you look between the NSS and the AMC replications on any day there seems to be a 3 min gap between one book finishing and another starting.
We are not using Apache prox in between.
I am not a programmer but I can follow instruction, if you need anything else let me know.
Stefan this has been driving me nuts for a while now so any help you can give would be more than appreciated.
Cheers,
Lance
|
66427
|
Fri Jun 26 17:04:23 2009 |
| weiluo | lwsy711@gmail.com | Question | Linux | 2.7.6 | Re: attached picture size changed |
Stefan Ritt wrote: |
weiluo wrote: |
Hello everyone.
Here I found a problem recently with attaching screen-shot to the elog.
I am using "elog -f xxx/xxx.gif" to make elog entry. Recently I found my attached pictures were scaled to the half of the original size horizontally appearing in the log entry, the other half of the picture was filled with black. I need to click it once to magnify the picture to see it.
Does anyone know how to solve this problem? It bugs me a lot.
By the way, I saw some pictures were produced with the name "xxx.gif.png" in the logbook directory.
Thanks, and one of the modified picture is attached.
|
When you submit a picture, elogd calls the ImageMagick package to generate a thumbnail out of it, therefore you get the "xxx.gif.png" file (which represents the thumbnail). If you create your GIF images with the ROOT package, ImageMagick will give problems because ROOT does not use standard GIF encoding, therefor the black border on your pictures. You can turn off the thumbnail generation completely by specifying
Thumbnail size = 0
in the configuration file. This option was just introduced recently, so please update to SVN revision 2227 for this option to work. |
Thanks a lot for the detailed explanation! It works! |
66430
|
Thu Jul 2 09:39:40 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 2.7.6-2226 | Cancelling an Roption selection in Edit. | Hi Stefan,
I don't know if anyone else would be interested or need this...
If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
entry and have replies without any of the attributes in that Roption being selected.
However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
condition before one was selected on that entry (so far as I can tell).
Is a way of cancelling all the possible attributes in an Roption practical? Would others want it? It is
possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
option that has been selected.
Regards, David |
66431
|
Thu Jul 2 10:04:13 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.6-2226 | Re: Cancelling an Roption selection in Edit. | > Hi Stefan,
>
> I don't know if anyone else would be interested or need this...
>
> If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
> entry and have replies without any of the attributes in that Roption being selected.
>
> However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
> condition before one was selected on that entry (so far as I can tell).
>
> Is a way of cancelling all the possible attributes in an Roption practical? Would others want it? It is
> possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
> option that has been selected.
>
> Regards, David
The easiest to achieve this is to define another option. Assume you have the three options
One, Two, Three
and you want to "unselect" them. So just add a fourth option like
Unspecified, One, Two, Three
so if you do not want any of the "One, Two, Three", just click on "Unspecified" and you get what you want. |
66432
|
Thu Jul 2 11:33:48 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Question | Linux | 2.7.6-2226 | Re: Cancelling an Roption selection in Edit. | > > Hi Stefan,
> >
> > I don't know if anyone else would be interested or need this...
> >
> > If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
> > entry and have replies without any of the attributes in that Roption being selected.
> >
> > However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
> > condition before one was selected on that entry (so far as I can tell).
> >
> > Is a way of cancelling all the possible attributes in an Roption practical? Would others want it? It is
> > possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
> > option that has been selected.
> >
> > Regards, David
>
> The easiest to achieve this is to define another option. Assume you have the three options
>
> One, Two, Three
>
> and you want to "unselect" them. So just add a fourth option like
>
> Unspecified, One, Two, Three
>
> so if you do not want any of the "One, Two, Three", just click on "Unspecified" and you get what you want.
This is sort of what I do now, I just wondered if there was a way of clearing that would leave the field completely
blank in the YYMMDDa.log file.
Thanks. |
66433
|
Sun Jul 5 19:14:05 2009 |
| Ed Strohak | estrohak@gmail.com | Question | Windows | 2.7.3-2058 | Password recovery setup | I'm trying to use gmail to send password recovery e-mails, I get this error when I submit the email address.
"Error sending Email via "smtp.gmail.com": 5.7.0 Must issue a STARTTLS command first. 2sm5111524agd.34"
Any help or insight would be appreciated.
Ed... |
66434
|
Mon Jul 6 07:48:09 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.7.3-2058 | Re: Password recovery setup |
Ed Strohak wrote: |
I'm trying to use gmail to send password recovery e-mails, I get this error when I submit the email address.
"Error sending Email via "smtp.gmail.com": 5.7.0 Must issue a STARTTLS command first. 2sm5111524agd.34"
Any help or insight would be appreciated.
Ed...
|
gmail uses TLS (Transport Layer Security) for the mail communication, which is currently not supported by elog. |
|