Attached logfile cannot be searched via quick filters; Lines not correctly recognized

[PhilLab]

Current behaviour

The file

13:01:22 >> C:\something
first line
second line
third line

does not work well with Tailviewer, I tested 0.8.1 and 0.8.0. Configured quick filters are completely ignored. I noticed that the lines are all light (and not light - dark - light - dark ....) as usual, so this might be a hint here, as maybe the line parsing fails.

If I remove the first line, the file works.

Expected behaviour

### Steps to reproduce the problem

[Kittyfisto]

This behaviour probably occurs because of the way tailviewer tries to parse a log file into a list of log entries. A log entry is a consecutive list of one or more lines so by default, tailviewer interprets the log file in your example to consist of a single log entry. Therefore any quick filter which produces a match in any of those lines (so for example quick filter for "third line") will cause the entire entry to be shown.

Quick solution You can change this behaviour by toggling the "Single line" option under view:

More boring explanation The reason why this behaviour vanishes when you delete the first line is because tailviewer assumes that log entries start with a timestamp and then have a list of 0 or more lines without timestamps: The next line to have a timestamp is assumed to be part of the next log entry (This algorithm works very well with log files produced by frameworks such as log4j/cpp/net and similar). When you delete the first line, then there's no discernible timestamp anymore and therefore tailviewer assumes that every log line is its own log entry and then quick filters work per line.

Followup questions Currently treating log files as being multiline is the default, so whenever you open a new log file you will have to change it to singleline again. This could quickly become a hassle. What do you think about being able to configure multiline/singleline default value in the global settings page? This way you only have to this once.

[PhilLab]

@Kittyfisto Thanks for the explanation. Actually, as soon as you understand that it is a feature, it is a good one, to be honest :-) So you can still parse single events whose messages consist of multiple lines.

• Yes, having the single / multi line mode as configuration might help!

I think in my actual use case, it was just a problem of conflicting time stamp formats:

10:30:44 >> C:\bin\run.exe --test --logToCout
[10:30:46]: 
[10:30:46]: ERROR: Could not initialize WinToast lib (PlatformSupport.cpp, line 907)
[10:30:48]: INFO: Trying to register non-exitsting algorithmId Camera__Fusion_Win
[10:30:48]: INFO: Checking license file

If I convert all timestamps into the syntax without brackets, it works. If I convert all to the syntax with brackets, it works as well. Only when the patterns differ, we have problems

So this is also a question: should Tailviewer deal with different timestamp formats in the same file?

[Kittyfisto]

Thanks for the explanation. Actually, as soon as you understand that it is a feature, it is a good one, to be honest :-)

I'm glad you agree. Given your initial confusion though, this feature isn't really intuitive so I guess the way this is communicated to the user should still be improved.

Yes, having the single / multi line mode as configuration might help!

It should be easy enough to add a global configuration for this. I'll get right on it.

should Tailviewer deal with different timestamp formats in the same file?

This one is a tough one. It used to be like that in the start, but I couldn't optimize this code path for this approach to be reasonable for longer log files (timestamp detection took a lot of processing power, given the varying degrees of freedom: timestamp format, start index, length). As it stands, tailviewer performs a brute force search for the first few lines of a log file and then decides upon which format produced the best matches. Based on this format, the offset from line start is determined (thus allowing for formats to start with [ ) and only this format is used for matching from then on.

There's also the other problem that any timestamp also part of a log message would throw of the current heuristic to group multiple lines into one log entry, for example:

10:30:44 >> C:\bin\run.exe --test --logToCout
[10:30:46]: 
[10:30:46]: ERROR: Foo
                              Still part of foo
                              There's a problem with the flux capacitor at 10:30:44
                              Whatever
[10:30:48]: INFO: Trying to register non-exitsting algorithmId Camera__Fusion_Win

If tailviewer were to allow multiple formats in the same log file, then it would assume that the flux capacitor line would make up a new log entry (and not belong to the previous one).

In the end, I opted for having a simpler (yet still not totally apparent) heuristic in favour of a more complex one. I'm afraid that using an even more complex heuristic were even harder to understand and confuse people even more.