Hash is not picked up from Onetrainer SDXL loras

Nobody has claimed this yet.

SS model hash embedded in lora:
"sshs_model_hash": "**DA259DF60E36**12CDA6E7736D9E733018D585DF5C6F8821273AAB137160A5510E",

Hash in image:
NOOB_vp1_detailer_by_volnovik_v1: **DA259DF60E36**,

Actual hash:
PS S:\StabilityMatrix\Models\Lora> Get-FileHash .\NOOB_vp1_detailer_by_volnovik_v1.safetensors

Algorithm Hash Path
--------- ---- ----
SHA256 **8216B71295D4**286FADF3893EEAB4A15D6143DFA6BA785F6027BB3FDAB68E7942

OneTrainer lora:
"modelspec.hash_sha256": "0x**1585b50b9d7d**c20b8d62f9d2948685df9f6336a223256fd54657a740ff26edfd",
Hash in image:
NOOBVP1_stoopid_colorfix_modified: **28f11be9dbf2**
Actual hash:
PS S:\StabilityMatrix\Models\Lora> Get-FileHash .\NOOBVP1_stoopid_colorfix_modified.safetensors

Algorithm Hash Path
--------- ---- ----
SHA256 **28F11BE9DBF2**DD7E044F19471CBAF757E8F7B50BAFAACD92022C712E2CB47E2D

As we can see image hash is picked from actual hash this time.
The issue is that civitai actually parse both and stores autov2 from actual sha256 and autov3 from hash embedded in model. Autov3 is properly parsed from model metadata in case of OneTrainer metadata format.

In ComfyUI only autov2 is saved and it is calculated from actual hash. No issues in detection.

Either OneTrainer metadata format should be parsed properly or autov2 from actual metadata.

I personally think autov2 from actual hash is better securitywise.

The report names no source files, tests, or entry points. Start by locating the model-metadata hash extraction and compare the OneTrainer fields with the image hash and actual SHA256; done means the intended autov2/autov3 behavior is decided and the two reported metadata formats are handled consistently.

Written by the indexing model from the issue text.