Kphotoalbum ignores the 'Do not read RAW files if a matching JPEG/TIFF file exists' setting

[Andrew Kovacs]

Hello, and happy new year!,

Firstly, a heartfelt thank you to all the developers and contributors of this 
wonderful application.
I'd be lost without it.

A bit of an intro...
I have been using linux since 2002.  I'd been driven mad by Windows (95, 98, 
2000, etc...) then OS/2 (had potential, but went nowhere), when a friend 
loaned me a set of Red Hat 7.3 CDs.  I struggled, and learned the 'NIX way, 
with that and a bit of help, before distro-hopping through some RPM-based 
systems for a few years until I knew I needed stability, and more importantly, 
a sane package management system.
Debian released Sarge, and with my meagre skills, I could install and use it.  
More importantly, I could maintain it!  :-)

My digital photo organising journey was similar.  I started in 2004 with some 
cheap, nameless digital camera (1.3MPx), storing my photos in directories, 
beginning with the ISO date, then some meaningful description.  Backups were 
burnt to DVD.
It worked for a while, but I moved to better cameras with bigger cards, took 
more photos, and by mid 2006, returning from a holiday with thousands of 
photos, and I was struggling to keep track of them.  Especially finding photos, 
and how to add places, names, etc... to them.  I knew about exif, but had no 
clue of what software to use, nor how to work out a tagging scheme that would 
properly store the tags.
In my search for these, I stumbled across Kphotoalbum.  I tried it a few 
times, occasionally making a mess, then reinstalling, until I worked out which 
files to backup elsewhere, or to go back to an earlier index.xml backup.

I moved to newer versions as I progressed to the newer Debian stable releases, 
and photo management was a breeze.  I stuck with Debian Jessie until mid 2022, 
when I attempted to move to Bullseye, .  This proved unsuccessful, mostly due 
to kmail generating thousands of copies of existing emails no matter what I 
did, so I elected to stick with Jessie, until Bookworm was released.  

This seems to be working well, (kmail too) but Bullseye had introduced a minor 
problem with Kphotoalbum, and it still exists in Bookworm (Kphotoalbum 5.9.1).

This is summed up in the subject: Kphotoalbum ignores the 'Do not read RAW 
files if a matching JPEG/TIFF file exists' setting.

New image files are copied from the camera SD cards to my NAS (huge plug for 
OpenMediaVault) into a directory structure thus: Digital_camera/<cameramake-
model>/YYYY-MM-DD/files.
The files keep their sequential naming and extension as created in the camera.

I mostly use Pentax cameras, set to simultaneously save .JPEG and .DNG for 
each image.

When I start Kphotoalbum, it's set to search for new files, and this is where 
the problem occurs.  Same when searching for new files from within Kphotoalbum.  
No matter what setting changes I make, Kphotoalbum insists on loading in the 
raw image files, and creating what are effectively 'duplicate' images in the 
thumbnail view.  I've been getting around this issue, by doing a blank search, 
ticking the raw file checkbox, then manually deleting the duplicate (raw) 
images from the database, leaving the raw files intact on the NAS.  While this 
works, kind of, if Kphotoalbum hasn't been started for a while, then loading 
(and creating the duplicate thumbnails for the raw files) can take a very long 
time.

To test if a fresh install of Bookworm behaves differently, I copied a current 
Live Bookworm KDE to a USB stick, booted off that, updated everything, 
installed the current stable Kphotoalbum package, copied my all my files, 
symlinks, etc... to the same 'Images' folder in the live system home 
directory, mounted the NAS to the same mountpoint, and... no change.  
Kphotoalbum still loads in the raw files.
I created a new 'Image-test' directory, copied a couple of small image 
directories there, started Kphotoalbum with -c and created a new index.xml 
(thinking my main database might be corrupt), and still the same problem.

I then went through the same process with Debian Trixie, the current testing 
release, this time with Kphotoalbum 5.13.0.  The problem was gone!  So now, 
how to get 5.13.0 into Bookworm?

I looked for a new version of Kphotoalbum in Debian-backports, but no luck.
I set up my Bookworm install with the appropriate pinning, all set to install  
5.13.0 from Trixie, but the number of packages that would have been removed, 
as well as installed, stopped me from pursuing that path.

I then thought to create my own local backport.  The Debian instructions 
seemed simple enough to create a local, non-uploadbable, non-signed backport.

For extra safety, I booted into the live Bookworm with the USB key, then 
successfully completed all the steps and created and installed a local 
backport of Kphotoalbum 5.13.0, built using Debian testing sources, as 
recommended in the Debian instructions.  I then set everything else up as 
before, crossed my fingers and started my shiny new Kphotoalbum.
Sigh...., the problem still exists.  :-(

I don't wish to migrate to Debian Testing, as I've tried that before and 
constant stream of package updates, plus the occasional breakage that can  
take considerable time to fix, isn't my idea of a stable production desktop.

I tried using search, in the Debian-Users mailing list, but although there 
were a few posts about Kphotoalbum, nothing like I'm experiencing.  Also, 
there's no bug report about this in any version of Kphotoalbum in the Debian 
releases.

I haven't filed a bug report with Debian or KDE, as this may well be caused by 
some other package/library/setting outside of Kphotoalbum.  If anyone else has 
encountered this, and knows how to fix it with some Debian or Kphotoalbum 
settings, I'd be grateful.

Failing any solution, I'm prepared to continue with my workaround and wait for 
the release of Debian Trixie as stable, with what ever version of Kphotoalbum 
that finally 'ships' with.

Thanks to anyone for any help or suggestions and I'll try to answer questions 
that might help.

Kind regards,
Andrew