Hi Dallan
Thanks so much for your quick response. I’ll send the original exported GEDCOM file and my modified version for your consideration. I don’t understand why one works but not the other and, of course, different things might happen with other products.
Regards,
Marlene
fyi for anyone else reading this thread - I’ve made a fix and Marlene will test it.
Hi Dallan
Well it’s been a while (again) but I’ve finally got to test this and, sad to say, it isn’t working as expected.
In the example file I sent you I suggested that the multimedia object format be:
1 OBJE
2 FORM image/jpeg
2 TITL Marriage Certificate - Joseph Pitman and Catherine Lang
2 FILE 370803443014220.jpg
2 _PRIM N
1 OBJE
2 FORM application/pdf
2 TITL Joseph Pitman death certificate
2 FILE 4804808481125282.pdf
2 _PRIM Y
but you have
1 @370803443014220@ OBJE
2 FORM image/jpeg
2 TITL Marriage Certificate - Joseph Pitman and Catherine Lang
2 FILE 370803443014220.jpg
2 _PRIM N
1 @4804808481125282@ OBJE
2 FORM application/pdf
2 TITL Joseph Pitman death certificate
2 FILE 4804808481125282.pdf
2 _PRIM Y
Firstly, acknowledging my limited knowledge of GEDCOM format, the latter doesn’t seem to have the correct syntax.
Secondly, if the same file is linked to two people the exact same line appears twice in the GEDCOM which seems fraught.
Is there a need in other programs to have prefixed or suffixed the OBJE line with an identifier? Certainly Reunion isn’t looking for this and isn’t handling it.
BTW this is now worse than the previous version. Previously Reunion knew the multimedia files existed, it just couldn’t repair the links to them, now it doesn’t even know they exist.
To my knowledge, adding an @ID@ before a level-1 tag is in conformance with GEDCOM syntax. This is how INDI and FAM objects work. I didn’t expect Reunion to have a problem with it.
If the same file is linked to two people, we need to have two separate entries using this approach. I don’t think it will cause problems, but since I don’t have Reunion myself, I can’t be sure.
If you remove the @ID@'s from the file, does everything work then?
Hi Dallan
Sorry I wasn’t as clear as I should have been in my previous reply. The format with the @ID@ resulted in the imported file having no recognition of there being any media, ie it was effectively ignored. However, when I removed the @…@ and just left the less detailed heading it worked as expected, including correctly identifying that one of the objects linked to two people.
That’s very strange. I’m on vacation right now, but I will make that change by the end of the month.
Thanks Dallan
I’ve just removed the IDs from media when they are level 1 (under a person). When you get some time, would you please try it again? Thank you
I held my breath, but pleased to say, YES it worked. Preferred photos are being picked up as expected, media linked to more than one person is being linked correctly. Just have to tell Reunion where to look for the photos and it corrects the default links and finds everything.
Just one thing though - which I mentioned somewhere earlier. Could the .ged file please be named meaningfully within the folder, not gedcom.ged. I can’t see any reason why it can’t have the same name that the gedcom file has when the media is not exported, ie the same name as the folder with .ged suffix.
I’m happy to hear that! Renaming the gedcom file should be an easy fix.
Just wondering if this one is still on your radar? Still coming through as gedcom.ged
Sorry, I’m running a bit behind. I should have it fixed this weekend.
Gedcom files in zip files should now have the tree name. (I actually fixed this earlier, but just realized that I hadn’t announced it.)