digiKam databases

Well, this is nifty. According to the documentation, digiKam supports using MySQL/MariaDB as a backend as an alternative to local SQLite files. Plus it documents the constraints relevant for using digiKam across multiple computers with respect to databases and collections.

On the whole, I’ve found the documentation pretty good and comprehensive. Sometimes the English feels a little off once in a blue moon. But the docs are pretty solid. I guess between 17 years of active development and growing professional grade feature sets, I should have expected the docs to be worth more than five minutes.

Good on you, digiKam contributors!

Thoughts on photo management

Along with taking the day for mental health and generally trying to be sane. I’ve been thinking about the future of how my photos are managed and how that needs to evolve.

The present system is pretty much this:

  1. Photos are cached to preferred cloud storage (+2 copies).
    • One is cleared periodically ‘en mass’ after draining.
    • One is cleared periodically during ‘archiving’.
  2. Photos are archived to my file server (+3 copies).
    • Master copies under my Plex media library.
    • Periodically backed up to another local location.
    • Entire file server is backed up locally.
  3. Photos are archived unfiltered to cloud storage (+1 copy).

Now, there’s a few problems with this scheme. Aside from getting off my butt closer to quarterly or yearly than monthly to drain cached images into the master. Over the years the definition of 3 has changed a bit. Another problem has been the evolution of format: I’ve generally migrated from classic JPEG to HEIC, as I’m seeing on the order of 50% disk savings. But of course Plex doesn’t speak HEIC, and therefore viewing outside of mounting the network drive hasn’t worked in years!

I don’t think there’s a good solution to how often I process photos through this pipeline, relative to any other habitual behavior.

There’s also the fact that whether I am draining the cache or actively looking for images, such as building my ‘Remembering Corky’ or ‘Photo Frame’ albums, that doing this at OS level kind of sucks. Explorer and Finder have actually gotten pretty good at dealing with photos since circa 2000, but aren’t exactly fun. More than once I’ve wished for something like Geeqie that my previous Unix machines had. In suffering the native tools, I found that building my Photo Frame album was really damn painful in finder’s gallery view, until I decided to just copy everything to a memory card and go through a process of deleting whatever I don’t want to move.

Actually, the general work flow and process has sucked enough that I’ve considered writing a bit of software to help compensate, or transitioning my master copy into something more cloudy and photo centric. Something that can offer better navigation / movement than a file-centric manager and a little bit more database goodness than my Photos/${YEAR}/${COLLECTION}/ approach to on disk storage.

Then in putzing around Steam Deck, taking its desktop mode for a test drive made me remember an old KDE application called digiKam. It has features for basically everything but pulling free disk storage out its digital back oriface.

In the old days, I never messed around with digiKam. Partly because it and KDE, were kind of heavy weight on my laptop back when I was a KDE user. Partly because by the time digital cameras and smartphones were part of my life, I had no KDE systems and an increasingly heterogeneous computing environment.

I’m thinking that digiKam may be a good solution to the solvable problems. It certainly should be able to handle my photos archive, which is over 40G and 14,000 image and video files. Actually, when the heck did this get so large? It feels like just a lustruum ago, I could fit everything on one Blu-ray layer 😆. Actually, maybe I should run WinDirStat or Grand Perspective over that. On the flip side, digiKam will probably offer much of the goodness I remember Google+ Photos having back when I used that. For me personally, being both cross platform and open source are huge pluses. It’s also helpful that it is one of the more cross platform KDE applications, as KDE off Linux/*BSD has become a thing.

As far as I can tell, there’s two problems to this plan.

Problem one is the file wrangling. My photos will remain on my file server with its redundant 8 TB of storage, and the SQLite databases of digiKam are best kept locally. This means that it will need its own backup management. A simple path is using my Mac and its Time Machine destination for that. How well sharing digiKam’s database files across different systems, I’m not sure, but in any case the trend has been for me to prefer one set of muscle-memory.

Problem two is transient image management. See, most of what I do with images fall under two categories: either my master repo, or some pipeline stage denoted above; or ‘a directory full of stuff I want to peruse’. I’m not sure that digiKam really handles that perusal factor. One of the things that I liked about running Debian and FreeBSD on my laptops, was being able to throw geeqie at that problem. Although, it might be viable to just create a staging area and export things.

In any case, it’s looking like digiKam is probably the best non-proprietary solution for the photo management hoopla that doesn’t involve me writing code to scratch itches.

MicroSD cards

When I decided to grab a Steam Deck during the last sale, I opted to take advantage of the opportunity to get the 512 GB model rather than my default choice of the 256 GB. Overall this has worked out pretty well, since most of the games I’m more inclined to play laying in bed or sacrifice the power of 4 pounds of RTX for portability’s sake, on the whole tend to be on the smaller side. That is to say under 35 GB and often closer to under 10 GB.

On my Xbox One, aka Deathstar One, I’m used to the peasy 500 GB of storage being augmented by 3 to 4 TB of platter drives. Which made things a lot more roomy over the years as typical game sizes started to spring past 60 GB and toward 90 GB and beyond.

So much in the same way, the Steam Deck’s 512 GB of storage is rather small one you start loading larger games in the over 60 GB club. With about 200 GB of the 460-something GB capacity filled, I think this is a fair trade off between capacity and affordability. The 256 GB model, I suspect would feel pretty tight once you load modern “Big assed” video games on the device.

Effectively, I’m straddling the line between not having to care and needing to pay attention to what I install. For example a few more recent games the size of dual and quad layer Blu-ray discs, and I’d have cause to manage storage but for games measured in terms of CD-ROM or a few single or dual layer DVD, there’s enough capacity to be well stocked for a nice vacation.

I’ve been meaning to take a look at the cost of larger MicroSD cards since getting the ‘Deck. When I came across yet-another Best microSD Cards for Steam Deck article, I decided to take a gander since it would likely recommend larger cards. Then I realized a nice 512 GB microSD card cost about as much as the handful of 64 GB cards I bought a year or two ago, as a mixture of refitting vintage computers with non vintage SCSI/IDE drives and restocking my pool of memory cards for random Raspberries.

Racking up pretty nice results in Amorphous Disk Mark, I can’t help but think if SD slots weren’t as rare as they are, at these prices I’d start using the smaller sizes as modern floppy disks for those times I don’t feel like busting out my external NVMe to USB-C drive :D.

Yes, the 2018 iPad Pro has aged well


I’m inclined to agree with much of this. The 2018 model came into my group of hardware and started running circles around my other devices, particularly my third generation Core i5s.

Right now the only good reason I see to upgrade are support for secondary displays and perhaps thunderbolt. Features I desire in my tablet but that aren’t worth the price of a new iPad when everything else is dandy.

Well, if you discount that the base 64GB of storage is getting less roomer, the battery is aging, and I’m sometimes tempted by the idea of an cellular capable iPad. Those are all interesting points, but still sufficient for the time being 😛

Signs of getting old

Random things that make me feel like I’m getting old: having seen entire generations of hardware make the transition between hot, sexy, powerful computers and being the oldest equipment this side of a dumpster.

Also, it’s probably a good thing that I don’t have room for a server rack in my closet.

Having spent part of my day studying network captures that made me ask if a network attached blender was involved, I’m reminded of my awesome router.

About a decade ago, after a stream of typical home routers and much rage, I decided to buy an RT-AC68U. At about $242 and change it was like pulling teeth bare handed, to pay that much for a router. But it quickly became worth every penny when it achieved the level of more reliable than our ISP, like literally the neighborhood had network outages more often than there has been need to reboot the thing.
I reckon, if the savings in pain and suffering haven’t caused it to pay for itself yet, the whole reliable long lived service life thing has. One of my favorite equations for equipment is cost divided by age, by which that router has cost me about $24 and change per year. By contrast, the $65-$75 routers it replaced were only lasting a few years before they either failed or failed to cope with the ever increasing number of devices connected. Ahh, there is such a thing as a good router.

Rimuru Restoration – With a screwdriver, I stab at thee

Despite it only being only a few years old, motherboards compatible with Rimuru’s processor are largely gone and needless to say, my AsRock isn’t re-obtainable as far as local resources go. That’s been the sad trend IMHO, that yes, desktops are still pretty modular, no the parts won’t be worth a fart tomorrow. But alas, that’s a different issue.

Deciding that the motherboard is the root of the problem based on my multimeter readings and the screwed up power behavior, I debated two courses of action: decommission Rimuru in favor of a laptop, as it was already expected to be my last desktop build; or attempt to fix things with replacement parts. The upside of the later is that it is the minimal cost option, the former that it’s the less likely to piss me off.

Rimuru is now rocking an Asus motherboard a generation forward. A small fortune and the better part of my day later, everything seems to be operational. Fortunately, re-activating Windows licenses purchased from Microsoft’s own store are still not too terrible to deal with motherboard replacement.

In the process, I’ve also decided to ditch the humongous air cooler and get a liquid cooler, cue kraken, stage left. When I originally designed Rimuru, I had considered liquid cooling and decided to stick with what I know. Well, I decided if I was going to be replacing a motherboard, there was going to be something a lot smaller hovering over the processor getting int he way of my hands, or I was going to drive a spike through the board. So, liquid cooler it be.

Now if there was just a solution for the raging headache ^_^.