Handbrake not responding after browsing to an external USB hard drive

[DJQuad]

Description of problem or question:

Handbrake not responding after browsing to an external USB hard drive.

Steps to reproduce the problem (If Applicable):

Trying to select a file or folder for converting.

HandBrake version (e.g., 1.0.0):

1.0.7

Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):

Windows 10 Home version 1709

HandBrake Activity Log ***required*** (see How-to get an activity log)

The only lines in the activity logs are

Code: Select all

[11:38:34] hb_init: starting libhb thread
[11:38:34] hb_init: starting libhb thread
[11:38:34] hb_init: starting libhb thread
[11:38:34] hb_init: starting libhb thread

[Woodstock]

Does Windows Explorer see content on the USB drive? At the point you describe, handbrake is waiting for Windows to provide data.

[DJQuad]

Yep Windows Explorer sees it fine.

[Woodstock]

My suggestion would be to tell Windows to eject the drive, unplug it, and plug it back in. Close any applications that are "looking" at the drive first; even if it is just looking at the directory.

There are times when Windows "remembers" the content of a drive, but does not actually talk to it. You can "read" it in Explorer, but if you actually try to open something on the drive, it isn't available. You may find that Windows says can't safely eject the drive, because it cannot really "see" it anymore to close it properly.

Unplugging and replugging resets the hardware interface, and wakes up Windows to the fact that it needs to re-read the drive.

[DJQuad]

That didn't seem to help. I'm able to browse to a smaller USB drive (1 TB) and of course the data drive. The one it immediately makes it non-responsive is 4 TB.

[Woodstock]

I'd recommend having Windows do a chkdsk on the drive, to make sure there isn't something not quite right.

In the root directory, are there any media files, or just directories? This would include "hidden" files that Windows doesn't normally show.

I doubt that this is a handbrake failure, again because handbrake is relying on Windows at this point to provide data.

It might be interesting to see how the nightly build responds to the situation, though.

[DJQuad]

The chkdsk didn't detect any errors. I actually already tried that.

The root directory doesn't contain any files, just directories. Here's a screenshot -

https://imgur.com/a/W6wr8

I do believe this is some sort of HandBrake failure because browsing to that drive in other programs work fine. Things like saving a file (in Notepad, Excel, Plex playlist, etc) work fine.

[DJQuad]

Any ideas about this?

[s55]

The File chooser a Framework control. So if it's causing a freeze, then it's a kernel level event happening and we have no control over that I'm afraid.

[DJQuad]

It only happens when I use Handbrake though, no other programs do it at all.

[s55]

That's irrelevant in this instance. Not all apps use the same file chooser, or configure it in the same way. Regardless, a crash there is a Windows / .NET problem, not a HandBrake one.

I'm not sure what to suggest here. There's literally 100 things that could trigger this. From exposure plugins, AV, MRU Lists, last state, file/explorer metadata