By AndreasP - 3 Apr 2020
Hi Toby,
there is another thing that is in my mind for a long time. I think that I even mentioned it once.
It is regarding the following behavior as described in the documentation:
Also, note that as you navigate between views LogViewPlus attempts to keep your current record in focus. This allows you to easily view records which were written before and after the current entry when moving between views.
This is a very important feature. However there are cases where I navigate between different views that don't exactly contain the same entries but focus on different aspects of the logs. For example there is a view where I narrow down a specific problem, but then need to look on another view to see different aspects. And this other view might not contain the log entries from the first view. So current behavior is that the current log entry jumps to the start of the view. So I very often have to remember the date and time of the event and manually navigate to the time of interest.
Another example is navigating between a filtered view and the full log. When looking through a filtered view I often use double click to go back to the full log, check some log entries in the vicinity and then want to go back to the filtered log again. However if I selected another log entry in the full log, that does not exist in the filtered view I end up at the beginning of the filtered view and have to find the last position again.
(I just noticed during testing, that this even does not work with "Previous Filter" if I selected an existing entry. This only works if I don't click in the log entry grid at all).
So I want to ask if the navigation between views could be improved in a way that when the currently selected log entry in the old view does not exist then in the new view a log entry that is close in time to the selected old log entry is selected.
Regards
Andreas
|
By LogViewPlus Support - 3 Apr 2020
Hi Andreas,
You're absolutely right - this is a very important feature and I am definitely open to suggestions for improvement.
However, this is one of those features that seems simple but actually has a lot of complexity. The problem is user intent. Double clicking on a log entry - it's clear that the entry selected is important to you. However, selection can change for a lot of reasons (including tail) and it is not clear that every mouse click or selection change is important. Similarly, moving between views is not necessarily an indication that the currently selected entry is important.
I would suggest that further improvement in this area might require a new feature. For example, maybe when you double click a log entry, we look it up in the main log file and 'auto-bookmark' it. This would probably be a feature separate but similar to bookmarks.
If your filters shared a common time range root filter, maybe that would help?
I don't think 'views focused on a time range' is the correct solution. I can see where this might be confusing in some situations as it implies the software understands your intent.
Let me have a think about it. Thanks for the feedback!
Toby
|
By AndreasP - 22 Apr 2020
Hi Toby,
I can understand that when implementing such a feature you have to consider all the special cases and that it's best to find a solution that conceptionaly does not require any or a lot of special cases.
But I can tell you that I desperately need such a feature. When changing between views I need to stay at the same/similar time!
For example at the moment I look at a complicated case where I have log files that span over a month with millions of log entries. And every time I change between views it takes a lot of time to get again to the time instance I currently focus on.
Additionally this time I have the difficulty that I have to consider log files from two (or even four) systems (that communicate with each other).
And I don't want to merge all log files together, since then I completely loose the overview. But I naturally have to jump many times between the different views.
In this respect I have some additional questions that I wanted to ask:
1. The two system have a time offset that I would like to compensate. However the "Time Offset" feature only seems to work on source log files but not the merged log files view. How can I change the time offset of all log files from a single system at the same time after I loaded them?
2. This is additionally complicated by the fact that when opening a workspace again the order of the log files/views change. At the beginning I first loaded all log files from system 1 and merged them. Then all log files from system 2 and merge. After that I know which log files belong to which system (merged view). But after loading the workspace again it first displays all log files and then the two merged views. Is that reordering necessary?
3. Analysis would be a bit easier I assume, if I could load the log files of each system into separate instances of LogViewPlus. However it seems possible to only start one instance. Is this restriction necessary?
Thanks for helping and regards
Andreas
|
By LogViewPlus Support - 22 Apr 2020
Thanks for the feedback Andreas.
What about creating a time range filter for the range you are interested in - and then copying this filter to the other log files as needed? Does this help? This filter can then be the root for any further queries.
Regarding your other questions:
1. You can set a time offset on files when you open them (see Additional Settings). I suggest you open all files from the application at the same time. That way, you will only need to apply the offset once. Alternatively, the time offset can be set after the files are opened - buy only one file at a time. Time offset modification is not currently supported for merged files.
2. The ordering is not explicitly saved, so the load order cannot be guaranteed. I will take a look to see if we can improve this. For now, I would recommend you add all files from a particular application into a Category. Categories are saved as part of the workspace and should help keep things organized (if not in order).
3. You can run multiple instances of LogViewPlus, just deselect the appropriate Application Setting.
Hope that helps,
Toby
|
By AndreasP - 22 Apr 2020
Hi Toby,
thanks for the tip with the application settings and category. But how can I change the category of multiple files at the same time?
Regarding the idea with the time range filter. Sounds very inflexible/cumbersome to me if you look through a lot of places in the log files. (I often use a custom analyzer to view areas of potential interest. And there might be many of these areas.)
Regards
Andreas
|
By LogViewPlus Support - 22 Apr 2020
Files need to be added to a category individual, but after the category has been created you should see it in the context menu. So it is easier to add the second file. Directory Monitors also have a setting which adds files to a category.
I think that when you are navigating between files - it may make sense to stay close to the currently selected time. I think this would need to be an application setting because the current behavior (place is remembered) is also useful.
Would that help?
Toby
|
By AndreasP - 22 Apr 2020
If this also works when navigating between filters. Absolutely! :-)
|
By LogViewPlus Support - 22 Apr 2020
It should already work this way when navigating between filters on the same file. I think the problem is happening when you switch to look at another file.
|
By AndreasP - 23 Apr 2020
I think the problem is that I work most of the time with filters on merged log files.
When the filtered views contain log entries from multiple files the "staying close to the selected time" is also not working.
During testing I observed two additional points (when using only a single log file).
a) "staying close to the selected time" is always rounding down (like the "floor" function). I would prefer to round to the nearest time (like the "round" function).
b) When switching between views the currently selected log entry, always is scrolled to the top of the view (even when using double click). This is not optimal since I usually look at the log entries around the currently selected entry. So would be nice if the scroll-position of the selected log entry could be kept the same (or similar).
Thanks for listening!
|
By LogViewPlus Support - 29 Jun 2020
Hi Andreas,
I just wanted to let you know that we have now released LogViewPlus v2.4.36 as a BETA release.
This release has a number of bug fixes regarding selection. We did not make any changes related to selection based on log entry time, but given the the amount of change and bug fixes made, I think it is worth installing the application and re-raising any selection issues you have.
We have also added two new configuration options which I think you will be interested in:
The first is a row offset which you can use to specify that X rows should be shown above the current log entry. When navigating between views, this helps ensure that the previous log entries are visible.
The second is a setting which will show all selected log entries in the Log Entry Box. This is a new feature, but I am already finding it a surprisingly useful change. It's just another way to view log entries and sometimes it is a bit easier to see the log entries together rather than in the grid.
Hope that helps. Please let me know if you have any further questions or issues.
Toby
|
By AndreasP - 30 Jul 2020
Hi Toby,
thanks for the Info. I observed the new version now for some time, but the initial problem that staying close to the selected time is still now working for merged log files.
Do you need more info or a test case?
Regards
Andreas
|
By LogViewPlus Support - 30 Jul 2020
Hi Andreas,
Yes - I think more detail on the problem would help. Is this an issue when navigating between files or are the navigation issues specific to the same merged file?
Thanks,
Toby
|
By AndreasP - 2 Aug 2020
Hi Toby,
I observed the issue when navigating between different filters/views between the same merged log file.
In the current case I have merged about 40 Log files. Then I have a view A that shows only errors of the merged logs (contains log entries starting on the first original log files). And I have a view B (parallel to view A) where I view a specific error message (starting a log file number 12).
Staying close to the selected log entry works if I use log entries that exist in both views.
But when I use log entries in view A that do not exist in view B, staying close to the selected log entry only works, if I select log entries in view A that belong to file number 12 (or lower, which will move to the first entry in view B). If I select log entries of file number 13 or higher in view A and change to view B then I will end up on a entry of file number 12 (and not 13 or higher).
In a second test case I created view C which shows only warning messages (starts with log entries from file 1). So not containing any common log entries.
When changing from view A to C or C to A I always land on a log entry on file 3, no matter which log entry of any file I selected on the starting view. During further tests this behavior somehow changed, but never not bringing me to close log entries.
Hope this helps in tracking down the issue.
Regards
Andreas
|
By LogViewPlus Support - 2 Aug 2020
Thanks for the detailed error report Andreas. Let me take a closer look and get back to you.
Toby
|
By LogViewPlus Support - 16 Oct 2020
Hi Andreas,
I have spent some time investigating this issue again today. Unfortunately, I am still not able to recreate.
Here is the filter structure I am using for testing
This structure allows me to test scenarios where log entries do or do not exist in filters of different arrangements (parent, child, grandchild). In all cases, log entry selection seems fine. If a log entry does not exist in a filter, a log entry near the target time is selected. This is the expected behavior.
This was tested on the BETA version - v2.4.43.
I feel like your setup is probably different somehow, but I am not sure what the issue could be.
Toby
|
By LogViewPlus Support - 27 Oct 2020
Hi Andreas,
As discussed offline, this issue should now be resolved in the latest BETA release - v2.4.46.
Thanks again for your help debugging this issue. The detailed recreation steps provided were a big help.
Toby
|