View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004588 | MMW v4 | Other | public | 2008-04-17 19:18 | 2019-02-25 17:37 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0004588: Workflow for importing external podcasts isn't intuitive | ||||
| Description | Currently, if a user imports a track with Genre=Podcast, that track doesn't appear within a node in the podcasts node unless the track is inside the defined podcasts directory. Most users, however, will not intuitively understand this. Given the way this functionality has evolved, we should modify it slightly so that tracks for which Genre = Podcast are added directly to the podcast node. Ludek indicated possible problems that: -The newly downloaded episodes would not be situated in the same location (for the same subscription, however, I don't consider this to be a major issue. -it could slow down scanning although this should not be the case. -it might be better to make it configurable or at least add a message box so that tracks aren't inadvertently added to the node e.g.: "Some tracks with Genre = Podcast that have not been in your library were found. Do you wish to associate (add to Podcast node) them?". I don't think this is required either, though--the user could just change the Genre and cause the tracks to be removed from the Podcasts node. | ||||
| Additional Information | Originally reported in 4549. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1163 | ||||
|
|
Another (related) suggestion reported here: http://www.mediamonkey.com/forum/viewtopic.php?t=28369 Currently if a user want to re-import already downloaded episodes (by MM, but unsubscribed) then the workflow is not intuitive, he needs to: 1. Delete all the downloaded episodes from the feed, but only from library. 2. Unsubscribe the feed. 3. Re-subscribe the feed 4. Re-scan the podcast download location As Owyn suggested: The process feels cumbersome. It would simplify the UI if steps 1+2 could be combined, and then 3+4 combined. i.e. When a podcast is being subscribed MM should automatically search library for previously downloaded episodes and import them to the feed without a need to re-scan. |
|
|
I have made several fixes / changes /improvements: 1. All tracks with Genre = Podcast are added directly to the 'Podcast Subscriptions' node despite the fact they are not in the podcast directory. (i.e. fixed your suggestion) 2. When a podcast is being subscribed MM automatically searches the library for previously downloaded episodes and imports them to the feed without a need to re-scan. (i.e. fixed my suggestion) 3. If a podcast is being unsubscribed and just "Unsubscribe" is selected (i.e. without the prompt to delete also episodes ) then its "grey" subscription version remains, but it only includes episodes that have been downloaded. Fixed in build 1162. This way a podcast can be re-subscribed with automatical import of previously downloaded episodes. |
|
|
When I scan a folder containing an external podcast with build 1162, I get the following error: There was a problem querying the database: Error executing SQL "INSERT INTO PodcastEpisodes (IDPodcast, PubDate, NetSource, downloaded, idTrack, title) VALUES ( 37, NAN, 'Unknown - 7583', 1, 7583, "Today: 0750 Biofuels 14 Apr 08') ":no such column:NAN(1,1) Once the problem occurs, all subsequent operations to add tracks to the DB (e.g. scan a directory, podcast update) trigger the error--even if the folder containing the external podcast isn't being scanned. Tested with the following podcast: http://downloads.bbc.co.uk/podcasts/radio4/today/rss.xml Note: I get the error whether the podcast episodes are stored to the C: or F: Drive (i.e. it's unrelated to the drive that My Documents is on) |
|
|
Although I has not been able to reproduce by using the podcast there was obviously problem with decoding date value. Probably the another podcatcher has not stored the pub. date value to the track tag. I was able to simulate it and it is fixed in build 1163 (i.e. the SQL error is fixed). |
|
|
Verified in 1162 update. The regression seems to be resolved and the new functionality is working really well! |
