Folding Forum

RMCholewa wrote:Tried 7.6.13, same error while adding the client.

Please try the new 0.9.17 release... post to follow here.

New Version: 0.9.17.1040 - Project Site - Download

I encourage everyone to save their hfmx configuration file once loaded into 0.9.17. Just select File > Save Configuration. I did not make this automatic because it does create an hfmx file that is incompatible with the previous release version 0.9.12. However, taking this step will generate unique identifiers for each client which enhances the link between the client definition and slot benchmarks.

- Enhancement: Slot Type now reports actual threads for CPU slots.
- Enhancement: Benchmarks captures and tracks individual GPU or CPU + threads.
- Enhancement: Slots grid painting rewritten (b/c the old code was a travesty). The main change you'll see is PPD and Credit is now right justified and the number formatting is applied. So much easier to read.
- Enhancement: Client hostname/IP and port echoed in status bar.

- Fix: Ensure Main and Benchmarks windows are restored in the viewable screen.
- Fix: Fix to allow log viewers like notepad++ to be used.

- Change: Changed many of the labels in the UI to align better with current FAH terminology.
- Change: Removed "Allow Asynchronous Clocks" setting (v6 thing).
- Change: Use the new HFM.Client API NuGet package.
- Change: Requires .NET Framework v4.7.

---

Need help with HFM? Please post in the HFM Google Group. http://groups.google.com/group/hfm-net

Have a feature request or bug report? Open a new Issue on GitHub. https://github.com/harlam357/hfm-net/issues

@harlam357 - great to have you still working on this!!

Just installed it and all working as before including my web upload (great feature!!)

harlam357 wrote:

RMCholewa wrote:Tried 7.6.13, same error while adding the client.

Please try the new 0.9.17 release... post to follow here.

Hi there!

Here are the findings. Windows 10 190318. F@H Client 7.6.13. HFM 0.9.17.

I added the localhost and it is working.

Added two remote hosts (local network) and, although they test ok, they remain blank (like there is no connection).

Is there anything else I can do to help you troubleshoot it?

Thank you and great work!

harlam357 wrote:I'm sooo sorry I haven't responded to your GREAT ideas and observations here. A lot of information here... so let me address what I've absorbed.

...

2) I think you'll find the "Unknown" issue is much better in the latest 0.9.17 release posted today.

...

So, you're obviously passionate about the HFM, which I really, really dig... nothing makes a dev happier than to have engaged users. So if you're serious about helping drive some of these changes, here's where you can help me... open issues on GitHub and detail these asks there. ONE issue for ask please.

https://github.com/harlam357/hfm-net/issues

Once these things are logged there we can continue to conversation and refine the scope. Also, please understand that I develop and support HFM on my own time and for my love of the Folding@Home project. I have to prioritize issue based on the time I have available.

Thanks for your detailed response! And, yes, #2 now is much better. And, I will create issues shortly.

Thank you for the new version!

Tuna

RMCholewa wrote: Hi there!

Here are the findings. Windows 10 190318. F@H Client 7.6.13. HFM 0.9.17.

I added the localhost and it is working.

Added two remote hosts (local network) and, although they test ok, they remain blank (like there is no connection).

Is there anything else I can do to help you troubleshoot it?

Thank you and great work!

Forget HFM for a moment. Can localhost see the two remote hosts in FAH Advanced Control? Have you added them there first? (It's not necessary for HFM to work but if FAH can't see the remote hosts then HFM won't either.)

HaloJones wrote:
Forget HFM for a moment. Can localhost see the two remote hosts in FAH Advanced Control? Have you added them there first? (It's not necessary for HFM to work but if FAH can't see the remote hosts then HFM won't either.)

Yes, the F@H control can see all three machines (localhost and the other two on the local network). I am able to access them and configure them without a problem. Using the same address and password tried in HFM.

My only suggestion then is to downgrade the FAH software on the remote machines back to 7.6.9 which I know for certain works with HFM 0.9.17

RMCholewa - Open the HFM.log file (see the Help menu) and look for entries with the reblouise or starbuck names please. A connection failure should generate some information in the log that will be helpful in diagnosing the problem.

Hello,

JWhy wrote:I think I have the same issue (new F@h 7.6.11 & HFM 0.9.12 installation).
When I try to add a new client, testing the connection is fine
But when I click OK, HFM crashes

A follow-up to this issue ^

After having theses crashes with F@H 7.6.11 , I rolled back to F@H 7.5.1
Then I upgraded HFM to 0.9.17 (still working fine with F@H 7.5.1)

FYI : both HFM and F@H are running on the same Win10 computer.

With this new HFM version , I installed F@H 7.6.9 ( as a PortableApp , because I did not want to screw up my working F@H 7.5.1 installation)

HFM does not crash any more when I try to add a new (local) client, but it does not display any information.

- F@H is running (cf. here)
- HFM finds the local client and its 2 slots (cf. here)
- but when I click "OK", only one line appears and it stays empty (cf. here), event after refreshing it with F5 or F6.
- communications between HFM and F@H seem OK , according to my interpretation of RawCap+Wireshark data (cf. here) . [pcapng file available, if needed.]
- F@h logfile shows the usual "ERROR:Receive error: 10054" with possible encoding issues (cf. here)
- No warning/error in HFM logfile.

Any idea where this behaviour could come from ? Should I test again with F@H 7.6.13 ?

Thanks for your help.

JY.

Yes, try 7.6.13 again please. If that doesn't pan out I'll get another preview out with some additional logging around the HFM & FAHClient communications.

Also, what appears to be character encoding changes might also an issue. I was not aware of any localization in the log data... so that may be tripping things up. That log-restart message from the wireshark capture is a good test case so thank you for that.

Hi Harlam.

No change with 7.6.13

RawCap+Wireshark traces for testing connection , adding a client , refreshing said client.

Hi JWhy - I've taken your capture of the client messages, specifically the log-restart message and pushed it through HFM's log parsing, thinking that the unicode characters represented in hex might be tripping something up, and those character sequences don't appear to be a problem. I also investigated transforming these the hex representations to the correct character value and I believe I can do that... but the effort would simply be for readability in HFM's log viewer, so it's not super high priority. If you would, however, please log an issue similar to the issue you logged for FAHControl regarding the character display issue at the HFM github repo, I'll get that addressed soon.

https://github.com/harlam357/hfm-net/issues

However, this doesn't solve the problem at hand... getting no reading at all. There is a new preview release that can be downloaded here. Please install it and see that yields any additional information on the connection/reading failure in the HFM.log file.

Hi Harlam,

Thank you for your answer and this new version.

Same behaviour, but there is more info in HFM traces (as expected).
Here are the logfiles, for the same tests as before : testing connection + adding a client + refreshing (with a 10sec. interval for each action.)
- HFM 0.9.18 in debug mode
- F@h 7.6.3
- RawCap+Wireshark

I will log a new issue (rather an enhancement, since it's not really an issue with HFM) later this week.

JY.

Hi JWhy - Yep, that got it. Localized error message with hex encoding in the info message. I missed it when looking at your previous captures.

This "style" of hex encoding may be specific to python. I'm using the .NET industry standard library to parse the JSON from FAHClient and that component is where the error is being thrown. That leads me to believe that this hex encoding being used is not a widely recognized standard.

I'll raise this flag with the FAHClient developer. Because there was obviously a change in behavior between v7.5 and v7.6. Perhaps he can restore the previous behavior. That would fix the log rendering in FAHControl and HFM and also fix this communication issue with HFM. If that conversation doesn't yield any results, then I'll see if I can work around this issue in HFM.

Thank you for the report and the help diagnosing the issue. Much appreciated!