[Support] Djoss - MakeMKV


Recommended Posts

  • 3 weeks later...
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:

 

 

  • Like 1
Link to comment

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.

Link to comment

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?

Link to comment

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".

  • Like 1
Link to comment
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...

  • Like 1
Link to comment
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...!

  • Like 1
Link to comment
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 :-)

Link to comment

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.

Link to comment

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
Link to comment
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.

Link to comment

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.

Link to comment
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.

  • Like 1
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.