Need to build a path field for my media objects

I have exported a GEDCOM from Ancestry and successfully imported into a new tree in Gramps (Linux v5.1.4). Separately I used the RootsMagic7 TreeShare for Ancestry to download all my media from Ancestry to my computer (~1800 media objects). Now, in my Gramps database I have all my media objects with Title: string that matches the filename, Type: image/jpeg, and Path: . (yes that is just a dot)! I have set up my base path for relative media paths.

What I need to do is update the Path field in the media object (that is a dot now) to be Title.jpg where Title is the string that is already there.

I have looked at the Media verify as well as Media Manager but I am not sure if either of those tools will allow me to generate this path from the other fields in the media object. In Media Manager I would like to replace . with Title.jpg where Title comes from the media object.

For what it is worth: This is what is coming over in the GEDCOM that Gramps uses to build the media object:
0 @M333@ OBJE
1 FILE
2 FORM jpg
3 TYPE photo
3 _STYPE jpeg
3 _SIZE 574601
3 _WDTH 3385
3 _HGHT 2505
2 TITL 1809 Giuseppe Eramo death Antenati Bari Gioia #201
1 RIN 63f2c27d-798a-43eb-83de-03e4fe511164
1 _ORIG u

I would like my path field to be:
1809 Giuseppe Eramo death Antenati Bari Gioia #201,jpg

I hope that makes sense. Any ideas? Thanks

It would probably be easier to export another Gedcom from Rootsmagic. That way the paths would already be set up correctly. The other data should not have lost much if any information.

Otherwise it will take some programming, I think.

You could try this using Isotammi SuperTool:

[Gramps SuperTool script file]
version=1

[title]
SuperTool-Media

[category]
Media

[initial_statements]

[statements]
media.set_path(desc + ".jpg")

[filter]

[expressions]

[scope]
selected

[unwind_lists]
False

[commit_changes]
True

[summary_only]
False

I have been using the plug-in “Media Verify” to good effect when I move or rename folders in my media pile. I feel like it will create a map of the media in your tree and connect what it can. It tells me when there is media missing or when there is extra non-referenced media, so it might be what you need. Don’t think you have to tell it to connect this to that, just tell it the things referenced by Gramps can be found in this tree and see what you get. Generate, Verify and Fix is what I normally do.

Thanks @prculley I was able to get a GEDCOM from RootsMagic to link up with my media after running the media manager to strip off the absolute path. I was reminded though why I didn’t want to use the RootsMagic GEDCOM. The TreeShare doesn’t support the weblinks coming from Ancestry. I used Weblinks in Ancestry to link to many of the the Italian records that Ancestry didn’t have.

Looks like I might give the Isotammi SuperTool a try next.

@CareyP I think that Media Verify isn’t working for me because they were never linked up in the first place. All my media just shows up as “Extra Files” which need to be dealt with individually.

Thanks @PLegoux I’ll give this a try tomorrow when I have some time. I haven’t used Isotammi SuperTool before so will need to read up on that first.

1 Like

When I move a folder I don’t tell it where it went, it finds the file again. No path information provided other than the root. The file names are correct in the media objects?

Media Verify uses the checksum that was set when you added the media record to Gramps the first time to find the file again if you move or rename it. On an import, no checksums are set.

In the verify, there is the Generate button that will set the media’s checksum. But Gramps first has to be able to find the file. A Catch 22.

The generate is great if you edit a media file after adding it to Gramps. The generate will reset the checksum for these edited files.

Thanks Dave, that explains it.

If file names were unique, could they be used to ID files, checksums for ambiguous cases, if any? What am I missing?

@PLegoux Here I thought this was going to be a big learning curve and when I sat down to try it you had done all the work for me! This did exactly what I needed it to. I quickly discovered that the filenames were truncated at 59 characters so a quick web search found me the syntax to substring the desc field.

Thanks so much for giving me the opportunity to try something new. I look forward to more challenges down the line I can try the SuperTool out on.
Cindy

1 Like

If all of your media files names were unique so that all files could be stored in the same folder, then the relative base path could be set to that folder so Gramps could "find’ them and set the checksums. Then if the files were moved or renamed, Media Verify would be able to find them again and update the record’s path information.

Hi Dave,

It sounds like Cindy has solved her problem, but now an abundance of curiosity makes me wonder what prevents walking the tree under the root to find the files with unique names and to throw an error for the ones that don’t. I’m asking just to check my thinking and/or learn something were I to write something like this in the future. I’m the guy who would spend a week coding to avoid four hours of “manual labor.” Back in the day I knew I had to write something when I saw someone performing their job duties and said, not usually out loud, “That’s a stupid job for a human!”

:wink:

Carey

I am not a coder so do not know all the pitfalls that would need to be considered, let alone how to code for them. I can hep explain what is currently available.

To give another observation in the use of the Media Verify, as I said, it works off of the checksum. If you edit a file after it has been added to Gramps, there becomes a mismatch in the sums. The name of the file and its location did not change. Media verify will report the file as missing (cannot find) and report that the edited file is in the folder as an extra file. Currently there is no “fix” for this scenario in media verify other than a manual reselect of the file.

Maybe solving this will help solve the bigger issue of syncing media after a gedcom import.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.