Hello,

I work for a medium-sized developer and I'm currently investigating the feasibility of us using LogViewPlus to view and debug the logs generated by the software we make. It has lots of killer features that would be very useful for us, but unfortunately at least one killer drawback.

The software being developed generates a text log, and overwrites this log each time the application is started. By default, LogViewPlus keeps the output from old logs in its view, so if you run the application five times and then try to filter the view, you see output from the previous four runs along with the current run. This confuses the output and is not desired.

I found the option in LogViewPlus settings to "Clear all log entries when the log file is rolled or recreated" which looks like it should solve this. However, when this option is enabled, LogViewPlus now shows the following prompt when the software being developed is restarted.



LogViewPlus then has to be restarted, or the logfile has to be re-added to its view, in order to view logs again.

A potential factor is that the log-generating software, when restarted, copies the old log file and renames it within the same folder. For example, if the application is set to write logs to client.log, when it starts up it will copy the previous client.log to client-backup-<timestamp>.log and then start a new client.log file. This behaviour may or may not be related.

Has anyone seen this issue before, and/or know how to fix it?

Unfortunately so. That pattern matches the hundreds of lines produced after the first line, see the "Message with no timestamp" lines in the example log below:

Log file open, 04/05/24 16:14:04
Logger: Message with no timestamp 1
Logger: Message with no timestamp 2
Logger: Message with no timestamp 3
Logger: Hundreds of these messages with no timestamp
[2024.04.05-16.14.05:545][123]Logger: Message with timestamp 1
[2024.04.05-16.14.05:546][123]Logger: Message with timestamp 2
[2024.04.05-16.14.05:547][123]Logger: Message with timestamp 3
[2024.04.05-16.14.05:548][123]Logger: An error has occurred!
--- CALLSTACK ---=[C](-1) : ?
@C:/Path/To/Source/Files/sourceA.py(123) : functionA
@C:/Path/To/Source/Files/sourceB.py(456) : functionB
@C:/Path/To/Source/Files/sourceC.py(789) : functionC
--- CALLSTACK ---
[2024.04.05-16.14.05:549][123]Logger: Message with timestamp 4
[2024.04.05-16.14.05:550][123]Logger: Message with timestamp 5

I think I've now managed to get this working, with the following parser mapping:

[%d{yyyy.MM.dd}-%d{%H.mm.ss:fff}][%t]%c: %m%n
[%d{yyyy.MM.dd}-%d{%H.mm.ss:fff}][%t]%c: %m--- CALLSTACK ---%n
%c: %m%n
%m, %d{dd/MM/yy %H:mm:ss}%n

The additional --- CALLSTACK --- line seems to match these errors. Can you think of a reason why this wouldn't work and/or a better solution?

Please see our definition of a log entry.

Consider the log line:

[2024.04.05-16.14.05:548][123]Logger: An error has occurred!
--- CALLSTACK ---=[C](-1) : ?
@C:/Path/To/Source/Files/sourceA.py(123) : functionA
@C:/Path/To/Source/Files/sourceB.py(456) : functionB
@C:/Path/To/Source/Files/sourceC.py(789) : functionC
--- CALLSTACK ---

Is that one long entry - or four or six?  According to our definition, it is one log entry because there is only one timestamp.

The parser configuration:

%c: %m%n

Does not meet our definition of a log entry because it does not define a timestamp.  This is actually a bug which I believe is specific to multi-patterns (which are an advanced feature).  We will probably need to fix this in a future release.  In fact, this thread is leading me to think it should be fixed with a higher priority because we don't test for this scenario and you are likely to have additional issues with this configuration in future (which we will not be able to support).

I would suggest using the parser configuration:

[%d{yyyy.MM.dd-HH.mm.ss:fff}][%t]%c: %m%n
%m, %d{dd/MM/yy %H:mm:ss}%n

Using this configuration, the file above contains 7 log entries.  The two 'advanced' entries will be parsed across multiple lines:


If it is necessary to break the header up across multiple lines and you are not able to change your application, you may also want to consider a custom parser which will give you an opportunity to set a timestamp even if one does not exist in the log entry.

Hope that helps,

Toby