chrrs / camerapture

Fabric mod with cameras that can take pictures!
https://modrinth.com/mod/camerapture
MIT License
4 stars 1 forks source link

Pictures not being saved #15

Closed k2helix closed 5 months ago

k2helix commented 5 months ago

What's the issue?

When taking a picture with the camera, a paper is consumed but no picture appears in inventory or is dropped on the ground. Nothing remarkable in the client logs, but the server logs this:

pool-16-thread-9/ERROR]: Uncaught exception in thread "pool-16-thread-9"
mc-1  | java.lang.UnsatisfiedLinkError: 'long com.luciad.imageio.webp.WebPDecoderOptions.createDecoderOptions()'
mc-1  |     at com.luciad.imageio.webp.WebPDecoderOptions.createDecoderOptions(Native Method) ~[io_github_darkxanter_webp-imageio-0.3.2-e4e37d5606a8f057.jar:?]
mc-1  |     at com.luciad.imageio.webp.WebPDecoderOptions.<init>(WebPDecoderOptions.java:26) ~[io_github_darkxanter_webp-imageio-0.3.2-e4e37d5606a8f057.jar:?]
mc-1  |     at com.luciad.imageio.webp.WebPReadParam.<init>(WebPReadParam.java:24) ~[io_github_darkxanter_webp-imageio-0.3.2-e4e37d5606a8f057.jar:?]
mc-1  |     at com.luciad.imageio.webp.WebPReader.getDefaultReadParam(WebPReader.java:147) ~[io_github_darkxanter_webp-imageio-0.3.2-e4e37d5606a8f057.jar:?]
mc-1  |     at javax.imageio.ImageIO.read(Unknown Source) ~[?:?]
mc-1  |     at javax.imageio.ImageIO.read(Unknown Source) ~[?:?]
mc-1  |     at me.chrr.camerapture.picture.ServerPictureStore.put(ServerPictureStore.java:64) ~[Camerapture-1.3.1+mc1.20.1.jar:?]
mc-1  |     at me.chrr.camerapture.Camerapture.lambda$registerPackets$4(Camerapture.java:179) ~[Camerapture-1.3.1+mc1.20.1.jar:?]
mc-1  |     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
mc-1  |     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
mc-1  |     at java.lang.Thread.run(Unknown Source) ~[?:?]

I have looked for any other issues similar to this one and I think that it could be caused by the C2ME mod. I'm unable to test without it right now as the server is running for many people but would be able to do it in another one with the same mods.

Screenshots

No response

Mod and Minecraft version

1.3.1, Fabric for 1.20.1

chrrs commented 5 months ago

Huh, that's an interesting problem, looks like it doesn't load a native library. I don't think it has to do with C2ME. What are you running the server on? Are you running it yourself, or through a server host? Also, maybe a weird question, if you don't know it's fine, but do you know the OS and architecture of the server?

k2helix commented 5 months ago

I have managed to solve it partially. Here's how I did it.

My server runs on a virtual machine using a docker container, and has a data folder where I put the corresponding Minecraft folder (e.g. mods, config). Here's where I noticed this issue.

Today, I wanted to reproduce it on my machine, where I first tested the server some days before definitely uploading it to the virtual machine using the same docker image. So I put the same exact mods (with the same versions) and world in the data folder of my machine, but not config as I didn't find that necessary.

Surprisingly, it worked, with the only difference that Camerapture's config was not the same (it was not the same because when I first tested the server I was using an older version of Camerapture, probably 1.3.0, but some days ago I updated it directly on the VM which seems to have edited the file)

So I tried copying Camerapture's config from the VM to my machine, and as expected the same error happened. And doing the same but from my machine to the VM solved it.

Basically, what I did was changing this

{
  "version": 3,
  "max_image_bytes": 200000,
  "max_image_resolution": 1280,
  "ms_per_picture": 50,
  "can_rotate_pictures": true,
  "check_frame_position": false
}

to this

{
  "version": 1,
  "max_image_bytes": 200000,
  "max_image_resolution": 1280
}

Which seems to be the config of the older version which I first used on my machine when testing the server, but that got changed when updating the mod directly on the VM.

However, Camerapture automatically edits the config file to match the newer version, which is a problem because when the server restarts it's going to use that config that causes the problem.

Why does the config cause/solve this issue? No idea. Hope this can be useful for you.

k2helix commented 5 months ago

The VM runs Ubuntu 22.04.4 LTS aarch64, and my machine Debian GNU/Linux 12 (bookworm) aarch64

chrrs commented 5 months ago

Hmm. I couldn't recreate the problem on Linux on my own PC, and I've also never seen it on a server I run. More testing needed I guess..

It's weird that the config thing fixes it for a moment, since it's a whole separate system. It shouldn't matter, as when it's an older version, it just uses default values for the missing fields, and the two configs effectively are exactly the same.

The check on the server side is optional, so if all else fails, I can hide it behind a config option as a workaround.

Thank you for being so detailed! I'll see if I can hopefully find the issue.

k2helix commented 5 months ago

Thanks for your answer! I can try to reproduce it on a docker container only with this mod, and if I'm able to do it I can share the docker compose file so you'd be able to run the same exact container.

k2helix commented 5 months ago

I managed to reproduce the issue, but now for some reason the workaround (tweaking the config) stopped working. This time, as only Camerapture was included, I was able to see that it logs some lines saying that it cannot load a library when starting the server. Here are the full logs of the server starting and me taking a photo: https://mclo.gs/YseQS1c

It seems that it has to do with GLIBC version, but I'm not sure how to handle that as it's a docker container. I checked the GLIBC version on my machine and it is 2.36, but on the container (running docker exec -i mc-mc-1 ldd --version ) it returned ldd (Ubuntu GLIBC 2.31-0ubuntu9.16) 2.31

If it's that what's causing the issue, I think I should probably report it to the docker image maintainer. I don't know if there's anything that can be done on Camerapture's side.

If you want to test it and see if you can reproduce it, you'll need to install docker (which you can uninstall after doing this). I'm using this docker-compose.yml file:

services:
  mc:
    image: itzg/minecraft-server:java17
    ports:
      - "25565:25565"
    environment:
      EULA: "TRUE"
      TYPE: "FABRIC"
      VERSION: "1.20.1"
      INIT_MEMORY: 5600M
      MAX_MEMORY: 5600M
      USE_AIKAR_FLAGS: "TRUE"
      GUI: "FALSE"
      OVERRIDE_SERVER_PROPERTIES: "FALSE"
      DUMP_SERVER_PROPERTIES: "TRUE"
      ENABLE_AUTOPAUSE: "FALSE"
      AUTOPAUSE_TIMEOUT_EST: "1800"
      AUTOPAUSE_TIMEOUT_INIT: "450"
      RCON_PASSWORD: "same password as in server.properties"
    restart: unless-stopped
    dns:
      - 8.8.8.8
      - 4.4.4.4

    volumes:
      - ./data:/data

Here's how the folder tree should look:

.
└── mc/
    ├── docker-compose.yml
    └── data/
        ├── mods/
        │   ├── fabric-api
        │   └── camerapture
        ├── server.properties
        └── other files and folders that minecraft will create

Once you have all that set, you have to download the image by running docker compose pull in the folder where docker-compose.yml is. Then, docker compose up -d will start the container for the first time (if it doesn't work try docker compose restart). To access the logs, simply run docker compose logs -f.

In addition, in order to run minecraft commands (to make yourself op, for example), you have to enable rcon and set its password in server.properties, then run docker exec -i mc-mc-1 rcon-cli (replace mc-mc-1 with the name of the container, which you can see using docker ps).

k2helix commented 5 months ago

I have just tested on a x86_64 computer, and it works fine there. It is definitely related to the architecture (aarch64) and it not being able to find a suitable glibc version.

chrrs commented 5 months ago

Ah yeah, you got it exactly. Looks like the image the docker container is using uses an incompatible version of glibc to the one that the WebP library was compiled against. The minecraft-server docker image is based on Ubuntu 20.04, which has a slightly outdated version I think. As you've already found out, not much i can do to fix that. I did test using Docker in the meantime, but all computers I have are x86_64, which work fine.

Since the server check is kind of flawed anyway, I'll remove it in the next version, as it's not really necessary either.

chrrs commented 5 months ago

I've released 1.4.0 which removes the server check, so it should work now!

k2helix commented 5 months ago

Thanks, it works now! But I don't understand what you did to solve it. You removed the server check of this library and now it works without it? I mean, is the library required in the first place?

chrrs commented 5 months ago

I'm using a library to read and write webp files, mostly on the client side. The server side basically just accepts the image bytes, and passes them through to other clients. I did have a small sanity check on the server side, just to check if it's actually an image or not, which is the only part where this library was used on the server. That's the check I removed, which makes the server work without it.

It's a workaround for sure, but it's the best fix I can do right now. Theoretically, this issue can also exist on the client, but it's very specific to linux that hasn't had an update for a while, and since you don't run your Minecraft client in Docker (i hope at least), it doesn't really happen.

k2helix commented 5 months ago

I see, thanks for explaining. I definitely don't run (and don't want to) my Minecraft client in Docker 😆