More precise remaining time calculation, ui.py split #42
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 8 commits
September 5, 2020 23:25
sezanzeb
changed the title
added 3 commits
September 6, 2020 17:56
…aining-time-calculation # Conflicts: # soundconverter/interface/ui.py
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
More precise remaining time calculation by replicating how soundfiles are distributed among processes. It also calculates a correction factor based on historic calculations and actual outcomes. The leftover problems are, that the decoding speed of the source files depends on the format. If it werent for the uncertain encoding speed due to various settings, the only way to avoid that would be to generate a lookup table of
type -> bitrate -> relative speed, query the closest value and multiplicate that on the second return value ofget_progressin converter.py. Even worse, the conversion speed for files slows down over time, and I need to fit a linear function to it and do some integration and inversion stuff, and I can't do that quickly and need to properly verify what the hell I'm doing since it has been a few years since I learned that.The progressbar doesn't reflect how many seconds of data have been converted anymore, but rather how much of the time has passed. As long as all processes are working, this is almost identical. This avoids having an almost full progressbar when a single process is still working on a large file that takes a long time to finish. Since this calculation happens only once per second, it is wrapped into a class that interpolates smoothly to the next value.
Created multiple files from ui.py, because that file was very long and contained multiple classes