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

report_destination before sleeping #17301

Closed
amishmm opened this issue Aug 22, 2018 · 5 comments
Closed

report_destination before sleeping #17301

amishmm opened this issue Aug 22, 2018 · 5 comments

Comments

@amishmm
Copy link

@amishmm amishmm commented Aug 22, 2018

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2018.08.22. If it's not, read this FAQ entry and update. Issues with outdated version will be rejected.

  • I've verified and I assure that I'm running youtube-dl 2018.08.22

Before submitting an issue make sure you have:

  • At least skimmed through the README, most notably the FAQ and BUGS sections
  • Searched the bugtracker for similar issues including closed ones
  • Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

  • Bug report (encountered problems with youtube-dl)
  • Site support request (request for adding support for a new site)
  • Feature request (request for a new functionality)
  • Question
  • Other

Description of your issue, suggested solution and other information

This is minor enhancement request when downloading playlist videos with sleep between 2 downloads, using --sleep-interval / --max-sleep-interval

youtube-dl first sleeps and then prints the name of the file (which is more or less title of the video)

[download] Sleeping 11.85 seconds...
[download] Destination: some_title.webm

Sometimes sleeps are more than 30-45 seconds and I have to wait to find out which video its going to download next.

I request to rearrange this a bit ... first print the filename and then sleep.

[download] Destination: some_title.webm
[download] Sleeping 11.85 seconds...

This can be achieved by calling self.report_destination(filename) inside download() function of common.py.. i.e. just before sleep call which happens just before real_download() function call.

This will also eliminate report_destination(filename) lines located inside many "downloaders". And instead bring it to one single place. (common.py)

I can create a PR if developer wants.

@dstftw
Copy link
Collaborator

@dstftw dstftw commented Aug 22, 2018

No such change will be accepted since downloaders may output arbitrary messages (like [hlsnative] Downloading m3u8 manifest) before actual writing to file (that is [download] Destination: stands for) so that this will break logical flow.

@dstftw dstftw closed this Aug 22, 2018
@amishmm
Copy link
Author

@amishmm amishmm commented Aug 22, 2018

Ok how about changing output slightly from

[download] Sleeping 11.85 seconds...

to

[download] Sleeping 11.85 seconds for info_dict['title'] ...
OR
[download] Sleeping 11.85 seconds for filename ...

@dstftw
Copy link
Collaborator

@dstftw dstftw commented Aug 22, 2018

I won't do any adjustments just to fit some particular case. If you want to get title before downloading then you have to separate info extraction and actual downloading or even handle downloading on your own.

@amishmm
Copy link
Author

@amishmm amishmm commented Aug 22, 2018

But info_dict and filename are already available at that stage. There is no need to change anything. I am just requesting to be more verbose in output. In any case, thank you for your prompt replies.

@dstftw
Copy link
Collaborator

@dstftw dstftw commented Aug 22, 2018

Then use it. I've already pointed out how you should do that. And again: I'm not going to do any verbosity changes just to fit your concrete case. You want "sleeping X seconds for filename", someone may want to have "sleeping Y seconds for filesize video", someone may already rely on current wording. This output is not supposed to be used as source of metadata. For metadata you have info dict that you must use.

@ytdl-org ytdl-org locked as resolved and limited conversation to collaborators Aug 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.