Windows Handbrake 0.9.1 - queue still has problems
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.
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.
Windows Handbrake 0.9.1 - queue still has problems
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
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
#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)
#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)
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.
- 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.
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.
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.
-
- Posts: 2
- Joined: Tue Oct 16, 2007 12:53 am
-
- Posts: 2
- Joined: Tue Oct 02, 2007 12:46 pm
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.
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.
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.
-
- Posts: 5
- Joined: Fri Oct 12, 2007 1:12 pm
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.
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.
-
- Posts: 2
- Joined: Tue Oct 16, 2007 12:53 am
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.
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.
It won't be a settings issue. All that happens is the settings are converted into a query string. e.g
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.
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.)-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
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.
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.
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.
-
- Posts: 5
- Joined: Fri Oct 12, 2007 1:12 pm
-
- Posts: 5
- Joined: Fri Oct 12, 2007 1:12 pm
Using the old exe the exception is:
Haven't seen it with the new exe.
[/quote]
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]
-
- Posts: 1
- Joined: Thu Nov 08, 2007 4:34 pm
GUI locks up after a while, CLI repeats last job endlessly
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.
I have disabled my screen saver. I have also completely removed Handbrake and re-installed it.
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.
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.
-
- Posts: 1
- Joined: Thu Nov 29, 2007 4:42 pm