Djoss Posted December 20, 2017 Author Share Posted December 20, 2017 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! Quote Link to comment
hawihoney Posted December 20, 2017 Share Posted December 20, 2017 You are my hero. I usually would try to add a r/w path "Mnt" with "/mnt=/mnt" but I bet this is not possible? Quote Link to comment
Djoss Posted December 20, 2017 Author Share Posted December 20, 2017 It should be possible. Just edit the existing mapping in container's settings (or delete the existing one and add a new one). Quote Link to comment
NewDisplayName Posted January 6, 2018 Share Posted January 6, 2018 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? Quote Link to comment
Djoss Posted January 7, 2018 Author Share Posted January 7, 2018 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: 1 Quote Link to comment
NewDisplayName Posted January 7, 2018 Share Posted January 7, 2018 I just want downloaded material which is in .img to get converted so plex can read it. How to automate handbrake? Quote Link to comment
Djoss Posted January 7, 2018 Author Share Posted January 7, 2018 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. Quote Link to comment
ppunraid Posted January 12, 2018 Share Posted January 12, 2018 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? Quote Link to comment
Djoss Posted January 12, 2018 Author Share Posted January 12, 2018 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". 1 Quote Link to comment
cybrnook Posted January 12, 2018 Share Posted January 12, 2018 (edited) 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 January 12, 2018 by cybrnook Quote Link to comment
ppunraid Posted January 12, 2018 Share Posted January 12, 2018 Sweet! That worked! Quote Link to comment
cybrnook Posted January 13, 2018 Share Posted January 13, 2018 @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? Quote Link to comment
ppunraid Posted January 13, 2018 Share Posted January 13, 2018 I highly doubt it.I got the notification just as soon as I reverted to 1.5.1 Quote Link to comment
cybrnook Posted January 13, 2018 Share Posted January 13, 2018 Yep, will just hang back and watch the makemkv thread where DJoss is at: https://www.makemkv.com/forum2/viewtopic.php?f=3&t=16939&sid=eed59b6f6bddfb826995145685a6adc1 Quote Link to comment
Djoss Posted January 14, 2018 Author Share Posted January 14, 2018 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... 1 Quote Link to comment
cybrnook Posted January 19, 2018 Share Posted January 19, 2018 (edited) @Djoss 1.10.10 seems to be out : https://www.makemkv.com/forum2/viewtopic.php?f=3&t=224&sid=b580bf9325d77c6b0391be68408b11cf EDIT: Scratch that, seems to be still not fixed: https://www.makemkv.com/forum2/viewtopic.php?f=3&t=16939&start=15 Might as well set your main image to 8. Edited January 19, 2018 by cybrnook Quote Link to comment
Djoss Posted January 21, 2018 Author Share Posted January 21, 2018 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...! 1 Quote Link to comment
cybrnook Posted January 22, 2018 Share Posted January 22, 2018 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 :-) Quote Link to comment
Djoss Posted January 22, 2018 Author Share Posted January 22, 2018 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. Quote Link to comment
cybrnook Posted January 22, 2018 Share Posted January 22, 2018 (edited) 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 January 22, 2018 by cybrnook Quote Link to comment
saarg Posted January 22, 2018 Share Posted January 22, 2018 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. Quote Link to comment
Djoss Posted January 23, 2018 Author Share Posted January 23, 2018 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. Quote Link to comment
cybrnook Posted January 23, 2018 Share Posted January 23, 2018 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? Quote Link to comment
Djoss Posted January 23, 2018 Author Share Posted January 23, 2018 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. 1 Quote Link to comment
cybrnook Posted January 24, 2018 Share Posted January 24, 2018 :-) 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 :-) Quote Link to comment
Recommended Posts
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.