Truncated BAD encodes (bad sources) being indicated with GREEN queue success status and result=0 in log! #1517
Comments
When an error occurs in the original media stream, that's "end of file" as far as handbrake is concerned. Completing the encode at that point, it has a successful result. The question is, why did the decoder stop getting data? The answer is almost always a disk flaw, whether it be a scratch or a fingerprint. Even MakeMKV says it can't read the disk at that point, and aborts. MakeMKV might have recorded more about the nature of the flaw it ITS log, but that's speculation about facts not in evidence. The MakeMKV forum has a topic on common read errors: https://makemkv.com/forum2/viewtopic.php?f=8&t=15055 But, as far as handbrake is concerned, this was not an error in the encoder, so it will return a zero/success response (if running from the command line) or show a green response in the GUI queue. |
|
There is a reason we tell people not to try rip directly from discs. libbluray isn't designed for handling copy protection. (Structural protections, deliberate errors etc). MakeMKV is and they have a massive amount of experience that allows them to better detect fatal vs non fatal errors and in many cases recovery / workaround problems much better than pretty much most other tools out there. They'll have a ton of code to handle the thousands of scenarios that now come up and change with every new disc released. Much in the same way we recommend running stream repair tools before dealing with OTA recordings in HandBrake. There are tools specialised just to that file type. As far as HandBrake can tell, there isn't a problem here so it did the correct thing in not failing the encode. The error here isn't fatal and won't always result in a failed encode. I reckon, if we flagged every decoder error we see, we'd see a 60+% failure rate on encodes across millions of users. That's never going to end well for anyone, especially when a large percentage of those won't actually have resulted in failed encodes. So, our options are actually very limited. Unfortunately, looking at the logs is not sufficient to tell if you have good encodes. No matter what software you use, the only way to be sure is to watch the entire file and pay very close attention to it. Same with MakeMKV. We've seen it be successful but data that it read was incorrect without error due to marks on discs or whatever. |
|
I've been a developer for 30 yrs (not open source where nobody can fire me) and all I can say is WOW. I'll be sure to spread the word I had no idea HB's stance was who cares if source media can be properly read and if we can't catch ALL general failures, literally why would we test for ANY of them - even the most basic PROGRAM INPUT testing. This is basic friggin I/O, not rocket science and you coded enough to log the issue, someone made a very irresponsible call to not call a total FAILURE TO READ SOURCE only 30 seconds in a success. I hear Twilight Zone music. |
|
For a developer with 30 years experience, your clearly not showing it as it's a hell of a lot more complicated than "basic IO". Also making a lot of untrue assumptions there as well. |
|
Handbrake is not a disk ripper. You are having a problem with ripping a disk. You are attempting to use the wrong tool for the job. There are many examples of this sort of problem in the developer world, that even a "newbie" like you have encountered. (yes, I've been programming for over a decade longer than you) A disk ripper (like MakeMKV) would tell you directly that the file isn't readable. It would stop the rip with a failure, if you were using its direct interface. Whatever you're using right now to remove the encryption from the BD is likely logging that there is a problem with the disk. But it only tells handbrake "end of data". The program handbrake has no way to differentiate between "end of data because disk is scratched" and "end of data because you reached the end of the file". What handbrake was asked to do completed properly. What you are feeding handbrake with is where the problem lies. How are the handbrake developers responsible for a program that isn't theirs? |
|
And FYI, this has ZERO to do with the PHYSICAL media it is hilarious that was the first defensive knee-jerk reaction to make this go away and close it. HB doesn't even make low-level I/O calls the failure is in the reading of the actual source file regardless of where the heck it sits. Copy a corrupt source file, any source file to the hard drive and Handbrake simply is coded so poorly that corrupt source file that fails to read, will not properly fail the job - period. I just tried it by hex-editing a source file to corrupt it and HB did the exact same thing. It is fully reproducible and to simply close this issue is absolutely unbelievable. |
|
I understand you're frustrated. Regardless of the issue, you're being an ass. HandBrake is open source, free software, and nobody owes you anything, despite our efforts to provide support in our free time. I'm going to leave these here and lock the issue. Please consider them and if you don't feel like changing your attitude, please go away. https://github.com/HandBrake/HandBrake/blob/master/CODE_OF_CONDUCT.md https://forum.handbrake.fr/app.php/rules?sid=fb1221fde5e3932a3c035b4bcf439b95 |
Description of the problem
Encode movie with apparent bad source disc. Handbrake encodes less than 10%, shows a green SUCCESSFUL finish in queue as shown here (last on the list):
And the end of encode log as:
Yet only after manually determining (obvious in this case) that encode not complete, and parsing through what end as an "error free" return code log, do I see entries like this:
As a test, which has only upset me more, when I run this source media through multiple other encoder/video tools that even just copy the streams, literally every one but Handbrake quickly return errors like this (MakeMKV identified source as bad within 2 min into stream RIP and gave a very clear indication there was a problem with source):
With HB the result of this reported successful encode job is ultimately a truncated 21 minute BAD video file - accompanied with two thumbs up from Handbrake. I do not nor ever have expected Handbrake to work any magic with a bad source, but any encoder should at least know when it has failed due to having a bad source, and in such until now I thought had been properly returning the job as failed on a bad source. My HUGE concern now is as it stands that I have to go back and hand-parse EVERY encode log and watch every video to determine if the job was truly a success because, had this one instead been a 98% complete encode, seeing "success" in both the GUI and looking at the end of the the log for failure (which I would never usually even do unless the job showed as failed) I would have never caught the failure and simply moved it to my library and then wondered why parts either stuttered or did not play at all or in this case, the movie just stopped prematurely. And given this example and depending on how long this bug has been in place, I'm sure it has already occurred for me and this is going to become VERY time-consuming to hand-parse logs or re-run my media through other tools to verify source media was readable or not. Parsing this known bad encode log for the word "errors" renders exactly twelve lines ending in "errors"....and all twelve have ZERO before the word errors. I can't stress enough how big of an issue this is.
With all that said, if possible to nail it down, I would be interested in knowing how long this issue has existed so I can have an idea of just how long I have to back-trace my encodes and manually review all logs to ensure I don't have not yet watched bad encodes (that HB returned as good) now sitting in my media folders. Also, is parsing for "skipping broken unit" in bad HB versions the best/only way to truly determine when an otherwise successful returned job was really a failure due to bad source media? TIA!
Steps to reproduce the problem
Select source
Add to queue
Start encode queue
Encode job shows erroneously shows success
HandBrake version (e.g., 1.0.0)
20180729125104-ecf8523-master (2018073001)
Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.3 High Sierra, Windows 10 Creators Update)
Win7x64
Error message text or screenshot
Last job on the list is job in question showing as successful completion:
HandBrake Activity Log required (see https://handbrake.fr/docs/en/latest/help/activity-log.html)
The text was updated successfully, but these errors were encountered: