All three spacings are actually tabs, it seems they got converted to spaces when copying.

Thanks for the update. 

I will try and reproduce the issue now.  Can you please confirm that the area between the fields represents spaces and not tabs?

Note that if your parser configuration specifies there are 4 spaces between fields, it will always expect 4 spaces.  You can work with spaces with format modifiers.

Alternatively, you could include the spaces in the resulting values by using a simplified pattern like: 
%d{yyyy-MM-dd %H:mm:ss.fff} [%p] <%t> %m%n

Hello Toby,

The issue isnt a delay in displaying entries, but the entries not displaying at all no matter how long you wait until more entries are added in files.

In this case a really simple configuration is used - a pattern parser with the following arguments:
%d{yyyy-MM-dd %H:mm:ss.fff}    [%p]    <%t>    %m%n

An example to reproduce this:
Start with a text file containing some entries.
2020-08-19 07:41:10.068    [INF]    <1>    Starting service...
2020-08-19 07:41:10.074    [INF]    <1>    Service started.
Open file in LogViewPlus.
Add a line (without newline / line break):
2020-08-19 07:41:10.068    [INF]    <1>    Test message 1.
*This line probably already wont show, no matter if you wait.
Add another line.
2020-08-19 07:42:00.000    [INF]    <1>    Test message 2.
Both message 1 and message 2 will now show.

It seems it has to do with newline (%n) not being present, since it works otherwise if a newline is added after each entry, but this is not always the case in all log files. And why does it load the second entry with the first one then when no newline is present at the second entry also baffles me.

The issue with session is not consistently reproducible. The session start and end dates are correct though as long as you do not reload the file (if you reaload it, nothing goes into session view anymore and the date starts at jan 1. 00:00:00).

Hi Inel,

Thanks for the feedback.

LogViewPlus monitors files by polling them.  A small delay of a fraction of a second is expected.  If you are experiencing delays beyond this it might be a problem with your parser.  In this case, LogViewPlus might be expecting more data in order to complete parsing of the log entry.  Log entries can only be displayed once they have been completely parsed.  

It sounds like you have a significant delay and parsing might be the issue.  I am happy to help with this if you can give me a few sample log entries and the parser configuration you are using.  This might best be done in a separate thread.

Sessions work by taking the last known log entry timestamp and using that as a starting point for a date range filter.  Note that the last known starting point may be several hours ago - or even in a different timezone.  Once the start date is chosen, the filter is simply "show everything after this date".  This is a very simple filter.

Does the session show the correct log entries once started (start date only)?  Does the session show the correct log entries once it is completed (start + end date)?  What happens in both scenarios on a log file refresh?

LogViewPlus does not have the ability to selectively remove or skip a log entry.  So the behavior where it "would not appear in original view" is very strange.  To debug this, I will need more information so I can try to recreate the problem on my side.

Hope that helps,

Toby

Hello,

We are testing live monitoring of log files and noticed, that LogViewPlus only updates on every second or third file change, so it is effectively behind on showing the current log state (tested with other solutions at the same time and those showed the changes as they happened).
The second issue we noticed is that sometimes entries would go missing when starting session (they would not appear in original view, nor in session view that is supposed to show new changes) and refresh while having session started also yields strange results in many cases.
This was tested with both the latest release and beta versions.