fail in module dupcheck

[tlahuizcalpantecutli]

Hi, Team

Any guidance would be much appreciated: suddenly module 'dupcheck' crashed on me. Nothing changed that I am aware of, except that one of my users uploaded 100+ duplicated images by mistake.  I used to identify and delete those using this particular module, but now it refuses to work...

Below is the log and an image of the error on the screen

Thanks and regards...

Humble but hopeful

➜  ~ cat /storage/gallery/logs/2022-03-15.log.php
<?php defined('SYSPATH') or die('No direct script access.'); ?>

2022-03-15 00:41:42 -04:00 --- error: Error [ 0 ]: Attempt to assign property "next_page_link" on null
/usr/share/gallery3-3.1.5/modules/dupcheck/controllers/dupcheck.php [ 83 ]
#0 [internal function]: dupcheck_Controller->dupes()
#1 /usr/share/gallery3-3.1.5/system/core/Kohana.php(302): ReflectionMethod->invokeArgs()
#2 /usr/share/gallery3-3.1.5/system/core/Event.php(208): Kohana_Core::instance()
#3 /usr/share/gallery3-3.1.5/application/Bootstrap.php(67): Event_Core::run()
#4 /usr/share/gallery3-3.1.5/index.php(124): require('/usr/share/gall...')
#5 {main}
➜  ~

[tlahuizcalpantecutli]

Team, my immediate problem is solved.  By detecting duplicate images through a script (external to gallery) and deleting them from the gallery manually using 'Organize Album', the 'dupcheck' module works again.  It was --I  guess-- some overflow due to too many duplicates having been uploaded through 'Server add'.  I am not sure how many duplicates crash the module, but in this case it was over 100 that I deleted.

Thanks and regards

t

[J.R.]

Never used dupcheck module myself, but if all the duplicate images when into the same folder then it should be easy to see them when going to that album when logged in as admin and do a mass delete. If the only thing in that album is the dupes, then just deleting the whole album would do the trick (if delete is successful then re-create that album if you still want it in place for future use).

-- J.R.

--
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:
gallery...@googlegroups.com
 
To view or sign in to this group on the web, use this URL:
https://groups.google.com/forum/#!forum/gallery-3-users
---
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/fbb42428-90f4-474e-a77a-b7ff92d4067en%40googlegroups.com.

[Gerardo L. Cahn]

That makes sense, JR.  In this case, unfortunately, the images (3.8k new photos) were in three separate 'trees' representing memories of trips done over the years by 3 different members of the family, placed in subdirectories per each of their separate criteria: dates, places, camera used, etc., and colliding with photos already present in the gallery, uploaded years go by a different user, 100-200 of the photos being also in the newcomers' batch... all in all, the dupes ended up distributed in 56 directories...  after detecting the collisions via script, we had a boring manual session deleting 1-10 images from each folder.  Oh, well... what doesn't kill you, makes you stronger.

I could have deleted the new folders as you say, or restored a backup and detect/delete the dupes via script ahead of uploading, but by then too much time had passed and we were not sure if anything else had been changed, so... we just soldiered on.

Thanks,

t

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/2ed6b645-d526-ebcf-1e88-2f0f1e72da9e%40thepostalzone.com.

-- 
// Gerardo L. Cahn <ger...@niuk.org>
//  linux, mac ... and, well, yes,
//        ((windows too)).

[Brad Dutton]

Do you have a link to the dupcheck module? It's hard to troubleshoot anything without access to the code.

[Gerardo L. Cahn]

Sorry, I would not know where to download it from... it came to me --I think-- back in gallery2 times...  but here is the zipped folder: I hope this helps?

The admin/modules page says:

"Duplicate Image Module, version 8, When images are added/modified, this module will update a table in the gallery database to contain the MD5SUM of the fullsize image. It will add an item in the admin/contents menu to check for duplicate files, then display them in a dynamic album for you.<br /> | By J.E. Nash"

t

You received this message because you are subscribed to a topic in the Google Groups "Gallery 3 Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gallery-3-users/w3vXYq5tCGU/unsubscribe.
To unsubscribe from this group and all its topics, 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/b49c4dfd-26d3-4855-853c-329b1e2e5685n%40googlegroups.com.

[Brad Dutton]

The code generally works for me. I might use this on my on site to keep my wife from uploading dupe photos... The only error I saw was during the index build that ran after I enabled the module. It looks like the sessions table is too small (limited to 64k of data). Due to this limit the list of duplicates isn't complete (if the list is large) when you run the initial admin task, only a subset of the duplicates are shown.

I see where the error you encountered would occur but I'm not sure how to replicate the issue. What were you clicking to produce the error? I want to verify a fix.

I added this module to the contributions:

https://github.com/bwdutton/gallery3-contrib/tree/master/3.0/modules/dupcheck

[Gerardo L. Cahn]

Excellent!  I am glad that dupcheck works and that you may give it another lease in life.  It has served me well if not too frequently over the years, and it is back to working now that I reduced manually the number of dupes.  It is probably that 64k table limit that you mention, that was killing it.

The problem happened upon batch-adding images through 'Server add', containing many dupes between the images added and those already in the gallery.  The process became slower and slower until it stalled.  You could see the counter going up fast, then slower, then not increasing at all.  And after closing that session, if you asked for dupes (through menu 'Admin-Content-Gallery Photo Duplicates'), that is when the crash I reported at the beginning of this chain happened ("Something went wrong!...").

t

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/54fac443-a316-4d35-8297-8b688769b560n%40googlegroups.com.

[Brad Dutton]

Here is the updated file that has the fix:

https://github.com/bwdutton/gallery3-contrib/blob/master/3.0/modules/dupcheck/controllers/dupcheck.php
Use the "Raw" link to download or copy the content.

[Gerardo L. Cahn]

Thanks, Brad.  New version installed and briefly tested.  All looks good.  I am not going to add dupes on purpose, but if anything goes amiss, I'll report it here.

Best,

t

To view this discussion on the web visit https://groups.google.com/d/msgid/gallery-3-users/4d817f99-6595-4dcc-8a09-80d9404820a6n%40googlegroups.com.