Backslash problem in global podcast options BUG #5213

[chrisjj]

> the nightmare scenario that occurs if (a) these unlikely files are created in the root directory and (b) you try to remove-and-delete one of them?

Out of interest, do you get the errors of b) if you don't do a)?

[Teknojnky]

I believe that this is a design flaw. The program should assume that the content of the field is a directory, and should automatically insert the trailing backslash if the user fails to do so. And of course the program should offer to create the dir if it does not already exist.

If you use the button to open the destination dialog, you will get a properly formatted folder path that includes the trailing backslash.

I'll create a ticket, in that edit box should allow only folder paths, or provide the set destination wizard if it is intended to allow user specified file naming masks (like for auto-organize etc).

I agree with Chris, that it should NOT be assumed that content field is a directory since you can currently use auto-organize masks, and a valid example might be:

C:\Podcasts\<artist>-<title> (podcast)

If the option assumed that was a folder, then you would get separate folders for every podcast, instead of one podcast folder with artist-title files.

[chrisjj]

> I'll create a ticket, in that edit box should allow only folder paths, or provide
> the set destination wizard if it is intended to allow user specified file
> naming masks (like for auto-organize etc).

Intention aside (esp give no docs), the fact that the installation default is [stuff]\My Documents\My Music\Podcasts\<Artist>-<Title> surely means naming mask support should be retained.

[rusty]

Hi,

We're not going to make any changes to the functionality here for 3.1 (though I think it would be a good idea to clarify the documentation). The take away lesson for me is that any time there's a mask configuration in MM, the Mask configuration wizard should be available.

Re. the bug about unpredictable behavior occuring when the podcast download mask is set to C:/Podcast, I could not replicate any strange behavior when attempting to delete such podcasts. If anyone else can, please share a debug log.

Thanks.

-Rusty