Wes
Not really possible for PGV to alter the MEDIA type without some input from a user. Did you examine the CHAN record for those that 'have mystically' modified? Then look at the regular log to confirm an IP on the date and time of the change. This will help. It is possible there is a typo in the code that selects audio as a type when you select something else, but I've not seen this.
No CERTIFICATES? Birth, death, burial? While technically these too are 'documents', thats a pretty general type, don't you think?
-stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-06-21
Wes, Stephen's right. I can't imagine any way PGV could be doing this. I'm constantly adding media items, and I've never seen this happen. Can you do some sleuthing on your data and logs and see if you can pinpoint anything?
I know you update to svn from time to time - perhaps it was a fleeting error on a single SVN version that you stopped on long enough to trigger when the rest of us moved on sooner? If so, dates and times might help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm, didn't occur to me to check the CHAN - and since I fixed each one I found, too late now!
I have no certificates scanned yet.
The temporary bug is a good possibility. Or another just occurred to me: Some of the images were on the website but not in the GEDCOM until I worked on them. Maybe the code automatically gives them the first TYPE in the list when it adds them to the GEDCOM ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I know what happened. I had a LOT of unlinked census images.
I arranged them in the directory the way I wanted, and then I wrote
a script to create fragments of the form:
0 @M117@ OBJE
1 FILE media/census/IL/1850-IL-Coles-Salisbury-(pg).jpg
2 FORM jpeg
2 TITL 1850-IL-Coles-Salisbury-(pg)
I inserted that fragment into my GEDCOM and re-imported. PGV apparently filled in the missing parts, either on export or on edit. So now, those 82 files look like:
0 @M117@ OBJE
1 FILE media/census/IL/1850-IL-Coles-Salisbury-(pg).jpg
2 FORM jpeg
3 TYPE audio
2 TITL 1850-IL-Coles-Salisbury-(pg)
1 _THUM N
1 _UID E3E6FB087B71B503484D9DDF868AD4B5
1 CHAN
2 DATE 14 JUN 2009
3 TIME 11:47:38
2 _PGVU Admin
To test that hypothesis, I could remove a few of those subrecords and re-import. But (here we go again!) should keep links be YES or NO? It took me a few tries each time to get it right, and I didn't write down what finally worked. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If that's what happens, I'd call it a bug. In 5.5.1, only FILE and FORM are required; the other parts are optional.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-06-22
Wes, I would agree IF that's what happens. But I've had a look at the code, and whilst I'm no expert I don't see anywhere that PGV adds a TYPE tag when one doesn't exist, not even with some sort of default value. Happy to be proved wrong of course - it wouldn't be the first time :-)
But TYPE doesn't even have its own table field, its just stored as part of the GEDCOM record in m_gedrec. The only place TYPE is added is when a new media item is added via PGV itself, and then it defaults to 'PHOTO', not audio.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If by "replace my GEDCOM" you mean to re-import your GEDCOM, then my understanding is that "Keep media links" should be set to NO. Therefore you statement is FALSE.
--
Stuart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
KEEP refers to the links made by another program. Links made by PGV will always be kept?
How does PGV know it created that FILE and not another program?
Anyway, back to the original question:
I used direct SQL to remove everything except TITL, FILE, FORM from one record. Then I went to media.php and did several things with that record. Each time, I retrieved the record via SQL, and there was no change.
When I selected Edit (not raw), the type menu defaulted to photo (but I didn't save)
Then, I selected "edit raw GEDCOM" and changed the TITL SQL showed me that PGV had added a UID and a CHAN and nothing else.
I finally took "edit" (not raw) and saved without change. Since the menu defaults to "photo," that's what I got.
My guess is that there was a time when the menu had no default selection specified and therefore the browser selected the first item: audio.
No, that couldn't be it, because there are 82 of them and I almost never edit except in raw GEDCOM.
Well, whatever it was, it's not happening now, so I guess I'll use batch update to change 'audio' to 'document'
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<<KEEP refers to the links made by another program. Links made by PGV will always be kept?>>
My simple reasoning on this is that the media links are stored in the database from the previous import. But these links and any new ones are also in the GEDCOM being re-imported. If you set the - Keep media links - to YES - then the existing links will be retained in the database and all of the links contained in the GEDCOM being re-imported, will be added to the links already in the database.
If you set the - Keep media links - to NO, then the existing links in the database will be deleted and replaced by the links in the GEDCOM being re-imported.
Keeping media links is how duplicate links are created and the number of these links will be incremented each time you re-import your GEDCOM.
--
Stuart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not only does that make sense, it might be a good candidate for the pop-up help on that option!
I was completely off on the wrong tree. I was thinking of the "link" from the media record to the actual file.
I'm still a bit confused, though.
If my GEDCOM contains
0 @M222@ OBJE
1 FILE media/big_picture.jpg
1 TITL Look at the big picture
and
0 @P123@ INDI
1 CENS
2 SOUR @S45@
3 PAGE blah blah
3 OBJE @M222@
then keep links = NO will remove the 3 OBJE @M222@ but retain the 0 @M222@ OBJE ?
If my upload is a replacement, then why would it keep ANYthing in the DB? And if I am adding to the oh, never mind, it's too late at night for that much brain work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wes
You are trying to make this much more difficult than it is. And perhaps confusing others.
Keep Links retains all the data in the SQL. It has nothing to do with your GEDCOM.
Why would your 3 OBJE be removed? It's in the text, appropriately subordinate to your CENS (although it will not show on the Personal Data page since it is level 3 - AFAIK, only level 2 OBJE's will appear inline.
Your data could, just as easily be written
0 @P123@ INDI
1 CENS
2 SOUR @S45@
3 PAGE blah blah
2 OBJE @M222@
In this case, the CENS fact will show the image in thumbnail and be displayed using mediaviewere or Lightbox, whichever you use.
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now I am hearing that keep links means keep the links in the DB, not the links in the GEDCOM.
I thought I had heard the opposite before. This desperately begs for someone who can not only understand it, but make it clear to the rest of us. I'm a good writer, but I can't help if _I_ can't understand it.
I'll probably end up doing like I did last time--back up everything, try it one way, restore, try it another, until it finally does what I want. And then, like last time (and the time before), I won't remember it because it just doesn't make sense either way.
I do understand the other, though. I put the OBJE link at level three on purpose--not only is it an image of the source, and therefore subordinate to it, but I don't want the thumbnails of census pages making the page a mile long. Putting it at three hides it until the visitor chooses to look at it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"I'm a good writer, but I can't help if _I_ can't understand it. "
Perhaps you could help me write a short Wiki article on this topic, and hopefully remove all confusion. It seems like the information is scattered, and it is almost clear but not quite:
- PhpGedView keeps media information in Media Objects (OBJ), and it keeps media in a directory structure of user's choice.
- Media Objects have references to media locations (media links) like this:
0 @M469@ OBJE
1 FILE media/I0340_Aunt_Matilda.jpg
[...]
- Other genealogy programs are known to mangle those 'links', and if such mangled GEDCOM is imported, PhPGedView would not know, where the files are.
To avoid this "keep media links" option exists in phpGedView.
1 If you select Keep media links = no, the following happens during GEDCOM import:
- the database is cleaned of all GECOM data and all data in the imported GEDCOM is added fresh to the database
2. If You select Keep media links = Yes, the following happens during GEDCOM import:
2.1
a) All OBJE records (Media objects) in imported file are ignored, and the existing database OBJ data are used. (???)
or
b) Imported OBJ records are used, replacing the old OBJE objects, but the records like
1 FILE media/I0340_Aunt_Matilda.jpg are retained. This means the import compares the object ID, and updates the record, skipping only the media link information (which it retains)
or
???
also:
2.2
If there are new OBJE records in the GEDCOM which were not in the database, those records are:
a) ignored
or
b) added 'as is', with possibly wrong media link.
also
2.3
during import, if there are in the database OBJ records that are not in the imported file those records are:
a) deleted
or
b) retained.
also
2.4
links to Media Objects that exist in many places in GEDCOM and look like 1 OBJE @M469@ etc are:
a) added, replaced or retained according to what happened with corresponding media objects in options above
or
b) Added always, possibly duplicating those that already existed in the database.
I am sure that the answers to dillemas above are somewhere, but they are not clear to me at this point. They may depend on the version, but let's focus on the latest (with a note that in the past it might not work axactly like this).
Can somebody in the know answer
2.1a, 2.1b (or something else, it is possible that there are other alternatives) is true
2.2.... etc.
Thanks - Marek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wes
It really is not that difficult. PGV puts creates OBJE for media items and stores these file references in the GEDCOM in the appropriate place. (remember, this format varies from other programs, but is similar to most). Additionally, PGV can store your images in a directory architecture of your choosing, allowing only one - or multiple depths. Again, the depth is recorded in the GEDCOM.
If the program you use outside of PGV handles media differently, the only manner by which you could retain the links would be for PGV to store them. However, if you export the GEDCOM from PGV (as it is now unlikely you use sync to GEDCOM, and its not perfect anyway), everything needed to reconstruct all the 'pointers' to the uploaded and stored media is within the GEDCOM.
If you exported and reimported using KEEP LINKS (in the DB), then PGV would create duplicated links and the GEDCOM would be very messy. If you create a new DB from the import, and click KEEP MEDIA = NO, then PGV will do what it is supposed to do, and recreate ONE instance of pointers to the media from the MEDIA tags and subordinate OBJE tags within each FAM, INDI, SOUR, etc record.
I'm not sure what is confusing about any of this, or why it needs to be explained, but there - now you've got it. You continue to confuse the DB with the GEDCOM. They are really two separate entities, although the DB is retaining the latest copy of your GEDCOM as it is the only thing being 'refreshed' when changes are made by users.
-Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It may not be confusing to someone who is so intimately involved in the development of PGV as you. But I can assure you that I agree with Wes, that it is confusing. I was confused when I first upgraded to 4.2.1 to find I had duplicate links. There have been many other users experiencing the same confusion. I now understand the underlying concept that is essential in understanding what Keep Media Links means.
On re-reading the context help on this, it seems to have been re-written since the first time I looked. If I get some time I will have a go at re-writing it and see if it meets with the consent of the developers.
--
Stuart
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I could probably argue both sides. Now that I am starting to grok what it does, it's not so confusing.
The problem for me was two-fold:
(1) "Keep media links" does not mean what it _appears_ to mean. There are a lot of things that could be called links, and this is not referring to the ones I thought it was referring to.
(2) What I _thought_ it was saying was illogical and the "Spock" side of me just could not assimilate that. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have no audio files.
I only have photos and documents (well, maybe a few tombstones)
But I keep finding media items that say
3 TYPE audio
Now, that's not exactly a typo, so how does that get changed?
Wes
Not really possible for PGV to alter the MEDIA type without some input from a user. Did you examine the CHAN record for those that 'have mystically' modified? Then look at the regular log to confirm an IP on the date and time of the change. This will help. It is possible there is a typo in the code that selects audio as a type when you select something else, but I've not seen this.
No CERTIFICATES? Birth, death, burial? While technically these too are 'documents', thats a pretty general type, don't you think?
-stephen
Wes, Stephen's right. I can't imagine any way PGV could be doing this. I'm constantly adding media items, and I've never seen this happen. Can you do some sleuthing on your data and logs and see if you can pinpoint anything?
I know you update to svn from time to time - perhaps it was a fleeting error on a single SVN version that you stopped on long enough to trigger when the rest of us moved on sooner? If so, dates and times might help.
Hmmm, didn't occur to me to check the CHAN - and since I fixed each one I found, too late now!
I have no certificates scanned yet.
The temporary bug is a good possibility. Or another just occurred to me: Some of the images were on the website but not in the GEDCOM until I worked on them. Maybe the code automatically gives them the first TYPE in the list when it adds them to the GEDCOM ?
The change records are consistently "admin"
I think I know what happened. I had a LOT of unlinked census images.
I arranged them in the directory the way I wanted, and then I wrote
a script to create fragments of the form:
0 @M117@ OBJE
1 FILE media/census/IL/1850-IL-Coles-Salisbury-(pg).jpg
2 FORM jpeg
2 TITL 1850-IL-Coles-Salisbury-(pg)
I inserted that fragment into my GEDCOM and re-imported. PGV apparently filled in the missing parts, either on export or on edit. So now, those 82 files look like:
0 @M117@ OBJE
1 FILE media/census/IL/1850-IL-Coles-Salisbury-(pg).jpg
2 FORM jpeg
3 TYPE audio
2 TITL 1850-IL-Coles-Salisbury-(pg)
1 _THUM N
1 _UID E3E6FB087B71B503484D9DDF868AD4B5
1 CHAN
2 DATE 14 JUN 2009
3 TIME 11:47:38
2 _PGVU Admin
To test that hypothesis, I could remove a few of those subrecords and re-import. But (here we go again!) should keep links be YES or NO? It took me a few tries each time to get it right, and I didn't write down what finally worked. :-)
If that's what happens, I'd call it a bug. In 5.5.1, only FILE and FORM are required; the other parts are optional.
Wes, I would agree IF that's what happens. But I've had a look at the code, and whilst I'm no expert I don't see anywhere that PGV adds a TYPE tag when one doesn't exist, not even with some sort of default value. Happy to be proved wrong of course - it wouldn't be the first time :-)
But TYPE doesn't even have its own table field, its just stored as part of the GEDCOM record in m_gedrec. The only place TYPE is added is when a new media item is added via PGV itself, and then it defaults to 'PHOTO', not audio.
For the record, true or false:
If the item is already on the site at media/census/IL/filename.jpg
And the GEDCOM says 1 FILE media/census/IL/filename.jpg
Then when I replace my GEDCOM, I want keep media links to be YES.
True or False?
(I _really_ don't want to re-create 400+ subrecords)
Wes,
If by "replace my GEDCOM" you mean to re-import your GEDCOM, then my understanding is that "Keep media links" should be set to NO. Therefore you statement is FALSE.
--
Stuart
Wes
It has little or nothing to do with just the 1 FILE, but do the
0 @Mxxxx@ OBJE
1 FILE media/xxxxxxxxxxx.xxx
tags exist in the downloaded GEDCOM?
If so, then NO, do NOT set the KEEP to YES.
-Stephen
Wow, that sure is confusing.
OK, it's coming back to me....
KEEP refers to the links made by another program. Links made by PGV will always be kept?
How does PGV know it created that FILE and not another program?
Anyway, back to the original question:
I used direct SQL to remove everything except TITL, FILE, FORM from one record. Then I went to media.php and did several things with that record. Each time, I retrieved the record via SQL, and there was no change.
When I selected Edit (not raw), the type menu defaulted to photo (but I didn't save)
Then, I selected "edit raw GEDCOM" and changed the TITL SQL showed me that PGV had added a UID and a CHAN and nothing else.
I finally took "edit" (not raw) and saved without change. Since the menu defaults to "photo," that's what I got.
My guess is that there was a time when the menu had no default selection specified and therefore the browser selected the first item: audio.
No, that couldn't be it, because there are 82 of them and I almost never edit except in raw GEDCOM.
Well, whatever it was, it's not happening now, so I guess I'll use batch update to change 'audio' to 'document'
Wes,
<<KEEP refers to the links made by another program. Links made by PGV will always be kept?>>
My simple reasoning on this is that the media links are stored in the database from the previous import. But these links and any new ones are also in the GEDCOM being re-imported. If you set the - Keep media links - to YES - then the existing links will be retained in the database and all of the links contained in the GEDCOM being re-imported, will be added to the links already in the database.
If you set the - Keep media links - to NO, then the existing links in the database will be deleted and replaced by the links in the GEDCOM being re-imported.
Keeping media links is how duplicate links are created and the number of these links will be incremented each time you re-import your GEDCOM.
--
Stuart
Not only does that make sense, it might be a good candidate for the pop-up help on that option!
I was completely off on the wrong tree. I was thinking of the "link" from the media record to the actual file.
I'm still a bit confused, though.
If my GEDCOM contains
0 @M222@ OBJE
1 FILE media/big_picture.jpg
1 TITL Look at the big picture
and
0 @P123@ INDI
1 CENS
2 SOUR @S45@
3 PAGE blah blah
3 OBJE @M222@
then keep links = NO will remove the 3 OBJE @M222@ but retain the 0 @M222@ OBJE ?
If my upload is a replacement, then why would it keep ANYthing in the DB? And if I am adding to the oh, never mind, it's too late at night for that much brain work.
Wes
You are trying to make this much more difficult than it is. And perhaps confusing others.
Keep Links retains all the data in the SQL. It has nothing to do with your GEDCOM.
Why would your 3 OBJE be removed? It's in the text, appropriately subordinate to your CENS (although it will not show on the Personal Data page since it is level 3 - AFAIK, only level 2 OBJE's will appear inline.
Your data could, just as easily be written
0 @P123@ INDI
1 CENS
2 SOUR @S45@
3 PAGE blah blah
2 OBJE @M222@
In this case, the CENS fact will show the image in thumbnail and be displayed using mediaviewere or Lightbox, whichever you use.
Stephen
Others? Confusing me!
Now I am hearing that keep links means keep the links in the DB, not the links in the GEDCOM.
I thought I had heard the opposite before. This desperately begs for someone who can not only understand it, but make it clear to the rest of us. I'm a good writer, but I can't help if _I_ can't understand it.
I'll probably end up doing like I did last time--back up everything, try it one way, restore, try it another, until it finally does what I want. And then, like last time (and the time before), I won't remember it because it just doesn't make sense either way.
I do understand the other, though. I put the OBJE link at level three on purpose--not only is it an image of the source, and therefore subordinate to it, but I don't want the thumbnails of census pages making the page a mile long. Putting it at three hides it until the visitor chooses to look at it.
Wes,
"I'm a good writer, but I can't help if _I_ can't understand it. "
Perhaps you could help me write a short Wiki article on this topic, and hopefully remove all confusion. It seems like the information is scattered, and it is almost clear but not quite:
- PhpGedView keeps media information in Media Objects (OBJ), and it keeps media in a directory structure of user's choice.
- Media Objects have references to media locations (media links) like this:
0 @M469@ OBJE
1 FILE media/I0340_Aunt_Matilda.jpg
[...]
- Other genealogy programs are known to mangle those 'links', and if such mangled GEDCOM is imported, PhPGedView would not know, where the files are.
To avoid this "keep media links" option exists in phpGedView.
1 If you select Keep media links = no, the following happens during GEDCOM import:
- the database is cleaned of all GECOM data and all data in the imported GEDCOM is added fresh to the database
2. If You select Keep media links = Yes, the following happens during GEDCOM import:
2.1
a) All OBJE records (Media objects) in imported file are ignored, and the existing database OBJ data are used. (???)
or
b) Imported OBJ records are used, replacing the old OBJE objects, but the records like
1 FILE media/I0340_Aunt_Matilda.jpg are retained. This means the import compares the object ID, and updates the record, skipping only the media link information (which it retains)
or
???
also:
2.2
If there are new OBJE records in the GEDCOM which were not in the database, those records are:
a) ignored
or
b) added 'as is', with possibly wrong media link.
also
2.3
during import, if there are in the database OBJ records that are not in the imported file those records are:
a) deleted
or
b) retained.
also
2.4
links to Media Objects that exist in many places in GEDCOM and look like 1 OBJE @M469@ etc are:
a) added, replaced or retained according to what happened with corresponding media objects in options above
or
b) Added always, possibly duplicating those that already existed in the database.
I am sure that the answers to dillemas above are somewhere, but they are not clear to me at this point. They may depend on the version, but let's focus on the latest (with a note that in the past it might not work axactly like this).
Can somebody in the know answer
2.1a, 2.1b (or something else, it is possible that there are other alternatives) is true
2.2.... etc.
Thanks - Marek
Once I feel I do understand exactly what's happening, I will be glad to document it. Your contribution will hasten that day.... :-)
Wes
It really is not that difficult. PGV puts creates OBJE for media items and stores these file references in the GEDCOM in the appropriate place. (remember, this format varies from other programs, but is similar to most). Additionally, PGV can store your images in a directory architecture of your choosing, allowing only one - or multiple depths. Again, the depth is recorded in the GEDCOM.
If the program you use outside of PGV handles media differently, the only manner by which you could retain the links would be for PGV to store them. However, if you export the GEDCOM from PGV (as it is now unlikely you use sync to GEDCOM, and its not perfect anyway), everything needed to reconstruct all the 'pointers' to the uploaded and stored media is within the GEDCOM.
If you exported and reimported using KEEP LINKS (in the DB), then PGV would create duplicated links and the GEDCOM would be very messy. If you create a new DB from the import, and click KEEP MEDIA = NO, then PGV will do what it is supposed to do, and recreate ONE instance of pointers to the media from the MEDIA tags and subordinate OBJE tags within each FAM, INDI, SOUR, etc record.
I'm not sure what is confusing about any of this, or why it needs to be explained, but there - now you've got it. You continue to confuse the DB with the GEDCOM. They are really two separate entities, although the DB is retaining the latest copy of your GEDCOM as it is the only thing being 'refreshed' when changes are made by users.
-Stephen
Stephen,
It may not be confusing to someone who is so intimately involved in the development of PGV as you. But I can assure you that I agree with Wes, that it is confusing. I was confused when I first upgraded to 4.2.1 to find I had duplicate links. There have been many other users experiencing the same confusion. I now understand the underlying concept that is essential in understanding what Keep Media Links means.
On re-reading the context help on this, it seems to have been re-written since the first time I looked. If I get some time I will have a go at re-writing it and see if it meets with the consent of the developers.
--
Stuart
I could probably argue both sides. Now that I am starting to grok what it does, it's not so confusing.
The problem for me was two-fold:
(1) "Keep media links" does not mean what it _appears_ to mean. There are a lot of things that could be called links, and this is not referring to the ones I thought it was referring to.
(2) What I _thought_ it was saying was illogical and the "Spock" side of me just could not assimilate that. :-)
No, I'm not confusing the DB with the GEDCOM. I think I am starting to see that the confusion is "What exactly does 'LINK' mean in this context?"
Your explanation above clears that up. There is another point I still question, but I don't have time right now to ask it clearly.