Windows Handbrake 0.9.1 - queue still has problems

HandBrake for Windows support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Windows Handbrake 0.9.1 - queue still has problems

Post by mshandony »

Hello,

I was one of the people that had problems with the "Added an Item" dialog box appearing in the 0.9 release when using the Queue functionality, so I was really looking forward to the 0.9.1 release.

Unfortunately, I am now experiencing a different problem with the queue.

Here is what I did:

1. I added 5 movies to the queue by using the "Add to Queue " button.
2. I clicked the "Encode Video(s)" button on the Queue Window.
3. The first movie converted fine.
4. The second movie starts converting. (I never notice if it completes or not. I know it gets close.)
5. Go back to step 4. (repeat forever)

The second movie keeps re-encoding over and over again. It never makes it to the third movie in the queue.

Another problem I encountered was that once I realized this repeating was happening, I had a lot of trouble stopping handbrake from running. If I killed the DOS window, it would automatically restart with the 2nd movie again.

The third problem I have is that it appears that the Handbrake GUI is single threaded. Once the DOS window appears, the other Handbrake windows (the main window and the queue window) no longer get refresh events and are essentially blocked until all the encoding is finished (which it never does due to the repeat problem listed above).

My System Info:
Handbrake 0.9.1
GUI Build: 2.4.1
Windows XP Pro SP2

Unless someone has a workaround, I guess I will be waiting for Handbrake 0.9.2.

Thanks,
Michael
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Post by s55 »

#1 - I've been completely unable to re-produce this. That's with 5 Items added to the queue.

#2 - There is no option to stop / start the queue. (Although that's definatly a good idea for a future release) It will start an item, remove it from the queue and continue doing this until done.

#3 - The GUI is most defiantly multi-threaded. You should have full interaction with the GUI (and in testing there has been no issues with this). It shouldn't like the thread that controls the GUI has been deadlocked (which really shouldn't be possible)



Personally I'd suggest selecting a source with dvdtitle & chapters. Using the normal preset. Queue up 5 small test samples with different filenames and see if it works. (that is, using the default program settings)

Failing that i'd make sure you have the latest version of .net 2 and all windows updates.

could try Re-Install the thing, Completely removing all the files from c:\program files\handbrake.

If all that fails then I'm at a loss. Unless I can actually re-create the error there is no chance in it getting fixed (assuming it is even a HB issue)
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Post by mshandony »

I followed your instructions and I was successful.

- My PC was already up-to-date with all the Windows Updates.
- I deleted the c:\program files\handbrake folder. I had installed on-top-of my old Handbrake installation.
- I re-installed Handbrake.
- I rebooted my PC just to be sure.
- I chose 1 chapter from each of my 5 DVD's that I was converting and added them to the queue.
- All 5 chapters encoded correctly.
- The GUI also worked correctly this time.

I am going to assume there was something wrong with my PC. I will re-try to add the 4 remaining movies into the queue and have Handbrake convert them. My PC is slow so I will not be able to respond on the results until tomorrow.

Thank you for your fast reply and good suggestions.
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Post by mshandony »

I was successful in adding 4 movies to the queue and having them processed.

The problem was either with with the way I had installed Handbrake or my PC just needed a reboot.

Again, thanks for the help!

-Michael
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Post by mshandony »

Unfortunately, the problems have returned.

This time it was the last movie (out of 3) in my queue that would convert completely and then restart again. It would just keep redoing it over and over again. If I tried to kill the DOS window, a new one would pop up to take its place.

The GUI also became unresponsive/dead.

Just so you do not think I am some kind of idiot, I am a software engineer, so I do understand how software works. I have not done very much Windows programming, though, but if there are some debugging steps you would like me to take, I can certainly look into it.

My bet is that some part of the code is not thread safe.
OneGoodKnee
Posts: 2
Joined: Tue Oct 16, 2007 12:53 am

Post by OneGoodKnee »

I have the same problem. 2nd item in queue does an infinite loop.

I've done a clean install and still have the same problem. I'm using the IPOD high-Rez preset.
TorontoDrew
Posts: 2
Joined: Tue Oct 02, 2007 12:46 pm

Post by TorontoDrew »

I have the same problem but for me it's reproducable. I am using Handbrake Windows GUI on a Dell Inspiron 6400 laptop computer. The behaviour described by other people in this thread also happens to me if the power management of the laptop turns off the screen (for example, by lowering the screen so the backlight turns off). When I do this, both the GUI and the queue crash leaving the CLI running. When it finishes the current job, it cannot communicate with the queue to retrieve the next file to be processed since the queue has crashed. The CLI then starts again with the only file it is aware of, that is, the file it has just processed. And so, it starts processing it again. I can reproduce this specific event consistently. So far, my workaround is to enable screen saver blanking instead of using the laptop's power saving function. Neither the GUI or queue crash when the screen saver blanks the screen.
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Post by mshandony »

I feel a lot better that other people are having the same problem. I am sorry that Handbrake has a problem, though.

I am running Handbrake on a DIY PC. I have my power settings set to:

- turn off monitor: after 30 minutes
- turn off hard disks: after 1 hour
- system standby: never
- system hibernate: never

What is weird is that I cannot reproduce the problem reliably. I thought I did the same thing each time, but maybe not.

Let me try to set it to never shut off the monitor and hard disks. I will manually turn off the monitor when I leave to let Handbrake do its thing.

I will report my findings in a few days.
angelessme
Posts: 5
Joined: Fri Oct 12, 2007 1:12 pm

Post by angelessme »

I have the same issue.

CLI gets stuck looping item 2 while the GUI and queue are frozen.

My only power management feature that's turned on is Monitor Off after 20 minutes.

I am also unable to reliably produce the problem since i've had some huge encode queues(18 items) go through no problems with me away from the computer, and other smaller queues(3 items) randomly fail.
OneGoodKnee
Posts: 2
Joined: Tue Oct 16, 2007 12:53 am

Post by OneGoodKnee »

What settings/preset are you all using?

I had a batch go through night before last that worked all the way through the queue using Ipod High-Res with chapters markers OFF.

Last night I tried the same with chapter markers on and it looped on item 1 in queue.

The queue and gui are definitely locked/frozen when the looping occurs.

As with the rest of you I'm kind of grasping at straws, I can't find anything that is consistently reproducible.
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Post by mshandony »

Here are the settings I am using:

- I select the "iPod High-Rez" preset.
- I set the "Auto Crop" option
- I select "2-Pass Encoding" and "Turbo 1st Pass"

I leave all the other settings as-is (thus I have "Chapter Markers" selected).

-Michael
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Post by s55 »

It won't be a settings issue. All that happens is the settings are converted into a query string. e.g
-i "C:\Documents and Settings\Scott\Desktop\Files\DVD\National Treasure.iso" -o "C:\Documents and Settings\Scott\Desktop\test.m4v" -e x264b30 -E faac -w 640 --crop 0:0:0:0 -m -b 1500 -x keyint=300:keyint-min=30:bframes=0:cabac=0:ref=1:vbv-maxrate=1500:vbv-bufsize=2000:analyse=all:me=umh:subme=6:no-fast-pskip=1 -B 160 -R 48 -v
Now, Should you change that to complete guff, the queue will still run. It will launch each item just fine. (the CLI will have a hissy fit and close after a few seconds. After which the next cli process will be launched.)


The problem will be down to the way Windows / .NET is handling threads/processes. It would appear that in your case one of the threads is dying for no good reason (when it should be throwing an exception) and this is having a knock on effect on every other thread used.

There is nothing technically wrong with the code itself (as far as I can tell)

The worst part is, unless I can actually re-create this (I've tried) it's very difficult to run the debugging tools to find out what the hell is actually happening.
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Post by mshandony »

Could you have the master thread do something like this?

1. create the child threads
2. sleep for 10 minutes
3. check the status of the child threads
4. if a child thread is dead, log it.
5. go back to step 2

If we hit the problem, we could send you the log. It may not tell you why the thread is dying, but at least you would know which thread is dying.

Also, maybe the master thread could have a catch-all try-catch block to catch any and all exceptions that maybe thrown from a (dying) child thread?

Also, I have done a fair amount of GUI programming and trying to get threads and a GUI objects to work together can be a real pain. GUI objects can usually only be accessed by the thread that created them which makes writing code in a natural way very difficult. I usually got around the problem by doing something like:

1. GUI thread creates the layout, widgets, event handlers, etc.
2. GUI thread sleeps until it is notified of an event (button press, scrollbar moved, etc.).
3. GUI thread handles event
4. GUI thread checks a shared resource (i.e., a thread safe queue) to see if another thread needs to do something with the UI. If yes, then handle the request. The request needs to be something that runs very fast so the GUI thread can get back to handling the UI events as soon as possible.

I did the above for a logging window. Another thread ran an external program and then read the stdout and stderr of the external program. It would take that output and need to add it to the GUI's log window. It would prepare the logs into the proper format and then add a request to a queue to update the GUI. The GUI thread would see the request and copy the new logs to the logging window. It would have been nicer for the 2nd thread to add the logs directly to log window, but it doesn't work that way.

I do not mean to tell you how to write your code. I hope that maybe I could help out to find the source of the problem.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Post by s55 »

Can you give:

Link Removed No longer available

a shot. Just copy this into your handbrake install directory. (backup your old copy, this is a dev build which may have other issues)

I've changed the way the threads are started. Shall be interesting to see if this does anything.
angelessme
Posts: 5
Joined: Fri Oct 12, 2007 1:12 pm

Post by angelessme »

I noticed yesterday when this happened again that it prodocued an error window with a box that said exception/ok/cancel or something (dont remember sorry). Though i couldn't click the box as it was frozen like the rest of the GUI.

I'll have a crack with the new exe this weekend.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Post by s55 »

IF you see any exceptions at all, can you please please record them, screenshot them, whatever. They will be of help!
angelessme
Posts: 5
Joined: Fri Oct 12, 2007 1:12 pm

Post by angelessme »

Using the old exe the exception is:
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.312 (rtmLHS.050727-3100)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Accessibility/2.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

Haven't seen it with the new exe.
[/quote]
digitalaero
Posts: 1
Joined: Thu Nov 08, 2007 4:34 pm

GUI locks up after a while, CLI repeats last job endlessly

Post by digitalaero »

I am also having this problem. The GUI stops responding after a while. It works for some time, I can click on it and see the Queue, I can work with the Handbrake interface. After a while, now usually before even the first job finishes, the GUI stops responding. It will not re-paint the window or respond to anything. After the GUI has frozen like this, the hbcli just keeps repeating the last encode job that it processed when the GUI was responding in an endless loop.
I have disabled my screen saver. I have also completely removed Handbrake and re-installed it.
mshandony
Posts: 9
Joined: Thu Oct 11, 2007 5:25 pm

Post by mshandony »

Sorry for the long delay replying as to the success or failure of the special developer build of HandBrake.

I have processed around 15 DVDs now with the developer version and everything has gone smoothly. I have not seen the problem with the freezing GUI or the repeat encoding.

I will continue to test with it and if I have any issues, I will let you know.
bjurkovski
Posts: 1
Joined: Thu Nov 29, 2007 4:42 pm

Post by bjurkovski »

I too am having the same problem on Vista. Is the modified version still available to try. I can't seem to find it
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Post by s55 »

Nope sorry.

You can either wait to 0.9.2 or checkout the wiki article on compiling the source.
Post Reply