Five images still change channel data across a write (one invents 60 channels)

[jasiek]

Summary

After #31/#32, a load → export → reload cycle preserves channel data for 212 of 217 images that write successfully. Five still change, and one of them is serious.

Method: load the image, export it, reload the exported bytes, compare rows field by field. Byte differences alone are not interesting — 170 images differ in bytes while every row is identical, which is padding and unused regions, not data loss. Only the five below actually change what the user sees.

The five

Image	Driver	Rows	Changed	Field
Icom_ID-51_Plus2	id51plus.ID51PLUS2Radio	2 → 62	2 gone, 62 new	whole rows
Radioddity_GM-30	radioddity_gm30.RadioddityGM30	56 → 56	22	Offset
Yaesu_FTM-7250D_R	ftm7250d.FTM7250Radio	2 → 2	2	Power
Anysecu_UV-A37	mml_jc8810.UVA37Radio	21 → 21	1	Power
BTECH_GMRS-20V2	btech.GMRS20V2	30 → 30	1	Power

Icom ID-51 Plus2 — writing invents channels

The image has 2 channels. After a write it has 62: both original locations vanish and 62 channels that never existed appear, all at 440.000000.

before: locations 0, 1
after:  62 channels, e.g. loc 7@440.000000, 15@440.000000, 23@440.000000

This is the most severe of the set — a user who loads this codeplug and exports it gets a materially different one. Likely erase_memory() on the untouched locations materializing driver defaults rather than clearing, but that needs confirming.

Radioddity GM-30 — offsets rewritten

22 channels have their offset replaced with a constant:

loc 1: Offset 295.895850 -> 0.600000
loc 2: Offset 295.920850 -> 0.600000
loc 3: Offset 295.945850 -> 0.600000

The original values look like uninitialized data in a field the channel does not use, in which case the rewrite is harmless normalization. This needs triage against the channels' duplex before it is called a bug — if those channels are simplex, offset is ignored and nothing is lost.

Yaesu FTM-7250D — an upstream CHIRP defect, not ours

Power inverts between the two channels: loc 1: Hi -> Low, loc 2: Low -> Hi.

This reproduces in pure CHIRP with no webchirp code involved:

_r = directory.get_radio_by_image(path)
for _n in (1, 2):
    _m1 = _r.get_memory(_n)
    _r.set_memory(_m1)        # write back unmodified
    _m2 = _r.get_memory(_n)
    # loc 1: before Hi, after Low
    # loc 2: before Low, after Hi

get_memory → set_memory → get_memory does not round-trip power in this driver. Upstream's test_brute_force.py::test_get_set_all runs that exact sequence, but assertEqualMem (chirp/tests/base.py:160) skips power with a # FIXME, so their suite cannot see it. Worth reporting upstream rather than working around here.

Anysecu_UV-A37 and BTECH_GMRS-20V2 each change power on a single channel and should be checked the same way — driver-level set/get first, before assuming the fault is ours.

Note on byte-level comparison

Byte-identity is a poor oracle: 170 images differ in bytes with no row changing. Any regression test here should compare rows, not bytes, and treat byte-identity (42 images) as a bonus rather than a requirement.

Measured across chirp/tests/images/ after #32.