So the question is, is there any advantages (features/speed etc) to run Photostructure as a docker under Unraid or run it in a windows VM under Unraid.
I’m finally getting to sorting out my photos and get Photostructure up and running properly. I’m running Unraid, so I can set it up under docker, or I’ve got a Windows vm running under Unraid which will be running all the time, I just prefer to run some things on it. I’m ok with docker, but probably more familiar with running things in Windows. So I don’t know whether to run it in the windows vm or on docker.
Windows running as vm under unraid is one step more vs running directly on docker.
just use dokcer imo, it’s a more efficient way to manage your resources.
also I think you should go for the beta, the stable version is unusable for docker (couldn’t use an imported library created from a more powerfull machine and the sync is forever stuck, while the fix is to rescan all the library again, which is very wastefull on my dual core celeron).
tldr - go for docker, use beta because there is no eta to the next stable version!
Know that Windows, in general, has slower file I/O compared to Linux. There are a bunch of places in the PhotoStructure code base where I had to extend default timeouts for Windows or Raspberry Pi. RPi CPUs are 4-10x slower than (even 8-year-old) laptop or desktop CPUs. It’s a huge hit.
This can be “fixed” somewhat by excluding certain directories from your anti-virus software, but that’s not a great solution, and feels a bit unsafe as a general recommendation.
I’d use Docker or an Ubuntu VM running PhotoStructure for Node: you’ll get much more performance out of your current hardware.
Using PhotoStructure for Node means it’s much more convenient to add or remove drives (if you’re doing a big sweep through, say, boxes of old hard drives): just plug in new drives, leave PhotoStructure on “automatic” scanning, and it’ll find new drives and scan them as they’re plugged in.
v2.0-beta.1 is known to accidentally drop remote libraries on Docker: I do not recommend running that build on Docker, unless you explicitly set PS_FORCE_LOCAL_DB_REPLICA=false.
To avoid those kind of issues in the future, I bit the bullet and added Alpine to PhotoStructure’s continuous integration suite a couple weeks ago, and have been working through the issues that popped up in volume and system parsing. I’m much more confident that regressions like in v2.0-beta.1 will be avoided in the future (or at least prior regressions: no telling what new bugs are in store, but that’s why there are alpha and beta builds!)
Ah, ok, I’ll try the beta in docker. I was playing around with the docker version of the stable release and it just wasn’t working for me, that’s when I started thinking about whether it was easier to run on a vm. I have other dockers running fine, but as I don’t have as much experience with dockers, I thought it was purely me.
Awesome. Thank you, I must have missed that bit of doco about different versions. That’s exactly the kind of info I wanted.
I would rather it run under docker, and I would like to get the best performance out of it, so docker it is. Nice option for Ubuntu VM though.
I’m doing a slight clean up of my photos before getting Photostructure to look at them, so between the clean up process and Photostructure deduping and doing it’s thing, it should be looking nice after that.
As I’m not quite ready to import photos, I might wait till you push v2.1 alpha.
