Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression w/nightly: Crashes w/The Black Cauldron #2259

Open
PrimalNaCl opened this issue Aug 19, 2019 · 23 comments

Comments

@PrimalNaCl
Copy link

commented Aug 19, 2019

Title: Regression w/nightly: Crashes w/The Black Cauldron

Description of the problem

Regression w/nightly: Crashes w/The Black Cauldron

  1. Insert 25th Anniversary edition of The Black Cauldron (UPC: 786936765021)
  2. Launch HandBrake Nightly.
  3. Choose drive w/The Black Cauldron inserted. (In this case drive D:)
  4. Observe "Please wait ..."/"Scanning Title..." overlay 'window'.
  5. Observe windows popup indicating HandBrake has crashed.

The above occurs with or without AnyDVD HD running.

HandBrake version (e.g., 1.0.0)

Nightly 20190816180347-9d61025-master (2019081601)

NOTE: This crash does NOT occur w/version: 0.10.2.7286 - 64bit Version

Operating system and version (e.g., Ubuntu 18.04 LTS, macOS 10.14 Mojave, Windows 10 1809)

Windows 10 Pro 10.0.17134 Build 17134

Error message text or screenshot

Attached a screenshot.

HandBrake Activity Log (see https://handbrake.fr/docs/en/latest/help/activity-log.html)

[18:55:39] Nvenc version 9.0
[18:55:43] hb_init: starting libhb thread

Starting Scan ...

[18:55:43] CPU: Intel(R) Core(TM) i7-5960X CPU @ 3.00GHz
[18:55:43] - Intel microarchitecture Haswell
[18:55:43] - logical processor count: 16
[18:55:43] Intel Quick Sync Video support: yes
[18:55:43] - Intel Media SDK software: API 1.19 (minimum: 1.3)
[18:55:43] - H.264 encoder: yes
[18:55:43] - preferred implementation: software (null)
[18:55:43] - capabilities (software): bpyramid vsinfo opt1 opt2
[18:55:43] - H.265 encoder: no
[18:55:43] hb_scan: path=D:, title_index=0
src/libbluray/disc/disc.c:424: error opening file BDMV\index.bdmv
src/libbluray/disc/disc.c:424: error opening file BDMV\BACKUP\index.bdmv
[18:55:43] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.0
libdvdread: Encrypted DVD support unavailable.
libdvdread: Can't open D:\ for reading
libdvdread: Device D:\ inaccessible, CSS authentication not available.
libdvdnav: Unable to open device file D:.
libdvdnav: vm: dvd_read_name failed
libdvdnav: DVD disk reports itself with Region mask 0x00000000. Regions: 1 2 3 4 5 6 7 8
libdvdread: Encrypted DVD support unavailable.
libdvdread: Can't open D:\ for reading
libdvdread: Device D:\ inaccessible, CSS authentication not available.
[18:55:43] scan: DVD has 96 title(s)
[18:55:43] scan: scanning title 1
[18:55:43] scan: duration is 00:00:00 (400 ms)
[18:55:43] scan: ignoring title (too short)
[18:55:43] scan: scanning title 2

Please replace this text with the Activity log, or upload the log file to Github by dropping the file on this post.
Leave the ~ marks above and below.

handbrake_nightly_tanking_on_black_cauldron

@woodstockathbf

This comment has been minimized.

Copy link

commented Aug 19, 2019

libdvdread: Encrypted DVD support unavailable.

Handbrake does not deal with encrypted video sources. It is not a disk ripper. To make it act like one, you need to add a third-party library, and that has not been supported for over a decade.

There are a number of disk rippers on the market, including some that are free to use. Disk rippers are intended to deal with copy protection. I use MakeMKV, which is available for Windows, MacOS, and Linux. There are others out there.

@PrimalNaCl

This comment has been minimized.

Copy link
Author

commented Aug 19, 2019

libdvdread: Encrypted DVD support unavailable.

Handbrake does not deal with encrypted video sources. It is not a disk ripper. To make it act like one, you need to add a third-party library, and that has not been supported for over a decade.

There are a number of disk rippers on the market, including some that are free to use. Disk rippers are intended to deal with copy protection. I use MakeMKV, which is available for Windows, MacOS, and Linux. There are others out there.

That's a red herring. Several things:
0) As I mention in the bug, "NOTE: This crash does NOT occur w/version: 0.10.2.7286 - 64bit Version"

  1. Further, and again, as I mentioned in the bug, "The above occurs with or without AnyDVD HD running."
  2. When using version: 0.10.2.7286 - 64bit Version, I am able to get a correct .mkv transcode w/out issue.

So...given that it worked in a prior version and it does not now, w/all the things being equivalent, this nightly represents a regression.

@woodstockathbf

This comment has been minimized.

Copy link

commented Aug 19, 2019

So, you went through the procedure to install the 3PL on your SEPARATE handbrake installation, so that it would work with it?

This is one of the problems with the 3PL; its installation is ever so much more fragile with changes in Windows. The log says it is CURRENTLY NOT INSTALLED on the nightly build, and you're having issues because the nightly build is being asked to read an encrypted source.

That's not a regression - that's a failure to duplicate the circumstances.

@sr55

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2019

Can we have a log for 0.10.2 as well please.

In all likelyhood, either dvdnav was turned off, dvdcss was installed or there is bad metadata on the disc that we no longer handle well for some reason but it'd be interesting to see what 0.10.2 says it did.

@PrimalNaCl

This comment has been minimized.

Copy link
Author

commented Aug 19, 2019

So, you went through the procedure to install the 3PL on your SEPARATE handbrake installation, so that it would work with it?

3PL == Third-party library? I have had an installation of 0.10.2 since whenever it was that came out. I grabbed the installer version and installed it. The installer and Windows did whatever it did. I touched/altered it not. The same goes for the nightly. I grabbed yesterday and installed it in the same manner.

This is one of the problems with the 3PL; its installation is ever so much more fragile with changes in Windows. The log says it is CURRENTLY NOT INSTALLED on the nightly build, and you're having issues because the nightly build is being asked to read an encrypted source.

From a third-party pov, any libraries of other apps/tools may have littered about in various trees I have not done an exhaustive search. I have makemkv, anydvd hd, and mktoolnix installed. I just now tried the nightly against Dawn Of The Dragon Racers (UPC: 024543087458) and it works w/out issue. Attached is the log from there.

That's not a regression - that's a failure to duplicate the circumstances.

Given that it works on one encrypted source and not another, I'm thinking this is not the case.

Note that in either/all cases the libdvdread complaints about encrypted DVD support are identical. Hence the 'red herring' bit.

activity_log18832.txt

@PrimalNaCl

This comment has been minimized.

Copy link
Author

commented Aug 19, 2019

Can we have a log for 0.10.2 as well please.

In all likelyhood, either dvdnav was turned off, dvdcss was installed or there is bad metadata on the disc that we no longer handle well for some reason but it'd be interesting to see what 0.10.2 says it did.

I have attached all the logs associated w/the 0.10.2 release and The Black Cauldron.

The Black Cauldron.mkv 8-18-2019 7-24-34 PM.txt
last_encode_log16832.txt
last_scan_log16832.txt

@sr55 sr55 removed the Awaiting Feedback label Aug 21, 2019

@sr55

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2019

activity_log18832.txt => 1.2.2 Successful Scan, no Crash
The Black Cauldron.mkv 8-18-2019 7-24-34 PM.txt => 0.10.2 Successful Encode, no Crash
last_encode_log16832.txt => 0.10.2 Successful Encode, no Crash
last_scan_log16832.txt => Successful Scan, no Crash

All the logs provided show the process completed so I'm a bit confused as to what's going on here unless we are missing a log file here?

@PrimalNaCl

This comment has been minimized.

Copy link
Author

commented Aug 21, 2019

activity_log18832.txt => 1.2.2 Successful Scan, no Crash

This is from the nightly w/Dawn Of The Dragon Racers. That worked fine. I only included it to mitigate the other individual's flawed assertions.

The Black Cauldron.mkv 8-18-2019 7-24-34 PM.txt => 0.10.2 Successful Encode, no Crash
last_encode_log16832.txt => 0.10.2 Successful Encode, no Crash
last_scan_log16832.txt => Successful Scan, no Crash

These are from the 0.10.2 release working on The Black Cauldron. Which isn't the issue. It works fine w/the 0.10.2 release. There's some regression that has occurred somewhere between 0.10.2 and this cited nightly that presents itself w/The Black Cauldron and not w/other encrypted media.

All the logs provided show the process completed so I'm a bit confused as to what's going on here unless we are missing a log file here?

The original log I pasted into the bug is of the nightly on The Black Cauldron. That has the issue and is the entirety of the logs that are created when using this media and version of HandBrake. If you have some additional options I can feed it to enable more verbose debugging output for which I can attach, there are no other logs.

For obscene clarity:
With Nightly 20190816180347-9d61025-master (2019081601), The Black Cauldron doesn't even get through a scan successfully whereas using another encrypted media, Dawn Of The Dragon Racers, works flawlessly. Further, w/0.10.2, I haven't run into any issues for any other encrypted media source; +/- AnyDVD obviously. In the 0.10.2 release both pieces of encrypted media, The Black Cauldron and Dawn Of The Dragon Racers, works w/out issue.

This is why I believe there is a regression...somewhere between 0.10.2 and that nightly version. I do not know how many versions that represents...I'm open to some form of binary search if you have no other means of narrowing it down.

@sr55

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2019

While AnyDVD has proved unreliable in recent years, it's consistent when problems occur between versions of HandBrake so I'd say yes, probably some kind of issue introduced here.

Unfortunately, that doesn't help us much. The particular source isn't available here, sharing not an option so we don't have much avenue to diagnose this unless one of the other DEV's happens to have this.

This being one of the reasons we don't generally investigate issues with discs as a) MakeMKV virtually always removes the problem. b) Without samples that reproduce, it's looking for a needle in a haystack if it's not a common issue. c) more often than not, it's deliberately faulty media that triggers some kind of issue.

I'll leave it open for a bit see if we get any other discs with the issue showing up but unless something stands out, this will probably end up as won't fix.

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

I had exactly same issue with HandBrake-20190816-9d610250d and HandBrake-20190822-a58118b81 versions, but NOT when I rolled back to HandBrake-20190801-a584dc912 version.

Problem was with one MP4 file.
Here it is: https://mega.nz/#!grhTCSbR!q51mjQC56e4zoyFaX0s-8V4Kk0EBPfJHgqHFVOT4kWc
It is 419 MB documentary from mvgroup.org.

When "Automatic" cropping was used, then same error appeared at moment when "Start Encode" is pressed.
Without cropping, encode started, but when "Stop" button is pressed and after confirmation in "Stop Encode" window, same error appears.
Problem was with software H.264 and hardware (Intel QSV) H.264 encoding and audio "Auto Passthru".
There were no error messages in any log files.

My system is:

HandBrake Nightly 20190822200620-a58118b-master (2019082201)
OS: Microsoft Windows NT 6.3.9600.0
CPU: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz
Ram: 7906 MB, 
GPU Information:
  Intel(R) HD Graphics 4600 - 10.18.14.5067
Screen: 1920x1080
Temp Dir: C:\Temp\HandBrakeNightlyPortableTemp\
Install Dir: D:\PortableApps\HandBrakeNightlyPortable\App\HandBrake64
Data Dir: C:\Users\Master\AppData\Roaming\HandBrake\Nightly

Windows 8.1 Enterprise, with all latest updates.

But when I closed program few times and cleared (deleted) log and queue history, somehow latest HB nightly started to encode same file normally, with or without automatic cropping, and I can not reproduce same error with this file again.

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

After restarting system (Windows) and opening same file again with same latest nightly, same error window appeared after pressing "Start Encode".
activity_log472.txt

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

After closing program and repeating with same file, encoding started normally, so I pressed "Stop" after short time (with no error window) and here are logs:
activity_log3864.txt
Magneto Presse (2018) - Arkan's Legacy - The Serbian Mafia.mp4 08-24-2019 11-49-43.txt

To repeat, this is not happening with HandBrake-20190801-a584dc912 version.
Hope this will help in finding source of this problem.

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

And here is log file with same error after start encoding with software H.264:
activity_log4408.txt

After closing program and opening same file encoding started again and I stopped it without error, here are logs:
activity_log2476.txt
Magneto Presse (2018) - Arkan's Legacy - The Serbian Mafia.mp4 08-24-2019 12-24-54.txt

P.S.
Original file is created with HandBrake 1.1.0 2018040700

@sr55

This comment was marked as outdated.

Copy link
Contributor

commented Aug 24, 2019

Getting the generic Windows application crashed issue is not a good indicator of what the problem is. It could literally be anything.

I can see from the logs it looks like some memory has corrupted data config data in it. Most likley the cause of your crash.
I can also tell you, with that source, those settings on an HD 4600 the issue is not reproducible for me.

Might be worth looking at upgrading that GPU driver incase it's an API incompatibility with that the old driver series your currently running.
I should warn you though, we no longer support the 4000 series encoders and as far as I know, the -17 and -21 intermittent error problems probably still exist for the 4000 and earlier series and won't ever be fixed so there is a probability upgrading the driver will just replace one problem with another.

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

Thanks for feedback.
All drivers and system are up to date.
As same problem occurs with HW and SW encoding (my last post), it is possibly not related to HD 4600 GPU, as it is not involved in that last case.
Also this occurs only with few specific files and only with mentioned HB versions and not any earlier.
Another curious thing is that after restarting only HB, encoding of same files generates no error.

@sr55

This comment was marked as outdated.

Copy link
Contributor

commented Aug 24, 2019

Can you raise a new issue please with all the above information.

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

Should I copy all my posts with all files uploaded or can I do that in simpler way?

@sr55

This comment was marked as off-topic.

Copy link
Contributor

commented Aug 24, 2019

If you upload the logs to github, samples fine on mega thanks.

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

All logs are already uploaded here and specific sample is already on mega.

@sr55

This comment was marked as outdated.

Copy link
Contributor

commented Aug 24, 2019

Yeh, sorry, all I meant was you can copy/paste into a new ticket. It's fine as-is

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

I hope you can just modify title to "Crashes with some files" and spare me of ping-pong, where I could only make some mistake.
Thanks for understanding.

@sr55

This comment was marked as outdated.

Copy link
Contributor

commented Aug 24, 2019

It's two completely separate issues, non-related issues.
Unfortunately, github doesn't allow us to split.

@passat1

This comment was marked as off-topic.

Copy link

commented Aug 24, 2019

I'll do it ASAP, with screenshot, but at moment I'm not able.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.