1.0.0-beta.5 (small bugfix)

Only one bugfix from beta.4:

:bug: 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',
     id: 63687,
     queueId: 15,
     type: 'image' },
   { name: 'Error',
      [ '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

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.

1 Like

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  \

I no longer have the logs, btw the button at the end of the menu “Send us your recent logs” for me fails consistently.


Sorry about that! My error reporting service changed their API which means the error reporting service is now a source for errors. :dancer: