Docker - Covers will not apply (automatically or manually

[Kalidibus]

Using docker image with version 0.5.4.0. Host system is Manjaro Linux (Arch base) on an older home server.

Installed with:

docker run --name kavita -p 5000:5000 -v /home/gyjo/Storage4TB/Manga/:/manga -v /home/gyjo/Storage4TB/Manga/kavitaconfig/:/kavita/config --restart unless-stopped -d kizaing/kavita:latest

Everything works fine except every time I run "Refresh Covers" it hangs at 0% completion, and if I try to click on a page like "Home" or a library, it seems to crash the docker container and restart it. Covers don't get applied. Manually attempting to add a cover also crashes the container. All other settings, logs, cache seems to write to the disk normally.

I have tried the following:

• reinstalling with clean config folder
• restarting docker containers
• restarting server
• chmod -R 777 config folder
• chmod -R 777 Manga folder
• changing location of config folder to different drive

No changes

[mastervol]

This seems somehow similar to my experience: #1413.
Although I am not using docker.

[majora2007]

Any chances your CPU doesn't support AVX? We have a hard requirement with that (due to one of our downstream libraries) and that will cause the situation you're expecting (the crash from image manipulation).

[Kalidibus]

Yes, after posting this issue I learned of that requirement. It's unfortunate as all other self hosted applications I use work fine (including komga which generates covers no problem) and since home servers often have older hardware I imagine I'm not the only one who's run into this issue.

[majora2007]

You are in fact not the only one, but not too many have hit this wall since I started the project, less than 10 people. I haven't spent much time delving into which of the downstream libraries is actually creating the requirement (also because I have no way to test it).

Sorry that we are unable to be a solution for you. Maybe you or another user could help us identify the problematic library and we can fix it once and for all.

[Kalidibus]

If there's anything I can do to help test I'm happy to. I love the project and would love to be able to use it, so don't mind putting some work in for that.

[kleisauke]

@Kalidibus What's your CPU? NetVips has a minimum CPU requirement that applies only to Linux x64 and Linux ARMv7. The AVX and AVX2 instruction sets aren't a hard requirement.

[Kalidibus]

It is an AMD A6-3650

[kleisauke]

It looks like your CPU doesn't support SSE4.2, which is required by the prebuilt binaries for Linux x64 provided by NetVips - see:
kleisauke/net-vips#176 (comment)

As a workaround, you could install libvips via the package manager, compile it yourself, or downgrade to NetVips.Native 8.10.5.1. Note that there are probably more distros/packages that would increase the x86-64 platform requirement to x86-64-v2, which isn't supported by this CPU.

[Kalidibus]

Looks like the package for my distro is libvips 8.13.0-1.

I'm installing it now via the Arch (Manjaro) package manager, but assuming that doesn't work I can compile it myself and see how that goes.

@majora2007 sorry to bother you, but would I need to do anything to point Kavita to the distro package, or self compiled version of libvips? Or does it check for package manager versions before using the bundled binary?

[majora2007]

@kleisauke How does the loading work? By default, I'm packaging NetVips.Native with my self-contained code, but if the user has a different version installed, would it prioritize that?

[Kalidibus]

No change in behaviour from simply installing package manager version

Forgot I was using docker. I'll need to figure out how to change that inside the container.

[kleisauke]

I think(?), the easiest way is to delete libvips.so.42 in the directory where the Kavita executable is located.

$ vips -v
vips-8.14.0
$ ldd /usr/bin/vips | grep libvips
	libvips.so.42 => /lib64/libvips.so.42 (0x00007f9ee2ec7000)
$ curl -sL https://github.com/Kareadita/Kavita/releases/download/v0.5.4.2/kavita-linux-x64.tar.gz | tar xzC .
$ cd Kavita
$ chmod +x ./Kavita
$ rm libvips.so.42
$ LD_DEBUG=libs ./Kavita |& grep 'libvips.so.42'
      6173:	find library=libvips.so.42.so [0]; searching
      6173:	  trying file=/lib64/libvips.so.42.so
      6173:	  trying file=/usr/lib64/libvips.so.42.so
      6173:	find library=liblibvips.so.42.so [0]; searching
      6173:	  trying file=/lib64/liblibvips.so.42.so
      6173:	  trying file=/usr/lib64/liblibvips.so.42.so
      6173:	find library=libvips.so.42 [0]; searching
      6173:	  trying file=/lib64/libvips.so.42
      6173:	calling init: /lib64/libvips.so.42

This ensures that the libvips library from LD_LIBRARY_PATH is loaded (if you've installed libvips in a non-standard path) or from the default paths (/lib{,64} or /usr/lib{,64}) rather than from the RPATH (which has a higher priority than LD_LIBRARY_PATH).

[Kalidibus]

I think(?), the easiest way is to delete libvips.so.42 in the directory where the Kavita executable is located.

Wild, this actually worked I think. I was able to set a cover image manually just now. Every other time I tried the container would crash.

Here's what I had to do in order (since I'm using a docker container):

docker exec -it kavita sh to enter the container
apt update to update the apt package list
apt-get install libvips --no-install-recommends to install libvips(42), without 500MB of recommended packages
rm libvips.so.42 to remove the precompiled version

docker stop kavita
docker start kavita Restarted container for good measure. Maybe not necessary.

I'll try messing around with it some more, but so far so good, thank you all!

edit: Just added a new series, and it immediately grabbed the automatic covers perfectly!

[majora2007]

@kleisauke Thank you so much for jumping on and providing support. This is a huge break through for an issue that has plagued me since day 1.

[majora2007]

The team is looking into modifying the docker image to handle support for this automatically. This will be trailed post v0.5.5.

[majora2007]

@Kizaing please move ahead with trialing this in our docker containers for v0.5.6 (nightly)

[Kalidibus]

docker exec -it kavita sh to enter the container apt update to update the apt package list apt-get install libvips --no-install-recommends to install libvips(42), without 500MB of recommended packages rm libvips.so.42 to remove the precompiled version

docker stop kavita docker start kavita Restarted container for good measure. Maybe not necessary.

Just wanted to mention that this issue is still present as of 0.6.1.0 and that these workaround steps still work.

[GlacierFox]

Just tried this work around on a bare metal RHEL 8 install with an old AMD processor. Installed the vips packages from the Remi repository and everything seems to be working fine now. I was getting crashes when generating thumbnails before.

[prosthetichead]

Left a comment on the pull request attached to this issue here #1479 (comment).

This is still a issue and the work around still needs to be applied to the docker image on older cpus after pulls.