[chirp_users] New Chirp metadata support : was New Daily Build

[David Ranch]

Thanks for making this happen Dan and I think this will go a long way in 
the usability for new Chirp users!

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?

--David
KI6ZHD


On 08/09/2018 07:17 AM, Dan Smith wrote:
> Hi all,
>
> I wanted to call out this change in today's build specifically:
>
>> [Dan Smith <dsmith at danplanet.com>] 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).
> 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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_users/attachments/20180809/2a273d4a/attachment.html