View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003908 | MMW v4 | Other | public | 2007-11-04 22:26 | 2009-02-20 03:27 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0003908: Podcasts: Expanding a Podcast can look like MM is frozen | ||||
| Description | A reported in EL, MM can look like frozen in case user expands a Podcast. The relevant callstack of this problem is: TFMainWindow.PodcastsViewExpanding() AddFeedEpisodes() UpdateEpisodes() where it directly reads HTTP data. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1186 | ||||
|
|
Assigning to Ludek. In case you don't see a very safe fix, I'd rather wait after 3.0 release, in order to not introduce some new threading bugs. |
|
|
I see a very safe fix: I tried to find a way to reproduce and for example Podcast Directories -> Podcast.com -> PODCASTS (audio) -> POLITICS -> Aliance for Justice - Supreme Court Watch seems to take long time to read the whole feed data, because if you look at the link http://allianceforjustice.libsyn.com/rss there is to much useless metadata included for each episode. Result is that all 605 KB is read for 58 episodes !!! Because this action should be only a preview and the most recent episodes are included firstly in the feed, my suggestion is restrict the feed reading to 100 KB so that all feed data needn't to be read and at least 10 most recent episodes are shown as a preview. |
|
|
Fixed in build 1106. |
|
|
Per discussion with Jiri, reopening in order to add '...' at the end of episodes list so that it is clear that not all episodes are shown for such a large feeds (> 100 KB). Note: After subscribing of cource all episodes are read for all feeds in the thread (doesn't matter on feed size). For 3.1 we probably could perform also this expanding in a thread and individual episodes should be gradually shown (similar like filling the tracklist in case of a node e.g. 'Artists' is selected) |
|
|
Tested 1106. It solves the problem, but it's a bit confusing. a) The current visual representation is: episode 22 episode 21 episode 20... This doesn't communicate the fact that additional episodes exist. The way this should be represented is: episode 22 episode 21 episode 20 ... b) Also, if the user wants to play an episode prior to episode 20 it's unclear how to do so. One would expect that clicking the '...' would cause the remaining episodes to download (or some other obvious solution that would cause all the episodes to be available if needed). |
|
|
Re: a) That is strange , I implemented it that way: episode 22 episode 21 episode 20 ... in build 1106. I guess that you tested another feed which size is less than 100 KB and all its content was read. Does a) occur also on the feed mentioned by me? Which feed you tested? |
|
|
Yes--I tested using the feed that you described in the bug. |
|
|
I am unable to reproduce, works fine form me, tested on Digital Podcast Directory -> Podcasting -> Adam Curry: Daily Source Code there is listed the first 17 episodes in order: 789 788 787 ... 772 ... i.e. instead of 771 there is the "..." (triple point) mark. |
|
|
Nevertheless I added expanding of a podcast feed into a thread and individual episodes are gradually shown. i.e. the '...' is now eliminated completely and issue B is resolved by this addition. Added in build 1186. |
|
|
verified 1223 |
