View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003086 | MMW v4 | Other | public | 2007-06-04 10:44 | 2008-03-21 14:58 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0003086: Podcasts: (command to) Automatically look up previously downloaded episodes for given rss feed. | ||||
| Description | This idea came from http://www.mediamonkey.com/forum/viewtopic.php?t=17942 where a user would like to have an command to automatically look up already downloaded episodes and import these episodes into a subscribed rss feed so that he doesn't have to download them all again in case he has already downloaded it by previous rss programs. | ||||
| Additional Information | Technically we could perform this look up by comparison of episodes' file size, there would be very low probability (~ 1/1000000) that two episodes are of the same file size and in case it is, we could compare first X bytes (1000 bytes ?) to ensure that this episodes contain the same data. The whole process could run on the background and could be executable through a command from context menu of given rss feed. Note: Only files located in the podcast directory (chosen in options) would be searched by this process. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1146 | ||||
| has duplicate | 0004403 | closed | rusty | Auto associate podcasts in a library with Podcast subscriptions |
| related to | 0004422 | resolved | Ludek | Podcast sub. generates a new random key for the same episode everytime -> results in epis. dups |
| related to | 0004549 | closed | Ludek | Importing Podcasts doesn't work for some non-default download locations including masks. |
|
|
I agree that this might be useful, but I'd rather see this implemented as a plug-in by some of our users, so that we don't have to do it and that it doesn't unnecessarily appear in menus for users who don't need it. |
|
|
I would like to implement this, but I guess that it is too late in the MM 3.0 release cycle because we don't have a string for this command. I would suggest something like 'Look up previously downloaded episodes' as a command in context menu for given rss feed (next to 'Update podcast' command) But 'Look up previously downloaded episodes' text is too long, we need something shorter, maybe Rusty would suggest a suitable text string. |
|
|
I've got another idea how to solve it without adding such a command. The process could be performad on the first update immediatelly after new subscribing with dialog: "Would you like to look up already downloaded episodes (by a previous podcaster) that are presented in your podcasts directory?" [Yes] [No] Raising to immediate because of the new text string. |
|
|
To tell you the truth, I'm a bit wary of adding this at this stage since -it adds UI complexity -I'm not clear about the means by which previously downloaded podcasts would be detected and whether they would actually be labelled as 'Podcasts' by MM (i.e. would the 'old' Podcasts appear in the Podcasts node in the auto-sync dialog?). Can't this be implemented without _any_ UI? i.e. a) During a scan, automatically label any Tracks that Match Filter=Podcast as a podcast b) During podcast updates, do the camparison, against previous podcasts, and then if the file is detected, just indicate that the detected episodes have already been downloaded. BUT the danger is then that MM may automatically delete podcasts unintentionally. --i) label them as Podcasts --ii) indicate ' |
|
|
I'd rather defer this. |
|
|
Changed Priority to 'high' |
|
|
As I wrote, there is a need to perform this per subscription, because the tracks need to be at least partialy compared with its opposite on the internet (via subscription URL link) Because we don't know the link we _cannot_ do a) During a scan, automatically label any Tracks that Match Filter=Podcast as a podcast -> not possible b) ...and because we need the episode to be at least partialy compared with its opposite on the internet (via subscription URL link) the process is time consuming and should not be performed automatically on each podcast update, because it could slow down the 'Update Podcast' process. i.e. We need at least one of the two _small_ UI changes I suggested above. 1) The process could be performed on the first update immediatelly after new subscribing with dialog: "Would you like to look up already downloaded episodes (by a previous podcaster) that are presented in your podcasts directory?" [Yes] [No] 2) The whole process (running on the background) could be executable through a command from context menu of given rss feed (next to 'Update podcast' command). The 1) seems to be better in my opinion. But as you wrote we are probably deffering it from MM 3.0 |
|
|
I agree that a more automated approach makes sense. What do you think of adding a global parameter to a section above Global Podcast Options: [x] Search for episodes locally before downloading New Subscriptions / Updates Location to search: _\My Music\iTunes\Podcasts_________________________[browse] Tooltip: Searches locally for Podcast episodes that have been previously downloaded before attempting to download them again via a new subscription or manual update. Note: The only reason I prefer this is that: a) it wouldn't pop up the dialog every time b) it would allow the user to associate episodes after the initial subscription |
|
|
I'd suggest to solve this without any additional UI by considering anything in Podcast folder (by default in <My Music>\Podcast) to be a podcast. An example of workflow could be like this: 1. MM scans Podcast folder for the very first time and finds a couple of tracks. They are flagged as Podcasts and categorized according to their Album field(?) since we don't have anything better in tag (e.g. URL). I.e. for each Album there is a dummy Podcast created with all episodes found. 2. User can create new Podcasts then or enter an URL to one of the Podcasts created in step 1., which would make the Podcast 'live' (MM would know how to download new episodes). 3. As suggested above, in step 2. MM could try to match already downloaded episodes with new ones based e.g. on size of tracks or some other criteria. |
|
|
I like Jiri's suggestion. The only issue would be whether it would work in cases where the user initially has Podcasts that aren't in MM's podcast folder. e.g. Supposing iTunes podcasts are stored to My Music/iTunes/podcasts, and MM's podcast directory is My Music/podcasts. In that case the initial scan of /My Music would not cause the iTunes podcasts to be labelled as podcasts. For scenarios such as the one above, what workflow would you propose? I suppose either of the following would work? 1) User changes MM Podcast directory to /My Music/iTunes/podcasts and then rescans /My Music OR 2) User moves contents of /My Music/iTunes/podcasts to /My Music/podcasts and then rescans /My music |
|
|
Correct, these are the ways I suppose users could go in such a case. Since it seems that we are in agreement, assigning to Ludek to implement in MM 3.1 (or possibly even sooner, no UI should be needed). |
|
|
ok, I have implemented this in build 1142. i.e. After rescanning the podcast download location all tracks that haven't been in DB and including word "Podcast" in its genre tag are associated to subscriptions based on its album tag (album = Podcast/feed name). If such a "dead" subscription is edited then podcast URL can be input in order to revive the feed. Tested on various podcasts and seems to work fine. |
|
|
Fixed in build 1142. |
|
|
Verified in 1144. Re-opening for clarification: I found that the only workflow that is supported is: User scans old podcasts and then edits subscription information. i.e. Joining old podcasts to an existing subscription is not supported. Is that correct? Also, I noticed a possible bug: -If the user re-enters podcast information for episodes that were previously downloaded, then Duplicate episodes are downloaded i.e. MM doesn't seem to 'Know' which episodes are new. Seems like a bug, but I'm not certain... |
|
|
> I found that the only workflow that is supported is: > User scans old podcasts and then edits subscription information. > i.e. Joining old podcasts to an existing subscription is not supported. > Is that correct? No, joining is supported: e.g. You are subscribed to 'Health Update' podcast and after re-scanning the podcast location the old episodes are added to your 'Health Update' podcast subscription > Also, I noticed a possible bug: > -If the user re-enters podcast information for episodes that were previously > downloaded, then Duplicate episodes are downloaded i.e. MM doesn't seem >to 'Know' which episodes are new. Seems like a bug, but I'm not certain... No, this is not a bug, but rather a missing feature I previously mentioned, i.e. the episodes needs to be compared (at least partially) and this would be quite consuming, another way could be to compare episodes only by its title, but there could be a tweak that 2 episodes could have the same title, but usually don't so I could try to resolve this by comparing the title? If you agree, re-assign to me. |
|
|
Maybe prevent dups from downloading by comparing Episode Title _and_ date? One other suggestion--the Top Level node is 'Podcast Subscriptions' and based on the recent changes, we've added Podcasts to the node even when the subscription isn't active. It would probably be useful to visually differentiate an 'unsubscribed' podcast from a subscribed one (perhaps a new icon?). |
|
|
ok, added the feature to find imported episodes in the feed and vice versa by comparison of key combination {PubDate, title, podcast} + added new icon (grayed out) for the feeds that are imported (unsubscribed) Fixed in build 1146. |
|
|
Verified 1146. This works really nicely. |
