Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLI] videodownload: Calculate percentage in "Finalizing Video" by file size #991

Closed
2 tasks done
superbonaci opened this issue Mar 17, 2024 · 6 comments
Closed
2 tasks done

Comments

@superbonaci
Copy link
Contributor

superbonaci commented Mar 17, 2024

Checklist

Edition

Unsure

Describe your issue here

Step 5/5 in most cases only displays the 3 dots instead of the real percentage:

TwitchDownloaderCLI videodownload -u 2065608792 -o 2065608792.mp4
TwitchDownloaderCLI 1.54.1 Copyright (c) lay295 and contributors
[STATUS] - Fetching Video Info [1/5]
[STATUS] - Downloading 100% [2/5]
[STATUS] - Verifying Parts 100% [3/5]
[STATUS] - Combining Parts 100% [4/5]
[STATUS] - Finalizing Video... [5/5]
[STATUS] - Finalizing Video 100% [5/5]

All the percent values are 2147483647 except the first which is 0 and the last is 100. My feature request is to compare the file size of the output to output.ts file size, and use that as percent for mp4. For .m4a adjust also.

Add any related files or extra information here

No response

@superbonaci superbonaci added the bug Something isn't working label Mar 17, 2024
@superbonaci superbonaci mentioned this issue Mar 17, 2024
1 task
@ScrubN
Copy link
Collaborator

ScrubN commented Mar 19, 2024

The size of the final mp4 is different from the size of the combined ts (and frankly I want to rewrite finalization so combining is never performed) so this is not plausible. Believe me, I tried to find a correlation between the ts and mp4 file sizes for #770 but did I could not find a pattern, hence the language "may not".

I'd rather try to fix the root issue, however I have never been able to reproduce the out of bounds percent values so I cannot debug anything.

@ScrubN
Copy link
Collaborator

ScrubN commented Mar 19, 2024

Also, reading from ffmpeg stdout is much cheaper than making fs calls.

@superbonaci
Copy link
Contributor Author

The issue comes from this line:

double seekDuration = Math.Round(downloadOptions.CropEndingTime - downloadOptions.CropBeginningTime);

if the user doesn't set -e to the video duration it will be 0.

@superbonaci
Copy link
Contributor Author

I'll add a fix to the PR if I find how to fix it.

@ScrubN ScrubN removed the bug Something isn't working label Mar 21, 2024
@ScrubN
Copy link
Collaborator

ScrubN commented Mar 21, 2024

#1004 fixes the root issue that causes the -2147483648% percent

@ScrubN
Copy link
Collaborator

ScrubN commented Mar 29, 2024

Because audio encoding is non-deterministic, this will probably never be possible with the same or better accuracy than parsing the timecode from FFmpeg stdout.

@ScrubN ScrubN closed this as not planned Won't fix, can't repro, duplicate, stale Mar 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants