I just upgraded my website to 4.2.3, including the switch to PHP 5 and killing my old MySQL database (4.0) and creating a new one (5.1).
When I import my longer GEDCOMs I keep getting the error listed at the bottom. It is not always at the same point . . . sometimes I can actually make it through the import. I am using a "refresh" number of seconds less than (58) the alleged timeout value in PHP (60). I do see this error popping up on Google with PhpGedView websites from time to time . . . any clues? I am guess something is quitting too early . . . the Apache status doesn't seem to be indicating a problem that it can see . . .
HTTP/1.1 200 OK Date: Mon, 03 Jan 2011 22:25:48 GMT Server: Apache Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Keep-Alive: timeout=15, max=91 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1
OK
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.33 Server at www.corduan.com Port 80
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did use a much smaller increment (27), same result.
This is a message that PhpGedView is reporting back . . . it is in the status stream, along with errors encountered when the GEDCOM is being imported (I had some duplicate IDs and other junk) . . . I am on IE 7.0.
Try typing
200 OK "internal error or misconfiguration" PhpGedView
as the search string in Google . . . you will see that Google encounters this from time to time on PhpGedView websites . . . so . . . that can't be a browser issue.
Thanks,
-Alfred
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I strongly disagree that PhpGedView is causing the error. PGV simply sends HTML to the browser and waits for a browser response before continuing. If there are problems with the HTML created by PGV, you see incomplete or "garbage" pages. You might see a meaningful error message from your browser if it's been configured that way.
The browser is seeing a message from your Apache server and is not acting on it correctly. The message is NOT being generated by PGV, and PGV is unaware that you are seeing this message.
Try a different browser, such as Firefox, Opera, Safari, or Chrome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where is your server being hosted?
If you use Google and search parts of your error …
+"19 Nov 1981" +"The server encountered an internal error or misconfiguration"
you'll see that several sites have this problem running all kinds of software …
It appears to be a server configuration issue, and as Gerry says is not a phpGedView issue.
Are your sessions being initiated OK and is your browser set up to allow cookies?
What exact versions of Apache, MySQL and php are running on your server?
Is your server on GoDaddy by any chance?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had PhpGedView running for many years and, yes, on GoDaddy . . . Browser the same (yes, cookies are full on). I did upgrade to PHP 5 and upgraded the MySQL database to 5. This message is coming up at the end of the PhpGedView generated status messages . . . the list that shows up as, blow by blow, it encounters various issues during import . Someone was not expecting this server message and is presenting it as an error . . .
For the record, the medium sized database which showed this problem at different points just uploaded succesfully . . . depends on how I hold my mouth? :-) The big boy .ged - which I did get in successfully a few days ago - just failed on the import. The fact that it happens at different points or not at all would seem to point either to a timing issue or a memory issue. One would thing the memory issue would get worse and worse . . . so I am guessing a timeout of some kind.
For those with PHP 5 . . . should I be setting up a php5.ini file . . . and if so, what are the things to address?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Again .. have a look around on Google … perhaps with a search query like …
+"HTTP/1.1 200 OK" +"The server encountered an internal error or misconfiguration" +"GoDaddy"
Most of the search results for whichever software application points you towards checking the .htaccess and/or php.ini / php5.ini files. Are you running in fastcgi mode or not?
http://help.godaddy.com/article/1085
IMPORTANT: If you are running PHP 4, name your initialization file php.ini. If you are running PHP 5, name your initialization file php5.ini. Always upload the initialization file to the root directory of your site.
http://help.godaddy.com/article/1232
Using Zend Optimizer
To enable Zend Optimizer on your hosting account, you must either modify or create a php.ini file if your hosting account runs PHP 4, or your php5.ini file if your hosting account runs PHP 5.
http://help.godaddy.com/article/1113
Using Server Variable ($_SERVER) Elements with PHP 5
Our Linux hosting accounts run in CGI mode. When PHP 5 runs in this mode, the server variable element PATH_INFO behaves differently than under PHP 4. PHP 5 scripts can use the element SCRIPT_NAME in place of PATH_INFO to ensure the expected value is returned.
Not sure if this image attachment thing works . . . but . . . I am attempting to attach a screen shot at the bottom of the error in context . . . please note again that there are a series of messages generated from within PhpGedView . . . then, SOMEONE catches an "OK" message and takes the trouble to BOLD in a huge font the "OK" . . . that has to be PhpGedView code, right? It might help to know what what the import script was expecting to see when that errant server message came rambling in . . .
I have scanned the GoDaddy site . . . I will keep looking. I currently do not have a php5.ini file . . . not sure what to put in it.
This is my .htaccess file, something that came in with FrontPage years ago . . . . which I haven't used in years
<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName www.corduan.com
AuthUserFile /var/chroot/home/content/A/C/o/ACorduan/html/_vti_pvt/service.pwd
AuthGroupFile /var/chroot/home/content/A/C/o/ACorduan/html/_vti_pvt/service.grp
=====================================
Thanks so much for all your effort . . . I deeply appreciate it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: I got my big .ged in . . . now that the site is roughly "up" I am seeing this same error pop up (w/o the bolding) in other places . . . in the middle of pages . . . not often . . . hit "refresh" and it will likley not be there. So . . . that does point to some consistent timing issue . . . I will keep poking . . . if anyone has any ideas, I will be most grateful. I will exersize GoDaddy . . . once I have all the ammunition in hand that I can acquire.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello:
If you wish, you can e-mail me a ZIP copy of the GEDCOM file you're trying to import. I can look at this on my off-line server to see if I can figure out the source of your "invalid GEDCOM" error messages.
The server error is NOT being generated or presented for your viewing pleasure by PhpGedView. The browser is displaying this message in response to something it received from the server.
Note: It's highly likely that the version of PHP 5 you upgraded to is buggy. What IS the PHP version?
e-mail: gkroll at keldine dot ca
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks so much . . . gedcom is attached (separate email). I did not see the request for .zip until after I sent it . . . "big" to me is 1.4MB . . . I know they get lots bigger.
I suffered a major hit of some kind, just for the record . . . I was starting to get errors when committing changes to the order of "Unable to locate xref #", evidently unable to match a viewed record with a database entry . . . something like that. I backed up, reimported the gedcom before upgrading . . . it had lost entire legs, families . . . pieces here and there . . . gone for ever :-( . . . I am currently getting a series of "unable to find family #" errors due to this . . . . *sigh*. I believe the "Synch database to gedcom" option was on . . . in 4.1.7? In any case, I never would have turned it off . . . I went looking for it in 4.1.7 and at the time could not find it. I am sure it was on . . . because even updates I made shortly before the upgrade made it in . . .
I was holding off on upgrading because, well, the PHP upgrade with unknown effects . . . and the MySQL upgrade . . . my hand was forced by these errors which I lived with for months, finally exceding the ability to ignore. Frustrating . . . what is a mother to do. I intend to set up some kind of synch between my PhpGedView database and a PC based version so at least I can see trouble faster . . . and have a live local backup.
As to PHP version, it is 5.2.14 . . . here is a script that dumps the environment, along with a picture I was playing with:
Alfred
A 'good sized' GEDCOM on PGV may well require more than 64mb of memory and may require, especially for lists and relationships, more than 30 secs of execution time, somewhat depending on the processor speed, but more so on good principle.
In today's environment, especially if you are running multiple GEDCOMs, I would look at a minimum of 128mb of memory. RAM is cheap now!
You also have not advised the environment in which you operate. What about bandwidth? Usually, GODADDY has pretty solid UP speeds, but do you have good UP/Down at the client? -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I received the requested GEDCOM and was able to import it into my off-line copy of PGV with no trouble other than those pesky "Invalid GEDCOM format" errors.
While looking at the GEDCOM, I noticed that it was full of LRM characters. They shouldn't cause problems, but I removed them just to make the GEDCOM more readable with my favourite text editor. Older versions of PGV recorded LRM and RLM characters in the database when an on-line edit was done. Current versions remove any LRM and RLM characters they see so that text in the database is clean, and only add these codes when they are needed while displaying on RTL pages.
I added some debugging code to the two places in "includes/functions/functions_import.php" where the error messages are produced. It turned out that PGV was complaining about a GEDCOM format error while processing some "0 @Mnnn@ OBJE" records. It was seeing empty lines - but not for all such OBJE records.
I can't see what's wrong with the OBJE records that generated the errors, but when they were removed the Import no longer complained. I suggested to Alfred that he should just ignore the error messages and then to see whether the "bad" OBJE records are actually missing from the database. I sent him a text file containing just those "bad" records so that he knows which ones are causing problems.
I'm waiting for more information on where the update is failing. I agree with Stephen that more memory would help, particuarly if the "Synchronize GEDCOM" option is on. Alfred can't lose anything by turning this option off, just to see whether the previously failing updates are actually correctly recorded in the database.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On memory . . . I am not sure I understand. I doubt you are talking about PC RAM (I have 4GB) . . . but I am confused about the "Memory is cheap" comment . . .
I have GoDaddy . . . in the hosting spec they say bandwidth is "unlimited" . . . which I presume says they won't charge me for volume but says nothing about throughput ("latency"?)
I have Comcast for my ISP with several ticks above "worst" speeds. We do have 8 computers on the network (we have 11 kids, no kidding) but response times have been fine. I also operate with a VPN link on this system to work (work from home) . . . but, again, response times have not been an issue. I went ahead and just did a "speedtest.net" check . . . with VPN on (encrypted link from Chicago to LA, then bouncing out their proxy to the open Internet) I got about 3MB/sec both up and down . . . which they think is slow. When I took VPN off I got 4MB up and 24MB down, which they think is excellent. However I got the "OK" error again bringing the "big boy" back in twice before it succeeded the 3rd time. Maybe it would have taken 10 times with VPN on, so I presume it is better.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting that at least one of the images showing the problem is in the database twice . . . the one showing the error has a bunch of garbage in the title string and note . . . are THOSE the LRM characters?
0 @M18@ OBJE
1 FILE media/Cordua_Heloise_Rhenardus_Letter_1.jpg
2 FORM jpeg
3 TYPE manuscript
2 TITL Heloise Rhenardus Letter ‎‎‎‎‎‎(1949)‎‎‎‎‎‎ - page 1
1 _PRIM N
1 _THUM N
1 NOTE Paramaribo 14th May, 1949
2 CONT Heloise Rhenardus
2 CONT Saramacca Straat
2 CONT 65o ‎‎‎‎‎‎‎‎ / the river
2 CONT
2 CONT My dear Emmy,
2 CONT
2 CONT I hope this will find you, husband and children in good health. Your letter I have received quite save and of course your picture, and very glad to hear from you . . . How do you do?
2 CONT
2 CONT I sincerely hope that sad time is past and now you're happy again. In Dutch we say, "Every time has its struggle ‎‎‎‎(trouble)‎‎‎‎". To us you look very sweet. I note that you're married twice and I not even once ‎‎‎‎
2 CONC (ha ha)‎‎‎‎. A very good action of you to take care of your first husband, until he is gone. God will bless you. That could never happen here in Suriname. Does it happen often in America? The next husband should never agree with the id
2 CONC ea, if it was a Surinamer, any rate you have done good work and you will not remain unpaid by God.
2 CONT
2 CONT So you were married in 1912. Just the year I was borned. My birthday is 27th July and let me kindly know yours and family. Gladly I should like to know Edith, Ed's‎ and the others birthdays. Please ask Edith to let me know.
2 CONT
2 CONT Well, Emmy, I went to spend a day with my two old aunts, Cornelia Cordua 86
1 CHAN
2 DATE 08 FEB 2008
3 TIME 09:48:24
2 _PGVU ACorduan
The one that came in right has none of that:
0 @M39@ OBJE
1 FILE media/Cordua_Heloise_Rhenardus_Letter_1.jpg
2 FORM jpeg
3 TYPE manuscript
2 TITL Heloise Rhenardus Letter (1949) - page 1
1 CHAN
2 DATE 17 NOV 2006
3 TIME 01:51:38
2 _PGVU ACorduan
The "Invalid Format" images did not import . . . the other did
So . . . I will try to clean those up and try again when I have a chance . . . or just splice yours in if you have already done the work (my time is gone for the moment)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I couldn't help myself . . . I stripped that weird sequence of 3 characters out of the .ged, removed the duplicate references to the same .jpgs and reuploaded . . . for the record it came in without the "OK" error the first time, with VPN on . . . and the 4 "Heloise" images came in without an error. I still have 3 other "invalid Gedcom format" errors that you may have addressed in your other comments . . .will get to that (REALLY have to get back to work).
Thanks for your help . . . deeply appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
acorduan
I'm confused about your confusion. Your PHPINFO definitely shows your server restricted to 64mb Master and 64mb local (this in NOT your machine, but what is assigned to PGV via the config.php). Your local can not exceed your master, so GoDaddy has allocated only 64mb to your installation. If you are running other programs, and you are on a shared server, access to your processor may be restricted and the ram is certainly low.
AFA bandwidth, it sounds adequate, but you don't know your server's Up speed, nor do you know the load on the server from perhaps a shared environment. Do you share, or are you dedicated? All these factors have a major effect on your overall performance.
Finally, yes - corrupted data can be have a very detrimental impact on your ability to import and manage your GEDCOM. If it is not too many records, you may be able to clean it up manually, but I would prefer you return to another copy (backup) that lacks any indication of corruption as identifying all instances can be near impossible. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the clarification. I just increased it to 96MB with php5.ini . . . is that good . . . or should I shoot for higher? For the record the "OK" message/Error happened again twice on import after the change (Memory upper verified by phpinfo())
Also - as this feeling of unbridled power sweeps over me - does it make sense to increase the length of time scripts may process? I see these two variables:
max_execution_time = 30 ; Maximum execution time of each script, in seconds (30)
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data (60)
I have gone through to clean up the errors I can see. Interesting that all of the "Invalid Gedcom format" errors came on Media references that were both duplicates (more than one OBJE pointing to the same file) and had those "LRM" characters in them. Removing the characters did not fix it . . . doing that and removing the duplicates did.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I do. Many of my lists and a media management search take up to 90 seconds due to the size of our data and the management techniques used by the program. But then, i also give PGV 1gb of memory. Perhaps overkill, but the old adage of you can never have too much RAM still resonates in my mind. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that garbage you see in your GEDCOM are LRM codes. These codes specify directionality of the character that follows when it's displayed on RTL pages such as Hebrew and Arabic. This a requirement because of the dumb way the HTML standard has defined the processing of text when it's to be displayed on pages that read from right to left (RTL).
The LRM codes got in there because you edited the text using PGV. It added the LRM codes to the text for display purposes, you then saved a change (not necessarily to the text), and PGV stored the result in the database. PGV should have removed the LRM codes before storing the result. The more times you saved the result, the more LRM codes were added. If you see three of them in a row, you saved the change three times.
It's interesting that you have found duplicate file references for some media objects. As far as I know, this is perfectly legitimate and shouldn't cause any errors. I'll have to put a test case together for this condition to identify where the Import is actually going wrong. This won't happen any time soon - I have too much else to do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just upgraded my website to 4.2.3, including the switch to PHP 5 and killing my old MySQL database (4.0) and creating a new one (5.1).
When I import my longer GEDCOMs I keep getting the error listed at the bottom. It is not always at the same point . . . sometimes I can actually make it through the import. I am using a "refresh" number of seconds less than (58) the alleged timeout value in PHP (60). I do see this error popping up on Google with PhpGedView websites from time to time . . . any clues? I am guess something is quitting too early . . . the Apache status doesn't seem to be indicating a problem that it can see . . .
HTTP/1.1 200 OK Date: Mon, 03 Jan 2011 22:25:48 GMT Server: Apache Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Keep-Alive: timeout=15, max=91 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1
OK
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.33 Server at www.corduan.com Port 80
This "error" isn't actually an error: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
It appears to be a browser issue. What browser are you using, and can you try a different one?
If your PHP timeout is set to 60, you should try a shorter time-out for the Import. 55 seconds might be better.
I did use a much smaller increment (27), same result.
This is a message that PhpGedView is reporting back . . . it is in the status stream, along with errors encountered when the GEDCOM is being imported (I had some duplicate IDs and other junk) . . . I am on IE 7.0.
Try typing
200 OK "internal error or misconfiguration" PhpGedView
as the search string in Google . . . you will see that Google encounters this from time to time on PhpGedView websites . . . so . . . that can't be a browser issue.
Thanks,
-Alfred
I strongly disagree that PhpGedView is causing the error. PGV simply sends HTML to the browser and waits for a browser response before continuing. If there are problems with the HTML created by PGV, you see incomplete or "garbage" pages. You might see a meaningful error message from your browser if it's been configured that way.
The browser is seeing a message from your Apache server and is not acting on it correctly. The message is NOT being generated by PGV, and PGV is unaware that you are seeing this message.
Try a different browser, such as Firefox, Opera, Safari, or Chrome.
Where is your server being hosted?
If you use Google and search parts of your error …
+"19 Nov 1981" +"The server encountered an internal error or misconfiguration"
you'll see that several sites have this problem running all kinds of software …
It appears to be a server configuration issue, and as Gerry says is not a phpGedView issue.
Are your sessions being initiated OK and is your browser set up to allow cookies?
What exact versions of Apache, MySQL and php are running on your server?
Is your server on GoDaddy by any chance?
I have had PhpGedView running for many years and, yes, on GoDaddy . . . Browser the same (yes, cookies are full on). I did upgrade to PHP 5 and upgraded the MySQL database to 5. This message is coming up at the end of the PhpGedView generated status messages . . . the list that shows up as, blow by blow, it encounters various issues during import . Someone was not expecting this server message and is presenting it as an error . . .
For the record, the medium sized database which showed this problem at different points just uploaded succesfully . . . depends on how I hold my mouth? :-) The big boy .ged - which I did get in successfully a few days ago - just failed on the import. The fact that it happens at different points or not at all would seem to point either to a timing issue or a memory issue. One would thing the memory issue would get worse and worse . . . so I am guessing a timeout of some kind.
For those with PHP 5 . . . should I be setting up a php5.ini file . . . and if so, what are the things to address?
Again .. have a look around on Google … perhaps with a search query like …
+"HTTP/1.1 200 OK" +"The server encountered an internal error or misconfiguration" +"GoDaddy"
Most of the search results for whichever software application points you towards checking the .htaccess and/or php.ini / php5.ini files. Are you running in fastcgi mode or not?
http://help.godaddy.com/article/1655
What do I do when I receive an Internal Server Error?
http://help.godaddy.com/article/1085
IMPORTANT: If you are running PHP 4, name your initialization file php.ini. If you are running PHP 5, name your initialization file php5.ini. Always upload the initialization file to the root directory of your site.
http://help.godaddy.com/article/1232
Using Zend Optimizer
To enable Zend Optimizer on your hosting account, you must either modify or create a php.ini file if your hosting account runs PHP 4, or your php5.ini file if your hosting account runs PHP 5.
http://help.godaddy.com/article/1113
Using Server Variable ($_SERVER) Elements with PHP 5
Our Linux hosting accounts run in CGI mode. When PHP 5 runs in this mode, the server variable element PATH_INFO behaves differently than under PHP 4. PHP 5 scripts can use the element SCRIPT_NAME in place of PATH_INFO to ensure the expected value is returned.
http://wordpress.org/support/topic/clueless-thats-me-500-error-help-please-godaddy-response
Clueless (that's me). 500 Error help please. Godaddy respons
http://wordpress.org/support/topic/500-internal-server-error-showing-at-instalation-in-go-daddy-server/page/2
500 Internal Server error showing at instalation in Go Daddy server
http://nossdutytask.com/drupal_config/godaddy_500_internal_server_error_solution.html
Godaddy 500 Internal Server Error Solution
Not sure if this image attachment thing works . . . but . . . I am attempting to attach a screen shot at the bottom of the error in context . . . please note again that there are a series of messages generated from within PhpGedView . . . then, SOMEONE catches an "OK" message and takes the trouble to BOLD in a huge font the "OK" . . . that has to be PhpGedView code, right? It might help to know what what the import script was expecting to see when that errant server message came rambling in . . .
I have scanned the GoDaddy site . . . I will keep looking. I currently do not have a php5.ini file . . . not sure what to put in it.
This is my .htaccess file, something that came in with FrontPage years ago . . . . which I haven't used in years
=====================================
# -FrontPage-
IndexIgnore .htaccess */.??* *~ *# */HEADER* */README* */_vti*
<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName www.corduan.com
AuthUserFile /var/chroot/home/content/A/C/o/ACorduan/html/_vti_pvt/service.pwd
AuthGroupFile /var/chroot/home/content/A/C/o/ACorduan/html/_vti_pvt/service.grp
=====================================
Thanks so much for all your effort . . . I deeply appreciate it.
Update: I got my big .ged in . . . now that the site is roughly "up" I am seeing this same error pop up (w/o the bolding) in other places . . . in the middle of pages . . . not often . . . hit "refresh" and it will likley not be there. So . . . that does point to some consistent timing issue . . . I will keep poking . . . if anyone has any ideas, I will be most grateful. I will exersize GoDaddy . . . once I have all the ammunition in hand that I can acquire.
Hello:
If you wish, you can e-mail me a ZIP copy of the GEDCOM file you're trying to import. I can look at this on my off-line server to see if I can figure out the source of your "invalid GEDCOM" error messages.
The server error is NOT being generated or presented for your viewing pleasure by PhpGedView. The browser is displaying this message in response to something it received from the server.
Note: It's highly likely that the version of PHP 5 you upgraded to is buggy. What IS the PHP version?
e-mail: gkroll at keldine dot ca
Thanks so much . . . gedcom is attached (separate email). I did not see the request for .zip until after I sent it . . . "big" to me is 1.4MB . . . I know they get lots bigger.
I suffered a major hit of some kind, just for the record . . . I was starting to get errors when committing changes to the order of "Unable to locate xref #", evidently unable to match a viewed record with a database entry . . . something like that. I backed up, reimported the gedcom before upgrading . . . it had lost entire legs, families . . . pieces here and there . . . gone for ever :-( . . . I am currently getting a series of "unable to find family #" errors due to this . . . . *sigh*. I believe the "Synch database to gedcom" option was on . . . in 4.1.7? In any case, I never would have turned it off . . . I went looking for it in 4.1.7 and at the time could not find it. I am sure it was on . . . because even updates I made shortly before the upgrade made it in . . .
I was holding off on upgrading because, well, the PHP upgrade with unknown effects . . . and the MySQL upgrade . . . my hand was forced by these errors which I lived with for months, finally exceding the ability to ignore. Frustrating . . . what is a mother to do. I intend to set up some kind of synch between my PhpGedView database and a PC based version so at least I can see trouble faster . . . and have a live local backup.
As to PHP version, it is 5.2.14 . . . here is a script that dumps the environment, along with a picture I was playing with:
http://www.corduan.com/phptest.php
Thanks again,
-Alfred
Alfred
A 'good sized' GEDCOM on PGV may well require more than 64mb of memory and may require, especially for lists and relationships, more than 30 secs of execution time, somewhat depending on the processor speed, but more so on good principle.
In today's environment, especially if you are running multiple GEDCOMs, I would look at a minimum of 128mb of memory. RAM is cheap now!
You also have not advised the environment in which you operate. What about bandwidth? Usually, GODADDY has pretty solid UP speeds, but do you have good UP/Down at the client?
-Stephen
I received the requested GEDCOM and was able to import it into my off-line copy of PGV with no trouble other than those pesky "Invalid GEDCOM format" errors.
While looking at the GEDCOM, I noticed that it was full of LRM characters. They shouldn't cause problems, but I removed them just to make the GEDCOM more readable with my favourite text editor. Older versions of PGV recorded LRM and RLM characters in the database when an on-line edit was done. Current versions remove any LRM and RLM characters they see so that text in the database is clean, and only add these codes when they are needed while displaying on RTL pages.
I added some debugging code to the two places in "includes/functions/functions_import.php" where the error messages are produced. It turned out that PGV was complaining about a GEDCOM format error while processing some "0 @Mnnn@ OBJE" records. It was seeing empty lines - but not for all such OBJE records.
I can't see what's wrong with the OBJE records that generated the errors, but when they were removed the Import no longer complained. I suggested to Alfred that he should just ignore the error messages and then to see whether the "bad" OBJE records are actually missing from the database. I sent him a text file containing just those "bad" records so that he knows which ones are causing problems.
I'm waiting for more information on where the update is failing. I agree with Stephen that more memory would help, particuarly if the "Synchronize GEDCOM" option is on. Alfred can't lose anything by turning this option off, just to see whether the previously failing updates are actually correctly recorded in the database.
On memory . . . I am not sure I understand. I doubt you are talking about PC RAM (I have 4GB) . . . but I am confused about the "Memory is cheap" comment . . .
I have GoDaddy . . . in the hosting spec they say bandwidth is "unlimited" . . . which I presume says they won't charge me for volume but says nothing about throughput ("latency"?)
I have Comcast for my ISP with several ticks above "worst" speeds. We do have 8 computers on the network (we have 11 kids, no kidding) but response times have been fine. I also operate with a VPN link on this system to work (work from home) . . . but, again, response times have not been an issue. I went ahead and just did a "speedtest.net" check . . . with VPN on (encrypted link from Chicago to LA, then bouncing out their proxy to the open Internet) I got about 3MB/sec both up and down . . . which they think is slow. When I took VPN off I got 4MB up and 24MB down, which they think is excellent. However I got the "OK" error again bringing the "big boy" back in twice before it succeeded the 3rd time. Maybe it would have taken 10 times with VPN on, so I presume it is better.
Are LRM characters types of control characters?
Interesting that at least one of the images showing the problem is in the database twice . . . the one showing the error has a bunch of garbage in the title string and note . . . are THOSE the LRM characters?
0 @M18@ OBJE
1 FILE media/Cordua_Heloise_Rhenardus_Letter_1.jpg
2 FORM jpeg
3 TYPE manuscript
2 TITL Heloise Rhenardus Letter ‎‎‎‎‎‎(1949)‎‎‎‎‎‎ - page 1
1 _PRIM N
1 _THUM N
1 NOTE Paramaribo 14th May, 1949
2 CONT Heloise Rhenardus
2 CONT Saramacca Straat
2 CONT 65o ‎‎‎‎‎‎‎‎ / the river
2 CONT
2 CONT My dear Emmy,
2 CONT
2 CONT I hope this will find you, husband and children in good health. Your letter I have received quite save and of course your picture, and very glad to hear from you . . . How do you do?
2 CONT
2 CONT I sincerely hope that sad time is past and now you're happy again. In Dutch we say, "Every time has its struggle ‎‎‎‎(trouble)‎‎‎‎". To us you look very sweet. I note that you're married twice and I not even once ‎‎‎‎
2 CONC (ha ha)‎‎‎‎. A very good action of you to take care of your first husband, until he is gone. God will bless you. That could never happen here in Suriname. Does it happen often in America? The next husband should never agree with the id
2 CONC ea, if it was a Surinamer, any rate you have done good work and you will not remain unpaid by God.
2 CONT
2 CONT So you were married in 1912. Just the year I was borned. My birthday is 27th July and let me kindly know yours and family. Gladly I should like to know Edith, Ed's‎ and the others birthdays. Please ask Edith to let me know.
2 CONT
2 CONT Well, Emmy, I went to spend a day with my two old aunts, Cornelia Cordua 86
1 CHAN
2 DATE 08 FEB 2008
3 TIME 09:48:24
2 _PGVU ACorduan
The one that came in right has none of that:
0 @M39@ OBJE
1 FILE media/Cordua_Heloise_Rhenardus_Letter_1.jpg
2 FORM jpeg
3 TYPE manuscript
2 TITL Heloise Rhenardus Letter (1949) - page 1
1 CHAN
2 DATE 17 NOV 2006
3 TIME 01:51:38
2 _PGVU ACorduan
The "Invalid Format" images did not import . . . the other did
So . . . I will try to clean those up and try again when I have a chance . . . or just splice yours in if you have already done the work (my time is gone for the moment)
OK, I couldn't help myself . . . I stripped that weird sequence of 3 characters out of the .ged, removed the duplicate references to the same .jpgs and reuploaded . . . for the record it came in without the "OK" error the first time, with VPN on . . . and the 4 "Heloise" images came in without an error. I still have 3 other "invalid Gedcom format" errors that you may have addressed in your other comments . . .will get to that (REALLY have to get back to work).
Thanks for your help . . . deeply appreciated.
acorduan
I'm confused about your confusion. Your PHPINFO definitely shows your server restricted to 64mb Master and 64mb local (this in NOT your machine, but what is assigned to PGV via the config.php). Your local can not exceed your master, so GoDaddy has allocated only 64mb to your installation. If you are running other programs, and you are on a shared server, access to your processor may be restricted and the ram is certainly low.
AFA bandwidth, it sounds adequate, but you don't know your server's Up speed, nor do you know the load on the server from perhaps a shared environment. Do you share, or are you dedicated? All these factors have a major effect on your overall performance.
Finally, yes - corrupted data can be have a very detrimental impact on your ability to import and manage your GEDCOM. If it is not too many records, you may be able to clean it up manually, but I would prefer you return to another copy (backup) that lacks any indication of corruption as identifying all instances can be near impossible.
-Stephen
Thanks for the clarification. I just increased it to 96MB with php5.ini . . . is that good . . . or should I shoot for higher? For the record the "OK" message/Error happened again twice on import after the change (Memory upper verified by phpinfo())
Also - as this feeling of unbridled power sweeps over me - does it make sense to increase the length of time scripts may process? I see these two variables:
max_execution_time = 30 ; Maximum execution time of each script, in seconds (30)
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data (60)
I have gone through to clean up the errors I can see. Interesting that all of the "Invalid Gedcom format" errors came on Media references that were both duplicates (more than one OBJE pointing to the same file) and had those "LRM" characters in them. Removing the characters did not fix it . . . doing that and removing the duplicates did.
Well, I do. Many of my lists and a media management search take up to 90 seconds due to the size of our data and the management techniques used by the program. But then, i also give PGV 1gb of memory. Perhaps overkill, but the old adage of you can never have too much RAM still resonates in my mind.
-Stephen
Alfred:
Thank you for keeping us all informed.
Yes, that garbage you see in your GEDCOM are LRM codes. These codes specify directionality of the character that follows when it's displayed on RTL pages such as Hebrew and Arabic. This a requirement because of the dumb way the HTML standard has defined the processing of text when it's to be displayed on pages that read from right to left (RTL).
The LRM codes got in there because you edited the text using PGV. It added the LRM codes to the text for display purposes, you then saved a change (not necessarily to the text), and PGV stored the result in the database. PGV should have removed the LRM codes before storing the result. The more times you saved the result, the more LRM codes were added. If you see three of them in a row, you saved the change three times.
It's interesting that you have found duplicate file references for some media objects. As far as I know, this is perfectly legitimate and shouldn't cause any errors. I'll have to put a test case together for this condition to identify where the Import is actually going wrong. This won't happen any time soon - I have too much else to do.