anarcatso i have this problem. i have something like 500GB of digital photos acccumulated over the years, and it got particularly bad when i got a fancy new Fuji X-T2 camera, gory details in https://anarc.at/hardware/camera/#disk-usage
(#nextcloud coming up, I promise. you asked a #streamofconsciousness #straightintomyveins and also a #blog post, so you'll have the first part, maybe the second if you're nice)
anyway. for reasons irrelevant here, life is busy and I haven't been able to do my normal photo processing for almost two years. latest photos in #darktable are from April 2021. complaining about it on #pixls did not work https://discuss.pixls.us/t/bulk-import-workflow-advice/33763
bulk import workflow advice
Hi there, long time no see! I have a problem: I have a huge backlog of photos (~18 months, ~3000 shots) I need to process. I’m not satisfied with my current workflow because it’s kind of bespoke and incomplete. Current workflow I take pictures on my phone and (much less than before) a Fuji X-T2 camera. I have about 1500 photos to process on each, so I guess an average of 100 a month. That doesn’t sound like much, but skip a few months and you’re kind of doomed… Anyways. The current workflow ...
i tried to fix that this morning, but #rapidphotodownloader almost bricked my laptop https://bugs.debian.org/1031557 so i reverted back to this bespoke hack, polished it a bit, imported all videos and all photos before 2022 https://gitlab.com/anarcat/scripts/-/blob/main/photos-import
not super happy with this: now i got a pile of unprocessed shit i just punted unto the "buy more hard drives" #zfs #yakshaving but the phone was getting full and I had to do something
so the plan is to have something where i can browse my gigantic photo collection without having it all present on the phone (or laptop, for that matter). some magic #cloud thing. and yes, #fuckgoogle and al, so #diy it must be. i have some experience with #nextcloud, so surely it can do something
installing #nextcloud *should* be easy. it's a frigging web #PHP web app, how hard can this be. kind of a lot, actually. https://nextcloud.com/install/ is not your friend: it talks about entreprise solution, one-click installs and a nightmarish maze of #containers they call AIO (for "all in one", pronounce "aaaooowwwouch")
that thing sets you up with a web server, redis, mysql (or is it #mariadb? is that still a thing? why not #percona! knock yourself out), some office thing (#collabora?), an imaginary thing (presumably not literal), backups and AV. the full mounty. that's the Way.
i had advice to install nextcloud straight from the tarball and manage from the commandline, but aarghl, i'm done with "upload this tarball to an FTP server", thank you very much
then i thought, surely there #mustbeabetterway! and then i found https://hub.docker.com/_/nextcloud which is what you get if you docker pull nextcloud
that thing is super confusing to me. it's called an "official docker image" yet it's not even mentioned in the #Nextcloud paraphernalia anywhere. but it's what I remember trying before, so that's what I'm going to try next
so there you have it, i have basically nothing still, just an idea: #nextcloud will serve my gigantic #gitannex repository from a read-only mount, maybe something to generate thumbnails automatically, trust that the #android app will do the right thing in managing storage and call it a day. photos sync'd out of the phone by #syncthing (already done), moved into gitannex by my bespoke stuff (or #phockup?), and hope for the best
this will fail in interesting ways, to say the least, and i'll leave you hanging there waiting to see the result, which will come on someone else's blog before me I hope, I'd love to not do that work for you #lazyweb
oh and before #unix #graybeards come hunting me down with figurative fork()s, yeah, i'm using #containers, #sueme and before you start packaging #nextcloud make sure you catch up with the latest shitshow which was https://bugs.debian.org/816376 (https://bugs.debian.org/835086 is a little less depressing)
ah, that's partly because i use the apache container, the :fpm one is smaller. i can't make the auto installer work, looks like the environment variables don't pick up. next up is external storage.
external storage needs to actually index all those files in batch, so that's another job i need to slap on top. worse: this thing runs as the www-data user and i have so far kept that wildcard user out of my photos for obvious privacy reasons, so i'll have to make a rootless container here, #podman to the rescue...
but the killer #nextcloud #wtf is that it spends all this time indexing those photos but doesn't actually parse EXIF data: all photos are dated from the import date, not the shoot date (!!) "Nextcloud does not read photo metadata" according to https://rayagainstthemachine.net/linux%20administration/nextcloud-photos/ unbelievable i guess next up is #photoprism
epic. #nextcloud just doesn't parse EXIF data in photos. https://github.com/nextcloud/photos/issues/87
Sander Meijer@Anarcat for photos Nextcloud is a disaster (and I say this as Nextcloud Fan Boy). @photoprism is your tool instead.
Free Pietje 🇵🇸 🍉@Anarcat
3 years in and the issue is still open 👀 ... for what I'd consider the most basic thing in a photo app 🙄
On the bright side, I now know I won't have to spend time on evaluating nextcloud. It's apparently the same freaking mess it was 7 years ago.
Only with 5x system requirements.
I too often see 'Docker container' as a strong indication that they couldn't do things properly/normally and thus an architectural deficiency.
Their previous hostility was another red flag.
i ended up killing the scan after 15 minutes. it had scanned 112298 files and 103298 folders which is... "interesting" because there's actually only about 30000 photos in there, not sure how it added up to three times that. also not sure why it took 15 minutes to iterate over a directory that `find` iterates over in a few seconds (and it wasn't done). #nextcloud out
zhenech@Anarcat then don't look at the individual layers too closely ;-)
@Anarcat something that changed compared to 2016 (and the earlier attempt with owncloud) is that we now have fasttrack.d.n. It works for Gitlab, and would be a fine fit for nextcloud as well