I noticed this issue as a sender, where a vmail template in my canned messages ends up with tags in the message body. 1. Was there a change in the parsing between versions - but the canned messages were not checked and updated? 2. Is there a slight difference between parsing of templates for emails and vmails that triggers it? 3. Looks like I can remove and it works for a vmail template. But the tag parsing behavior is unexpected! Suggestion 1. Modify the parsing to handle/fix canned messages that are written in the intuitive form - similar to how they are sent, and similar to email messages. 2. More care and QA is needed for the code that parses message templates. *** Example *** Canned template: Message Resulting message text: Message

OK I see what is happening: 1. VarAC cluster hears itself beacon. Maybe picked up on a different band! 2. VarAC reports it to PSKreporter on the wrong band! 3. PSKreporter's timestamp is apparently 5 minutes behind! 4. Note that there are no self-beacons listed in any instance, nor do they appear in the logs! Solution: This should definitely be filtered out: 1. VarAC should NOT be reporting its own beacons if heard on the wrong band. 2. It should NOT respond to its own beacons! 3. Filter out any self-heard beacons from the same cluster! 4. I don't know if it is really hearing itself through the radio or if this is some phantom effect bug!

Happened again on 15m at 10:12! The last beacon was at 10:07: Happened again - 20m beacon, reported on 17m!

Example PSKreporter screen of VarAC claiming I heard my own beacon. And surprisingly, it is being reported on the wrong band! Note: There is no beacon entry in the log at that time! In this example, I am beaconing on 20m only and I am NOT beaconing on 40m! Note: My cluster is monitoring multiple bands, and it is possible my 40m instance responded to a spurious INCOMING CONNECTION REQUEST, since PTT is not disabled. Note: It is the middle of the day and there are NO incoming signals on 40m. Log 26/08/2025 08:51:41 - (CN:20) Sending beacon 26/08/2025 08:51:41 - (CN:20) KISS BEACON sent 26/08/2025 08:53:21 - (CN:20) KISS BEACON received from HB9AVK 26/08/2025 08:53:21 - (CN:20) PSKReporter: Logged successfully (HB9AVK) 26/08/2025 08:53:21 - (CN:20) PSKReporter: Sending accumulated records 26/08/2025 08:53:21 - (CN:20) Logging Contact to DB: HB9AVK 26/08/2025 08:58:32 - (CN:20) PSKReporter: Logged successfully (HB9BFM) 26/08/2025 08:58:32 - (CN:20) PSKReporter: Sending accumulated records 26/08/2025 09:00:25 - (CN:1) PSKReporter self report: Logged successfully 26/08/2025 09:00:25 - (CN:1) PSKReporter: Sending accumulated records 26/08/2025 09:01:35 - (CN:20) KISS BEACON received from SV1UY 26/08/2025 09:01:35 - (CN:20) PSKReporter: Logged successfully (SV1UY) 26/08/2025 09:01:35 - (CN:20) PSKReporter: Sending accumulated records 26/08/2025 09:01:35 - (CN:20) Logging Contact to DB: SV1UY

Great! Please test it also for single-channel setups that do not QSO (e.g. FM and SAT).

It still happens in VarAC 12.0.4. Bug seems to be triggered by the Message is too long to display code, and using mousewheel to scroll back the history.

Still happening in VarAC 12.0.4.

Still happening: VarAC Cluster on VarAC 12.0.4 Pretty sure this log entry is related! CN:20) Unable to log QSO with VU2ROE ,missing information Log: 25/08/2025 20:40:59 - (CN:20) Sending beacon 25/08/2025 20:40:59 - (CN:20) KISS BEACON sent 25/08/2025 20:41:23 - (CN:20) KISS packet received 25/08/2025 20:41:23 - (CN:20) Async message received: TO:4Z5PE FROM:VU2ROE DATA: 25/08/2025 20:41:33 - (CN:20) Resetting to Slot 0 25/08/2025 20:41:33 - (CN:20) Connecting VU2ROE 25/08/2025 20:41:47 - (CN:20) Connected to VU2ROE 25/08/2025 20:43:45 - (CN:20) Disconnected from VU2ROE 25/08/2025 20:43:45 - (CN:20) Logging QSO to DB: VU2ROE 25/08/2025 20:43:45 - (CN:20) Unable to log QSO with VU2ROE ,missing information 25/08/2025 20:43:49 - (CN:20) Clearing outgoing queues. 25/08/2025 20:43:55 - (CN:20) Connecting VU2ROE 25/08/2025 20:44:12 - (CN:20) Disconnected from VU2ROE 25/08/2025 20:44:12 - (CN:20) Logging QSO to DB: VU2ROE Screen capture:

I observe this in VarAC v12.0.4, with VARA SAT on QO-100, and with VARA HF. May I suggest to move this discussion, out of the VarAC FM forum, and into VarAC Bug reports? I too, do not wish to disable incoming connection alerts, just to eliminate the spurious ones.

See https://www.varac-hamradio.com/forum/varac-fm-discussion-forum/after-beacon-no-luck/dl-243684d4-7dc3-4d72-aae4-c9880ee4d4ee Please comment there.

Originally, I thought he did it, see https://www.varac-hamradio.com/forum/bug-reports/check-for-illegal-email-names-or-addressees-v12-0-4 But it turns out that I was wrong, and VarAC 12.0.4 did it, but itself. Not user error.

He didn't do it! When he sent through a different station on QO-100 then it only sent once. It's an internal VarAC bug: My VarAC did it! So it is something about my station's software. Possibly related to the alpha version I am running: v12.0.4?

It turns out to be a bug in VarAC, not just a lack of validation. Please see https://www.varac-hamradio.com/forum/bug-reports/duplicated-emails However, I suggest VarAC employ sanity checks any way, to catch these types of issues at whatever stages it can!

In such a case, I would recommend copying it manually and sending a return mail, to let them know they had a typo. It's a good thing that it is hard to edit other people's mail relay etc. :-) Actually, it would be nice to have a "Bounce" or "Return" mail feature, in case messages are undeliverable. I would even consider allowing the message to be CCed to their email address. I sent a bunch of vmails that never got a reply - presumably they are stuck somewhere in a vmail queue or got deleted. I was experimenting trying to relay vmails to the U.S.A. over multiple hops. Unfortunately, it seems they did NOT get manually relayed to their destination.

Here is a new example of this bug - the EMAIL GATE indicators turned ORANGE: 1. Toggling PTT Lock did NOT clear the issue, this time! 2. The QO-100 instance is the email handler. It remained GREEN. 3. All the other instances turned ORANGE! Is it related to incomplete QSO info and automated logging failure? Log file 27/07/2025 08:14:12 - (CN:1) Connected to DL0VBK 27/07/2025 08:14:37 - (CN:1) Incoming message. 27/07/2025 08:14:53 - (CN:1) Disconnected from DL0VBK 27/07/2025 08:14:53 - (CN:1) Logging QSO to DB: DL0VBK 27/07/2025 08:14:53 - (CN:1) Unable to log QSO with DL0VBK ,missing information 27/07/2025 08:14:56 - (CN:1) Clearing outgoing queues. 27/07/2025 08:15:53 - (CN:1) Debug mode disabled 27/07/2025 08:15:54 - (CN:1) Instance number: 1 27/07/2025 08:15:54 - (CN:1) Setting unattended links ON (load) 27/07/2025 08:15:54 - (CN:1) Resetting to Slot 0 27/07/2025 08:15:54 - (CN:1) Opening COM port 27/07/2025 08:16:08 - (CN:1) Sending beacon 27/07/2025 08:16:08 - (CN:1) KISS BEACON sent 27/07/2025 08:17:15 - (CN:1) Error: unable to load QSO data: Value was either too large or too small for an Int32. at System.Convert.ToInt32(Int64 value) at System.Int64.System.IConvertible.ToInt32(IFormatProvider provider) at System.Convert.ToInt32(Object value) at VarAC.VarAC.get_qso_details(String guid) at VarAC.Form15.dg_ch_adif_history_SelectionChanged(Object sender, EventArgs e) 27/07/2025 08:17:15 - (CN:1) Error: unable to load QSO data: Value was either too large or too small for an Int32. at System.Convert.ToInt32(Int64 value) at System.Int64.System.IConvertible.ToInt32(IFormatProvider provider) at System.Convert.ToInt32(Object value) at VarAC.VarAC.get_qso_details(String guid) at VarAC.Form15.dg_ch_adif_history_SelectionChanged(Object sender, EventArgs e) 27/07/2025 08:17:17 - (CN:1) Error: unable to load QSO data: Value was either too large or too small for an Int32. at System.Convert.ToInt32(Int64 value) at System.Int64.System.IConvertible.ToInt32(IFormatProvider provider) at System.Convert.ToInt32(Object value) at VarAC.VarAC.get_qso_details(String guid) at VarAC.Form15.dg_ch_adif_history_SelectionChanged(Object sender, EventArgs e) 27/07/2025 08:17:21 - (CN:1) Error: updating instance keepalive in SQLite:database is locked database is locked at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt) at System.Data.SQLite.SQLiteDataReader.NextResult() at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave) at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery() at VarAC.VarAC.update_instance_keepalive(Int32 instance_id) 27/07/2025 08:17:21 - (CN:20) Error: updating instance keepalive in SQLite:database is locked database is locked at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt) at System.Data.SQLite.SQLiteDataReader.NextResult() at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave) at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery() at VarAC.VarAC.update_instance_keepalive(Int32 instance_id) 27/07/2025 08:17:21 - (CN:40) Error: updating instance keepalive in SQLite:database is locked database is locked at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt) at System.Data.SQLite.SQLiteDataReader.NextResult() at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave) at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery() at VarAC.VarAC.update_instance_keepalive(Int32 instance_id) 27/07/2025 08:17:21 - (CN:10) Error: updating instance keepalive in SQLite:database is locked database is locked at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt) at System.Data.SQLite.SQLiteDataReader.NextResult() at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave) at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery() at VarAC.VarAC.update_instance_keepalive(Int32 instance_id) 27/07/2025 08:17:22 - (CN:1) Error: unable to update instance busy status in SQLite:database is locked database is locked at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt) at System.Data.SQLite.SQLiteDataReader.NextResult() at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave) at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery() at VarAC.VarAC.update_instance_busy_state(Int32 instance_id, Boolean is_busy) 27/07/2025 08:17:22 - (CN:40) Error: unable to update instance busy status in SQLite:database is locked database is locked at System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt) at System.Data.SQLite.SQLiteDataReader.NextResult() at System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd, CommandBehavior behave) at System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery(CommandBehavior behavior) at System.Data.SQLite.SQLiteCommand.ExecuteNonQuery() at VarAC.VarAC.update_instance_busy_state(Int32 instance_id, Boolean is_busy) 27/07/2025 08:17:24 - (CN:1) Error: unable to load QSO data: Value was either too large or too small for an Int32. at System.Convert.ToInt32(Int64 value) at System.Int64.System.IConvertible.ToInt32(IFormatProvider provider) at System.Convert.ToInt32(Object value) at VarAC.VarAC.get_qso_details(String guid) at VarAC.Form15.dg_ch_adif_history_SelectionChanged(Object sender, EventArgs e) 27/07/2025 08:17:35 - (CN:1) Error: unable to load QSO data: Value was either too large or too small for an Int32. at System.Convert.ToInt32(Int64 value) at System.Int64.System.IConvertible.ToInt32(IFormatProvider provider) at System.Convert.ToInt32(Object value) at VarAC.VarAC.get_qso_details(String guid) at VarAC.Form15.dg_ch_adif_history_SelectionChanged(Object sender, EventArgs e) 27/07/2025 08:17:39 - (CN:1) Error: unable to load QSO data: Value was either too large or too small for an Int32. at System.Convert.ToInt32(Int64 value) at System.Int64.System.IConvertible.ToInt32(IFormatProvider provider) at System.Convert.ToInt32(Object value) at VarAC.VarAC.get_qso_details(String guid) at VarAC.Form15.dg_ch_adif_history_SelectionChanged(Object sender, EventArgs e) 27/07/2025 08:19:52 - (CN:1) PSKReporter: Logged successfully (FR4KF) 27/07/2025 08:19:52 - (CN:1) PSKReporter: Sending accumulated records 27/07/2025 08:20:57 - (CN:1) Closing Rig comport 27/07/2025 08:20:57 - (CN:1) Closing GPS comport 27/07/2025 08:20:57 - (CN:1) Closing Rig TCP port

In 2025 (v12) the 30m calling frequency is now 10,133.

How to reproduce the bug: So it turns out VarAC gets confused when I open a new VarAC instance (not in the cluster). All the secondary instances' indicators turn ORANGE! They remain orange, even if select a profile or I close the new instance. However, if I toggle PTT LOCK in the email handler node, they all turn BLUE again! I don't think opening a new VarAC instance should affect other instances - especially if it is NOT part of a cluster! VarAC v12.0.4

Isn't it supposed to be blue (not orange)?

And...it went back to ORANGE again! 26/07/2025 20:22:20 - VarAC base directory: C:\Program Files\VarAC\ 26/07/2025 20:22:20 - Checking for VarAC update. 26/07/2025 20:22:31 - Shutting down VarAC... 26/07/2025 20:22:32 - Starting VarAC (V12.0.4) 26/07/2025 20:22:32 - OS: Microsoft Windows NT 6.2.9200.0 26/07/2025 20:22:32 - OS: Microsoft Windows NT 6.2.9200.0 26/07/2025 20:22:33 - Debug mode disabled 26/07/2025 20:22:33 - FREQ Schedule off 26/07/2025 20:22:34 - (CN:40) Instance number: 40 26/07/2025 20:22:34 - Exiting - Closing email gateway thread 26/07/2025 20:22:34 - Exiting - Closing Relat notifications and broadcast thread 26/07/2025 20:22:34 - Exiting - Closing Load datastream history thread 26/07/2025 20:22:34 - Exiting - Closing check for update thread 26/07/2025 20:22:34 - Closing VarAC 26/07/2025 20:22:34 - (CN:40) Away status set to true 26/07/2025 20:22:34 - (CN:40) Setting away status to true (load) 26/07/2025 20:22:34 - (CN:40) Unattended links enabled 26/07/2025 20:22:34 - (CN:40) Setting unattended links ON (load) 26/07/2025 20:22:34 - (CN:40) PSKReporter: logging enabled 26/07/2025 20:22:34 - (CN:40) PSKReporter: Connected 26/07/2025 20:22:35 - (CN:40) Advanced Mode enabled 26/07/2025 20:22:35 - (CN:40) Opening DB connection 26/07/2025 20:22:35 - (CN:40) Current VarAC DB version: 29 26/07/2025 20:22:35 - (CN:40) Updating login data to database. 26/07/2025 20:22:35 - (CN:40) Applications launcher disabled 26/07/2025 20:22:40 - (CN:40) Connecting VARA Main Modem Command interface... 26/07/2025 20:22:40 - (CN:40) Connecting VARA Main Modem data stream... 26/07/2025 20:22:40 - (CN:40) Connecting VARA Main Modem KISS Command interface... 26/07/2025 20:22:40 - (CN:40) Connected to VARA modem 26/07/2025 20:22:40 - (CN:40) Setting Bandwith to 500Hz 26/07/2025 20:22:41 - (CN:40) VarAC base directory: C:\Program Files\VarAC\ 26/07/2025 20:22:41 - (CN:40) VARA version: VARA HF v4.8.9 26/07/2025 20:22:41 - (CN:40) Checking for VarAC update. 26/07/2025 20:23:18 - (CN:40) Email Gateway disabled (Manually) 26/07/2025 20:23:29 - (CN:40) Email Gateway activated (Manually) 26/07/2025 20:23:51 - (CN:40) KISS BEACON received from 4Z1AC 26/07/2025 20:23:51 - (CN:20) KISS BEACON received from 4Z1AC 26/07/2025 20:23:51 - (CN:20) PSKReporter: Logged successfully (4Z1AC) 26/07/2025 20:23:51 - (CN:20) PSKReporter: Sending accumulated records 26/07/2025 20:23:51 - (CN:20) Logging Contact to DB: 4Z1AC 26/07/2025 20:23:51 - (CN:40) PSKReporter: Logged successfully (4Z1AC) 26/07/2025 20:23:51 - (CN:40) PSKReporter: Sending accumulated records 26/07/2025 20:23:51 - (CN:40) Logging Contact to DB: 4Z1AC

Unfortunately, it happened again, in v12.0.4 (the 20m instance's EMAIL GATE indicator turned ORANGE). Then I set PTT Lock ON in the QO-100 instance, and the 20m instance turned BLUE. I set PTT Lock OFF again, and the 20m instance remained BLUE. Strange. The log appears normal: 26/07/2025 18:47:57 - (CN:20) Email Gateway disabled (Manually) 26/07/2025 18:48:03 - (CN:20) Email Gateway activated (Manually)