FortiusAnt on headless raspberryPi using VNC hangs gui

[GewoonGijs]

Hi, I started using your application today. I managed to get it running on a raspberry pi. But, I have issues when i try to use the gui over VNC. My raspberry pi is headless, so i want to control it form my Macbook or PC.

Does anyone has experience with this?

Or can I run the Runoff without the GUI?

I have a T1901 brake and a T1932 head unit.

[MeanHat]

Hi @GewoonGijs - my daughter uses a headless RPi 3 with iMagic and T1902 head unit remotely with BLE to Zwift. I can access the RPi remotely with VNC, if needed, as she doesn't live nearby. Using a start-up script RPi enters desktop (rather than CLI) which works for VNC. The start-up does not call "-g" for FortiusAnt GUI. She has dispensed with the runoff test.

[GewoonGijs]

I tried again tonight, but I am still running into problesm. There seem to be some threading errors.

One of the errors I get is:
Pango:ERROR:../pango/pango-layout.c:3871:pango_layout_check_lines: assertion failed

And sometimes i get X server related errors.

After going through the code, the only thing I ca think of that might cause these effects are the debug messages that are send to the Console from different thread without threat protection or some concurrency errors from the ant2Dongle thread, the main thread and the BLE thread in sending messages to the GUI.

[mikeherriman]

I also have GUI crash/lockup issues with my RPI 4b. The GUI will stop displaying any values for power, speed, Virtual Gearbox, the speed and power dials still function. Nay way to exit program is to click X in top right corner and wait for OS to prompt to shutdown process. This occurs if using either BLE or ANT+ mode. Have not tried running FortiusANT with no GUI.

I have just decided that the dials are good enough, as Zwift and RGT both display the values and control the trainer as normal.

[GewoonGijs]

@mikeherriman good to hear you are experiencing the same sort of issues. I have an idea it has to do with wxPython and using it in a thread safe manner. I will do some experiments later today to validate this hypothesis.

Probably I just have to to pack some calls to wx.elemetns in wx.CallAfter in the SetValues() method of FortiusANTGui.py. This seems to be necessary because SetValues() runs in a different thread then wx mainloop.

[WouterJD]

@GewoonGijs
Welcome to the FortiusANT community

---

I'm always curious to know who I communicate with, where FortiusANT is used and what configuration is used.
Please tell me what bundle did you buy, and what brake and what head unit do you use?
I would therefore appreciate that you introduce yourself; perhaps leave a comment under issue #14.

---

I would think wx is only called in the GUI thread. If not, please let me know

[WouterJD]

If -A is NOT specified, one thread is used

[GewoonGijs]

@WouterJD , the RunOff Thread and Tacs2Dongle Thread are spaned as well in the FortiusANTGui

[GewoonGijs]

@WouterJD , I think I found the problem. On pressing the Start button from the Gui a Tacx2Dongle thread is spawned, and form this thread the GuiMessageToMain() is called. The parent will start, and the first message back to GUI can be a SetValues() or SetMessage(). This will result in calling al kind of wxPython methods on the gui, but not from the main thread. And that can cause problems, according to WxPython multithreading.

I tried to put both of these in wx.CallAfter() wrappers, and now it works like a charm, at least with the simulated version. Haven't tested it with the Tacx and my bike.

The only strange thing that's left, is when I have paired FortiusANT with Zwift and press stop and try to start again, no bluetooth messages are sent anymore. The node server doesn't accept messages anymore. A bit strange, but if I unpair first from Zwift, and stop and start again it does work. Curious, but not really a problem :)

[WouterJD]

As said on the pull-request, happy to have you on board. Raspberry + python + magnetic trainer knowledge! Welcome

[WouterJD]

@GewoonGijs thanks for this, we probably touch something I was struggling with when writing this piece of code; and it does not cause too many problems so was forgotten.

There are two threads:

• the main thread which is "almost" inactive (nothing happens)
• the second thread for Runoff or Start

They usually run well together, but there is aan issue around the communication with the STOP button I did not properly resolve.

As you see OnClick_btnStop() does not only set self.RunningSwitch = False to stop the started thread, but also handles user-interface elements, which should better be done in the thread (when it detects that it should be stopped).

Thanks for putting me on the callAfter() path!

[WouterJD]

Implemented in branch; will be promoted to version 5.2 shortly