Forum Discussion
QR code scanning troubles
5 Replies
- MrCSuper Contributor
I have not been able to duplicate the problem you are seeing. So let's use --debug to see if we can narrow this down to a record.
For each record, there will be debug output indicating the record being processed, and the field / value pairs for the record:
gen_conversion_file : Processing record 'Bookmark 1' (category login) add_fv_pair : field: Vault = Imported M_C_S add_fv_pair : field: Title = Bookmark 1 add_fv_pair : field: Tags = Email add_fv_pair : field: Modified = 2025-06-06 08:59:14 add_fv_pair : field: Created = 2025-06-06 08:59:14 add_fv_pair : field: urls = www.example.com/
Examine your debug output and look for an empty field label. Each field / value pair is shown in the add_fv_pair debug line as:
field: Field = Value
Let me know if this helps isolate the record and offending field.
- douglsmithNew Contributor
Using --debug, hundreds of records show things like the examples below that are missing a field name. The xxxxxxxxxxxx represents what is usually a copy of the password for the record. When I look up those records in 1Passwords, sometimes I see autosaved web details that include the data from those rows, but not always.
add_fv_pair : field: = Login add_fv_pair : field: = xxxxxxxxxxxx
- MrCSuper Contributor
Ok, thanks for confirming. Now comes the hard part since I have no idea how to reproduce this. So I'll have to ask questions...
- When you look at one such record in 1Password, do field labels exist where they don't in the --debug output?
- If you enable 1Password's Settings > Advanced > Show debug tools, and then right-click an offending record and Copy item JSON, and paste the copy into a plain text editor, do you see field labels whereas you don't in the --debug output? I'll explain below what to look for.
- Were these records created by way of another password manager's export, which were then imported into 1Password?
- Are you be able to create a temporary vault and reproduce the issue with a new Login record in that vault?
- If you can't reproduce the problem with a new record, can you reproduce it with a copy of a problematic record stored in the temporary vault?
- If you can reproduce the issue with either (3) or (4), would you be willing to send me a sanitized version of the record as JSON. If you don't know how to do this, I explain below.
Each record has an array (list) of sections, and each section has an array of fields. Each field should have a title attribute (the field's title or label). If you've not provided a title when you created the field, it will appear blank in 1Password, but should have a generic name based on the type of the field. The yellow arrows below show two such custom fields, whereas the title attribute where I provided a label (red arrow) shows its label.
Login records also have two additional legacy "fields" contained in a different structure. These are in the loginFields array. There are usually two entries, one for the username, one for the password (and these are indicated by the fieldType and/or designation, and typically these have the name attribute of username and password, respectively:
Here's the complete sample Login record:
{ "uuid": "vxch6x3iyj2jcj7tyl6jkxirza", "favIndex": 0, "createdAt": 1749225554, "updatedAt": 1750690632, "state": "active", "categoryUuid": "001", "details": { "loginFields": [ { "value": "password3", "id": "", "name": "password", "fieldType": "P", "designation": "password" }, { "value": "user3", "id": "", "name": "username", "fieldType": "T", "designation": "username" } ], "notesPlain": "what is the meaning of life?\nSuper Dooper Party Pooper\nè ÿ æ Ą Ǝ Dž Ƙ\nEND", "sections": [ { "title": "", "name": "add more", "fields": [ { "title": "a custom text field", "id": "xyy2zu2wcsjw6k6mcshaxbkdga", "value": { "string": "value 1" }, "guarded": false, "multiline": true, "dontGenerate": false, "inputTraits": { "keyboard": "default", "correction": "no", "capitalization": "sentences" } }, { "title": "text", "id": "sruswjp2vduqe5ftkqyy2f636i", "value": { "string": "value 2 for empty label custom field 1" }, "guarded": false, "multiline": true, "dontGenerate": false, "inputTraits": { "keyboard": "default", "correction": "no", "capitalization": "sentences" } }, { "title": "text", "id": "w23zcb4l7xsjbzywuyvzlxbpf4", "value": { "string": "value 3 for empty label custom field 2" }, "guarded": false, "multiline": true, "dontGenerate": false, "inputTraits": { "keyboard": "default", "correction": "no", "capitalization": "sentences" } } ] } ], "passwordHistory": [] }, "overview": { "subtitle": "user3", "icons": null, "urls": [ { "label": "website", "url": "http://mail.example.com/", "mode": "default" } ], "title": "Web Account with 3 links (user3)", "url": "http://mail.example.com/", "watchtowerExclusions": null } },
Ultimately, we're looking for fields that have no values for the title attribute within the 1PUX's data.
To view the raw 1PUX data, make a copy, change the suffix from .1pux to .zip, and then expand that zip. Inside there's an export.data text file. That's the contents of your vault's data, minus the file exports stored in the files folder, and metadata stored in the export.attributes file. View the export.data with a plain text editor.
Hopefully you are able to detect some pattern, or the answers to my questions help me reproduce the issue.
- MrCSuper Contributor
You're welcome. But let's save any thanks until we get your issues resolved! :-)
The error is suggesting that one of the field labels in a record has no value (i.e. it's empty). I'll have to test this condition tomorrow, and I then handle this case better (and will warn about the condition during conversion). An empty field label should not be allowed, and might be botching the generation of the CSV.
For now, you might be able to use the --debug option, and look for per-record lines that start with gen_conversion_file : Processing record. Each will include the record's title and category. Hopefully you see the warning line you showed above after the debug line, so that you can identify the suspect record.
The --addfields issue may be due to the first problem. When used, custom fields go into their own section within the record. And because this section name is appended to the field label, it makes it impossible for the field label to be empty (thus, avoiding the problem).
Let's see if we can resolve the first problem first. I'll run some tests in the morning.