3 small issues with latest youtube-dl.py

[joeschmoe40]

1. If the file already exists, it still overwrites the *.description file.
   (It does catch and refuse to overwrite the *.flv file, but it has already
   overwritten the description file)

2) If you use --console-title, the console title is left changed (messed up)
after the program exits (at least on Mac OSX).

3) It would be nice to be able to use --console-title with -q. I.e.,
squelch all the usual terminal chatter, but still see the console title
indicate activity. Currently, if -q is present, --console-title is ignored.

Note: All testing was done using the latest version (2013.11.15.1), under Mac OSX.

Hopefully #2 and #3 are clear. To clarify #1, do following:

$ touch xxx.flv xxx.flv.description
$ youtube-dl.py --write-description -o xxx.flv http://youtube/something...

It will correctly tell you taht xxx.flv already exists, but it will have already overwritten xxx.flv.description. This seems to me to be a bug.

[phihag]

Thanks for the report. In the future, feel free to create multiple issues here at the GitHub system for multiple issues. Otherwise, the discussion becomes very cluttered. I've moved points two and three into their own bugs where we can discuss them (Click the button at the very bottom of the bug webpage to get informed of changes).

I'm not sure why overwriting the description file is a problem. We don't download any more information for it, and the file is rather small, so this should typically take only a split second. While the video hasn't been changed, its description may have. For example, some uploaders post an errata after receiving comments. Additionally, many video services only require the file and maybe the title in the upload form, so it's (at least for me) pretty common to see video descriptions being edited after upload and possibly download. So why is overwriting the description file a problem for you?

[joeschmoe40]

It's a problem if the two things being downloaded are not the same video - or even not related at all.

Suppose I have downloaded a song, say, Happy Birthday, sung by group X, and named it HappyBirthday.flv (and HappyBirthday.flv.description).  Now, sometime later, say a year later, I find a new version of Happy Birthday, sung by group Y.  And let's say I like both versions and want to have and keep both versions, but I forget that I've already downloaded the version by  group X - or, for whatever reason, I forget to check that HappyBirthday.flv already exists in my downloads directory.

So, I go ahead and download the "group Y" version as HappyBirthday.flv.  I get an error message that HappyBirthday.flv already exists, which is a Good Thing, but, alas, HappyBirthday.flv.description has already been over-written.  So, I end up with the same 2 files as I had at the start, but, alas, the .flv is for the "group X" version, while the .flv.description file is for the "group Y" version.  Not Good. 

And, I may not be able to fix this (i.e., to get the "group X" description file back), because I might not know the original URL that I used to get the "group X" version (or it might have changed, been deleted, any number of things can go wrong in the constantly changing world of YouTube).

Does that help in clarifying why it is a problem?

[phihag]

That problem can be solved by using good filenames, and that's one of the reasons why the default filename format includes the video ID. Furthermore, actual videos typically contain more information in the title, so I'd think name collisions are rather rare even if the filename contains neither uploader nor video ID.

If we were to check that the flv (or description file) existed and then not write the description file, this would make it impossible to update just the description / video info without redownloading the file. So I'm sorry, but either way we're breaking somebody's use case, and I believe your problem does not occur with the default naming scheme, and is rather rare in general - How often do filenames collide for you? Have you considered using the video ID or uploader in the filename?

[joeschmoe40]

OK - I accept your position and have already worked around the problem in my script(s).

Suffice it to say that I specifically avoid using the default filenames, preferring to always use the "-o" option to explicitly specify a simple output filename.  This is for the usual reasons regarding the wisdom of avoiding the use of spaces and other "funny" characters in filenames.

So, no worries...

On Sunday, November 17, 2013 10:55 AM, Philipp Hagemeister notifications@github.com wrote:

Closed #1780.
—
Reply to this email directly or view it on GitHub.

[phihag]

Are you aware of the --restrict-filenames option, which will remove spaces and "funny" characters? Also, neither should be a problem on a modern OS such as Mac OS X.