OK, I have downloaded the latest version, copied over my "ged" file, and have the following issue.
It seems like it is loading, for about 10-15 seconds, then pops up a "Document Contains no data" error. I have version .8 running fine, only have issues with this one.
Any thoughts? (I have changed teh time limit to 0, and have the globals thing turned on)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What operating system, web server, and version of PHP are you using?
Also, could you send a copy of your GEDCOM file to me at yalnifj@users.sourceforge.net
My first thought is that the problem is with the PHP flush(); commands. I use the flush command to start sending output back to the browser while the indexes are being built so that you can get some feedback as to what is going on. It could be that your webserver doesn't like to operate that way. You might try taking the lines with flush(); in them out of the buildindex.php file or turning the index files off in the config.php file.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm...
The only other line in the buildindex.php file that might be causing the problem is this one:
ignore_user_abort(true);
It is supposed to keep people from canceling the index builds in the middle and I've found that it doesn't always work anyway.
I don't see anything wierd about your server configuration. Especially since PHP seems to be working on the older version of phpGedView just fine.
I wonder if it is the PHP session handler code in the config.php file. That is the only other place I can think of that does anything with the HTTP headers. You can try turning off the clippings cart by setting $ENABLE_CLIPPINGS_CART=false;
or you might comment out the following lines at the bottom of the config file.
// -- setup session information for tree clippings cart features
if ($ENABLE_CLIPPINGS_CART) {
$sessionname = session_name();
if (!isset($$sessionname)) {
$sessionID = uniqid("");
}
else {
$sessionID = $$sessionname;
}
session_id($sessionID);
session_start();
if (!session_is_registered('cart')) {
session_register('cart');
$cart = array();
}
}
I hope this works.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using a new ged file for this version, so I just tried this ged file, with the old version, and I get a TCP error there as well.
I am using PAF, and exporting as Other GEDCOM 5.5 utf8. Is there anything of note there I need to turn off n the "Include" portion? Notes, Sourcing, Multimedia inks, contact information, confidential data, etc?
Thanks,
--Darren
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess I spoke to soon...even with the old one, it sits in an infinite loop now it seems, and evetually times out. I have the "time" setting set to 0 as suggested for no limit.
Now I have two problems I guess :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've downloaded your gedcom and I'm checking it out. I'm running it on my windows test site, which seems to be working ok. It is currently building the indexes, but I've haven't gotten an error yet.
I will also test it on a Red Hat linux server and see what happens.
I'll let you know...
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't encounter any of the problems that we have been having on your server.
You can see your Gedcom working on a Linux server running Apache 1.3.14 and PHP 4.0.4 at this address (I don't have permissions on the server to upgrade) http://sandbox.lib.byu.edu/johnstest/phpGedView/
You can see it running on windows with Apache 2 and PHP 2.2 here http://john.lib.byu.edu/phpGedView/
But I couldn't get windows to build the index files for your huge gedcom--blame bill gates ;-) But it probably would build them on the command line if I tried.
The timeout you experienced above probably came from your browser and not php. So if you wanted to, you could build the index from the terminal (assuming php is in your path and you are in the GedView directory) by typing:
php buildindex.php
You will see the HTML tags, but you will also see what is going on better.
The only other suggestions that I have is you might try upgrading or downgrading apache and php, which should be pretty easy on Debian with apt-get. Don't go to apache 2 yet as php 4 and apache 2 don't play well together yet, stick with the 1.x version of apache for now. The latest version of PHP is 4.2.3. If that is the version you are running, then try a 4.1.x version.
Also, I don't have PAF on my computer here, so I can't try different Gedcom encoding formats (something else to test in the next rev), but you could try creating your gedcom in plain unicode or ascii and see if that helps, though I don't know why your utf-8 gedcom is causing problems. It should be fine.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The box has 384M RAM. I have increased the maximum memory to be used in php.ini to 64M. It was at 16M. I have also mad ethe change you suggested.
It appears to be running now...I am going to try and kick off one from teh local filesystem in about 2 hours. I'll post an update then. How long did it take to run on your box?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It was a good idea to bump php up to 64MB with how large your file is. Yours is one of the largest GEDCOMs I have seen being used by phpGedView so far. Though people have claimed that they have larger, I haven't actually seen them being used yet.
It took about 15 minutes to build the index on the linux box.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great! I'm glad that we were able to figure it out.
I imagine that we were crashing PHP by opening a 4MB file into an array and then shoving that array into a 4MB string all at the same time. That is why we got the TCP/IP errors and document contains no data. So it makes sence that increasing memory would help.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I have downloaded the latest version, copied over my "ged" file, and have the following issue.
It seems like it is loading, for about 10-15 seconds, then pops up a "Document Contains no data" error. I have version .8 running fine, only have issues with this one.
Any thoughts? (I have changed teh time limit to 0, and have the globals thing turned on)
Here is the URL: <a href="http://www.greerfam.com/GedView2">http://www.greerfam.com/GedView2</a>
I've never seen this before.
What operating system, web server, and version of PHP are you using?
Also, could you send a copy of your GEDCOM file to me at yalnifj@users.sourceforge.net
My first thought is that the problem is with the PHP flush(); commands. I use the flush command to start sending output back to the browser while the indexes are being built so that you can get some feedback as to what is going on. It could be that your webserver doesn't like to operate that way. You might try taking the lines with flush(); in them out of the buildindex.php file or turning the index files off in the config.php file.
--John
Latest PHP with Debian unstable (I believe it is 4.2.something).
Apache 1.3.26
Linux Debian (Unstable)
I've tried with and without the Indexs in the config file, with the same results.
I'll try commenting out the flush commands and let you know.
--Darren
Just tried commenting out the flush() commands, and now I get a TCP error. Please take a look at:
http://www.greerfam.com/GedView2
http://www.greerfam.com/GedView2/buildindex.phps
--Darren
Hmmm...
The only other line in the buildindex.php file that might be causing the problem is this one:
ignore_user_abort(true);
It is supposed to keep people from canceling the index builds in the middle and I've found that it doesn't always work anyway.
I don't see anything wierd about your server configuration. Especially since PHP seems to be working on the older version of phpGedView just fine.
I wonder if it is the PHP session handler code in the config.php file. That is the only other place I can think of that does anything with the HTTP headers. You can try turning off the clippings cart by setting $ENABLE_CLIPPINGS_CART=false;
or you might comment out the following lines at the bottom of the config file.
// -- setup session information for tree clippings cart features
if ($ENABLE_CLIPPINGS_CART) {
$sessionname = session_name();
if (!isset($$sessionname)) {
$sessionID = uniqid("");
}
else {
$sessionID = $$sessionname;
}
session_id($sessionID);
session_start();
if (!session_is_registered('cart')) {
session_register('cart');
$cart = array();
}
}
I hope this works.
--John
Tried both...no luck.
Perhaps, if you have bandwidth to spare, you could try my ged file, to be sure it is working properly for you:
http://www.greerfam.com/GedView2/utf8_greer.ged
Could it be permissions in that folder? I have tried 777 on everything to see if that helped, but no luck.
Thanks,
Darren
I am using a new ged file for this version, so I just tried this ged file, with the old version, and I get a TCP error there as well.
I am using PAF, and exporting as Other GEDCOM 5.5 utf8. Is there anything of note there I need to turn off n the "Include" portion? Notes, Sourcing, Multimedia inks, contact information, confidential data, etc?
Thanks,
--Darren
Let's see how many posts I can do in a day! :)
Anyway...if I take my old gedcom file, and run it against this new install, it appears to be working (Still building indexes, but I see output).
So, other than doing a UTF8 GEDCOM 5.5 dump, am I missing something? Again, if you have bandwidth to spare (3.8M): http://www.greerfam.com/GedView2/utf8_greer.ged
Thanks!
--Darren
I guess I spoke to soon...even with the old one, it sits in an infinite loop now it seems, and evetually times out. I have the "time" setting set to 0 as suggested for no limit.
Now I have two problems I guess :)
I've downloaded your gedcom and I'm checking it out. I'm running it on my windows test site, which seems to be working ok. It is currently building the indexes, but I've haven't gotten an error yet.
I will also test it on a Red Hat linux server and see what happens.
I'll let you know...
--John
Thanks for taking the time.
Just wanted to thank you for the efforts, as my family LOVES the product!
--Darren
I didn't encounter any of the problems that we have been having on your server.
You can see your Gedcom working on a Linux server running Apache 1.3.14 and PHP 4.0.4 at this address (I don't have permissions on the server to upgrade) http://sandbox.lib.byu.edu/johnstest/phpGedView/
You can see it running on windows with Apache 2 and PHP 2.2 here http://john.lib.byu.edu/phpGedView/
But I couldn't get windows to build the index files for your huge gedcom--blame bill gates ;-) But it probably would build them on the command line if I tried.
The timeout you experienced above probably came from your browser and not php. So if you wanted to, you could build the index from the terminal (assuming php is in your path and you are in the GedView directory) by typing:
php buildindex.php
You will see the HTML tags, but you will also see what is going on better.
The only other suggestions that I have is you might try upgrading or downgrading apache and php, which should be pretty easy on Debian with apt-get. Don't go to apache 2 yet as php 4 and apache 2 don't play well together yet, stick with the 1.x version of apache for now. The latest version of PHP is 4.2.3. If that is the version you are running, then try a 4.1.x version.
Also, I don't have PAF on my computer here, so I can't try different Gedcom encoding formats (something else to test in the next rev), but you could try creating your gedcom in plain unicode or ascii and see if that helps, though I don't know why your utf-8 gedcom is causing problems. It should be fine.
--John
I'll give it a shot...I am at work, so I don't have access to the box right now...only through FTP.
I'll send an update tonight...thanks for taking a look!
--Darren
OK, so I got access to the box, and put in some debug "print" statements. In the functions.php, I have modified and placed:
print "READING 1: $GEDCOM\n";
$fcontents = implode("", file("$GEDCOM"));
print "READING 2: $GEDCOM\n";
Of those statements, only READING 1 prints out. When it prints out, I see the correct ged file, and they all have the appropriate permissions.
Any thoughts?
--Darren
How much memory do you have on the machine?
Try splitting the $fcontents = implode("", file($GEDCOM)); line into two parts
print "READING 1: $GEDCOM\n";
$fcontents_array = file($GEDCOM);
print "Reading 1a: $fcontents_array[0]\n";
$fcontents = implode("", $fcontents_array);
print "READING 2: ".substr($fcontents, 0, 50)."\n";
In researching this, I read on the PHP bugs database that some people were having problems with the implode function.
--John
The box has 384M RAM. I have increased the maximum memory to be used in php.ini to 64M. It was at 16M. I have also mad ethe change you suggested.
It appears to be running now...I am going to try and kick off one from teh local filesystem in about 2 hours. I'll post an update then. How long did it take to run on your box?
It was a good idea to bump php up to 64MB with how large your file is. Yours is one of the largest GEDCOMs I have seen being used by phpGedView so far. Though people have claimed that they have larger, I haven't actually seen them being used yet.
It took about 15 minutes to build the index on the linux box.
After implenenting that change you posted, and the php.ini change... all seems to be well.
Check out http://www.greerfam.com.
click on the "New Family Tree"
Thanks!!
--Darren
Great! I'm glad that we were able to figure it out.
I imagine that we were crashing PHP by opening a 4MB file into an array and then shoving that array into a 4MB string all at the same time. That is why we got the TCP/IP errors and document contains no data. So it makes sence that increasing memory would help.
--John