Archive of historical bug reports.
Please use the GitHub link above to report issues.
Forum rules
******************************* Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
Please describe the problem in as much detail as possible:
After upgrading from 0.10.5 to the latest stable version 1.0.0 on Mac, the feature to use the MakeMKV library for BluRay seams to be gone. After loading several discs it keeps on saying: "no valid source found", there is no such issue in 0.10.5
What are the steps to reproduce this problem:
Install HandBrake 1.0.0 or Nightly Build and follow the instructions on this page: http://www.macobserver.com/tmo/article/ ... -handbrake
The software will either start reading the disc and refuse afterwards or it displays the error message immediately.
After downgrading to 0.10.5 the content gets available again for conversion.
What version of HandBrake you are running:
HandBrake Nightly Build as above
What operating system and version and you running (e.g. OSX 10.11, Windows 7, Ubuntu 14):
Mac OS X 10.11.6
If there was any exception or error displayed, please copy it and paste it here:
This isn't a configuration we have ever officially supported I'm afraid. libdvdcss/aacs may or may not work. More often than not, not. It's not something we are going to spent any time fixing or updating for new protection schemes.
If you've got MakeMKV installed, why not use it to rip the disks directly to MKV files, and feed those to handbrake? It is significantly faster, if you have more than one disk to rip, because you can rip all tracks on a disk in less time than it takes to rip/encode one, and move on to the next disk.
It's not a matter of updating protection schemes as the previous versions of HandBrake support the aacs library by MakeMKV without any problems. Even VLC does with all BluRays that I tested. Not sure how much effort it is to fix but it would be a great contribution to the community. The solution Woodstock brought up is surely a workaround but doesn't solve the problem itself. Would appreciate if the developers showed a little more interest in user demand.
Paid developers usually respond to user demand. Volunteer developers respond to what interests them. Sometimes that is problem solving.
When the MakeMKV developer (who does charge for the program) decided to add the capability you are trying to use, I wondered why, but it must have interested him, because there certainly wasn't a big outcry of "got to have this feature!" on their forum. But since then, I've seen a lot of people asking how to make it work with this program or that program. I even tried it once... and found it was more trouble than it was worth, since I rarely have a DVD or BD out of its box after the initial rip and encode.
Handbrake's developers aren't paid. And if you've been around for a while, the "more interest in user demand" obligation is no doubt part of that. You've brought up a problem with a non-supported linkage to a third-party program. In three years of hanging around this place, I don't remember it coming up very often. Rather than being a case of "user demand", it seems more a case of "A user's demand".
There also isn't a huge user demand for this. >8bit internal pipeline which is quite niche in it's usage, has far higher demand. QSV on linux, or NVENC or AMD VCE all have much more demand from users, and all stuff we'd like to get working seamlessly some day.
Regardless, as we've said before, HandBrake is a video transcoder, not a ripper. We don't have any intention in getting into that cat and mouse game. Not least because we'd lose developers and discourage others to join by doing so. Given how few of us there are, it'd effectively kill the project.
