MakeMKV does not accept key, so ripper.sh is unable to recognize disc types #132
Comments
|
Two things: The second log shows, that your drive is correctly checked and its state is interpreted as open, see: Therefore the script does not do anything. Makes sense? |
Absolutely makes sense. Only problem is that the state aint changing when run privileged. It somehow freezes. [DEBUG] 21.01.2025 15:03:57: INFO: DRV:0,1,999,0,"BD-RE HL-DT-ST BD-RE BP40NS20 ML01 KVGD82D0931","","/dev/sr0" It logs "Checking disc." but in reality nothing happens. Disc aint spinning nor does the tray open by itself. It wont recognize when I open and insert a disc. It also doesn't log everything that happens after the initial start. It's unusual compared to half a year ago. The only way I get a feedback, is when I start the container unprivileged. It then continously opens the disc tray. |
|
Weird.. What you could do is b) Try to edit ripper.sh on your own so The unexpected output is interpreted as whatever you expect that disk to be. |
rix1337
added
help wanted
and removed
wontfix
This comment has been minimized.
This comment has been minimized.
|
The contrary: this whole thing relies entirely on makemkvcon output, as there is no other reliable way to "see" disk types and states in docker, see: Since MakeMKV is required anyway to rip Video, its the perfect basis for the entire image. It is very likely that one of the recent makemkv updates broke some of their output, so you may not be alone with this issue. That's the main reason I am responding to a non-sponsor request ;) Let me know what you find out - a change to the shared ripper.sh may be required, after all. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rix1337
added
sponsor ❤️
This comment has been minimized.
This comment has been minimized.
|
The odd thing is that makemkv does not seem to output anything according to your log. Could be related to, but this is not 100% certain. Does https://github.com/jlesage/docker-makemkv work for you? |
|
Unfortunately no, it does the same thing. |
|
Ok, then yours is almost certainly a hardware issue. There is nothing I can do except advise you to try and get in touch with MakeMKV or their forums. |
|
Alright, yea could be indeed an hardware issue. Thanks anyway for your help! |
|
Maybe with the new UNRAID update you need to pass the disk drive differently than you did before. But what about my initial proposal? Does this work for you?
You would need to edit one of these lines in your local ripper.sh: to reflect the state that you are ACTUALLY expecting your drive to be in. |
|
Basically @g4njawizard you should get different responses for this console command and need to map them accordingly:
Maybe your "${DRIVE:=/dev/sr0}" parameter is wrong? Maybe UNRAID now calls your drive /dev/foobar12? Asume your entire config is wrong and you need to carefully follow this section of the Readme: |
|
Haven't tried that out. Gonna test that tomorrow. Thanks again! |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@rix1337 Yes I can confirm that if I manually run both the reg command and the script then everything works. It does seem to be something with the startup script. After manually running Looks like for some reason when |
|
I just tried jlesages MakeMKV GUI container and it also fails to set up the latest beta key. According to this issue over there, this is a bug with MakeMKV - so nothing we can do about it currently: If anyone is willing to provide me with a paid MakeMKV key I can at least debug if this issue is purely related to the beta key not being accepted by the current release. Else someone with bash skills AND a paid key needs to debug this further while I am pausing. |
|
FYI: I just pushed a change to the startup script that outputs the registration command including the key (so you can double-check for issues there) and also the output by makemkv. The issue it seems is that MakeMKV falsely outputs: and Even though the beta key SHOULD be valid and the version is the latest one available. |
rix1337
changed the title
|
Thanks for your quick responses! For me, I'm using my own key that I bought, so I don't think it's an issue with the beta key. I think it must be some sort of weird user issue? If I run The container is definitely running as privileged because when I remove that line then I get permission errors. I've verified that the process that gets started automatically when the container restarts is owned by root. I think for sure this is due to some weird interaction going on with makemkvcon reg as I'm still seeing this line in the logs whenever /etc/my_init.d/ripper.sh tries to register the key: Again, this is only when the init script is run automatically. When I manually run it then it's able to register the key just fine but it only works for anything that I manually run using |
|
@veerpandya mind sharing the output of your container startup (success case when you run stuff manually) + what happens if you execute |
|
Sure, so Here are the logs after I force-recreate the container on first startup: And then here's the output when I manually run |
|
Ok, this is 100% a bug, that has to do with user rights. Is very much clear on that. Could you add whoami to |
|
Yep already tried that and it only ever returns root, regardless if I run via docker exec or if it's run automatically. I've included the output using the updated init script after restarting the container and adding whoami to it: I just want to note that M-KEYHERE is the same everywhere it's printed and the key is correct. Here is the output after running the updated script manually via docker exec: |
|
I just noticed, this line |
Hooray, you found the culprit. Please add some more debugging statements so we can see the difference. Once that is found I will push a fix! |
|
I've just included the output of and when run manually: Let me know what other debug statements would be helpful here |
|
HOME seems indeed missing in the automated run What happens if you set HOME=/root by editing the startup script? |
|
Tried that as well, I still get Here's my docker-compose in case I messed something up there: I'll mess around with building my own image using the dockerfile and see if I can work something out there when I get some time. Otherwise feel free to send some more debug suggestions and I can try them out in the meantime. |
|
@rix1337 I got it working. Basically we need to add the HOME variable to |
|
@veerpandya thanks for the thorough investigation. I also kept looking but didn't stumble upon the above. Just pushed c632f45 which contains the proposed solution. If you confirm It works, we can finally resolve this issue. Big ❤ for the support |
|
@veerpandya NICE! it seems to be working. I am closing this. Will reopen in case of any remaining issues. |
|
Yep just confirmed it works! Thanks so much! |
Have you read and understood this part of the readme?
[X] YES
Hi,
I haven't used the ripper for a while now, but it's now suddenly unable to recognize disc types.
It's just ejecting discs.
I use it on unraid with "manual-latest"
When I run the container unprivileged, I receive the following error:
When I run it as privileged user, my drive is recognized but nothing happens after starting it.
The text was updated successfully, but these errors were encountered: