Only one bugfix from beta.4:
Fixed asset info panel dropdowns
Installation instructions are here:
Note that Iāll be offline for the next several days:
Only one bugfix from beta.4:
Fixed asset info panel dropdowns
Installation instructions are here:
Note that Iāll be offline for the next several days:
Guh, at least for my local docker-powered library, the bug isnāt fixed (Iād reproduced it on my own library running node, changed the dropdown slot rendering, rebuilt, and it worked, honest, so⦠thereās something else going on here). Iāll fix this next week.
Seems like another issue with beta.5 docker image:
2021-06-10T21:12:55.603Z sync-9427 warn WorkQueue(afq:psfile://QGNKQQA5y/) handleError() { qi:
{ '$ctor': 'stats.QueueItem',
contents:
'/var/photos/archive/XXXXXXXX/IMGP4294.JPG',
id: 63687,
queueId: 15,
type: 'image' },
err:
{ name: 'Error',
stack:
[ 'Error: invalid file /var/photos/archive/XXXXXXXX/IMGP4294.JPG: code ENOENT: spawn /ps/app/tools/linux-x64/jpegtran/jpegtran ENOENTā¶Ā³Ā²',
' at Object.t.asError (/ps/app/bin/sync.js:9:566594)',
' at F.processItem (/ps/app/bin/sync.js:9:747481)',
' at runMicrotasks (<anonymous>)',
' at runNextTicks (node:internal/process/task_queues:61:5)',
' at processTimers (node:internal/timers:497:9)' ] } }
Iāve checked manually, and while the file is there, it refuses to run, and image does not have dev tools like ldd lying around to try and figure out what is the cause of this
Sorry, posted to the wrong thread: 1.0.0-beta.4 is ready! - #16 by adept and two messages before that
Ok, looks like /ps/app/tools/linux-x64/jpegtran/jpegtran is built with gnu libc:
# strings jpegtran | grep ld
/lib64/ld-linux-x86-64.so.2
I see only musl dynamic linker in the image, and not /lib64 at all:
# ls -l /lib/ld-musl-x86_64.so.1
-rwxr-xr-x 1 root root 604736 Jun 7 09:40 /lib/ld-musl-x86_64.so.1
Unsurprisingly, musl linker cant dynlink jpegtran:
# /lib/ld-musl-x86_64.so.1 jpegtran
Error relocating jpegtran: __fprintf_chk: symbol not found
Error relocating jpegtran: __sprintf_chk: symbol not found
Looks like same issue is present in beta.4 image as well
In beta.3, jpegtran is located in /usr/bin/jpegtran and works perfectly fine.
My host (though i suspect that it is not really important apart from host os being linux):
Linux 4.4.59+ #23824 SMP PREEMPT Fri Oct 26 18:34:30 CST 2018 x86_64 GNU/Linux
Iām hitting the same problem, thanks for the analysis.
Yes, @mrm suspected that was the problem
@adept @venza @avdp thanks for the analysis! Turns out my .dockerignore lost the tools line, so this was literally a one-liner fix. I shipped it with beta.6.
Hello,
With beta.7 the import process works with the Docker image, but only if the volume is read-write.
If I add the ā:roā at the end of the -v docker option, PhotoStructure will run the import without any obvious error, but there are no thumbnails and nothing is imported.
Note: my volume is actually an NFS volume mounted in /mnt/photo on the host, in Docker I add a subdirectory as a volume for the container (-> /mnt/photo/Root)
Is this adding :ro to a bind mount that you want to import? (/ps/library needs to be read/write, of course).
I canāt think why scanning the directory in readonly mode would make the import work. If you want to share logs, I can take a look at whatās going on.
Iām sorry, I was not clear. By volume I meant the volume where I store my pictures, not the library.
docker run \
--name photostructure \
--detach \
--restart on-failure \
--stop-timeout 120 \
--publish 1787:1787 \
-e TZ="$(cat /etc/timezone)" \
-v "$PSLIBRARY":/ps/library \
-v "$PSTMP":/ps/tmp \
-v "$PSCONFIG":/ps/config \
-v "$PSLOGS":/ps/logs \
-e PS_LOG_LEVEL=info \
-e PS_TAIL_LOGS=1 \
-v "/mnt/photo/Root:/pictures" # <-- ADD :ro TO THIS LINE AND THE IMPORT FAILS \
photostructure/server:beta
I no longer have the logs, btw the button at the end of the menu āSend us your recent logsā for me fails consistently.
Best,
Daniele
Sorry about that! My error reporting service changed their API which means the error reporting service is now a source for errors. ![]()