Do NOT put archive.txt and related entries into the download location paths, also allow output filename to be set about youtubedl-material HOT 2 CLOSED

Quick update on this issue:

Archives were moved to the appdata/archives in the last update. I also just got around to allowing global custom args to override output, so you can set the custom output globally (relevant commit).

Regarding file names with spaces when using custom args, this has also been fixed! You can see the relevant commit here. The only thing to note is that args are now delimited by double commas (,,) rather than a space.

from youtubedl-material.

Personally, I'd favor putting the archive related files into a specified directory.

You have a good point here, perhaps an appdata/archives folder can serve that role. I didn't want the audio and video archives to interfere, but I can just set them to have different names (like archive_audio.txt and archive_video.txt). I'll have to give it more thought.

Even when using a directory with underscores I get download failed errors.

Hm, I think I'm reproducing this bug too. This isn't expected behavior, I'll look more into it.

Snippet of error log when using video/%(uploader)s [%(channel_id)s]/%(upload_date)s - %(title)s [%(id)s] as output:

Just to clarify, you're using the custom output in Advanced mode, right? If so, and I need to update the Simulated output to reflect this, the Custom output is actually relative to your audio and video folders. So if you want it to end up in the video folder, you would use %(uploader)s [%(channel_id)s]/%(upload_date)s - %(title)s [%(id)s]. This shouldn't however, cause an error. It should just put the video in video/video/..., so it looks like something else is going on here.

However, as you can see there are definitely users who want to have a variable output directory, so expect that in your coding, but also a variable filename.

Good idea - there's a few roadblocks to implementing something like this. The file manager relies on a static output directory, so videos downloaded outside are not seen by it. The way the video/audio player is coded relies on static paths for non-subscription downloads, though this is easier to change.

I think the easiest way of implementing something like this is letting the global youtube-dl "-o" arg override the existing "-o", which it currently doesn't. It should be doing so anyways, so I'll consider that a bug worth fixing.

from youtubedl-material.