[Support] Djoss - MakeMKV


Recommended Posts

29 minutes ago, cybrnook said:

You don't HAVE to buy a key. But in that case, if you do stick with the BETA key, you will have gaps in time where the current key expires, and Mike hasn't posted a new one yet. Normally about a week or two in between.

 

If you get tired of that, buy a key, then follow DJoss's instructions on changing from BETA key to UNSET and then add your key in the GUI.

yep - I worked that out yesterday when I did a few googles.  It's working again today, so the key's been updated.

Link to comment
31 minutes ago, luisv said:

Upgraded docker to the 1.12.3 and receiving this error today.   Any ideas?


kernel: makemkvcon[4276]: segfault at 8 ip 000000000060c65d sp 000014cf32b8beb0 error 4 in makemkvcon[400000+5db000]

 

 

Screen Shot 2018-10-02 at 7.06.26 PM.png

How did you get this error?

Link to comment
9 minutes ago, luisv said:

After the upgrade, I inserted a disk to rip and after 20 seconds or so, it errors out.  I ripped a disk successfully last week or so.  

 

 

Screen Shot 2018-10-02 at 7.37.45 PM.png

You were able to rip a disk last week, but not the same one as today, correct?

Are you able to rip other disks?

Do you remember which Docker image version you had before upgrading?

 

Link to comment

As luck would have it, it seems to be related to the new disk.  I grabbed a bunch of others that were succesful and they are working just fine.  Wierd, I've never had an issue like this before, so I assumed it was due to the upgrade.  Is there a way to run a previous version of the container?  Sorry, but I don't recall what version I was previously running.  

Link to comment
8 hours ago, luisv said:

As luck would have it, it seems to be related to the new disk.  I grabbed a bunch of others that were succesful and they are working just fine.  Wierd, I've never had an issue like this before, so I assumed it was due to the upgrade.  Is there a way to run a previous version of the container?  Sorry, but I don't recall what version I was previously running.  

You can use a specific version of the container by editing the Repository in container's settings.  Just append the version, like ":v1.9.4", to the repo.  So you should have something like "jlesage/makemkv:v1.9.4".

 

You could check on the official MakeMKV forum to see if other users have the same problem with the same disc.  It's possible that new discs cause issues.  Also, I saw that your disc requires Java.  Do you have other movies that required Java and had ripped successfully?

Link to comment

I checked the MakeMKV forums and I don't see any posts for this specific disc.  Sorry, but I don't recall if other discs have required Java or not as it usually works or works once the docker is updated.  I went back a few versions, stopped at v1.8.0 as all had the same issue / failure.  I'll keep my eye on the MakeMKV forums for any updates as it's a recently released disc, so others should have similar issues.  Thanks for your time!

Link to comment
19 hours ago, luisv said:

I checked the MakeMKV forums and I don't see any posts for this specific disc.  Sorry, but I don't recall if other discs have required Java or not as it usually works or works once the docker is updated.  I went back a few versions, stopped at v1.8.0 as all had the same issue / failure.  I'll keep my eye on the MakeMKV forums for any updates as it's a recently released disc, so others should have similar issues.  Thanks for your time!

Feel free to report the crash yourself on the official MakeMKV forum.

  • Like 1
Link to comment

@DJoss

 

Thanks for all your help, and patience with everyone in the forums. It is appreciated.

 

I just wanted to circle back on that UMASK for backup mode issue. I saw the commit update you did against the autoripper, nice job. I did want to point out that the container has the same issue when using Backup Disc from within the GUI itself, wasn't just using autoripper. Not sure if there is/was anything you can do about that.

Edited by cybrnook
Link to comment
3 hours ago, cybrnook said:

@DJoss

 

Thanks for all your help, and patience with everyone in the forums. It is appreciated.

 

I just wanted to circle back on that UMASK for backup mode issue. I saw the commit update you did against the autoripper, nice job. I did want to point out that the container has the same issue when using Backup Disc from within the GUI itself, wasn't just using autoripper. Not sure if there is/was anything you can do about that.

The fix should cover both.  Are you seeing the issue with the GUI?

  • Like 1
Link to comment

Haven't tested yet, hope to do so this weekend.

 

Didn't realize you were interfacing with the program itself through the setup scripts. I thought you were just appending into the standard app with additional functionality. Meaning autoripper would work, but GUI driven wouldn't.

 

Great news then! Thanks, and look forward to testing my friend. (Sorry for assuming)

Edited by cybrnook
Link to comment

Also seeing the java segfault:

 

image.thumb.png.f2c33bd53837a9cbc70b1cac4d4a3b6c.png

 

Other users seem to relate this to the JAVA version:

https://www.makemkv.com/forum/viewtopic.php?f=3&t=17268

 

I know unrelated, but there is a broken symlink in /usr/bin as well:

appletviewer -> ../lib/jvm/default-jvm/bin/appletviewer

 

Maybe this helps, perhaps a compile error? (https://github.com/docker-library/openjdk/issues/77):

/usr/bin # ldd java
        /lib/ld-musl-x86_64.so.1 (0x1483185c6000)
Error loading shared library libjli.so: No such file or directory (needed by java)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x1483185c6000)
Error relocating java: JLI_Launch: symbol not found
/usr/bin # whoami
root

CONFIRMED: This fixed the backup issue, and ripping works again - no segfault:

/usr/bin # cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib

/usr/bin # ldd java
        /lib/ld-musl-x86_64.so.1 (0x1479396b8000)
        libjli.so => /lib/libjli.so (0x1479392a8000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x1479396b8000)
        libz.so.1 => /lib/libz.so.1 (0x147939091000)

However, the more permanent fix I think is to add the proper path variables as suggested by "echa" in the link above.

Edited by cybrnook
Link to comment
13 minutes ago, luisv said:

 

Is that performed within the docker or docker properties?

Either option is going to be within the container os itself. I would recommend this for now:

 

CONFIRMED: This fixed it, and ripping works again - no segfault:

/usr/bin # cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib

 

I am not sure if it will be persistent through container reboots yet, haven't tried.

You can click on your container icon and there is a terminal option to get you there.

 

I wanted to submit a pr, but I think this will need to be handled in the base Alpine os that's being used for the container. So Djoss will need to get it.

Edited by cybrnook
Link to comment
2 minutes ago, cybrnook said:

Either option is going to be within the container os itself. I would recommend this for now:

 

CONFIRMED: This fixed it, and ripping works again - no segfault:

/usr/bin # cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib

 

I am not sure if it will be persistent through container reboots yet, haven't tried.

You can click on your container icon and there is a terminal option to get you there.

 

I get the following message, sorry, never tried console access for a container before.  

 

sh: /usr/bin: Permission denied

Link to comment
8 minutes ago, luisv said:

 

I get the following message, sorry, never tried console access for a container before.  

 

sh: /usr/bin: Permission denied

Sorry, type this command manually:

 

cp -p /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/jli/libjli.so /lib

 

Respect there is a space between libjli.so and /lib

Edited by cybrnook
Link to comment

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 🙂 

Edited by cybrnook
Link to comment

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)

Edited by cybrnook
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.