No Valid DVD Titles Were Found

[sarbruis]

I'm running HandBrakeGTK 1.0.1 on top of version 0.9.1 of the CLI on Linux Mint.

I've successfully encoded one film, but I've tried two others that were ripped the same way using the same software (DVD Shrink), and I'm getting this error. They're just VOBs/BUPs/IFOs in the VIDEO_TS folder.

Also, how can I choose an audio channel and subtitles with HandBrakeGTK? They're both there, but I'm not able to choose anything except "Automatic" (ie, that's the only option; they don't seem to be recognized). Alternatively, how can I do this using the CLI?

Thanks.

[s55]

I wonder what the deal with all the HandBrake GTK suppot requests is lately. Is it being dugg or something?

Anyway, It's not supported in anyway shape or form by the HandBrake team.

It's a 3rd party app thats buggy and has appears to have been abandoned by it's author.

Your best using the CLI, http://trac.handbrake.fr/wiki/CLIGuide

[JohnAStebbins]

As the previous responder said, its buggy. Unless you feel the urge to dive into the code to fix some things, I suggest you don't get dependent on it.

Bugs I've found:
Path names to VIDEO_TS folder with spaces don't work (potentially your problem). Spaces are not being escaped in the command to retrieve disc information.
-The parameter it generates for constant quality encoding is incorrect. It gives an integer between 0 and 100 when it should be a float between 0.0 and 1.0. So encodings don't have the expected quality.
-It doesn't work with current SVN builds. HandBrakeCLI changed where it sends progress information. It used to go to stderr, now goes to stdout. HandBrakeGTK hangs waiting for input on stderr.
-The meaning of "-Q" (cqp vs. crf) changed in SVM HandBrakeCLI. So the crf checkbox does the wrong thing.
-x264 options are not added to the encoding command line
-In order to get a working detelecine filter, you need an SVN version of HandBrakeCLI, but as noted above, they don't play well together.
-For my setup, a bug in support libraries causes the default destination path to be junk.

Usability problems:
-Can't update a preset. Must delete, then re-enter settings and save.
-Can not store a preset specific default destination.
-Allows you to delete a "default" preset.
-Will not let you override a default preset.
-Doesn't support the new "-vfr" (variable frame rate) option.

The code is pretty easy to work with. Its not written too badly. You just need a good working version of monodevelop (fedora 8's is broken). I've fixed most of the problems that have bothered me. I'm sure I haven't found them all yet. For example, someone said it is mis-parses HandBrakeCLI output for some discs. I haven't encountered this yet.

[s55]

Nice summary of the issues. This is what happens when someone writes code then doesn't maintain it.

This is why we do not support it.

[sarbruis]

I've solved the problem. My issue wasn't with HandBrakeGTK, which is why I posted here, but I felt I needed to include that information. My issue was that the path name had spaces in it (which caused the same error using the CLI). And I added the second part because I saw that the HandBrakeGTK guy had previously answered questions in this forum, so I thought maybe he or someone else would know how to resolve the issues (which I did by just using the CLI instead of HandBrakeGTK).

[jupsoleil]

Hi!
I don't quite understand why the handbrake team supports a nice GUI for windows, and not for linux. Would it not be better to just join hands and include the code for handbrakeGTK into the main handbrake project?
Greetings,
Jürgen

[s55]

I don't quite understand why the handbrake team supports a nice GUI for windows, and not for linux.

This is because we have a windows developer(me) and a large portion of the userbase on windows.
There is no one on the team willing to maintain a linux port. Mainly because we are mostly Mac and Windows users.

Would it not be better to just join hands and include the code for handbrakeGTK into the main handbrake project?

Join hands with who? The person that wrote HandBrakeGTK didn't follow our guidelines (and didn't appear to have the time to) for GUI's and has left the project abandoned over nearly 3 months now. This simply isn't any use.
Noone else has come along to write a proper GUI for linux that actually works properly and follows our set guidelines. Theres the beginnings of an offical gui in the SVN however there is noone offering to write it or even maintain it.

[rhester]

To put it more directly, there are precisely two Linuxen actively involved in the project, and I'm one of them. Neither one of us is particularly interested in a GUI because we're both CLI-heads.

Anyone who wants to write and maintain a Linux GUI is welcome to write one. I'm not familiar with the licensing for HandbrakeGTK (abomination though it is), but if it's truly open-source and someone wants to work with us and move the ball forward with the existing code base, we'd welcome that.

There's no conspiracy to prevent creation of a decent Linux GUI. There's just no interest on the part of the people currently working on the project. There's always room for more coders!

Rodney

[jbrjake]

I don't quite understand why the handbrake team supports a nice GUI for windows, and not for linux.

I don't understand why Linux users can't find themselves a developer to write an actual Linux GUI for libhb when 90% of the work is already done:
http://trac.handbrake.fr/browser/trunk/qt4

Then again, I don't understand the concept of Linux users who'd prefer an underfeatured and outdated GUI to compiling the latest CLI out of the SVN.

Would it not be better to just join hands and include the code for handbrakeGTK into the main handbrake project?

Why would we want to include buggy, unmaintained code that's merely a Mono port of an ancient revision of the Windows frontend already in the SVN?