Output from var/logs/2021-02-23.log.php show below. Perhaps that is enough but are there other logs I can check? Please let me know what else I can check or provide to debug this.
2021-02-23 05:57:16 +00:00 --- error: Database_Exception: #2006: MySQL server has gone away [ SELECT *
WHERE `key` IN ('---') ] in /home/thevic11/public_html/gallery3-3.1.3/system/libraries/Database_Mysqli_Result.php:27
#0 /home/thevic11/public_html/gallery3-3.1.3/system/libraries/Database_Mysqli.php(79): Database_Mysqli_Result_Core->__construct(false, 'SELECT *\nFROM `...', Object(mysqli), true)
#1 /home/thevic11/public_html/gallery3-3.1.3/system/libraries/Database.php(272): Database_Mysqli_Core->query_execute('SELECT *\nFROM `...')
#2 /home/thevic11/public_html/gallery3-3.1.3/modules/gallery/libraries/MY_Database.php(48): Database_Core->query('SELECT *\nFROM `...')
#3 /home/thevic11/public_html/gallery3-3.1.3/system/libraries/Database_Builder.php(973): Database->query('SELECT *\nFROM `...')
#4 /home/thevic11/public_html/gallery3-3.1.3/modules/gallery/libraries/drivers/Cache/Database.php(105): Database_Builder_Core->execute()
#5 /home/thevic11/public_html/gallery3-3.1.3/system/libraries/Cache.php(141): Cache_Database_Driver->get(Array, true)
#6 /home/thevic11/public_html/gallery3-3.1.3/modules/gallery/models/task.php(58): Cache_Core->get(Array)
#7 /home/thevic11/public_html/gallery3-3.1.3/modules/server_add/controllers/server_add.php(288): Task_Model_Core->log('Skipping invali...')
#8 /home/thevic11/public_html/gallery3-3.1.3/modules/gallery/helpers/task.php(90): Server_Add_Controller::add(Object(Task_Model))
#9 /home/thevic11/public_html/gallery3-3.1.3/modules/server_add/controllers/server_add.php(122): task_Core::run('410')
#10 [internal function]: Server_Add_Controller->run('410')
#11 /home/thevic11/public_html/gallery3-3.1.3/system/core/Kohana.php(331): ReflectionMethod->invokeArgs(Object(Server_Add_Controller), Array)
#12 /home/thevic11/public_html/gallery3-3.1.3/system/core/Event.php(208): Kohana_Core::instance(NULL)
#13 /home/thevic11/public_html/gallery3-3.1.3/application/Bootstrap.php(67): Event_Core::run('system.execute')
#14 /home/thevic11/public_html/gallery3-3.1.3/index.php(123): require('/home/thevic11/...')
mysql.connect_timeout = 300
But that doesn't seem to help. Do you know if that's the right section? Should it go in the [Session] section of php.ini?
I just tried with these:
I'm going to throw in some info on the "timeout" issues that may or may not be helpful.
These connect maximum connect time setting are in seconds, so a setting=300 is 5 minutes, which may seem like plenty. But large files take time to process *after* they hit their destination and the processing must go through the old Gallery code -- and be integrated into the Gallery file system and the various database references for it created. I'm thinking Server_add is not going to send the next file until it gets confirmation that the previous file was properly processed. So a setting of 600 or more (10 minutes) might help. Bear in mind the setting is the *maximum* time allowed for the SQL transaction to *complete* -- so why not go for a higher ceiling? If the transaction completes and "reports back" faster than that, it's no harm, no foul, and the next file is sent.
Except, there is this to consider:
"mysql.connect_timeout applies only to establishing a connection to mySQL, while default_socket_timeout applies to all subsequent communication after the connection has been established. So, if you already have an established connection, the connect_timeout parameter will be ignored once you send your query. But if a subsequent transaction take more 300 seconds to acknowledge, the socket_timeout parameter -- if it is not set to higher than 300 seconds --will be triggered and kill the transaction."
So, maybe take a look at default_socket_timeout as well? The PHP manual states that the default for it is only 60 (1 minute).
More info on this setting at:
The above is the actual official PHP manual and keyword searching it can turn up all kinds of valuable info (most of which goes way over my head) which is why I'm only pointing out this stuff :)
WHEN USING AN EMAIL PROGRAM to reply to this message, click REPLY TO LIST or REPLY TO ALL so your reply goes out to everyone in the group. If you click REPLY or REPLY TO SENDER Google will *only* send your reply to the original author (not recommended).
To post a NEW MESSAGE to the group, send an new email to:
To view or sign in to this group on the web, use this URL:
You received this message because you are subscribed to the Google Groups "Gallery 3 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gallery-3-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/e0f4fbf8-5de1-4413-b693-f7b0c67a3f23n%40googlegroups.com.
upload_max_filesize = 20M
post_max_size = 100M
The same values are imposed in the .htaccess. I wouldn't think the upload size is being imposed here since the file is already on the server. But it does correlate with the size limit that looks like is being imposed. I tried increasing upload max size to 100M in both the php.ini and .htacess and adding a 75 MB video but it still stalled and produced the DB connection loss messages in the logs. I don't think these are the right values to change anyway because I still have the gallery source from the pre-revival upgrade and those values are also 20M and 100M in both the php.ini and .htaccess. I just checked and most of my videos from 2019 are over 20MB - some are as large as 300MB. I can keep poking around in the old source to see if I can find where these limits changed but if anyone can point me in the right direction, that would be great.
Also, would it make sense to try and trap these kind of errors? Knowing what the imposed limits are, should the code check the file size and throw a warning if the file size exceeds the limits?