<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font size="-1">Thanks for making this happen Dan and I think this
will go a long way in the usability for new Chirp users!<br>
<br>
One thing I would like to see along these lines is some sort of
new class of file for live radios say like a Kenwood F6A. I know
these are live radios and I also know I can create exports of the
settings those CSV exports aren't going to be treated the same way
as these new Chirp files. Couldn't people just save a .chp file
representing the radio's setting (it's not an image.. I get that)
and it includes all the same meta data support like what you've
added here?<br>
<br>
--David<br>
KI6ZHD<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 08/09/2018 07:17 AM, Dan Smith
wrote:<br>
</div>
<blockquote
cite="mid:6BAA7C03-37DB-40BE-A5C2-0970B119319E@danplanet.com"
type="cite">
<pre wrap="">Hi all,
I wanted to call out this change in today's build specifically:
</pre>
<blockquote type="cite">
<pre wrap="">[Dan Smith <a class="moz-txt-link-rfc2396E" href="mailto:dsmith@danplanet.com"><dsmith@danplanet.com></a>] Add metadata blob trailer transparently to image files
This makes FileBackedRadio transparently save image files with an extra
blob of metadata tacked onto the end of the file. The metadata region
begins with a magic string followed by a base64-encoded json blob. I
figure we can call all images created up until now "version zero" format,
since they really aren't formatted at all. Any major format changes after
this can increment the counter in the magic (although it's unlikely we
would need to).
The metadata currently saved includes the radio model details and the class
used at the time the file was created. All existing images will still load,
but when they are saved, will be augmented with metadata. Note that this will
mean images saved from newer versions of chirp will not be readable by older
versions which will be confused by the metadata.
One major feature this brings is the ability to make radio aliases (and other
weak subclasses) be "sticky" across save/load cycles. Right now if you download
with an alias (such as the Arcshell AR-6 alias of the BF-888), the file will
be detected and reported as a BF-888 from that point forward. With metadata in
the image, we can properly select the alias on load to provide better UX.
This includes some low-effort tweaking of the directory and clone code to
select the right radio class based on metadata if present, and to properly
return a radio class for the alias, if one matches. We might want to re-structure
the alias class arrangement after this to make them properly-registered and
fully-functional subclasses so that the hacky DynamicRadioAlias subclassing
done here isn't necessary.
Also note that the generic saving code will not append metadata for filenames
not ending in .img, to preserve behavor for .vx5 files, etc. If a filename forces
a non-standard file extension, the metadata will not be added and the result
will be effectively the same as the older format (which then may not be loaded
properly if it is mis-detected as a different model).
</pre>
</blockquote>
<pre wrap="">
This is something that has been a long time coming, but will really improve some things around how we deal with the massive duplication of clone models that is common these days. Before this change, when chirp saved a .img file, it was literally a copy of the internal memory of the radio. Historically, when we try to open one of those files, we look at the size and contents to determine which driver to use. That works well when everyone designs their own radios, but when some models are just simply re-badged versions of another radio, that becomes impossible.
The change above, included in today's build, is a step towards keeping some more chirp-specific details in the radio image file so that we can tell what driver was used originally, which will be a much better user experience. There are a couple of things to keep in mind about this:
1. Any older .img files you have will be missing this metadata. Chirp will still open them just fine, but will use the old detection method, which means it will usually choose the most generic driver available (as it always has). If you go to save the image again, Chirp will add the metadata to it, but the metadata will point to the generic driver, since that is all it knows about. However, if you upload that to your radio, and then download it again with the proper model selection in the download box, the resulting image will be endowed with proper metadata going forward. In short, old image files will continue to behave the same way, but will not magically report the proper name for cloned radios.
2. As of today's build, Chirp will always store the extra metadata in .img files. That will confuse older builds of Chirp, which determine the model by guessing at the contents of the image. So, if you use a new Chirp to download a .img file and then take it over to a friend who has an older build, the older build won't be able to open it. The solution is just to make sure everyone has updated to the latest build (which they should do anyway).
So, if you have a radio that you choose from the dialog box, but after download shows up as something else (like the *many* Baofeng clones), try with today's build and you should see the model and brand retained across the full lifecycle.
Of course, if you think you notice anything weird with this new system, report it here or file a bug.
Thanks!</pre>
</blockquote>
<br>
</body>
</html>