official MakeMKV port multimedia/makemkv

twschulz said:
I was wondering simply if maybe it's not disc 0?
Click to expand...
Looking at your output above, although there are several devices, only one of them is an optical drive (and the script therefore only links one). According to the makemkvcon documentation, disc:0 will just use the first optical drive found, so this should be correct.
twschulz said:
I haven't tried the drive on Linux yet, but I'll give it a shot. I have run this previously on MacOS with MakeMKV and it worked fine.
Click to expand...
Ok, this is already strange. But as this port uses the Linux version of MakeMKV with FreeBSD's Linux emulation, it still might be worth to check whether that same software works correctly on a "real" Linux...
Of course, I can't be entirely sure whether the "fake sysfs" created by my script is 100% correct in every case. You could try to check against what you find in /sys/bus/scsi/drivers/sr on Linux...
 
I managed to connect the blu-ray to a Linux laptop and MakeMKV found it and appeared to work just fine. I'll check /sys on Linux in a bit.

I guess I'm just wondering if the makemkvcon actually looks for the device "nodes" in /compat/linux/etc/makemkv/? It seems like it might not be looking in the correct place?
 
Nope. The package contains a binary patched makemkvcon, with /sys/bus/scsi replaced by /etc/makemkv/, see here (I had to ask the copyright holder for permission to redistribute this patched binary via FreeBSD packages repos...). The sysfs part is only used to discover devices, it will always use /dev/sg0, /dev/sg1 etc to actually communicate with the drive.

This whole magic works fine for me, and I have of course a few success notes by other people -- but I can't be sure there isn't something different on your machine causing my script to create a "sysfs-tree" that's not expected this way by makemkvcon. Unfortunately, I can't have a look in the source code ;)
 
Ah, yes, that's the trick! Yes, the fact that source code is not available makes it difficult ;-)

Anyway, I looked at the /sys tree on the Linux machine and looked at the thing on mine and it seems to be the same. I'm not sure what is going on. I'll have to take a look a bit later.

Thank you for the help. If I figure out what is going on, I'll update the thread.
 
With the release of 1.15.2, 1.15.1 refuses to work (at least for me). I'm already updating the port, but as I have some trouble with my testbuilder (used to check correct builds on all supported versions and architectures) right now, it might take a few days until the new version is available.
 
I'm having the same problem as twschulz.

Everything on the system is up to date. My BD drive is known to work under Linux, and works fine on FreeBSD with VLC.

Code: 
bagel/root-15051# pkg version -n makemkv
makemkv-1.15.2                     ?

bagel/root-15052# sh -x /usr/local/sbin/update-makemkv-drives
+ trap 'rm -fr $TMPFIFODIR' EXIT
+ mktemp -d
+ TMPFIFODIR=/tmp/tmp.UrzS6Wht
+ mkfifo /tmp/tmp.UrzS6Wht/campipe
+ SGDEVS=''
+ rm -fr /compat/linux/etc/makemkv/devices
+ rm -fr /compat/linux/etc/makemkv/drivers
+ camcontrol devlist
+ grep -E '[(,]cd[0-9]+[,)]'
+ read line
+ echo '<HL-DT-ST' BD-RE WH16NS40 '1.04>' at scbus1 target 0 lun 0 '(cd0,sg0,pass1)'
+ grep -Eo 'scbus[0-9]+'
+ sed -e s:scbus::
+ SCBUS=1
+ echo '<HL-DT-ST' BD-RE WH16NS40 '1.04>' at scbus1 target 0 lun 0 '(cd0,sg0,pass1)'
+ grep -Eo 'target [0-9]+'
+ sed -e 's:target ::'
+ TARGET=0
+ echo '<HL-DT-ST' BD-RE WH16NS40 '1.04>' at scbus1 target 0 lun 0 '(cd0,sg0,pass1)'
+ grep -Eo 'lun [0-9]+'
+ sed -e 's:lun ::'
+ LUN=0
+ echo '<HL-DT-ST' BD-RE WH16NS40 '1.04>' at scbus1 target 0 lun 0 '(cd0,sg0,pass1)'
+ grep -Eo '(.*)'
+ grep -Eo 'sg[0-9]+'
+ SGDEV=sg0
+ [ -n 1 -a -n 0 -a -n 0 ]
+ [ -z sg0 ]
+ SGDEVS=' /dev/sg0'
+ LOC=1:0:0:0
+ mkdir -p /compat/linux/etc/makemkv/devices/1:0:0:0/scsi_generic/sg0
+ mkdir -p /compat/linux/etc/makemkv/drivers/sr
+ ln -s ../../devices/1:0:0:0 /compat/linux/etc/makemkv/drivers/sr/1:0:0:0
+ echo 5
+ read line
+ [ -z ' /dev/sg0' ]
+ echo devices linked: /dev/sg0.
devices linked: /dev/sg0.
+ echo 'When your configuration changes, re-run this script (update-makemkv-drives).'
When your configuration changes, re-run this script (update-makemkv-drives).
+ rm -fr /tmp/tmp.UrzS6Wht

bagel/root-15053# makemkvcon --debug info disc:0
MakeMKV v1.15.2 linux(x64-release) started
Debug logging enabled, log will be saved as file:///root/MakeMKV_log.txt
DEBUG: Code 2 at AFr;N=c'Vq_*FY"FPD1 748':121261428
DEBUG: Code 2551185736 at ]Loc]gZel^[tu~>H:121263406
DEBUG: Code 0 at ]Loc]gZel^[tu~>H:29395356
DEBUG: Code 0 at .v}(>HM5#}/{Xeg:121262555
DEBUG: Code 0 at 7X1mAB=O_p?W?AYS:121275596
The program can't find any usable optical drives.
DEBUG: Code 0 at M@0"J\VE,$Wf#w\syMbTI:121264786
DEBUG: Code 233 at sgki5HEq7AZWSJ2uR8hCc8Mj:0
Failed to open disc
Total 0 titles
zsh: segmentation fault (core dumped)  makemkvcon --debug info disc:0

bagel/root-15054#

If there's any additional info I can provide, or anything else I can try, please let me know. Any help is appreciated.

Either way, thanks much for your work on this Zirias!
 
Trying again to debug this a bit, I noticed that there's still a reference to /sys/bus/scsi/ in the binary I've got, specifically:

Code: 
bagel/home/stu-108540: strings =makemkvcon|grep /sys/bus/scsi
/sys/bus/scsi/drivers/sr

In tracing makemkvcon, it doesn't look like it actually tries to open that directory; but nonetheless, I binary edited the path to /etc/makemkv/, matching the other instance:

Code: 
bagel/home/stu-108543: cmp -x ./makemkvcon /usr/local/bin/makemkvcon
0000bf88 65 73
0000bf89 74 79
0000bf8a 63 73
0000bf8c 6d 62
0000bf8d 61 75
0000bf8e 6b 73
0000bf8f 65 2f
0000bf90 6d 73
0000bf91 6b 63
0000bf92 76 73
0000bf93 2f 69

But of course this didn't help:

Code: 
bagel/root-15394# ~stu/makemkvcon info disc:0
MakeMKV v1.15.2 linux(x64-release) started
Profile parsing error: default profile missing, using builtin default
The program can't find any usable optical drives.
Failed to open disc
Total 0 titles
zsh: segmentation fault (core dumped)

Still hoping someone can help me track this one down...

Thanks.
 
I just thought I would give an update since I finally got a chance to take a little closer look at this. I tried this on a 12.1 laptop with the same blu-ray drive and it worked! I got curious, but then I remembered that I originally was trying this on a -CURRENT box. :-/

I haven't had a chance to try it on -CURRENT again. But since that is beyond the scope of the forums here, I'll just say it works for now.

I'll still file something in bugzilla if things are still going wrong in -CURRENT as someday 13.0 /will/ be in scope.

I'm sorry for the confusion and thank you for doing the heavy lifting to get the port in the tree. Looking forward to spending some time with it.
 
Hm, still not working for me on 12.1, failure mode still as described.

I'm giving up on debugging it for now; instead, I've been using VLC to auth to the drive, dd to make raw image backups, and HandBrake to transcode to H264 mp4.

Still, I very much appreciate the work Zirias put in and glad it's working for some folks. Thanks!
 
Just FYI, there was a bug in -CURRENT and -STABLE that made this not work. I reported it (PR 249395) and it was just fixed so that it doesn't make its way into 12.2.

Hope this helps. Things worked after this fix for me at least.
 
twschulz said:
Just FYI, there was a bug in -CURRENT and -STABLE that made this not work. I reported it (PR 249395) and it was just fixed so that it doesn't make its way into 12.2.
Click to expand...
Great, thank you very much!
I noticed that the fix was also MFS’ed to the 12.2 branch yesterday.
 
Not sure what you mean by "this", but you're refering to a completely different software. The ability to somehow output an .mkv file is more or less the only similarity.
 
Tested MakeMKV 1.16.7 on FreeBSD today. Segfaults. :( Reported the problem already for 1.16.5 here: https://forum.makemkv.com/forum/viewtopic.php?f=3&t=26392

So, the latest version working on FreeBSD is still 1.16.4 :(

Although I understand the reasons to keep the core tool closed-source, the drawbacks are obvious once again:
  • Can't do anything about the segfault myself
  • Can't help porting the code to run natively on FreeBSD either (and although upstream signaled interest, it seems they don't really have time for it)
Ok, to add at least something slightly useful to this post: An old version of MakeMKV still runs fine with an up-to-date "beta key". To easily update your key, the package includes an example script /usr/local/share/examples/makemkv/update-makemkv-key.sh.
 
Thanks for providing an update around this. I was wondering why 1.16.4 hadn't been updated. I'll also add that if you bought a license key (like I did back in 2012), this also works with older versions. It would be interesting to have an updated version eventually. If there was an attempt to do a native port, I could potentially help with that (caveat that I'm extremely overbooked on other things), but I use this software often on FreeBSD and would like to continue to do so. :)
 
twschulz said:
If there was an attempt to do a native port, I could potentially help with that
Click to expand...
Oh, I'd be quite happy to do that as well. Apart from the current "segfault problem" with newer versions, it would probably be the only way to make the GUI work on FreeBSD. It would also remove the dependency on Linux-compatible sg devices (requiring a custom kernel configuration), because you could use native pass(4) instead…

Problem is, this would require access to the makemkvcon source. So far, I didn't get the impression Mike was willing to hand it out (under an NDA of course). And again, I understand that reluctance. This binary contains the "tricks" to decrypt the disks. The industry would be pretty interested I guess ?‍♂️.
 
Yes, I think Mike is kind of stuck in that situation. For what it's worth, you can make the sg(4) device into a module. I did a brain dead version, it loads fine and works with makemkvcon, but it will not unload. I have a feeling that the only thing preventing it from being a module is that no one has had time/interest to make it one. It's on my TODO list to fix unloading and submit a differential on it, but I never get the time.
 
I still have the same problem with the new MakeMKV 1.17.0 :(.

If anyone has any idea how to debug (mind you: closed source executable using Linux ABI) and wants to help, I do keep the port updated in my WIP branch.
 
Amazingly, there's progress!

multimedia/makemkv 1.17.0 is now working fine, at least on 13.1-RELEASE/amd64.

The culprit wasn't the closed-source binary, but missing -DFORCE_OPENSSL_NO_EC which is somehow necessary to make this work with the OpenSSL from linux-c7 userland ?

Still the problem persists, no sane way to debug these things with both closed-source and foreign ABI....

I will do a good set of test builds, if all is fine finally submit this update!
 
Zirias said:
The culprit wasn't the closed-source binary, but missing -DFORCE_OPENSSL_NO_EC which is somehow necessary to make this work with the OpenSSL from linux-c7 userland ?
Click to expand...
Re-read the whole thread, and I still don't get why the linux-c7 version of OpenSSL is needed... is it license-related or ABI-related? Technically, I'd think that native OpenSSL would work better... ?
 
astyle, makemkvcon is a closed-source binary, only available for Linux. MakeMKV requires building some open-source libs that are used by this binary. A Linux binary can't link to a FreeBSD lib.
 
Yeah, mixing can be an awkward proposition... My hat's off to your stubbornness and problem-solving skills!
 
Landed. ?

Now I discovered there were makemkvcon binaries added in mankemkv-bin, for aarch64 and arm EABI5. I'll try to extend the port to support them as well!

Does anyone on here have some arm machines with BD/DVD drive attached and would volunteer to test? If so, please let me know!

edit: I had a look at the linux-c7 ports, it seems they don't support 32bit arm. Is this correct? Well, I can still try to enable MakeMKV for aarch64 ;)
 
Ok, I'm running into a dead end and looking for help!

In my local ports tree, there's now a commit multimedia/makemkv: Add support for aarch64 I would like to test. It probably still fails for one or the other reason, but it fails very early on my amd64 testbuilder using emulators/qemu-user-static. The build uses the compiler from devel/linux-c7-devtools, which is a Linux binary. My assumption is, running it through qemu-aarch64-static (which is a FreeBSD binary), all the "Linuxulator magic" (remapping syscalls, overlaying /compat/linux) can't work. So, the only chance to test would be to build natively on some aarch64 machine.

If anyone on here could help with that, please let me know!
 
You must log in or register to reply here.
Back
Top