Description of problem: while transcoding a .vob file to .m4v file, the Handbrake queue summary gives an impossible end time (68 years prior). the impossible end time occurs when the transcode is indicated as completed by the "Queue" status bar , but the "red x" has yet to change to a "green tick". in this case, it took several hours to change from "red-x" to "green tick" Version-Release number of selected component (if applicable): handbrake-1.5.1-1.mga9.tainted.x86_64 How reproducible: Steps to Reproduce: 1.transcode .vob file to .m4v file. 2. 3.
Created attachment 13394 [details] image indicating impossible end time
Created attachment 13395 [details] lspcidrake output
Thanks for the report; the screenshot is useful. It shows the process as ongoing (unless the blue line is a progress bar => completed). Does the 'Encode Time' stay at zero even when the indicators eventually change? When the process eventually ended (indicators changed), was the output file correct? Can you see (needs retry) from the final size whether it had got there sooner (by monitoring its growth)? Does the problem happen with every use, or just this specific type of conversion, or just one specific file? Are there other cases where Handbrake works? [eatdirt]
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #3) > Thanks for the report; the screenshot is useful. It shows the process as > ongoing (unless the blue line is a progress bar => completed). Does the > 'Encode Time' stay at zero even when the indicators eventually change? > When the process eventually ended (indicators changed), was the output file > correct? Can you see (needs retry) from the final size whether it had got > there sooner (by monitoring its growth)? ran a new conversion, see attached screen shots, hopefully they answer. > Does the problem happen with every use, seems to. > or just this specific type of conversion, it is the file format I am using ATM, > or just one specific file? no > Are there other cases where Handbrake works? > this machine is used for a specific purpose, I will see if I can get some different file types and try it > [eatdirt] ?
Created attachment 13396 [details] conversion run today, start
Created attachment 13397 [details] conversion run today, new impossible time
Created attachment 13398 [details] conversion run today, finished
initial file: VTS_01_1.VOB, size: 1,016.0 MiB (1,065,353,216) converted file: VTS_01_1.m4v, size: 983.1 MiB (1,030,832,129)
Thanks for the additional evidence. It looks as if: - it starts correctly, end time = start time + estimated ? encode time. 15Mb. - then it goes wrong, silly end time, zero encode time, 418Mb. - eventually ends OK ?, end time = start + encode time, 983Mb. Two things: - The process time is excessive. - Why the huge growth in file size? --- Is the output file really that big? And does it work (is it valid)? Assigning to ChrisD who looks after this pkg. Something is clearly wrong.
Assignee: bugsquad => eatdirt
Yes! But that pb would certainly deserve to be checked and reported upstream. I'll have look!
We have shipped version 1.6.0 with Mageia 9. Some info is required to check if this bug is still valid.
Status: NEW => NEEDINFO
seems to be ok
Status: NEEDINFO => RESOLVEDResolution: (none) => FIXED