Backslash problem in global podcast options BUG #5213

[Neil Parks]

Using beta build 1212 under XP with Service Pack 3.

I created a directory "Podcast" under the root directory on drive C. In Global Podcast Options, in the field Download Podcasts To, I wrote in "C:\Podcast ".

When I downloaded some episodes of a couple of podcasts, i got an unpleasant surprise. Instead of going into the expected directory, they went into the root directory with such oddball names as "podcast.mp3", "podcast(1).mp3", etc.

I changed the DPT entry to "C:\Podcast\" with a trailing backslash, and downloaded some more episodes. This time I got what I expected. The files went into the Podcast directory, and the names properly reflected the episode titles.

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.

mod edit:
http://www.ventismedia.com/mantis/view.php?id=5213

[nohitter151]

Moved this to the beta testing forum as you have indicated you are using a beta build.

[chrisjj]

Moved this to the beta testing forum

How did you do that NH, since you are not listed as a moderator?

[chrisjj]

The program should assume that the content of the field is a directory

I disagree. Even though the behaviour of this field is undefined, in practice it accepts a filepath with variables e.g. C:\Documents and Settings\Chris\My Documents\My Music\<Artist>-<Title>, and your suggested change would break that behaviour for existing users.

I think the problem is that, like many MM features, this one is not properly documented - the dialog help doesn't even mention the control. I'd guess that had the dialog help showed you the format definition, your problem would not have occured.

And Devs, I suggest also neededing documentation is the automatic filename generation feature that causes "C:\Podcast\" to work, preserving original filenames, since this is certainly not obvious, even to a user who knows about the variables feature.

[Neil Parks]

It gets worse. I attempted to remove a podcast episode that had been downloaded as "podcast.mp3" in the root directory. I selected the option to both remove the episode and delete the file.

The error messages that popped up are the stuff of nightmares. I had to use the Task Manager to force Media Monkey to close before any real damage occurred.

[Neil Parks]

The program should assume that the content of the field is a directory

I disagree. Even though the behaviour of this field is undefined, in practice it accepts a filepath with variables e.g. C:\Documents and Settings\Chris\My Documents\My Music\<Artist>-<Title>, and your suggested change would break that behaviour for existing users.

Podcast files aren't the same as music tracks. The default filename (if the file download is handled correctly) includes the title anyway. E.g.:

Code: Select all

"Townhall.com Weekend Journal on Oneplace.com - Broadcast for Saturday, December 6, 2008.mp3"
"Townhall.com Weekend Journal on Oneplace.com - Broadcast for Saturday, December 13, 2008.mp3"
"Quinn and Rose on 640 WHLO - Quinn & Rose 1-12-09 Hour 1.mp3"
"Quinn and Rose on 640 WHLO - Quinn & Rose 1-12-09 Hour 2.mp3"
"Quinn and Rose on 640 WHLO - Quinn & Rose 1-12-09 Hour 3.mp3"
"Townhall.com Weekend Journal on Oneplace.com - Broadcast for Saturday, November 29, 2008.mp3"

[chrisjj]

Ah. Possibly a bug.

[chrisjj]

> The default filename (if the file download is handled correctly) includes the title anyway.

"Anyway"?? Are you saying the default filename's inclusion of the title is not due to the default filepath spec's (C:\Documents and Settings\Chris\My Documents\My Music\Podcasts\<Artist>-<Title>) inclusion of the title?

> "Quinn and Rose on 640 WHLO - Quinn & Rose 1-12-09 Hour 1.mp3"

Looks just as one would expect from a filepath spec including Title, to me. Though it has spaces the default does not.

[Neil Parks]

"Anyway"?? Are you saying the default filename's inclusion of the title is not due to the default filepath spec's (C:\Documents and Settings\Chris\My Documents\My Music\Podcasts\<Artist>-<Title>) inclusion of the title?

But I'm not using the "default filespec". The DPT field contains only "c:\Podcast\".

[chrisjj]

> But I'm not using the "default filespec". The DPT field contains only "c:\Podcast\".

I guess it was you that removed the <Artist>-<Title> segment. Guessing that MM would fill in what you wanted, and being lucky.

Thing is, "The program should assume that the content of the field is a directory" would mess up those people using this control in the way that is primarily intended e.g. with the default filespec. Only a terminating slash can distinguish between a directory and file.

[nohitter151]

> But I'm not using the "default filespec". The DPT field contains only "c:\Podcast\".

I guess it was you that removed the <Artist>-<Title> segment. Guessing that MM would fill in what you wanted, and being lucky.

Thing is, "The program should assume that the content of the field is a directory" would mess up those people using this control in the way that is primarily intended e.g. with the default filespec. Only a terminating slash can distinguish between a directory and file.

I agree with chrisjj. This is the standard way that MM handles all files.

[Neil Parks]

Compromise suggestion: If the entry in DPT ends with a variable, e.g. <Artist>, consider it a file name and don't append a backslash. If it ends with a constant, consider it a directory so that we don't create "podcast[1}.mp3".

[nohitter151]

Compromise suggestion: If the entry in DPT ends with a variable, e.g. <Artist>, consider it a file name and don't append a backslash. If it ends with a constant, consider it a directory so that we don't create "podcast[1}.mp3".

What then, in the unlikely (but viable) case that someone actually wants their podcasts saved as "Podcast.mp3", "podcast (1).mp3", etc. ?

[chrisjj]

What then, in the unlikely (but viable) case that someone actually wants their podcasts saved as "Podcast.mp3", "podcast (1).mp3", etc. ?

Indeed. I appreciate Neil's POV but from many years of seeing this recur in different situtations I have learnt that that only constant that is completely free to distinguish directory and filename is one that cannot end a filename... and that leaves no better choice than '\' itself.

[Neil Parks]

What then, in the unlikely (but viable) case that someone actually wants their podcasts saved as "Podcast.mp3", "podcast (1).mp3", etc. ?

Perhaps he should be given a sobriety test?

Did you get a chance to try to replicate 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?