1155: Need to limit concurrent manual downloads

Owyn · Post by **Owyn** » Mon Apr 14, 2008 7:33 pm

I was looking at a new podcast and decided that I wanted to get several of the older episodes.
http://www.cbcradio3.com/podcast/sessions

Started right clicking and selecting download for the individual episode. In no time I had started 7 download tasks.

Started getting timeout errors. Clicked ok to each of the error pop-ups.

Then checked network status and the net had gone idle, even though all the tasks were still showing active.

Terminated all tasks via status bar context menu.

Selected all 7 episodes as a collection. Selected Remove and then Download from the context menu. Worked fine this time as a single task.

Think manually initiated tasks need to be enqueued in similar manner to "Update all Podcasts".

Ummmm. One strange artifact. One of the episides has the green download icon beside it but is not downloaded, can not be removed, and can not be manually re-downloaded.

Owyn · Post by **Owyn** » Mon Apr 14, 2008 7:49 pm

Ok. More to the saga.

I unsubscribed the new podcast and Kept the downloaded files.

I then re-subscribed. But, the one erroneously marked episode was still marked and none of the downloaded already downloaded episodes were recognized as downloaded.

I thought that MM could automatically find and associate tracks.

I tried to manually initiate download of one of the orphaned episodes, but, just ended up with another full download and duplicate "...[1].mp3" file.

Owyn · Post by **Owyn** » Tue Apr 15, 2008 12:10 am

Retested in 1159. Similar results, but, did not have to terminate tasks this time.

Ludek · Post by **Ludek** » Tue Apr 15, 2008 5:00 am

I thought that MM could automatically find and associate tracks.

MM can automatically find and associate tracks, but they needs to be out of library.

i.e.
Try the following (use build 1159):
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 your podcast download location

The episodes should be imported to the feed.

-----

One strange artifact. One of the episides has the green download icon beside it but is not downloaded, can not be removed, and can not be manually re-downloaded.

Although I has not be able to reproduce, I reviewed the code and added a prevention from this. This should not happen anymore in the next build (1160)

Owyn · Post by **Owyn** » Thu Apr 17, 2008 10:47 am

Try the following (use build 1159):
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 your podcast download location

Tested with 1159. Worked.

However, the process feels cumbersome. It would simplify the UI if steps 1+2 could be combined, and then 3+4 combined.

Ludek · Post by **Ludek** » Thu Apr 17, 2008 3:06 pm

Yes, you are right, the workflow is not intuitive.

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.

Added to our to-do list.

Owyn · Post by **Owyn** » Fri Apr 18, 2008 5:02 pm

Tested with 1162. Very nice.

- Un-subscribed podcast with several episodes, including latest
- Re-subscribed

All the existing episodes were automatically recognized and in particular no duplicate download was initiated

Will do some more testing of impact of this change on import of episodes from another client and cleanups.

Thanks

Teknojnky · Post by **Teknojnky** » Fri Apr 18, 2008 5:27 pm

Hmm, I assume it is related to these changes, but I had only 2 actual podcasts subscribed..

Now MM displays 2 other sets of file in the podcast node that had genre as podcast.

One of them was a bad genre and was not a podcast so I changed the genre but I can't seem to remove it from the podcast node (unsubscribe + do not delete) does not seem to work.

The other 2 files were some podcast mp3 I downloaded from they might be giants website a long time ago.

Owyn · Post by **Owyn** » Fri Apr 18, 2008 5:47 pm

Hmm. Might be, or it could be the difference between filters and podcasts.

e.g. I have a Podcasts auto-playlist Selection(Genre=Podcast),Sort(Playcount,Date Added). The playlist node shows 330 items, the Podcast Subscriptions node shows311 items, and, both are correct.

Podcast subscriptions shows downloaded tracks from current subscriptions.

The playlist shows anything with genre podcast, including unsubscribed podcasts for which I have kept the episodes.

Owyn · Post by **Owyn** » Tue Apr 22, 2008 6:41 am

Ludek:

The scan on subscribe fix is the bomb. Just finished a cleanup of my "J:\Podcasts\...." download destination. Cross audited:
- Locations
- Search Genre=Podcast
- Dir /S
- Podcast Subscriptions

With the addition of the grayed out subscriptions (1160/1162 change) I have almost got all 4 to reconcile (Locations=Dir=Search=352, Subscriptions=351). Just anal enough to want to get that last 1 resolved, but, will do that via SQL query. Going blind(er) looking at lists.

This should make it much easier for users migrating from other podcast clients.

Tekno:
You might want to take another look as of 1162. As far as I can see this function is now pretty solid.

Owyn · Post by **Owyn** » Wed Apr 23, 2008 8:43 am

Found that last discrepancy. I somehow had two files for one episode.

Found the files by Search bar search for "(1)".

DIIK how the problem arose (my guess is a mybad during import testing/cleanups), but, objective achieved. All artifacts from beta testing podcast functions should now be cleaned up. This gives me a new clean baseline for future testing.

Owyn · Post by **Owyn** » Fri Apr 25, 2008 6:41 pm

Retested original problem in 1164. Fixed by another change.

I had 10 concurrent download tasks running without problem. I think the problem showed up as a resource conflict with the end of download(s) memory load and file copy load.

With the speeded up direct to final folder download process and the memory optimization there is no longer a conflict. Monitored memory load and it never grew substantially.

Very well done Ludek.