Thanks for the feedback.

I would like to fix these issues.  I have not seen them before and I don't think they have been reported elsewhere.  The next step is to isolate the bugs so that they can be reproduced.  For tracking, it would be best to do this a separate forum post for each issue.

We have a new BETA release coming out tomorrow which will (hopefully) help with some of the issues are you are seeing.  The new release has a fix for opening files and Workspaces from the command line as well as via drag-drop.

We normally try and release every 6 - 8 weeks.  However, we will be looking at a major upgrade soon which will mean a large delay in the release cycle.  After the BETA version goes live, there will likely be another small release in 2 - 4 weeks before a large 8 - 12 week gap.  So, now is a great time to report these issues as we should have a quick turn-around.  I appreciate that it is frustrating to make bug reports - but if you can help, I am sure we can make quick progress against these issues.

In the meantime, if you are having trouble with Workspaces you might try using Templates instead.  Templates are simpler than Workspaces and may work more reliably.   You could also try simplifying your Workspaces to just opening a few files and applying templates after the files are opened.  Not an ideal solution - but maybe worth a try.

Hope that helps,

Toby

Hello Toby.

Thank you for taking the time to review the issue. I appreciate the solution. Given this and multiple other issues I have given up on using your software for reviewing or monitoring older logs. I am only using it to review recent uncompressed logs and drilling down into bugs. This is a shame, since the core workflow is great. And IMO my setup is the sweet spot for your solution.

Just within this week I had (1) 2 workspaces unrecoverabily lost (2) reported a problem as occurring on the wrong environment due to workspaces not shutting down cleanly (3) logview taking 100% CPU for minutes (?) with unpleasant side effects. Workspaces are a core feature for my use case. But based on my experience I would call this part of your software a beta release. Again - the core feature set is great. Had it not been I would have requested a refund.

My use case for context: I have 3 AWS EC2 virtual machines, accessible via SSH. Each of them is running the same software, consisting of 4-5 modules. Each module produces 1-2 log files. The logs are archived after a day into a tar.gz file. I am interested in current day's logs + 3-4 days back at times. The log traffic is light. I am basically running a single thread on each machine at a time. What I am trying to achieve is to have (1) a workspace per EC2 (2) with log files unmerged, as they represent different subsystems with unrelated log content (3) with each log file having filters preconfigured to display (a) errors (b) typical execution stages (c) previously diagnosed error symptoms.  These are not complicated workspaces; setting them up takes me ~10 minutes in total. Yet they get corrupted constantly (multiple times a week). And I am getting "fun" errors daily.

I hope you will be able to fix these issues. I appreciate both the core idea and feature set.

Hi Micmic,

As part of the upcoming release I reviewed this issue.  Unfortunately, we will not be able to resolve this in the near term. 

The problem is that the opened archive contains files which may or may not exist on the subsequent open.  The rules for managing these files are different than for files opened directly.  Certain metadata - like the category - cannot be persisted.  

Files opened via a Directory Monitor have the same problem.

The only solution I can recommend would be to open the files individually (without using LogViewPlus for extraction).  This will give you more control over persisting the presentation.

As a new feature, I think it worth thinking about opening archives and directory monitors purely as a merged file.  This would then open all of the data without the 'clutter' of the individual files.  Would this feature help?

Thanks again for reporting this issue,

Toby

Hi Micmic,

Thanks for reporting this issue.  I can confirm that this is a bug.  I will take a closer look and see if we can get this fixed in the next release.

Thanks again,

Toby

Hello.

After reloading a workspace, the categories I created are replaced with default ones.
Steps to recreate:

1. open a log file compressed as xxx.log.gz
2. the xxx.log.gz file is by default assigned to a category matching the archive file
3. "Set category" from the context menu on the xxx.log.gz file, input new_category
4. the category changes as expected:
1. the default, archive file category disappears (xxx.log.gz)
2. new_category appears
3. the log is stored in new_category
5. save workspace
6. close app
7. reopen app
8. open workspace