cybrnook

Sent! And thanks again, you are awesome to work with.

Thanks for getting to the bottom of it. How much was the disc, I will chip in to help $. Also, check the previous notes on the broken symlink and validate ldd if you don't mind.

That's what I am trying to figure out. You and I know we have a way to reproduce this issue, however, what do we need to provide to @Djoss that will be helpful to find the cause. Which logs, which dumps etc..... There is a few threads and responses online that point to the JAVA version that's installed, but of course, in our case we haven't proven that yet since we are in a docker container. Only Djoss would be able to test that on the Alpine build. Unless you or I try and install manually a newer v10 of Java inside our container directly, but I think that is a messy way.

I will go to the movie store and get Sicario this weekend, as posted before. I know this triggers the crash, and was also the same movie that caused @luisv 's crash as well. @Djoss if you have a movie rental store near you, you likely could reproduce the same, might be easier to collect logs. If not, let me know what i need to gather at the time it's happening, specifically.

Thanks, hopefully that helps get @Djoss a head start.

Can you share the protection they use?

Oh no.... I don't have that disc anymore. If you want, I can get it again this weekend if you're available.

You're not alone 🙂

@Djoss still no luck on the java issue? Hope all is well on your end.

Reinstalled your latest user scripts today, and the issue still comes back. This is the only plugin causing it for me on reboot (user scripts).

I saw this as well, and it was the user scripts plugin in my case.

Another user, stating upgrade to Java 10 fixed their issue. https://www.makemkv.com/forum/viewtopic.php?f=3&t=18134

Sure, but there is still a problem. This is a good disc to use to expose it.

Sicario: Day of the soldado If you have a movie store near you that rents.

Any luck?

I notice the same behavior 🙂 seems almost like "burps" of high CPU, then it goes back to %50 until it burps again.

That's how it's appearing. And seems that instead of copying, we could fix it by adding more PATH directories as well, though untested.

I think it's an Alpine Linux and Java related issue.

Nothing special, I am not as picky. I just use the default Fast 1080p 30fps as that's good enough for me.

Strange, I still see the same failure if I use MakeMKV to convert to mkv format. HOWEVER, that's not what I did last night. I use MakeMKV to "Backup" my disc's (whole disc, removing encryption), and then I use HandBrake to convert for me since it generates an equal quality video at a fraction of the size. Try "Backup", and see if that works now. If it does, use Handbrake to then encode it to mp4. (Chapter 354 I believe)

Looking at the playlist file you are parsing 00095.mpls, is it Sicario? I ran it last night, and it went fine after the change. Your errors almost look like a firewall type issue between your unraid server and elsewhere.

You have to be doing something wrong, your command shouldn't be interpreted as "sh" (I suspect your are trying to copy/paste the command?)..... /tmp # which cp /bin/cp /tmp # cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib /tmp # ls -l /lib/libjli.so -rwxr-xr-x 1 root root 55320 Jun 13 14:46 /lib/libjli.so /tmp # ldd /usr/bin/java /lib/ld-musl-x86_64.so.1 (0x149e9e174000) libjli.so => /lib/libjli.so (0x149e9dd64000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x149e9e174000) libz.so.1 => /lib/libz.so.1 (0x149e9db4d000) /tmp # And YES, the change does retain after a container restart 🙂