Just had an odd thing happen with AlbumPilot (1.4.0). I did a full sync, like I usually do when I add some new photos, and for some reason the extension re-added two entire albums that were already part of the gallery:
1. Import new files and their metadata into database Synchronization completed. Added: 601, Deleted: 0, Delta: 601 (before: 78258, after: 78859) ./galleries/people/mini-figs – added ./galleries/people/stanley – added
Now, I hadn't noticed anything missing before this sync. The one album was private with just a few photos and it's a historical one I haven't looked at in a while. The other one I've definitely added photos to recently.
Everything seems OK, I was just surprised (plus now, my "Recently Added" page is now filled with these older photos, pushing off the actual recent ones). Any idea what could cause something like that? Since AlbumPilot uses Piwigo's sync code I'm guessing this is not really a problem with the extension but maybe some database corruption? Weird.
Last edited by windracer (2026-04-04 00:34:22)
Offline
Thanks a lot for the feedback - much appreciated.
I have to admit, I cannot really explain that behavior either. It really sounds strange. AlbumPilot relies directly on Piwigo's core synchronization logic for this part, so this does not look like something caused by the plugin itself but rather something happening at the Piwigo core level.
The only explanation I have is that some external tool changed the photo's metadata - but that should be traceable by the date of last change of the files.
In any case, I will keep an eye on it, but I haven't observed anything similar in my own sync runs so far.
Offline
I recently switched on the Cloudflare DNS proxy in front of my Piwigo site (in an attempt to stem the flood of bot scrapers that were killing my server) but noticed this seems to have impacted AlbumPilot. All of the processes still seem to run properly, but the display shows errors and Cloudflare timeouts.
The AlbumPilot.log looks like this, so it seems like there are issues with the image dimensions call and then thumbnail generation:
[2026-04-21 09:29:40] Synchronization started (User ID: 1) [2026-04-21 09:29:40] Options: Simulate = No, Only new files = Yes, Include subalbums = Yes, Overwrite existing thumbnails (if present) = No, Use uploaded poster (if available) = No, Generate poster from frame at = Yes, Overwrite existing poster (if present) = No, Apply film effect to poster = Yes, Generate thumbnails automatically every = No, Generate poster from frame at = 4 seconds, Generate thumbnails automatically every = 5 seconds, Thumbnail size = 120x68, Output format for poster = PNG, Thumbnail sizes = [square, thumb, medium], Album = "(not set)" [2026-04-21 09:29:40] Starting synchronization (files) [2026-04-21 09:29:40] Options: Live, only new files, including subalbums [2026-04-21 09:31:48] Scanning for missing video posters... [2026-04-21 09:31:53] 0 file(s) to process (0 missing posters, 0 files with missing thumbnails) [2026-04-21 09:31:53] Step completed: 3. Generate video posters for 0 videos. [2026-04-21 09:31:54] Scanning for missing thumbnails... [2026-04-21 09:31:59] Invalid image dimensions in DB for ID 81264 (./<redacted>/2026-04-22/IMG_6069.JPG) – width/height missing [2026-04-21 09:33:08] Invalid image dimensions in DB for ID 81265 (./<redacted>/IMG_6071.JPG) – width/height missing [2026-04-21 09:33:08] Invalid image dimensions in DB for ID 81266 (./<redacted>/IMG_6072.JPG) – width/height missing [2026-04-21 09:34:35] Searching for missing checksums... [2026-04-21 09:34:35] Total checksums to calculate: 3 [2026-04-21 09:34:36] Checksum 1 of 3 (33%) – Image ID 81264 | Path: ./<redacted>/2026-04-22/IMG_6069.JPG [2026-04-21 09:34:36] Checksum 2 of 3 (66%) – Image ID 81265 | Path: ./<redacted>/IMG_6071.JPG [2026-04-21 09:34:36] Checksum 3 of 3 (100%) – Image ID 81266 | Path: ./<redacted>/IMG_6072.JPG [2026-04-21 09:34:36] Step completed: 5. Calculate missing checksums for 3 images. [2026-04-21 09:36:30] ./<redacted>/2026-04-22/IMG_6069.JPG – added [2026-04-21 09:36:30] ./<redacted>/IMG_6071.JPG – added [2026-04-21 09:36:30] ./<redacted>/IMG_6072.JPG – added [2026-04-21 09:36:30] Synchronization completed. Added: 3, Deleted: 0, Delta: 3 (before: 79079, after: 79082) [2026-04-21 09:36:50] Synchronization ended [2026-04-21 09:40:39] Total thumbnails to generate: 101 [2026-04-21 09:40:39] Thumbnail 1 of 101 (0%) – Image ID 81202 – Type: thumb | Path: ./<redacted>/2026-04-15/IMG_2008.JPG
Large image, but here's what the page looked like in Piwigo:
I was able to trigger the same behavior (once) using Batch Manager to sync, but didn't happen all the time like it's doing with AlbumPilot. I suspect this has something to do with the multiple IPs that proxied DNS traffic through Cloudflare can originate from?
Offline
windracer wrote:
I suspect this has something to do with the multiple IPs that proxied DNS traffic through Cloudflare can originate from?
To work around this issue, I had to create a non-proxied CNAME record in Cloudflare to use specifically for the Piwigo admin pages. That way all traffic comes from the originating IP address instead of through Cloudflare's servers and then I don't get the errors when synchronizing.
Offline
I had a look at the screenshot and the Cloudflare timeout messages. From what I can tell, this does not really look like an AlbumPilot-specific problem to me.
AlbumPilot is triggering the normal Piwigo synchronization/admin code here, but it does so through several longer-running admin requests. I understand that Piwigo normally ties sessions partly to the client IP address, via $conf['session_use_ip_address'] = true. If I understand it right, if the admin area is accessed through Cloudflare proxy mode, Piwigo may see Cloudflare edge IPs instead of a stable client IP, unless the origin server is configured to restore the real visitor IP from Cloudflare’s CF-Connecting-IP header.
That would also fit with the fact that the same behavior could be triggered once through Piwigo’s own Batch Manager. So my current guess would be that AlbumPilot is just making the underlying Cloudflare/Piwigo session or timeout issue more visible, because it runs these longer batch operations in sequence.
So I think the non-proxied/DNS-only admin hostname is probably the right workaround for now. But overall this looks more like a Piwigo/Cloudflare interaction than something AlbumPilot itself can really fix in its sync logic. Maybe someone on the Piwigo side can confirm whether the session/IP handling, Cloudflare headers, or long-running admin requests are the relevant factor here, and whether there is a recommended configuration for installations behind Cloudflare.
Does this make sense?
Offline
Yep, I have not had an issue since switching to a special non-proxied Cloudflare URL to access my admin area.
Offline
Hello,
Thanks a lot to rw22mhhs for providing the great AlbumPilot plugin.
Initially, I just wanted to run the synchronization via cronjobs on Linux, which isn't possible with
the standard browser interface. So, I asked a friend to help me develop a small script to solve this
issue.
In the meantime, the project grew significantly. It is no longer just a simple CLI bridge, but a
powerful standalone tool that solves several advanced operational limits, such as preventing browser
timeouts, fixing Piwigo video aspect ratios natively via SQL, and providing automated recursive
directory creation.
This command line interface for AlbumPilot is working on Linux or Windows. I like to share the script and the README file but don't know how I can provide it.
I would be absolutely thrilled if rw22mhhs would consider including it into the official plugin
repository!
Best regards,
Matthias
Offline
AthLux wrote:
This command line interface for AlbumPilot is working on Linux or Windows. I like to share the script and the README file but don't know how I can provide it.
Sounds absolutely amazing! Please let us know when you find/decide how to share your work :)
Last edited by neon (2026-09-24 19:55:21)
Offline
Hi Matthias,
Thank you very much, both for the kind words and for putting so much work into this! A real CLI for cron-based runs sounds like a very useful addition, since the current external_run URL still depends on a logged-in browser. In fact, this is something that AlbumPilot is still missing.
Since this forum does not support file attachments, the easiest way to share it is via the AlbumPilot repository on GitHub:
1. Open a new issue (a free GitHub account is required).
2. Pack the script and the README into a ZIP file and simply drag & drop it into the issue text field.
3. Post the link to the issue here, so others can follow along.
A few things that would help me when looking at it:
- Which Piwigo, PHP and database versions you tested with, on Linux and Windows.
- A short description of what the direct SQL changes for the video aspect ratios do, since anything touching the database needs to stay consistent with Piwigo and the VideoJS plugin.
- Your confirmation that you are fine with your code being published under the same terms as AlbumPilot (MIT / LGPL-2.1-or-later / GPL-2.0-or-later).
Please be patient with me, though: I am quite busy at the moment and cannot say yet when I will find the time, it may take a while. Once I have had a chance to review it, I will see how it fits into AlbumPilot.
Many thanks!
Best regards,
Hendrik
Offline
Thank you for this reply.
You'll find the Readme and AlbumPilot.php in [Github] AlbumPilot issue #30
I'd be happy if ypu would include it into your plugin :)
Regarding your questions:
- Which Piwigo, PHP and database versions you tested with, on Linux and Windows.
=> piwigo 16.4.0 with PHP 8.4.25, just on linux:
PHP 8.4.25 (cli) (built: Aug 28 2026 07:36:03) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.25, Copyright (c) Zend Technologies
with Zend OPcache v8.4.25, Copyright (c), by Zend Technologies
- A short description of what the direct SQL changes for the video aspect ratios do, since anything touching the database needs to stay consistent with Piwigo and the VideoJS plugin.
1) you can give an album-id or an album name for import. In case of album name we:
SELECT `id` FROM `piwigo_categories` WHERE `name` = '$album_name' AND `id_uppercat` = " . $parent_id . " AND `site_id` = 1 LIMIT 1"
if we don't find the album we create it with "method=pwg.categories.add&name=" . urlencode($album_name) . "&pwg_token=" . $pwg_token;
Details you can find in function piwigo_get_or_create_album_id
2) add dimensions for videos:
SELECT img.id, img.path FROM piwigo_images - several joins WHERE several filter to get the ids of videos without dimensions
UPDATE piwigo_images SET width = $w, height = $h WHERE id = $row['id'] with the dimensions of the video preview pictures
Details you can find in function piwigo_repair_video_dimensions
- Your confirmation that you are fine with your code being published under the same terms as AlbumPilot (MIT / LGPL-2.1-or-later / GPL-2.0-or-later).
Yes, for sure you can
Br
Matthias
Offline
Hi Matthias,
I am trying your script on my server (Synology NAS, Piwigo in web folder without docker). It seems to be trying to work at least :) Gives the following error:
[1;31mFAILED! Identification endpoint not responding.[0m
Do you have an idea what can be wrong?
Piwigo 16.3.0
Installed on 10 April 2023, 3 years 5 months 3 weeks 6 days ago
Operating system: Linux
PHP: 8.4.14
MySQL: 10.11.11-MariaDB
Graphics Library: External ImageMagick 6.9.12-61
Cache size 1210.65 Mo
AlbumPilot version 1.4.0 (configured and working)
Offline
Hi! Thanks for the feedback. This is a known environment quirk with native Synology NAS PHP installations.
On a Synology NAS, the command-line (CLI) PHP environment handles internal network streams via "fopen" much more restrictively than the web server does. It automatically blocks local SSL connections (like self-signed certificates or internal NAT loops).
You don't need to change anything in the script. You can easily bypass this rigid Synology restriction directly from your terminal by injecting the temporary SSL-override flags into PHP during execution.
Please try running the script like this:
php -d openssl.cafile="" -d allow_url_fopen=1 AlbumPilot.php -a <yourAlbumID>
This tells the Synology PHP engine to allow the internal web-stream context and ignore the local certificate chain for this specific execution task.
Let me know if this instantly solves the endpoint response for you!
Last edited by AthLux (2026-10-08 20:30:52)
Offline
Thanks, Matthias!
I did exactly as you suggested - but received exactly the same error message :(
Offline
Hi again!
I have just pushed an update (Version 1.0.1) to fix this issue permanently.
Instead of trying to override the restrictive Synology PHP environment settings via terminal flags, I completely refactored the script's internal authentication core.
### What changed?
* **Switched from PHP Streams to cURL:** The login process was completely migrated from native PHP streams (`fopen`) to a unified high-performance cURL engine.
* **Synology Compatibility:** While native PHP streams on Synology DSM strictly block local SSL connections and internal network loops, cURL bypasses these rigid security restrictions flawlessly by ignoring unverified local certificate chains (`CURLOPT_SSL_VERIFYPEER => false`).
* **Robust Cookie Parsing:** Cookies and authentication tokens are now parsed via regular expressions straight from the HTTP headers, making the login completely independent of your specific webserver or Docker configuration.
You can grab the updated script from the repository. It should now run completely "out of the box" on your Synology NAS without any errors or additional PHP flags.
Please pull the new version and let me know if it successfully logs in and starts syncing your elements!
In case of issues, please run with -vvv and post the output :)
Offline
Wow, thanks a lot!
Unfortunately still something doesn't work all the way. Please see below the script output with -vvv parameter (I manually removed credentials from the output - they all were correct):
[1;34m=== SKRIPT START (parameter summary) ===[0m
Album-ID: 7104
Base-URL: http://localhost/CORRECTFOLDERNAME
admin user: CORRECTUSERNAME
Password: ***
create thumbnails:NO
check database: NO
Simulation: NO
Mode Strategy: Scan New Elements Only (--updateNew)
verbose: 3
[1;34m======================================[0m
Logging into Piwigo Admin Area...
[STREAM] Target: http://localhost/CORRECTFOLDERNAME
[STREAM] Method: POST
[STREAM] Parameters: session_hash=123456789
[RESPONSE] Status: HTTP 200 (HTML Content, length: 5111 bytes)
[RESPONSE TEXT] Identification | CORRECTGALLERYNAME
var selected_language = `English [US]`;
var url_logo_light = `themes/standard_pages/imag...
[STREAM] Target: http://localhost/CORRECTFOLDERNAME/identification.php
[STREAM] Method: POST
[STREAM] Parameters: username=CORRECTUSERNAME&password=CORRECTPASSWORD&remember_me=1&
redirect=/matthias/&login=Absenden
[RESPONSE] Status: HTTP 200 (HTML Content, length: 1034 bytes)
[RESPONSE TEXT] Piwigo encountered an unrecoverable problem.
[Hacking attempt] the input parameter "redirect_decoded" is not valid
#1 check_input_parameter /volume1...
[1;31mFAILED! Admin session allocation failed.[0m
Last edited by neon (2026-10-13 15:28:55)
Offline