[merijnb]

This is the logic for how the import works (assuming MobileSheets is managing the files which is a setting that is only available on Android):

1) A PDF is selected and imported
2) A title for the new song has to be determined, which is calculated based on whether PDF metadata is being extracted (and with the next update, is being used for the title), or the dropdown selection on the import dialog
3) If "Create Subdirectory per Song" is enabled, a folder will be created in the storage location that matches the calculated title for the song.
4) The output location for the file is calculated based on #3 plus the storage location path + the name of the PDF.  So if we are on Windows, for example, no subdirectories are used and the PDF is named "Song 1.pdf", MobileSheets checks C:\Users\<your username>\AppData\Local\Packages\41730Zubersoft.MobileSheets_ys1c8ct2g6ypr\LocalState\Song 1.pdf to see if it already exists (assuming you are using the default storage location)
5) If Song 1.pdf already exists, MobileSheets checks the calculated hash for the existing file against the calculated hash for the new file to see if they match. Any modification, no matter how minor to the PDF, will cause the hash to be different. If the hashes do not match, a conflict dialog is displayed letting the user choose how to handle the new version of the PDF. If a Song 1.pdf does not exist, the new file will just be used and a song will be created with no need for user import. If Song 1.pdf is identical to what is already being used in the library, then it will either be ignored or a new song will be created using the same file based on the duplicate file behavior dropdown

That is the only thing that is considered. The metadata in MobileSheets plays no part. It just matters whether the PDF itself is different from what is already being used.

Mike

Clear, then I misunderstood you earlier and I expect all my 'problems' are gone when the new checkbox is available.

[sgruenbe]

I found an issue, at least something that could be improved, when importing a PDF with XMP meta data on my android tablet with MobileSheets Pro 3.8.43:

My observation:
1) When I transfer a pdf to my table via bluetooth, and then finally tap on the "Received file from ..." dialog, I am asked with which app to open the file. When I choose mobile sheets here, a file import dialog is displayed, where the XMP metatags that I've set in the pdf are already prefilled, which is something I also expected. Unfortunately, this is NOT the case for the title field, for whatever reason?

2) Contrary, when I manually open MobileSheets, go to Import and select a local file, the import dialog is completely empty. None of the preset XMP metatags in the pdf are prefilled. That's why I though for hours I'm doing something wrong with the metatags :-)

However, after the file has been finally imported, the tags and even the title are correctly assigned to the imported piece.

I think this is an unintended behaviour not only on my device?

Just wanted to share this :-)

Thx,
Stefan

PS: By the way, is it fine to create an XMP tag also for the title? I read, that also some standard fields are mapped like Author -> Composers. So, what happens if both are set? Which tag wins in the end? Or are they just aggregated?

[Zubersoft]

The current behavior is the correct behavior, because you can select 20 PDFs at once with Import->Local File, and it would be incorrect to populate the fields with metadata from all 20 files (as then all 20 songs would have the same metadata). Those fields are used to add additional metadata on top of any metadata that would be populated due to XMP metadata or metadata in chord pro files, for example.

As far as title, "Title" is already supported as one of the standard PDF fields. It doesn't need to be an XMP field because it's one of the standard ones that any PDF library should support. If you specify both Author and Composer, I believe the values are joined together, meaning if the values for each field are different, multiple composers will be generated for that song.

Mike