youtube-dl: «File name too long» should not error

This is particularly annoying when downloading videos from Twitter as it takes the whole post as file name. I usually use --id and rename the file manually.

But my ticket is addressing a different point. Shrinking/truncating long filenames should be default. It would be an immense step forward in terms of UX to go to «it just works, emits a warning» from «it does not work, errors out; search the error / skim the FAQ».

Of course, if the user has specific needs, they should be able to turn this off and get an error. (maybe via --fixup option).

Il 06 settembre 2021 alle 19:33 dirkf ha scritto:

The general solution to this is a FAQ entry

### My download fails because youtube-dl is trying to write to a file whose name is too long for the file system.

Use the `--get-filename` option to see what filename is being proposed. Then adjust, or add, the `-o`/`--output-template` option in your original youtube-dl command to make the filename shorter. For instance, if the extractor for the site sets a very long `title` field and you are using the default output template `%(title)s-%(id)s.%(ext)s`. you could try `-o %(title).50s-%(id)s.%(ext)s` instead to limit length of the filename.

– You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/ytdl-org/youtube-dl/issues/29912#issuecomment-913945852

--trim-filenames is a poorly implemented solution from youtube-dlc and I would not recommend porting it as-is. Even in yt-dlp, I recommend users to use the % formatting to control filename length instead. E.g. https://github.com/yt-dlp/yt-dlp/issues/3494

In the case of Twitter, id is NOT being truncated, which is a plus…

This is actually a bug and shows how poorly implemented the option is! See https://github.com/yt-dlp/yt-dlp/issues/2314. Do not rely on this behavior…

The general solution to this is a (new) FAQ entry

### My download fails because youtube-dl is trying to write to a file whose name is too long for the file system.

Use the `--get-filename` option to see what filename is being proposed. Then adjust, or add, the `-o`/`--output` option in your original youtube-dl command to make the filename shorter. For instance, if the extractor for the site sets a very long `title` field and you are using the default output template `%(title)s-%(id)s.%(ext)s`. you could try `-o %(title).50s-%(id)s.%(ext)s` instead to limit the length of the filename.

Plainly it’s not a showstopping issue but it is one that generates repeated complaints. It’s still open in case someone is eventually intrigued enough to work out a solution that meets an adequate subset of the problem constraints, after spending however long it takes locked in the basement with the necessary cold towels wrapped round the head. But we should fix Twitter/X if the extractor is ever viable and updated post-Musk.

Some fields are more important than others, like the unique ID’s, hashes, and file extensions can never be allowed to be truncated. As few as possible known fields could have an importance priority floating point number internally assigned in the extractor.

^ Then, generally, you can truncate all other fields equally to fit, as it’ll be more important to have some knowledge of the contents in the filename than have none at all, and 125, not to mention 255, chars per segment (or even a full path) is a lotta text. If the User is hellbent on changing a sensible default into something very much non-sensible like ID + hash + keywords/tags + collection name + description, that’s their fault.

Something like that.

I don’t see that --trim-filenames ... is much of an improvement on setting an explicit length for a problem field (title, I’m looking at you) in the output template.

A good solution would:

• never write a file whose pathname is too long for the filesystem (even for intermediate files)
• apply generally regardless of extractor and output template combinations
• not require user intervention, such as having to guess a parameter value and pass it to avoid filename length errors
• not alter any ID fields in the output template
• any more?

Clearly these are not completely consistent requirements, as an output template might be, say, %(id)16777216s.%(ext)s. Some prioritisation is necessary.

I still hold that the excessive filename length provoked by Twitter is an extractor bug.

@bryanpaget, you might like to reveal more details of how you “[ran] into this issue”, or is it just Twitter again?

Also, feel free to review the discussion in PR #29989 to understand why this is a difficult issue to fix retrospectively (other than by following the approach in https://github.com/ytdl-org/youtube-dl/issues/29912#issuecomment-913945852), and possibly contribute to the design of a general solution.

The defaults really do work in the vast majority of cases.

You can write a config file with your preferred options and select it with --config-location in your script if some default setting should not be satisfactory (or just make it your default config).

For instance, you could put -o %(title).50s-%(id)s.%(ext)s to avoid downloads being broken by unreasonably long titles.

If anyone has a suggestion for what (reliably concise) metadata item could be used as the title for media extracted from Twitter, we could make a PR for Twitter specifically.

#30839: “if you were actually running yt-dlp …”

Also, 90 isn’t a “constant”: pick a number that works.

What is this? The 90s? This shouldn’t be an error at all.

Depends on who/what you blame.

I’ve just tonight run into this bug with the Twitter extractor. You can reproduce it with the following:

youtube-dl https://twitter.com/TulsiGabbard/status/1555878318469091330
[twitter] 1555878318469091330: Downloading guest token
[twitter] 1555878318469091330: Downloading JSON metadata
[twitter] 1555878318469091330: Downloading m3u8 information
ERROR: unable to open for writing: [Errno 36] File name too long: 'Tulsi Gabbard 🌺 - Puberty-blocking procedures promoted by the Biden_Harris Admin are child abuse. The FDA has recently confirmed these hormones_drugs have extremely dangerous side effects, like brain swelling and vision loss.-1555878318469091330.mp4.part'

Would you be open to a Twitter specific workaround patch? Perhaps the title could be changed to a combination of the uploader name and date, with the tweet text moved to the description field?

I don’t see any other reasonable solution for the Twitter extractor. Maybe it could pre-truncate the post? That’s not any better than just doing it later when constructing the output file name though.

I’ve run into this issue many times, as I usually want to use youtube-dl to quickly download a video to my downloads folder and I don’t really care about the name but would prefer it give as much information as possible (so I don’t want to just default to using the id).

I would really, really love it if somebody made a youtube-dl flag --just-download-it-seriously-i-dont-care-about-the-details-just-do-your-best-i-believe-in-you, bonus points if that’s the default, but even just having it available so I can write a wrapper script or bash alias that uses it would be amazing.