View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003253 | MMW v4 | Other | public | 2007-07-11 04:25 | 2007-07-29 04:53 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0003253: Search for Podcasts (Memory leak & should search child nodes) | ||||
| Description | Browsing OPML directories is very inefficient when trying to find a particular podcast. In fact it's a major pain. One way of doing this would be to have the Search bar search the OPML subdirectories when they are highlighted. This may require caching of the directories though. | ||||
| Additional Information | Raised to immediate. There's a severe memory leak in this code. To reproduce just switch between directories and perform context searches. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1054 | ||||
|
|
Assigning to Ludek. However, I'd give this a little lower priority, it probably can wait past 3.0 release. |
|
|
Implemented in build 1051. |
|
|
Tested 1051 and although it functions, it doesn't quite meet the need. i.e. the current implementation only searches the contents of the current node, but not the children of the current node, and that is really what is needed (e.g. if I'm trying to find a podcast called 'The Onion' I may not know which node it is contained within. What I'd like to see is for MM to search the current node along with child nodes, when searching the OPML tree. (note: if this means that search results would be found one at a time, then that's fine). |
|
|
I must disagree, it search the children of the current node. e.g. if you search for "Hauz29" in Digital Podcast -> Art it is found althoug it is contained within the Digital Podcast -> Art -> Architecture child node. The problem is that "The onion" is included in Digital Podcast -> Comedy and humor and searching Digital Podcast node takes too long because there are many feeds included in the whole OPML file which is cached on HDD and has to be parsed once (anytime) is needed. Caching the OMPL content to DB would solve this problem (it would be parsed only before inserting to the DB). The searching would be much faster. |
|
|
Fortunately I've got an idea and I significantly reduced the time of parsing by using a batching trick. Previously it taken 3 minutes, but now it takes 3 seconds ;-) (for whole Digital Podcast). |
|
|
Much better. There's still one problem, though. When I run MM and then click 'Digital Podcast' _without expanding it_, and then try to search for a podcast, it doesn't seem to find it. It only finds it if I first Expand the node and then search for the podcast. It seems that this is because expanding the node is what triggers the OPML file to be downloaded/cached. What should happen is that as soon as the user clicks the node, the OPML directory should be downloaded so that it can be searched (even better, download the OPML as soon as the user clicks the Podcast Directories node). |
|
|
All the memory leaks and requirements fixed in build 1054. |
|
|
Verified 1054. |
