-
Notifications
You must be signed in to change notification settings - Fork 437
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
Pbar #57
Pbar #57
Conversation
Move ts files to src, build and output js files to build folder
this is triggered by signal events
I would leave the message that tell the user that there were no errors...or make it behind verbose Personally I like to know when a program like this runs successfully |
which message? |
The one you removed in the last commit |
ok, you can't print a success message when exit code is 0 because exit code could 0 when the program dies for other reasons, so we don't know what happened, but we know we should not tell the user everything is ok. |
I'm quite sure that if the program dies for any reason other than returning
at the end of the execution the code will not be 0
@snobu, your opinion on the exit message question?
|
I'll merge this as it is for now and we can tweak it as we go. |
signals can stop the execution and return 0 but it is not a success |
Yup, here's a CTRL-C in Node and PowerShell reporting back a happy exit 0.
|
Note to everyone involved, don't do a pull, start a fresh clone in a new folder since the structure has now dramatically changed to src/ and build/. I believe this to be the right move at this point as it was getting out of hand with those files sprayed out everywhere. |
Where is this coming from?
Is this expected or i'm launching it all wrong? |
Ah found it, it's building in |
So the progress works nicely but it never exists, just hangs like this: The file is there in the target output dir and is completed (muxed). I believe it hangs awaiting on the progress bar.
LATER EDIT: We could piggyback on .end() and pull the bar to 100% so it exists cleanly - tested, works. I'll let @kylon decide on the final implementation.
|
the progress bar should "kill" itself when the progress is 100% but here it is not, so it is waiting for the next update i would like to know why it s not 100, what is the currentChunk value and duration value (total chunks) |
Looks like it's an off by one problem as it always reaches 97%. Just print the chunks as it goes along maybe it reveals the flaw. |
my videos reach 100, i ll try more videos or is your video public? my ideas are: if the latter is the case, yeah we should move the bar ourself, otherwise it is probably better to see what happen to prevent future issues |
try this, it seems ffmpeg goes to end for the last chunk add this before ffmepg()
|
The question is, how reliable is the chunk counter, if we just do I'm more worried about what ffmpeg is feeding us than what we do in our method. There are dozens, dozens of slightly different builds of ffmpeg out there people use. |
yeah, i m fixing the video download and progress bar |
what you mean? |
I think that what @snobu meant is that being many different version of ffmpeg they might elaborate chunks slightly differently or they might feed sliglty different data into fluent-ffmpeg so we don't want to rely only on that and use that update(100) |
progress bar tested on linux and windows 10 (cmd and PS)