View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004296 | MMW v4 | Other | public | 2008-01-16 10:09 | 2010-12-14 15:12 |
Reporter | Ludek | Assigned To | |||
Priority | low | Severity | minor | Reproducibility | always |
Status | feedback | Resolution | open | ||
Product Version | 3.0 | ||||
Summary | 0004296: Podcast / RSS reader only downloads feeds with file extensions that are associated | ||||
Description | As reported here http://www.mediamonkey.com/forum/viewtopic.php?t=24931 user would like to use MM as podcaster, but MM only downloads episodes which file extensions are defined in Options -> File Types I added this request to our bug tracking system for review whether we shouldn't change this to download all files although they cannot be played by MM so that MM downloads also ".pdf" , ".avi", etc... Assigned to Rusty for prioritizing and decision if this make sense or whether it would be rather bothering to have e.g. PDFs presented in MM library?? | ||||
Tags | No tags attached. | ||||
Fixed in build | |||||
|
Note: Alternatively we could add support for .m4v, .mov and such a file extensions, because we can play it now by using QT (f_aac.dll), but do not associate these with MM by default, because only sound track can be played by MM for this video episodes. |
|
I'm not that keen on polluting the library with unsupported content, however, one way around this would be to allow MM to download unsupported content as long as it isn't saved to the library. I raised this idea in the forum as a possibility. |
|
i think that the real requirement here is for downloading Video podcasts, and synching them (without necessarily playing them). I don't think there's really a general need to download unsupported file types. i.e. we can tackle this issue once MM synch video. |
|
Reminder sent to: jiri, Ludek, rusty From what I see in MM4 this is obsolete and should be closed. |
|
There still might be some content (.pdf) that we don't support yet. That said, it probably doesn't give enough reason to implement something like this and we can defer until we possibly support even more types of files. |