| Summary: | handbrake transcode estimated end time gives impossible value | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Ben McMonagle <westel> |
| Component: | RPM Packages | Assignee: | Chris Denice <eatdirt> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | lewyssmith |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | handbrake-1.5.1-1.mga9.tainted.x86_64 | CVE: | |
| Status comment: | |||
| Attachments: |
image indicating impossible end time
lspcidrake output conversion run today, start conversion run today, new impossible time conversion run today, finished |
||
|
Description
Ben McMonagle
2022-09-20 05:20:48 CEST
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 =>
RESOLVED |