WheezyE/Winelink

Using the Channel Browser crashes RMS Express

KD2ROS opened this issue · 8 comments

KD2ROS commented

I know that this is already in your list of issues on the main page, but specifically, RMS Express crashes when using the Channel Selector after it starts the automatic update of the channel data upon entering the Channel Selection window...it downloads the Winlink channel data and the MPS data...as it is trying to take the downloaded data and update the Channel selection window, it crashes RMS Express.
There used to be an option to upgrade the channel selection/propagation data, yes or no, when you opened the Channel selection window...perhaps being able to select, no, would bypass what is causing the crash and allow the VARA session to proceed?

Also, if you have a known channel that you like to use you are able to type in the callsign, center frequency and dial frequency...when you start the session, it proceeds but, sends you the message that it cannot open the com port that is specified in your session settings, so it will not send the channel data that you typed in to the radio or operate the PTT...the session proceeds as is normal but fails because the radio cannot respond...

WheezyE commented

Thank you for searching for these bugs and documenting when they occur in detail. I’ll try to confirm your results and log them soon in wine-mono. I appreciate the extra set of eyes bughunting!

WheezyE commented

Now that madewokherd fixed the outbox & inbox errors, I've submitted a new bug report to winehq for this one too.
I'm submitting to winehq instead of wine-mono since madewokherd has done so much already and I don't want to barrage them. I'm hoping another dev can jump on this one.

Keep the bug reports coming though! And thank you for testing things

WheezyE commented

I’ve discovered that if you go edit ~/.wine/drive_c/RMS\ Express/KD2ROS/Data/RMS\ Channels.dat with a text editor, delete this line 9W2RUT|OJ02UX|7093|41|00-23|PUBLIC then save the file, then you can use the SFI button in the channel browser to predict propagation quality for channels.

With that bit working, does the radio still have connection issues?

WheezyE commented

I’ve updated my bug report with a possible fix idea for wine-mono too, but am not sure how to implement the fix in wine-mono. We’ll have to see what the devs say

KD2ROS commented
WheezyE commented

Regarding the Channel Browser crash, it seems that one of the stations in the RMS Channels.dat channels database had a typo (it listed its frequency as 7093 Hz instead of 7093 kHz). RMS Express then asked dvoa.dll (D-VOACAP, the propagation prediction calculation engine used by RMS Express) to compute a propagation prediction for about 0.01 MHz, and then dvoa.dll told RMS that it couldn't compute a 0.01 MHz frequency (the author of D-VOACAP says that calculating propagation for frequencies under 4 MHz is unreliable and that frequencies under 2 MHz break the VOACAP algorithm).

This part is speculation, but I believe that the error message from dvoa.dll (which was written in Delphi/Pascal) which was trying to warning us that it couldn't calculate a propagation prediction with that low of an input frequency, then crashed wine-mono somehow. I believe that wine-mono just doesn't know what to do with Delphi error messages yet.

It looks like the station with the typo fixed itself though at some point in time during our trying to find this crash. So the RMS Channels.dat file shouldn't have any more typos for the time being at least - though it could happen again in the future.

I've reached out to the wine-mono devs to see if they can try getting wine-mono to ignore Delphi exceptions. We'll have to wait for a patch before we can say this crash is behind us. I'll close this issue when we get a patch and when I can confirm that the crash doesn't happen anymore.

I've also contacted the RMS Express devs to ask them to put in a warning if there are small-value frequencies on channels. That way, users might be able to get a heads-up that a value in their RMS Channels.dat database might have a typo in it or that propagation for that station might be broken.

Until we hear back from the other devs, I suppose I'll move on to trying to find that COM port error.

the improved stability is a MAJOR improvement for me and will make winelink a win for pi users once VARA and packet issues are resolved...

Thank you for your encouragement - it means a lot. I think moving to wine-mono is the right thing to do, but seems to have introduced a lot of other bugs in the process. Seb has fixed a lot of stability issues in .NET 4.6, though I've been unable to get .NET 4.6 to install in box86 without significant user interaction. I think if I can find a working combination of wine & box86 that installs .NET 4.6 with winetricks completely silently, then I can then have the script move to the latest box86 again and get even better stability in RMS Express. My end-goal is to run everything with wine-mono, since wine-mono is open-source and more future-proof than .NET, but maybe that would fix the immediate issues until we can track down the other wine-mono bugs.

Thank you, also for all of your patience with these bugs! I really appreciate your support. While we wait for a path to install .NET 4.6 silently with box86, keep sending all the bug reports you can find in wine-mono.

WheezyE commented

I've got a possible workaround for the COM ports here while we track down the wine-mono COM port bug. I haven't tested it yet myself, but let me know if you have any install trouble.

WheezyE commented

I'm going to close this issue for now for the following reasons.

  • D-VOACAP is working as expected.
  • The wine-mono devs said that crashes on SEH exceptions are a known bug on their list (so might be fixed in due time)
  • The RMS Express support forum mod seemed uninterested in fixing this, but said he let the RMS Express programmers know in case they want to implement any error handling in the future for small frequencies (the idea would be that RMS Express would catch the small frequencies before they were sent to dvoa.dll and caused a Delphi exception that would crash wine-mono - or at least log the error in the RMS Express log so it's easier to figure out that there's a type in the channels list).
  • These crashes happen when dvoa.dll is given a frequency that is too small and throws a Delphi exception that wine-mono doesn't know how to handle (SEH Exception).
  • The small frequencies might be coming from occasional typo's in the Winlink online channels database, which is used to update the RMS Express HF Channel Selection Browser databases. If these typos are fixed in the online database, or client-side, the wine-mono crash will go away.

If anyone experiences this crash in the future with wine-mono, you can fix it by doing the following:

  1. Open the file ~/.wine/drive_c/RMS\ Express/KD2ROS/Data/RMS\ Channels.dat with a text editor
  2. Look for any lines that have small numbers after the first two entries (for example 9W2RUT|OJ02UX|7093|41|00-23|PUBLIC, where 7093 represents 7093 Hz, or < 0.01 MHz).
  3. Try adding three zeroes onto the end of any < 0.01 MHz frequencies you find (ie change 9W2RUT|OJ02UX|7093|41|00-23|PUBLIC to 9W2RUT|OJ02UX|7093000|41|00-23|PUBLIC). I believe these Hz frequency values need to be at least five or six digits long to play nicely with dvoa.dll (and not crash wine-mono).