View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005090 | MMW v4 | Other | public | 2008-12-27 02:05 | 2008-12-31 05:38 |
| Reporter | Assigned To | ||||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0005090: Podcast: Scan misses adding "duplicates" to PodcastEpisodes. | ||||
| Description | If two tracks have the same Album-Artist-Title and genre = 'Podcast' only one of the tracks is added to PodcastEpisodes. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1205 | ||||
|
|
Owyn, I don't quite understand. If two tracks have the same Album-Artist-Title and genre = 'Podcast' only one of the tracks is added to PodcastEpisodes. Isn't this intended? How MM could know which of the two episodes should be added? Do you have an example? |
|
|
Yeah. 4 in fact. It showed up in my (as yet unpublished) re-testing of the podcast functions. I have been running an audit report after each step to see if any of the "corruption" symptoms have showed up. In this case, tracks with Genre=Podcast with Songs.ID not in PodcastEpisodes.IDTrack. They are a consequence of: 1) GUID. These are truly distinct files which had been published with distinct guid but duplicate previous info in the feed. 2) "Mature" feeds in which the elder of the "duplicates" may no longer be in the current feed. Frequently these are detected by MM when the newer episode is downloaded. In this case the filename has "(1)" appended (if it is the first duplicate). I can force the track into the feed by appending something, e.g. "(1)" to the title. The imported episode may end up unmatched to any netsource but should still be shown in the subscriptions episode list. |
|
|
Ummm. More feedback required? |
|
|
Yes, currently the algorithm to associate newly scanned tracks to a podcast subscriptions works like this: Scan track's tag for Album, Title, Genre Associate those that have Album = [subscription name], Title = [episode title], Genre = 'Podcast'. Re: 1) Yes, we should use GUID for more precise comparing (e.g. two episodes with same title, but different GUID or URL source), but neither GUID or URL is not stored in tracks' tags. So we can work only with Album, Title, Genre info. Re: 2) "Mature" feeds in which the older of the "duplicates" may no longer be in the current feed. Yes, it is a problem, but we cannot do much about this. In both cases the imported episode may end up unmatched to any netsource but I don't think it should be shown in the subscriptions episode list, It could be rather annoying because of missing info from the feed - e.g. when sorting (by pub. date ?) etc. I think that it currently works quite fine and prevents from importing a duplicate track as it should. |
|
|
Reminder sent to: rusty Rusty, what do you think? |
|
|
FYI: I tested this before actually subscribing to any feeds. I was confirming that the basic scan function was working before proceeding with next steps in test plan. Re: 1)At this time it is possible to correctly download and link a "duplicate" but it is impossible to "refresh" the feed via Remove from Libary-Unsubscribe-Rescan-Resubscribe procedure. Re: 1&2)I think that "duplicates" in the episode list with NetSource=Unknown* are a much lesser problem than unlinked Songs with Genre=Podcast. We already can have scanned, un-duplicated episodes in the episode lists which stay as NetSource=Unknown* after subscribing the feed. Re: GUID) Yes, storing the info in a custom tag would be an elegant solution. |
|
|
See: http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=34296 For an example of a feed that is likely to cause this problem. |
|
|
I changed my mind, you seem to be right in several aspects, I fixed it according to your suggestion, tested on the example feed: http://www.971freefm.com/pages/podcast/43.rss i.e. now all scanned tracks with Genre = 'Podcast' are somehow assigned to subscriptions as you suggested. Hopefully this will satisfy most user needs. Fixed in build 1205. Re: GUID in special tag: The problem here is that another podcatcher doesn't store this info to tags therefore it will never fully work. |
|
|
Thanks. It is easier to explain to a user why a feed causes a problem than to explain why MM seems to be inconsistent. Understood about the limitations of GUID/URL in tag. It would be a strictly MM solution for episodes downloaded by MM. That said, it would improve reliability where the additional information was available for matching. If implemented it would have to be in a tag which is currently visible in Properties. But, no arm twisting on the item. Just my opinion. Podcasting support will never be perfect. The feed publisher can make too many arbitrary changes. |
|
|
Verified in 1205 |
