Got it. Right. I went to redeploy the stack and realised I missed the error. I’ve gone very wrong with the bits I need to change.
Where the script states to CHANGE THIS, I did, but I’m getting it wrong, I’m just not used to the format of file paths, and how it knows where even the file path is. Do I need to create the folders in advance on the NAS or does the script create them?
In simple terms, I just want (for now at least!) to have 1 folder in my ‘Public’ share (was auto created) to be ‘Photos’. this is where I want all of the Photostructure stuff, inc a fresh, deduced COPY of the photos and videos I want. I have a store of the photos and videos in the same Public share, under a temp folder atm.
I’m just not sure how to get it to know the locations are in the public share on the NAS, and to get everything needed in that folder above?
paths are case-sensitive on QNAP (being a linux based system). If you know how to shell/ssh into your NAS, it’s probably the best way to validate paths. Meanwhile, try /DataVol1/Public/Photos see if it makes it all better.
Sorted that now it looks like that you, would never have found out the proper name!
Now trying to figure out why it can’t find the path for ${HOME} in the script, I can’t see any where on there where ${HOME} is matched upto anything which feels odd, but again I’m not well versed on it.
I think those instructions might be a bit incomplete. A docker container can’t see anything outside of its sandbox unless you map it, so you need to bind mount TWO folders at a minimum.
#1 for the Photostructure library - that’s where PS will store its data. So /ps/library should be mapped to somewhere that is exclusively for photostructure to work in. For example, /DataVol1/Public/Photostructure.
#2 where your photos you want PS to scan. A container can’t see anything outside of its sandbox, you have to explicitely mount it. So you may mount /DataVol1/Public/Photos to /media inside the container.
Amazing!! thats awesome of you, and to be honest, I’m glad it will help others in my position
I’ve now managed to ‘sort of’ get it working thanks to that… I dumped a test photo into the binder media dir on the NAS, and I can see PhotoStructure has pulled it in and placed it into a dated folder as specified (told it to copy). However… there is no photo displayed in the actual photostructure app, which is odd I’d say! maybe its a alpha issue which is possible I guess…?
OK, progress. Progress is good. I am not seeing anything too alarming in the log… In fact the log shows the pic was processed successfully all the way through. but @mrm would definitely be better at looking at that.
It is odd that the status on sync is “new” … can you do a “restart sync” (from the sidebar menu) and/or restart the container.
Try dropping a few pictures in there to test.
Lastly, take a look at the sync-reports to see if the pic was skipped, although again the log does not show that it was.
I did the sync restart this time and got an sql error, ooooh - but I will say, on the previous container (I’ve re-created it a few times to see if an error on my end/glitch) I did the same restart sync and got no error, at least that I noticed from the dashboard.
yes, indeed. The dreaded SQLITE errors. I’d like to say those are just alpha issues, but I was experiencing those with prior releases as well. All I can say is that setting PS_FORCE_LOCAL_DB_REPLICA to false was helpful for me on prior releases, although I can’t explain why. Now you’re definitely in @mrm territory for assistance with this.
{"ts":1657802602992,"l":"warn","ctx":"express.ServerToastHelpers","msg":"sendServerToast()","meta":{"requestedURI":{"$mid":1,"path":"/api/system","scheme":"http","authority":"192.168.1.230:1787"},"toast":{"text":"Well, darn, that didn't work","uuid":"SqliteError: SQLITE_CORRUPT: database disk image is malformed","details":"SqliteError: SQLITE_CORRUPT: database disk image is malformed","type":"warning","button1Text":"Return home","button1Url":"/tag#dismiss","button1Class":"info","onClickUrl":"#dismiss"},"httpStatusCode":500}}