2.5.1 - Subfolders data keys not accounting for parent content versus nested content with {{channelName}}

[kauffy]

I just discovered this-- one of my channels has a number of threads that I was/am treating as subchannels. When DDG encounters this, it will create a new directory for the thread by name (great!) but it will create that directory at the same level as its parent channel, removing the channel from the path.

You can see from the "Finished history" lines what the name and path to the thread is as far as Discord is concerned, and then you can see from the filenames that are saved, where they are going.

[get-got]

The most ideal solution I came up with in terms of retaining all current functionality while minimizing settings additions/changes was to add a "subfoldersFallback" setting which now exists alongside all "subfolders" in any context as of https://github.com/get-got/discord-downloader-go/commit/a92234b433d8e8792a964ad3bc7702999ec4b427

The functionality for thread + parent naming like you want already exists, you can use the keys {{forumName}} and {{threadName}} in the subfolders to achieve this, but then any non-thread content being handled will have those unparsed keys in the folders, since there is no thread/parent. I had designed it with the assumption that you would be specifically targeting nested sources like threads in a forum or specifically targeting a normal channel, not both simultaneously.

To remedy this with "subfoldersFallback", you should do something like this:

{
    "destination": "aaa",
    "subfolders":           [ "{{forumName}}", "{{threadName}}" ],
    "subfoldersFallback":   [ "{{channelName}}" ]
}

The fallback subfolder structure will be used if the initial structure encounters any unparsed data keys (remnant {{ and }}). So in this case, it will always try to use the Parent & Thread names, but if they fail to parse, meaning it isn't a thread message being handled, it then falls back to just using the channel name.

If there is no fallback, it will leave the unparsed keys and handle everything just as it did prior to this change.

[kauffy]

That sounds like a good solution-- for my needs, though a case anyone is likely to encounter is ad-hoc threads, where the thread gets created kind of at random, then this configuration has to be set up for it. For example, in the channel where this matters, I was getting clutter, so I just started the threads.

Is "forumName" the value for "channelName" when a thread is involved?

To me, the logical behavior would be to check if there's a thread, and if there is, just put it in the thread-named subfolder in the channel's folder. Another would be to do what it's doing now, creating a new top-level folder with the thread name, except prepend it with the channel name.

[get-got]

I get your idea, but this was ultimately the ideal solution to be able to retain current functionality of data keys at both the parent and thread level, while being a solution for both this issue and potentially any other related issues. I'll add it to documentation on next release for anyone who may be searching to make it easier. This is mostly just a remedy for you, most people just want things downloaded and don't care how they're organized.

Is "forumName" the value for "channelName" when a thread is involved?

Yes