podcast download problems

[malikatan]

I am having a number of problems with podcasts.

First, the date field gets modified by MM from yyyy/mm/dd to yyyy, so I cannot know the order of episodes.

Similarly, MM over-writes the file name with the text from the "title" field. The original file name contains the year/month/date.

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?

I hate to say but iTunes work WAY better for podcasts!

Unfortunately, if I use iTune to download podcasts and upload them to my iPhone (a) it completely messes up the album covers of song upload from MM and (b) MM erases them next time I sync with MM.

Has anybody had luck getting podcasts to download cleanly and/or using iTune for download?

I have an iPhone 4 with 6.0.1 and I am using MM 4.0.7.1511.

[nohitter151]

Options > Downloads/Podcasts

Toggle the option "On download, tag episodes based on data from Podcast feed"

[wtanksleyjr]

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?

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.

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

[wtanksleyjr]

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.

Experiment didn't work -- the trigger works, but MM doesn't display the resulting comment2 field. It's just a blank, even though the field itself is populated when I look at the SQL tables. I have absolutely no idea what's wrong. Worse yet, the field IS displayed for most tracks. Unfortunately, this converts this from "an experiment" to "a headache".

-Wm