Can you please make sure you are using the latest BETA release?  I believe this issue has been resolved:
https://www.logviewplus.com/download.html

I updated to the beta. The main window no longer minimizes after saving the formatter. However, the newly added file still disappears from the top pane.

This sounds like the issue we have been trying to recreate.  I have tried several times, but I am unable to reproduce the issue locally.  You seem to be able to recreate the issue pretty consistently, so there must be something I am missing.

If you run the Parser Wizard and save the parser configuration, the log file is refreshed.  As part of the refresh process the file is removed and re-added to the view.  It seems LogViewPlus is getting confused on the refresh.  

After the parser has been configured, are you able to open the file - possibly after a restart?  If you are able to open the file, what happens if you refresh it (F5)?  Are you opening the file directly or through a Directory Monitor or Workspace?  Is there another file with the same name open?  Are there any errors in the SFTP transfer log?

Sorry for all of the questions.  This is a very strange issue.

1. If I close the workspace and reopen it, the file shows up again.
2. After reopening the workspace and selecting the file, clicking the Reload File button makes it disappear again. However, I just noticed, this happens with ALL files. Selecting any file and clicking Reload makes that file disappear from the top pane.
3. I'm not sure what you mean about Directory Monitor vs Workspace. This is a directory monitor configured within a workspace.
4. There are no other files with the same name.
5. There are no errors in the transfer log.

I have taken a closer look at this issue and am still struggling to recreate it.  I will continue investigating, but one thing I have noticed is that there can sometimes be a considerable delay between when the file is refreshed and when the download begins.  I am testing with large files, but the delay is a little strange.  Nothing major - 1 to 3 seconds max.  I am assuming that when you refresh the file never recovers.

There is also a time period where the file is downloaded before parsing begins.  LogViewPlus may seem like it is not busy during this period - especially if the transfer tab is not visible.  From your screenshots, I do not believe this is the case, but I thought it worth mentioning.

It might also be time to take a closer look at the transfer log and, possibly the SFTP server logs.  Does the re-download get triggered successfully?  Are there any signs of a deadlock?  I would be happy to take a look at these logs if you want to send them to me via email.

I sent you one of the transfer logs. If you want to troubleshoot this further, I can execute a series of actions and then send you the log after. But at this point, I can't even keep track of everything we've discussed, so you'd have to send me a specific set of steps and instructions for what you want me to test.

Thanks for the transfer log Brad.

I have added some additional transfer logging to the latest BETA release of LogViewPlus (v2.5.30). Can you please install this version and...

1. Open any file which has the issue.
2. Open the transfer log.
3. Clear the transfer log (F4).
4. Refresh the file opened in step 1 (F5).  This will hopefully recreate the issue.
5. Send me the log lines now displayed in the transfer log.

If possible, it would be good to execute the above steps after a restart as this would help ensure there is nothing else interfering with the test.

Thanks,

Toby

OK, i sent it.

Thanks Brad.

The file looks fine.  No sign of a deadlock or other download issues.  Have you seen this issue with local files?

I will need to think of the next steps.  I have not been able to recreate the issue even once nor have I had other customer reports.  You seem to be able to recreate the issue very easily.  This indicates to me that there is something different about your environment, but I am not sure what else it could be.  The remaining parts of the system should be constant across installations.

I will try and think of what else might be causing the issue.

Thanks for your help,

Toby

There's nothing special about my client-side environment; it's just Windows 10.

Therefore, I suspect the issue is with the SFTP on the server side. Probably not many of your customers are using SFTP and if they are, they're using it with a Windows server. Mine is running on a Ubuntu 20 server. If you want, I could give you SFTP access to my server, so you can test it. I bet you could reproduce the issue just as easily as I can.