No. In the permission box, you should have (at least) 5 permissions :
- View
- View Full
- Add
- Edit
- Download Album
If you don't have the permission "Download Album", upgrade the "downloadalbum" module. Take it from my repo to be sure to have the latest version.
James.OD
Joined: 2008-02-18
Posts: 11
Posted: Mon, 2011-05-02 18:38
OK, in acp>modules I unticked the mod, updated, replaced with the downloads module from "rledisez-gallery3-contrib-4ca5df3.zip", and nothing changed in the permissions (no new "Download Album" row). I tried on both default and new theme. Did I do something wrong? Maybe there's a cache for modules to delete somewhere? Thanks
ondex
Joined: 2009-04-30
Posts: 40
Posted: Tue, 2011-05-03 08:09
@James.OD: Could you confirm that you are running module downloadalbum version 3 ?
If you're still in version 2, you should use the upgrade procedure by going to this url : http://gallery.example.com/index.php/upgrader
(replace gallery.example.com with your domain)
James.OD
Joined: 2008-02-18
Posts: 11
Posted: Tue, 2011-05-03 08:39
eh right...the upgrader. sorry about that. all's well now! I haven't used gallery for years. happy to be back though!
rredmon
Joined: 2004-07-06
Posts: 34
Posted: Sat, 2011-05-14 03:36
Brilliant module! If I were to ask for a feature, I'd ask to give the user the ability to set each filename by the image's displayed title. Sure, the title would have to pass through some sanity filter for length, ASCII, etc... As an alternative (or addition), the zip could contain a manifest file that contained file_path,title,description,etc. I would find such features indispensable!
zebber
Joined: 2011-04-18
Posts: 1
Posted: Wed, 2011-05-18 08:49
Hi ondex, great module! I am having a bit of an issue with permissions on the root album. I am denying downloads of the root album and allowing access on sub albums. I can allow and deny on sub-albums and it works great. But when I deny on the root, it still shows the download album icon? I have tried and retried it and even though it says it is off, it still allows downloads. Any suggestions?
Nevermind, got it to work. Thanks.
destef1
Joined: 2007-10-06
Posts: 14
Posted: Sat, 2011-07-02 12:38
I have a problem witht this and all variations.
It works on albums that are only a few mB in size, But once I get up over around 90mb when I click the button to download it waits about 20 seconds then goes to a "page can not be found" internall 500 error.
This has to be some setting on my VPS causing this.
Any idea what it could be or what could be causing this?
Raybot
Joined: 2011-07-15
Posts: 1
Posted: Fri, 2011-07-15 09:44
I've got the same problem ... an album folder with around 20mb of photos works fine, another with around 50mb gives a 500 server error when I click the disk icon. Note that the directory structure and images in the two folders are identical - both were created from the same set of high res jpeg images but downscaled by different amounts. I've also tried it with an album folder with no directory structure (ie. flat) with similar problems.
My limited PHP debugging skills (consisting soley of placing a throw statement at different points in the code until I find a line where the exception is thrown if placed above the line but a server error produced when placed below the line) indicates that the server error occurs when the following line in downloadalbum_Controller.sendHeaders() is executed:
Which of course makes no sense as it's a perfectly valid line of code so it would indicate that either my attempt at printout debugging doesn't work or something else is messing up and it's only showing up when execution gets to this line.
I suspected that maybe the header() calls preceeding this were causing problems but all the variables through there looked sensible (and, apart from the Content-Length header, identical between working and not-working scenarios). I've checked the $filesize ($zipsize) heading into this function and it appears sensible (it works on a zipfile of size 24623477 and fails on one of size 52923458 - I'm on a somewhat slow connection so it's difficult for me to binary search this down to a specific number).
Anyone (perhaps with somewhat better knowledge of PHP than I) got any more ideas?
Update: Looks like it's also broken (for me at least) with a file of around 30MB ...
macin
Joined: 2011-01-25
Posts: 7
Posted: Mon, 2011-08-22 11:57
I installed the latest downloadalbum module from your private git repository and used the updater. The disk icon appears but clicking on it results in
Firefox can't find the file at http://.../gallery3/index.php/downloadalbum/zip/album/3126.
What is that about?
Regards,
macin
scrollgomes
Joined: 2011-10-19
Posts: 1
Posted: Wed, 2011-10-19 14:25
macin wrote:
I installed the latest downloadalbum module from your private git repository and used the updater. The disk icon appears but clicking on it results in
Firefox can't find the file at http://.../gallery3/index.php/downloadalbum/zip/album/3126.
What is that about?
Regards,
macin
Hi,
I´ve exactly the same problem, how can i solve this??
Regards,
ondex
Joined: 2009-04-30
Posts: 40
Posted: Fri, 2011-10-21 17:02
Hi all,
first of all, I'm sorry for my long silence. I'm very busy now and I can't find time to maintain my modules.
@zebber:
I can't reproduce your problem. Are you sure you're not admin ? (admin always have the right to download)
@destef1, Raybot:
Have you tried to increase max_execution_time ? (see the previous messages in this thread for explanation)
@macin, scrollgomes:
I can't reproduce the bug. I'm running Gallery 3.0.2 on PHP 5.3.2. Can you give me informations about your installations ? (version of gallery, php, ...)
ploef
Joined: 2011-05-11
Posts: 11
Posted: Sun, 2011-10-23 11:40
ondex wrote:
No. In the permission box, you should have (at least) 5 permissions :
- View
- View Full
- Add
- Edit
- Download Album
Hello, I was using this module and it worked fine, but I removed it for different reasons.
But now I still have the 5 permissions visible in the permission box.
Can anyone direct me in how I can remove this now obsolete line in the permission box?
With kind regards,
ondex
Joined: 2009-04-30
Posts: 40
Posted: Thu, 2011-10-27 13:05
ploef wrote:
I removed it for different reasons.
But now I still have the 5 permissions visible in the permission box.
Can anyone direct me in how I can remove this now obsolete line in the permission box?
Hello ploef,
currently, Gallery defines some actions on modules :
- install
- upgrade
- activate
- deactivate
activate is called when the checkbox is checked in the module section of the administration
deactivate is called when the checkbox is unchecked
install is called the first time the module is activated
upgrade is called when a new version of the module is available
The point is there is no way of uninstalling a module. It is something planned for future version of Gallery, but does not exist right now. Should I destroy the data when the module is only deactivated ? I don't think so.
What you can do is re-install and re-enable the module. Then modify the file helpers/downloadalbum_installer.php of the module by renaming the function "uninstall" to "deactivate". Then, deactivate the module, I think it should work (but I haven't tested it, so BACKUP your database before)
Let me know if it helped you.
ploef
Joined: 2011-05-11
Posts: 11
Posted: Sat, 2011-10-29 10:52
ondex wrote:
What you can do is re-install and re-enable the module. Then modify the file helpers/downloadalbum_installer.php of the module by renaming the function "uninstall" to "deactivate". Then, deactivate the module, I think it should work (but I haven't tested it, so BACKUP your database before)
Hello,
Thanks for the reply.
I did as you said and the "download" permission line is indeed gone now.
Just for the info.
When trying to deactivate the module after modifying the downloadalbum_installer.php I received an error saying :"An error has occurred when trying to install Downloadalbum", and the module "downloadalbum" was still checked as active. But the permission line was gone.
I then modified the downloadalbum_installer.php back to its original, and deactivated it again without any error this time.
Anyway, the permission line is gone.
Thanks for the help.
BurgerZ
Joined: 2011-11-14
Posts: 4
Posted: Tue, 2011-11-22 06:51
Hi. Is there any option to download album from search results (like from tag)?
It will be so great to have this possibility.
BurgerZ
Joined: 2011-11-14
Posts: 4
Posted: Thu, 2011-12-22 08:27
Hello.
I really need your help, mates.
I have no idea how to add to this module more functionality.
By now "downloadalbum" can save zips with TAGS and ALBUMS.
I'd be very happy to see the possibility of ziping SEARCH_RESULTS.
Can anybody help with it?
lousyg
Joined: 2012-12-26
Posts: 4
Posted: Thu, 2012-12-27 15:57
Hello all,
Brand new Gallery 3 user here, I just installed it this weekend and I'm loving it! I added the downloadalbum module to my server, but unfortunately, I've been having problems when trying to download some of my larger albums. When trying to do so, I get a "file not found" error, and after checking my apache error_log, I'm seeing "Allowed memory size of X bytes exhausted..."
I've set the PHP memory_limit variable to 2048MB to see if that fixes the problem. While it allows me to download some of the smaller albums (300-400MB), the larger albums (500MB +) still give me the same error. I tried setting the memory_limit variable to 4096MB, and while that seems to have fixed the problem with my albums, I'm not willing to let PHP have access to that much memory.
I scoured the downloadalbum code, but couldn't find anything that it's doing wrong (it's basically creating its own zip file and writing the data to stdout). I replaced the downloadalbum code with some simple PHP download code (and pointed it to a test 500MB zip file), but I still had the error. When I took that same code and ran it outside of Gallery3/Kohana, the download worked with no problems.
After doing some research, it's apparent that Kohana is doing some fancy output buffering. I expect that the problem I'm seeing has to do with that. It almost seems like Kohana is keeping around multiple copies of the output buffer (perhaps when calling functions its passing the buffer variable data instead of a reference). I had drafted up a post asking about upgrading the version of Kohana that's included with Gallery3, but I've seen that the API for Kohana v3 has changed drastically from v2.
Long story short, I've added two lines of code to downloadalbum that seem to have worked around the issue. I don't think this fix is ideal, as it disables Kohana's output buffering, executes the download album code, and then re-enables the output buffering before it returns. I've included the changes below for anyone who's interested (some searching shows that I'm not the only one who's encountered this problem).
I'd love for someone who's more familiar with PHP/Gallery3/Kohana to take a look and give me either a thumbs up or thumbs down. Perhaps somebody knows a better workaround or even a solution. Is adding these two lines a bad idea? Any inputs at all?
Quote:
--- downloadalbum.php
+++ downloadalbum.php
@@ -23,6 +23,7 @@ class downloadalbum_Controller extends C
* Generate a ZIP on-the-fly.
*/
public function zip($container_type, $id) {
+ ob_end_flush();
switch($container_type) {
case "album":
$container = ORM::factory("item", $id);
@@ -150,6 +151,8 @@ class downloadalbum_Controller extends C
0 // .ZIP file comment length (2 bytes)
// .ZIP file comment (variable size)
);
+
+ ob_start();
}
ondex
Joined: 2009-04-30
Posts: 40
Posted: Thu, 2012-12-27 21:26
Hi lousyg,
thanks for your feedback. I don't know where your problem comes. As you can see in modules/downloadalbum/controllers/downloadalbum.php, line 61, method prepareOutput() is called. This method calls (line 219) Kohana::close_buffers(FALSE).
Basically, Kohana::close_buffers() flushes all the buffer by calling ob_end_clean() as many times as necessary. You can check the code in system/core/Kohana.php, line 515.
Can you give me some informations of your installation (OS, PHP version, HTTP server). If I can, I will try to reproduce the bug. Can you try to disable all third party modules except downloadalbums ? May be an other module creates a new buffer without notifying Kohana.
FYI, I just downloaded a ZIP of 1GB without any problems. My memory_limit is 256M.
sunnychu
Joined: 2012-12-28
Posts: 1
Posted: Fri, 2012-12-28 16:03
I am not familiar also... I faced the same problem as you do.... However, I have tried to perform zip locally, it is found that it takes so long to zip the files. However, if using tar instead of zip (i.e. archive but not compressing), the speed is thousand times faster. So, I wonder if it is possible to use tar instead of zip in the php code file to increase the speed and reduce the loading of CPU. It is becuase JPG itself is a compressed format. Further compression does not help. But just archive the JPG picture does boost the performance ~
Please help ~
ondex
Joined: 2009-04-30
Posts: 40
Posted: Sat, 2012-12-29 12:01
@sunnychu
First of all, files are not compressed. ZIP defines the compression method "stored" which does not compress files. My module uses this one. So, your test is probably not valid. Secondly, ZIP decompressor is natively available on all OS. TAR decompressor is only natively available on Linux and Mac OS. I can't propose a module that does not work on Windows, it would eliminates 90+% of the users.
If you wan help, give me informations about your server so i can reproduce the problem.
lousyg
Joined: 2012-12-26
Posts: 4
Posted: Sat, 2012-12-29 15:21
Ondex,
Thanks for the response. While I know very little about Gallery, Kohana, and PHP, it really seems to me like Kohana might be making multiple copies of the buffer data during the "force download" process. I tried looking at the buffer code a bit, and I did see a few places where they passed the buffer data to functions as a copy instead of reference. Regardless, when adding the two lines of code that I posted above, I not only stop receiving the memory exhausted error, but the download also appears nearly immediately. Even when I had adjusted the PHP memory_limit to an extremely large value, the large albums would take 20-30 seconds for the download prompt to display. After making my changes, I receive the download prompt almost immediately after clicking the download button, no matter how large the album is.
As you requested, here's some information on my setup: I'm running gallery on my Fedora 17 VM on an ESXi hypervisor. My server as a Q6600 processor with 8GB of RAM (these resources are divided equally between my Fedora VM and a Windows 7 VM). I'm using the latest version of Gallery 3. I'm using httpd (which is just Apache 2 on RedHat/Fedora). I have mysql-server 5.5 installed. Here is a dump of all PHP-related packages that I have:
The only other modules that I've enabled/added are "downloadfullsize" and "serveradd". I disabled both of these, restarted Apache/httpd, and tried again, and I received the same error that I've always received. I don't believe it has to do with modules.
ondex
Joined: 2009-04-30
Posts: 40
Posted: Sat, 2012-12-29 18:03
Thanks for these informations lousyg. I installed a F17 and I was able to reproduce the bug. It was only affecting PHP 5.4 and superior versions.
It seems I may have mis-understood the behavior of Kohana::close_buffers(). Whatever, I do not use it anymore. I close the buffer myself. See the first post for the changelog and the commit.
Michi-Master
Joined: 2010-07-27
Posts: 5
Posted: Tue, 2013-01-08 18:28
Hello people,
I use v.3.0.4 Gallery and I can not upload videos, What I have to install modules and how I need to embed the path?
I installed NoFFMPEG and Video Dimensions.
I can now upload videos but they must not be larger than 17MB and the player shows no picture only sound.
Can someone help me with my problem?
Greetings Michi
floridave
Joined: 2003-12-22
Posts: 27300
Posted: Wed, 2013-01-09 00:43
Is your issue with the download album module or is it a general videos issue?
it is a general problem.
mp4 videos can I upload but maximum 17Mb per file.
I can use a little trick to get down so I can play larger files.
The main problem is that, I cant see the videoscreen, only audio works.
I use Flowplayer to play and think it is not compatible.
Maybe he has a problem with the codec or the nvidia driver.
Can I put another player in the Gallery?
@Michi-Master: this thread is to discuss of the module "downloadalbum". Please open a dedicated thread to discuss your problem. Thanks for your comprehension.
lightxx
Joined: 2010-12-02
Posts: 28
Posted: Tue, 2013-07-23 06:39
i have exactly the same problem.
dunno what caused this though, as the module was working flawlessly before.
have you ever found the reason why this is happening?
Posts: 40
@James.OD:
No. In the permission box, you should have (at least) 5 permissions :
- View
- View Full
- Add
- Edit
- Download Album
If you don't have the permission "Download Album", upgrade the "downloadalbum" module. Take it from my repo to be sure to have the latest version.
Posts: 11
OK, in acp>modules I unticked the mod, updated, replaced with the downloads module from "rledisez-gallery3-contrib-4ca5df3.zip", and nothing changed in the permissions (no new "Download Album" row). I tried on both default and new theme. Did I do something wrong? Maybe there's a cache for modules to delete somewhere? Thanks
Posts: 40
@James.OD: Could you confirm that you are running module downloadalbum version 3 ?
If you're still in version 2, you should use the upgrade procedure by going to this url : http://gallery.example.com/index.php/upgrader
(replace gallery.example.com with your domain)
Posts: 11
eh right...the upgrader. sorry about that. all's well now! I haven't used gallery for years. happy to be back though!
Posts: 34
Brilliant module! If I were to ask for a feature, I'd ask to give the user the ability to set each filename by the image's displayed title. Sure, the title would have to pass through some sanity filter for length, ASCII, etc... As an alternative (or addition), the zip could contain a manifest file that contained file_path,title,description,etc. I would find such features indispensable!
Posts: 1
Hi ondex, great module! I am having a bit of an issue with permissions on the root album. I am denying downloads of the root album and allowing access on sub albums. I can allow and deny on sub-albums and it works great. But when I deny on the root, it still shows the download album icon? I have tried and retried it and even though it says it is off, it still allows downloads. Any suggestions?
Nevermind, got it to work. Thanks.
Posts: 14
I have a problem witht this and all variations.
It works on albums that are only a few mB in size, But once I get up over around 90mb when I click the button to download it waits about 20 seconds then goes to a "page can not be found" internall 500 error.
This has to be some setting on my VPS causing this.
Any idea what it could be or what could be causing this?
Posts: 1
I've got the same problem ... an album folder with around 20mb of photos works fine, another with around 50mb gives a 500 server error when I click the disk icon. Note that the directory structure and images in the two folders are identical - both were created from the same set of high res jpeg images but downscaled by different amounts. I've also tried it with an album folder with no directory structure (ie. flat) with similar problems.
My limited PHP debugging skills (consisting soley of placing a throw statement at different points in the code until I find a line where the exception is thrown if placed above the line but a server error produced when placed below the line) indicates that the server error occurs when the following line in downloadalbum_Controller.sendHeaders() is executed:
header('Content-Disposition: attachment; filename="'.$filename.'"');Which of course makes no sense as it's a perfectly valid line of code so it would indicate that either my attempt at printout debugging doesn't work or something else is messing up and it's only showing up when execution gets to this line.
I suspected that maybe the header() calls preceeding this were causing problems but all the variables through there looked sensible (and, apart from the Content-Length header, identical between working and not-working scenarios). I've checked the $filesize ($zipsize) heading into this function and it appears sensible (it works on a zipfile of size 24623477 and fails on one of size 52923458 - I'm on a somewhat slow connection so it's difficult for me to binary search this down to a specific number).
Anyone (perhaps with somewhat better knowledge of PHP than I) got any more ideas?
Update: Looks like it's also broken (for me at least) with a file of around 30MB ...
Posts: 7
I installed the latest downloadalbum module from your private git repository and used the updater. The disk icon appears but clicking on it results in
Firefox can't find the file at http://.../gallery3/index.php/downloadalbum/zip/album/3126.
What is that about?
Regards,
macin
Posts: 1
Hi,
I´ve exactly the same problem, how can i solve this??
Regards,
Posts: 40
Hi all,
first of all, I'm sorry for my long silence. I'm very busy now and I can't find time to maintain my modules.
@zebber:
I can't reproduce your problem. Are you sure you're not admin ? (admin always have the right to download)
@destef1, Raybot:
Have you tried to increase max_execution_time ? (see the previous messages in this thread for explanation)
@macin, scrollgomes:
I can't reproduce the bug. I'm running Gallery 3.0.2 on PHP 5.3.2. Can you give me informations about your installations ? (version of gallery, php, ...)
Posts: 11
Hello, I was using this module and it worked fine, but I removed it for different reasons.
But now I still have the 5 permissions visible in the permission box.
Can anyone direct me in how I can remove this now obsolete line in the permission box?
With kind regards,
Posts: 40
Hello ploef,
currently, Gallery defines some actions on modules :
- install
- upgrade
- activate
- deactivate
activate is called when the checkbox is checked in the module section of the administration
deactivate is called when the checkbox is unchecked
install is called the first time the module is activated
upgrade is called when a new version of the module is available
The point is there is no way of uninstalling a module. It is something planned for future version of Gallery, but does not exist right now. Should I destroy the data when the module is only deactivated ? I don't think so.
What you can do is re-install and re-enable the module. Then modify the file helpers/downloadalbum_installer.php of the module by renaming the function "uninstall" to "deactivate". Then, deactivate the module, I think it should work (but I haven't tested it, so BACKUP your database before)
Let me know if it helped you.
Posts: 11
Hello,
Thanks for the reply.
I did as you said and the "download" permission line is indeed gone now.
Just for the info.
When trying to deactivate the module after modifying the downloadalbum_installer.php I received an error saying :"An error has occurred when trying to install Downloadalbum", and the module "downloadalbum" was still checked as active. But the permission line was gone.
I then modified the downloadalbum_installer.php back to its original, and deactivated it again without any error this time.
Anyway, the permission line is gone.
Thanks for the help.
Posts: 4
Hi. Is there any option to download album from search results (like from tag)?
It will be so great to have this possibility.
Posts: 4
Hello.
I really need your help, mates.
I have no idea how to add to this module more functionality.
By now "downloadalbum" can save zips with TAGS and ALBUMS.
I'd be very happy to see the possibility of ziping SEARCH_RESULTS.
Can anybody help with it?
Posts: 4
Hello all,
Brand new Gallery 3 user here, I just installed it this weekend and I'm loving it! I added the downloadalbum module to my server, but unfortunately, I've been having problems when trying to download some of my larger albums. When trying to do so, I get a "file not found" error, and after checking my apache error_log, I'm seeing "Allowed memory size of X bytes exhausted..."
I've set the PHP memory_limit variable to 2048MB to see if that fixes the problem. While it allows me to download some of the smaller albums (300-400MB), the larger albums (500MB +) still give me the same error. I tried setting the memory_limit variable to 4096MB, and while that seems to have fixed the problem with my albums, I'm not willing to let PHP have access to that much memory.
I scoured the downloadalbum code, but couldn't find anything that it's doing wrong (it's basically creating its own zip file and writing the data to stdout). I replaced the downloadalbum code with some simple PHP download code (and pointed it to a test 500MB zip file), but I still had the error. When I took that same code and ran it outside of Gallery3/Kohana, the download worked with no problems.
After doing some research, it's apparent that Kohana is doing some fancy output buffering. I expect that the problem I'm seeing has to do with that. It almost seems like Kohana is keeping around multiple copies of the output buffer (perhaps when calling functions its passing the buffer variable data instead of a reference). I had drafted up a post asking about upgrading the version of Kohana that's included with Gallery3, but I've seen that the API for Kohana v3 has changed drastically from v2.
Long story short, I've added two lines of code to downloadalbum that seem to have worked around the issue. I don't think this fix is ideal, as it disables Kohana's output buffering, executes the download album code, and then re-enables the output buffering before it returns. I've included the changes below for anyone who's interested (some searching shows that I'm not the only one who's encountered this problem).
I'd love for someone who's more familiar with PHP/Gallery3/Kohana to take a look and give me either a thumbs up or thumbs down. Perhaps somebody knows a better workaround or even a solution. Is adding these two lines a bad idea? Any inputs at all?
Posts: 40
Hi lousyg,
thanks for your feedback. I don't know where your problem comes. As you can see in
modules/downloadalbum/controllers/downloadalbum.php, line 61, methodprepareOutput()is called. This method calls (line 219)Kohana::close_buffers(FALSE).Basically,
Kohana::close_buffers()flushes all the buffer by callingob_end_clean()as many times as necessary. You can check the code insystem/core/Kohana.php, line 515.Can you give me some informations of your installation (OS, PHP version, HTTP server). If I can, I will try to reproduce the bug. Can you try to disable all third party modules except downloadalbums ? May be an other module creates a new buffer without notifying Kohana.
FYI, I just downloaded a ZIP of 1GB without any problems. My memory_limit is 256M.
Posts: 1
I am not familiar also... I faced the same problem as you do.... However, I have tried to perform zip locally, it is found that it takes so long to zip the files. However, if using tar instead of zip (i.e. archive but not compressing), the speed is thousand times faster. So, I wonder if it is possible to use tar instead of zip in the php code file to increase the speed and reduce the loading of CPU. It is becuase JPG itself is a compressed format. Further compression does not help. But just archive the JPG picture does boost the performance ~
Please help ~
Posts: 40
@sunnychu
First of all, files are not compressed. ZIP defines the compression method "stored" which does not compress files. My module uses this one. So, your test is probably not valid. Secondly, ZIP decompressor is natively available on all OS. TAR decompressor is only natively available on Linux and Mac OS. I can't propose a module that does not work on Windows, it would eliminates 90+% of the users.
If you wan help, give me informations about your server so i can reproduce the problem.
Posts: 4
Ondex,
Thanks for the response. While I know very little about Gallery, Kohana, and PHP, it really seems to me like Kohana might be making multiple copies of the buffer data during the "force download" process. I tried looking at the buffer code a bit, and I did see a few places where they passed the buffer data to functions as a copy instead of reference. Regardless, when adding the two lines of code that I posted above, I not only stop receiving the memory exhausted error, but the download also appears nearly immediately. Even when I had adjusted the PHP memory_limit to an extremely large value, the large albums would take 20-30 seconds for the download prompt to display. After making my changes, I receive the download prompt almost immediately after clicking the download button, no matter how large the album is.
As you requested, here's some information on my setup: I'm running gallery on my Fedora 17 VM on an ESXi hypervisor. My server as a Q6600 processor with 8GB of RAM (these resources are divided equally between my Fedora VM and a Windows 7 VM). I'm using the latest version of Gallery 3. I'm using httpd (which is just Apache 2 on RedHat/Fedora). I have mysql-server 5.5 installed. Here is a dump of all PHP-related packages that I have:
php-common-5.4.9-1.fc17.x86_64
php-mbstring-5.4.9-1.fc17.x86_64
php-cli-5.4.9-1.fc17.x86_64
php-gd-5.4.9-1.fc17.x86_64
php-5.4.9-1.fc17.x86_64
php-mysql-5.4.9-1.fc17.x86_64
php-pdo-5.4.9-1.fc17.x86_64
The only other modules that I've enabled/added are "downloadfullsize" and "serveradd". I disabled both of these, restarted Apache/httpd, and tried again, and I received the same error that I've always received. I don't believe it has to do with modules.
Posts: 40
Thanks for these informations lousyg. I installed a F17 and I was able to reproduce the bug. It was only affecting PHP 5.4 and superior versions.
It seems I may have mis-understood the behavior of Kohana::close_buffers(). Whatever, I do not use it anymore. I close the buffer myself. See the first post for the changelog and the commit.
Posts: 5
Hello people,
I use v.3.0.4 Gallery and I can not upload videos, What I have to install modules and how I need to embed the path?
I installed NoFFMPEG and Video Dimensions.
I can now upload videos but they must not be larger than 17MB and the player shows no picture only sound.
Can someone help me with my problem?
Greetings Michi
Posts: 27300
Is your issue with the download album module or is it a general videos issue?
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 5
Hi Dave,
it is a general problem.
mp4 videos can I upload but maximum 17Mb per file.
I can use a little trick to get down so I can play larger files.
The main problem is that, I cant see the videoscreen, only audio works.
I use Flowplayer to play and think it is not compatible.
Maybe he has a problem with the codec or the nvidia driver.
Can I put another player in the Gallery?
http://www.mrcclan.de
Posts: 40
@Michi-Master: this thread is to discuss of the module "downloadalbum". Please open a dedicated thread to discuss your problem. Thanks for your comprehension.
Posts: 28
i have exactly the same problem.
dunno what caused this though, as the module was working flawlessly before.
have you ever found the reason why this is happening?
EDIT:
never mind. i should learn how to read. sigh.
solution:
https://github.com/rledisez/gallery3-contrib/commit/b3f97c80231abe2d62ca022abf9791d77bcf521e
(i'm running
tomtom@kraxn:/$ php -v
PHP 5.4.17-1~precise+1 (cli) (built: Jul 17 2013 18:14:06)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
tomtom@kraxn:/$
)