v4.2.1 / v4.3.0 Nextion field mapping?

[G7OMN]

I have a 4.3" Nextion screen, with the ON7LDS driver loaded as per https://github.com/on7lds/NextionDriverInstaller.
Hardware is Pi3B+ and MMDVD HS Dual HAT
The nextion is connected on /dev/ttyUSB0
/dev/ttyNextionDriver is selected
Nextion Layout is ON7LDS L3 HS
Nextion has model 10 v1.05 Build 230820-01 loaded (PD0DIB)
Nextion driver is 1.25

I've recently noticed a change in behaviour on the mapped fields that are displayed in 4.2.1 which is an upgrade from earlier versions, where the current active callsign is being populated in a field that should be the TG description on the other timeslot.
The same symptom exists in 4.3.0 (I tried a clean install of that today, without running the driver install as above - as i know the driver is now supposed to be installed by default.)
I've reverted back to in image of 4.1.6, that i had kept and confirm that it still worked as expected.
Referring to the attached images:
In 4.1.6 with the nextion driver installed via the script:
The idle screen populates the CPU load, CPU cycles and Disk free fields. [416_ON7LDS_idle.jpg]
The TG description field is displayed in the bottom right of the display for each slot. [416_ON7LDS_inuse2.jpg]

4.2.1 & 4.3.0
The current callsign in 1 time slot is now being displayed where TG description should be in time slot 2 and vice versa. - [421_430_inuse2.jpg]

4.3.0
the CPU load, CPU cycles and Disk free fields are not displayed in the idle screen - i suspect this is something the NextionDriverInstaller script populates, as it also inserts extra fields in the MMDVM Host section of config as that section is not present in the 4.3.0 install.

So i'm not sure where this has gone awry - but it looks like it might be a field mapping somewhere, that has been introduced as part of the upgrades against the t8/t9 mappings defined in https://github.com/PD0DIB/Nextion_HAM-r ... %20use.txt

Is there something i should be checking, that i have missed?
Should the default driver populate the CPU load, CPU cycles and Disk free fields? (PD0DIB fields t21, t22, t23)

[G7OMN]

Bump....
Out of interest, i had kept an image of 4.1.6 and when i run that, all fields are in the correct places - so that would seem to confirm something has changed in the code?

[KN2TOD]

Have you considered copying the NextionDriver module in 4.1.6 (/usr/local/bin/NextionDriver) to the 4.2.1/4.3.0 images and seeing if that changes anything? (remember to make backups of the effected module).

There are at least three variants of the driver I'm seeing on my images: sized 53292, 55276, and 62892. Which one is correct, or current, is hard to determine as they all return 1.25 as their version number. The 55276 and 62892 sized variants exhibit the same behavior you're seeing on your systems; don't know if the 53292 variant will change that.

Not sure if this is a driver problem or a Nextion screen definition problem: either the wrong values are being populated in the variables passed to the screen OR the screen has field variables crossed somewhere.

Just some thoughts.

[G7OMN]

Thanks for looking at it.
(Maybe i have an uncommon Nextion config - i assume you are running the same? and this is why others haven't seen it?)

I've done a couple of things since yesterday.

I re uploaded the Nextion config to the screen to make sure it hadn't got itself corrupted - the same results.

So looked back at the SD card images.
I have an image of 4.1.6 with dashboard version 20221114 - that worked fine. Nextion Driver 53292bytes, dated 19/12/2022. this reports as driver 1.17
I also have an image of 4.1.6 with Dashboard version 20230924. The nextion driver is 62800 Bytes. Dated 23/03/2022 and reports 1.25
(why i have different dates, i am unsure - i don't remember rebuilding it, especially as the later dashboard seems to have an earlier version?)
However when I update this last version (20230924) and it picks up dashboard version 20240307 it breaks. This version installs Nextiondriver 55276 bytes dated today (this is just the date of the file creation on the local drive) and reports as driver 1.25

Overwriting the driver with v1.17 or the earlier version of 1.25 does not resolve it - so it looks like the wrong index fields have been mapped in Pi-Star, and it predates version 4.3.0 and 4.1.8 - the same issue has just been rolled through.

If I run a subsequent PiStar update - it doesn't update the NextionDriver to 1.25 and stays at 1.17

On Pistar 4.3.0, replacing the driver with 1.17 doesn't fix the issue and the same symptom is exhibited

At least i can see it's not something i have done.