Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import FAHClient logs into Work Unit History Viewer #306

Closed
NoMoreQuarantine opened this issue Apr 19, 2020 · 5 comments
Closed

Import FAHClient logs into Work Unit History Viewer #306

NoMoreQuarantine opened this issue Apr 19, 2020 · 5 comments

Comments

@NoMoreQuarantine
Copy link

For new HFM.NET users who have been folding for a while, they will have logs in their AppData\Roaming\FAHClient\logs folder. It would be nice to be able to import that data into the Work Unit History Viewer.

@harlam357
Copy link
Owner

So you're asking that each work unit log be stored with the completed work units? That's not out of the realm of possibility but I'm concerned about the long term usefulness and size of the data.

HFM does not have access to the AppData\Roaming\FAHClient\logs folder for each client. The log file is retrieved from the FAHClient.exe process through a remote interface and the only log available is the log from the current executing process, no previous executions.

Please provide some more detail to this request explaining what you want to accomplish by storing the log for each work unit.

@NoMoreQuarantine
Copy link
Author

There may be more use cases, but the one I was thinking of specifically is for new HFM users, or users who have reinstalled HFM, who have been folding for a while to view their entire work history on the machine. This would allow them to analyze and benchmark their machine without having to wait for additional WUs to complete.

@harlam357
Copy link
Owner

I think I understand what you're asking for. You'd like HFM to be able to "scan" for previous log.txt files and provide a history based on only the data from the log.txt file(s).

Interestingly enough, back in the FAH version 6 (and previous) days... HFM did exactly that. It would read the old queue.dat file, which listed the last 10 work units, then it would scan all available FAHlog.txt files and would go through all the motions to build benchmarks and history for those 10 work units. HFM was configured with the folder path where the logs were stored. So that information was accessed via a folder share when accessing a client not running on the same machine as HFM.

However, with FAHClient version 7 the connection to the client is not via a folder path but through a TCP interface provided by FAHClient.exe. That interface doesn't provide any history information. HFM can only access the log.txt data for the current execution of FAHClient.exe. So there's no way for HFM to do what you're asking automatically for each connected client.

However, if the user were to manually point HFM to a folder where log.txt files exist, it might be possible to glean enough information only from log.txt to build a history. Note that HFM uses the data available in log.txt as little as possible. It uses the FAHClient.exe interface (json) for most of the information it gathers. However, it does use the log.txt data for things that are not available via the interface.

I concur that being able to get an initial history without having to wait would be a great feature. I'd need to do some significant experimentation to see if what you're asking for is possible and that's time I do not have right now. I'm happy to leave this issue open because what you're asking for does make sense and has merit.

I hope my answers give you some more insight into what HFM does under the hood and I also hope I've explained this well enough that you'll understand why I will not be engaging this feature request at this time.

@NoMoreQuarantine
Copy link
Author

I hope my answers give you some more insight into what HFM does under the hood and I also hope I've explained this well enough that you'll understand why I will not be engaging this feature request at this time.

It does, thank you for explaining. I did not realize what this feature would require and completely understand not wanting to start such a large endeavor at this time.

@harlam357
Copy link
Owner

Closing. Good idea but too much experimentation required for what I feel is low value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants