Jump to content
Djoss

[Support] Djoss - MakeMKV

450 posts in this topic Last Reply

Recommended Posts

1 minute ago, hawihoney said:

My mapping is docker=/storage equals perl=/mnt. The perl script populates e.g. "/mnt/disk1/folder". So I do have to replace /mnt by /storage within the makemkvcon command giving e.g. "/storage/disk1/folder". Right?

Correct!

Share this post


Link to post

It should be possible.  Just edit the existing mapping in container's settings (or delete the existing one and add a new one).

Share this post


Link to post

im searching for a docker which can automaticly scan a folder /movies/*/* for .img files and convert them to .mkv can i do this with this docker, or anyone know a docker which can do that?

Share this post


Link to post
3 hours ago, nuhll said:

im searching for a docker which can automaticly scan a folder /movies/*/* for .img files and convert them to .mkv can i do this with this docker, or anyone know a docker which can do that?

Do you want to convert/compress/re-encode the videos?  If yes, then you may be better with Handbrake:

 

 

Share this post


Link to post

I just want downloaded material which is in .img to get converted so plex can read it. How to automate handbrake?

Share this post


Link to post

Handbrake docker container has an automatic video converter.  Basically, it watches for files in a specific folder.  Everything you copy inside that folder will be automatically converted using the configured preset and written to the output folder.

Share this post


Link to post

Hey Djoss,

Great App! I've been using this for awhile now. I'm not sure if this happened after the last update, but noticed yesterday makemkv can't see my dvd drive any longer. I tried restarting the server itself and the reinstalled the docker and added the --device /dev/srv0 as well and deleted the appdata folder asa well. In the docker logs makemkv says it can't see the optical drive drive. I confirmed from the CLI that UNRAID could see the dvd drive using lsscsi.

 

Any other thoughts on what the issue could be or other troubleshooting?

Share this post


Link to post

Yes it seems there is an issue with the latest MakeMKV version.  Other users (not using container) are complaining on their forum...

 

You can force using the previous version by editing the container settings and changing the Repository to "jlesage/makemkv:v1.5.1".

Share this post


Link to post

Just came here to note the same.

 

EDIT: AND Drive is detected again :-)    I assume when an update comes out to fix this, you will update the main repo and have us set it back to jlesage/makemkv ?

Edited by cybrnook

Share this post


Link to post

@Djoss I dropped back to your jlesage/makemkv:v1.5.1 and that let me downgrade so my Asus USB Blu-ray was detected again. I am getting an "update" notification now for your Docker on the 1.51 branch, is this correct?

Share this post


Link to post
On 12/01/2018 at 4:23 PM, cybrnook said:

I assume when an update comes out to fix this, you will update the main repo and have us set it back to jlesage/makemkv ?

Exactly!  And if the update takes too long to come out, I may update the main image with the previous working version of MakeMKV instead.

 

10 hours ago, cybrnook said:

I am getting an "update" notification now for your Docker on the 1.51 branch, is this correct?

Yeah it seem to have a glitch when a repository tag is used.  So just ignore the update.

If you update, the same version will be re-installed...

Share this post


Link to post
On 19/01/2018 at 6:38 PM, cybrnook said:

Might as well set your main image to 8.

Let's wait again.  At least there is a way for people to use a specific container version as workaround.

I doubt that the author of MakeMKV will ignore this bug with all the people complaining...!

Share this post


Link to post
On 1/20/2018 at 9:06 PM, Djoss said:

Let's wait again.  At least there is a way for people to use a specific container version as workaround.

I doubt that the author of MakeMKV will ignore this bug with all the people complaining...!

See you making progress in there. Seems the root cause was nailed down today :-)

Share this post


Link to post

Yeah, but still no comment from Mike about why the behavior changed and if we should expect any change from his side.

 

At least there is a fix/workaround that can be implemented if the detection mechanism used by MakeMKV doesn't revert to the original one.

Share this post


Link to post

I trust/hope now that the ground work is laid out, he will have a quick one liner in the 11 release "adjusted permissions for linux builds".

 

What are you doing to work around it? Are you just passing an additional --device in the gui, or are you adjusting a script within your container?

Edited by cybrnook

Share this post


Link to post
1 hour ago, cybrnook said:

I trust/hope now that the ground work is laid out, he will have a quick one liner in the 11 release "adjusted permissions for linux builds".

 

What are you doing to work around it? Are you just passing an additional --device in the gui, or are you adjusting a script within your container?

 

From 1.10.8 you need the /dev/sg* device. He also said you should pass through the /dev/sr* device as it will impact performance to not have it. I have not seen any perfomance issues though with only /dev/sg* passed through.

But in this container @Djoss made it so you do need it passed through. Probably for auto-ripping.

 

So the solution forward is to pass through both devices.

Share this post


Link to post

With the latest updated (that should be available in a couple of minutes), I updated the way optical drives are detected and devices that need to be exposed are indicated in the log.

 

As indicated by the author of MakeMKV, it is recommend to expose both  /dev/sr* and /dev/sg* devices to the container.  But if for some reason you only want to expose /dev/sg*, it is now possible.

Share this post


Link to post

Are we literally wild carding the third character (sr*, sg*), or is the * representation just an example, users still need to identify the numeric value for their device, then pass it through?

Share this post


Link to post
3 minutes ago, cybrnook said:

Are we literally wild carding the third character (sr*, sg*), or is the * representation just an example, users still need to identify the numeric value for their device, then pass it through?

Yes you need to find the correct values to use.

 

Just look at the container's log to see which ones are needed.

Share this post


Link to post

:-)

image.thumb.png.8d932717dc783b98a067baae05de95e8.png

 

Is there a way to comma separate the --device string? I just did --device /dev/sr0 --device /dev/sg1    thinking maybe I can --device /dev/sr0:/dev/sg1  ?

 

@Djoss thanks for the log hint, made it a breeze :-)

Share this post


Link to post

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.