malikatan wrote:First, the date field gets modified by MM from yyyy/mm/dd to yyyy, so I cannot know the order of episodes.
That's actually surprising -- it suggests that the podcast's feed has something odd about it. Could you right-click on the podcast's entry under the Podcast > Subscriptions tree, click on "Edit Subscription", and let us know whether that podcast has its "Customize subscription rules" box checked? If so, does it have the "on download, tag ..." box checked? Then, please click on the "Global Podcast Options" button at the bottom of that window, and let me know if the "On download, tag..." checkbox is marked in the global options?
malikatan wrote:Similarly, MM over-writes the file name with the text from the "title" field. The original file name contains the year/month/date.
I'm not sure whether MM can fix that (currently). I don't know whether it's capable of simply saving a file using the same filename as on the server it downloaded from; MM doesn't have a tag for that. I have some vague memories of a podcast that didn't have any information in its feed, and I vaguely recall MM3 correctly saving the files with the same name as they had on the server; but I can't check that anymore.
malikatan wrote:Often, the podcasts don't fully download. In the end, I get a bunch of duplicate podcasts listed and multiple versions of the podcast in the podcast folder and no podcasts to listen to. I have found that the only way to fix is to delete the podcast subscription and re-download everything (one file at a time so things don't get too messed up). Is this normal behavior?
When you say "don't fully download", do you mean that the episodes are shorter than they should be? I had that problem for a LONG time -- I haven't seen it again since I upgraded recently. I'm using 4.0.7, how about you?
Now, I currently see a different problem: I get tens of identical downloads, all put into different files and all apparently otherwise identical -- apparently MM keeps trying to download over and over again. Is that your problem as well?
The interesting thing is that all but one of the downloads has a Song.IDEpisode field of -1, meaning that MM thinks all of the other identical Songs are not actually podcast episodes. The one that's correctly assigned a Song.IDEpisode is almost always in the middle of the pack as far as Song.ID goes, and they all have exactly identical Date Added fields.
Speculation: MM's podcast updater code was moved into the new download manager, and in its new location it's losing track of which episode downloads were actually started, so it starts them over and over. This would certainly help explain why updating podcasts often eat more CPU and I/O power than my machine actually has (it even briefly stops the mouse cursor from moving).
Hmm, I just thought of a new experiment I could do with database triggers to narrow this down: I'm going to see whether the new songs are having their Song.IDEpisode field changed from the correct value to -1. If that's happening I can figure out a trigger to drop such pseudoepisodes into a playlist where I can destroy them at my leisure. That won't fix the real problem (MASSIVE overdownloading), but it'll make it possible to clean up afterwards.
-Wm
[quote="malikatan"]First, the date field gets modified by MM from yyyy/mm/dd to yyyy, so I cannot know the order of episodes.[/quote]
That's actually surprising -- it suggests that the podcast's feed has something odd about it. Could you right-click on the podcast's entry under the Podcast > Subscriptions tree, click on "Edit Subscription", and let us know whether that podcast has its "Customize subscription rules" box checked? If so, does it have the "on download, tag ..." box checked? Then, please click on the "Global Podcast Options" button at the bottom of that window, and let me know if the "On download, tag..." checkbox is marked in the global options?
[quote="malikatan"]Similarly, MM over-writes the file name with the text from the "title" field. The original file name contains the year/month/date.[/quote]
I'm not sure whether MM can fix that (currently). I don't know whether it's capable of simply saving a file using the same filename as on the server it downloaded from; MM doesn't have a tag for that. I have some vague memories of a podcast that didn't have any information in its feed, and I vaguely recall MM3 correctly saving the files with the same name as they had on the server; but I can't check that anymore.
[quote="malikatan"]Often, the podcasts don't fully download. In the end, I get a bunch of duplicate podcasts listed and multiple versions of the podcast in the podcast folder and no podcasts to listen to. I have found that the only way to fix is to delete the podcast subscription and re-download everything (one file at a time so things don't get too messed up). Is this normal behavior?[/quote]
When you say "don't fully download", do you mean that the episodes are shorter than they should be? I had that problem for a LONG time -- I haven't seen it again since I upgraded recently. I'm using 4.0.7, how about you?
Now, I currently see a different problem: I get tens of identical downloads, all put into different files and all apparently otherwise identical -- apparently MM keeps trying to download over and over again. Is that your problem as well?
The interesting thing is that all but one of the downloads has a Song.IDEpisode field of -1, meaning that MM thinks all of the other identical Songs are not actually podcast episodes. The one that's correctly assigned a Song.IDEpisode is almost always in the middle of the pack as far as Song.ID goes, and they all have exactly identical Date Added fields.
Speculation: MM's podcast updater code was moved into the new download manager, and in its new location it's losing track of which episode downloads were actually started, so it starts them over and over. This would certainly help explain why updating podcasts often eat more CPU and I/O power than my machine actually has (it even briefly stops the mouse cursor from moving).
Hmm, I just thought of a new experiment I could do with database triggers to narrow this down: I'm going to see whether the new songs are having their Song.IDEpisode field changed from the correct value to -1. If that's happening I can figure out a trigger to drop such pseudoepisodes into a playlist where I can destroy them at my leisure. That won't fix the real problem (MASSIVE overdownloading), but it'll make it possible to clean up afterwards.
-Wm