View Issue Details

IDProjectCategoryView StatusLast Update
0015133MediaMonkey 5Synchronizationpublic2019-09-17 16:13
Status resolvedResolutionreopened 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0015133: Downloading from cloud issues
DescriptionThere are some issues when downloading from cloud (GPM, MMS, OneDrive, DropBox, GDrive)

1) tracks fails to auto-download for MMS and GPM when configured so (regression in recent builds)
2) possible freeze when GPM tracks cannot be auto-downloaded (due to an error)
3) manual downloading from cloud fails for tracks already in the library
4) cloud tracks that are scanned into library and manually downloaded outside of 'Devices & Services' or 'Locations' nodes (e.g. from Music > All tracks node) are downloaded to the default download location instead of the location configured for the particular cloud profile (or fail to download completely)
Additional Information
TagsNo tags attached.
Fixed in build2198


has duplicate 0015536 resolvedLudek Duplicate podcasts 
related to 0015029 resolvedLudek Deletion of library tracks stored also to the cloud 



2018-10-04 16:31

developer   ~0051250

Last edited: 2018-10-04 17:33

View 2 revisions

1&2) are fixed in 2125
3&4) are fixed in 2126


2018-10-10 11:29

developer   ~0051289

Last edited: 2018-10-11 12:16

View 4 revisions

Use is reporting some further issues with downloading:
5) crash log 9547583F ... Too many threads for indexing ...
6) "file x:\xxxx\xxxxx already exists, Replace?" dialog issues
7) The path in file-listing isn't updated in some cases
8) Tracks that are downloaded and immediately deleted fails to download again in some cases
9) download location issues - the default download location for the particular profile is used only once user clicked [Apply] on the [Remote content] tab -- otherwise user profile folder is used


2018-10-10 19:42

developer   ~0051295

Last edited: 2018-10-11 12:17

View 4 revisions

5,6,7,8,9) are fixed in 2127


2018-11-26 21:08

developer   ~0051622

Last edited: 2018-11-28 14:55

View 6 revisions

Re-opened due to:

10) Initiating manual download (e.g. selecting 100 files > right-click > Download) adds the files to queue once after it gets the stream URIs.
This is problematic since the stream URI is valid only for some time (e.g. 1 minute in case of GPM) and also getting the stream URI can take longer time that actual downloading, this results in a strange behaviour that the download queue has still only 1 or two items, reported at
This needs to be re-worked so that the stream URI is getting on demand (only once the next item in the queue is about to be downloaded).

11) Manual download can be initiated only on track entities. It should be possible to select whole album/artist to add it to download queue


2018-11-27 15:25

developer   ~0051624

Last edited: 2018-11-28 14:56

View 3 revisions

Items 10,11 are fixed in 2135


2019-02-05 10:50

developer   ~0052396

Last edited: 2019-02-05 15:22

View 4 revisions

Re-opened: there are some further items addressed by user:

12) Issues with moving files once the download is finished (when the download mask includes <Album Artist>)
13) Download error log doesn't show the error/reason for the very long download links (like GPM links), there should be another column for the item error description
14) Unclear wording re the removal options (viz forum post), to be reviewed by Rusty
15) 'Source' column (in the Column Browser) isn't updated after the download


2019-02-05 14:04

developer   ~0052398

Last edited: 2019-02-08 17:32

View 6 revisions

Items 12, 13, 15 are fixed in build 2155 + improved error logging and Column Browser updating in general

Assigned item 14 to Rusty to review the wording (+ asked the user what is not clear about the wording via the forum link)

Especially it is not clear what 'delete local copy' does. It deletes only the file from disc, but the link to the remote copy remains in the database.


2019-02-27 12:45

developer   ~0052816

Last edited: 2019-03-05 12:23

View 6 revisions

Item 16) - possible "Too many threads for indexing" exception when many downloads are initiated manually (based on the debug log that Barry PM-ed to me), reported here:

17) podcast episode download is initiated twice (when manually initiated), this is a recent regression related to fix of item 10
Fixed in 2163


2019-03-04 16:46

developer   ~0052863

Last edited: 2019-03-05 12:23

View 4 revisions

16) the "Too many threads for indexing" error can still happen per (exception id 33D37CFB )
=> Fixed in 2165

Assigned to Rusty for the item 14 (the wording item)


2019-03-08 22:04

administrator   ~0052924

Resolving, and covering item 14) in 0015029.


2019-03-18 10:08

developer   ~0052999

Last edited: 2019-03-28 13:33

View 4 revisions

Re-opened: User is still seeing some issues (to be looked into):

=> Fixed in 2168


2019-04-20 23:10

developer   ~0053315

Last edited: 2019-04-25 00:53

View 2 revisions

Verified 2171

No issues downloading from GPM.

Please confirm that also it is fixed on larger scale.


2019-07-29 14:05

developer   ~0054230

Some further issues reported by Barry:


2019-07-31 17:43

developer   ~0054254

Fixed in 2189


2019-08-11 18:33

developer   ~0054314

Last edited: 2019-08-11 19:12

View 3 revisions

Re-opened: A regression cropped into 2191 (while fixing 0015023) and now download from GPM fails entirely with "Unknown protocol" error!!

=> Fixed in 2192


2019-08-28 09:03

developer   ~0054431

Last edited: 2019-08-28 13:46

View 4 revisions

16) "Too many threads for indexing" is still reproducible by Barry:
dump C6C601FC + debug log sent via PM
18) UI is sluggish when thousands of files are about to be queued for downloading
19) Some items (for which download is pending and MM5 is restarted) get 403 forbidden (after MM5 restart)

=> Fixed in 2193


2019-09-05 17:46

developer   ~0054520

Last edited: 2019-09-05 19:19

View 5 revisions

20) There is an issue with "Cancel all" action (Downloads > right-click > Cancel all), it can result in a freeze for many download items.
Workaround in 2194 is to select a download item in the list, press Ctrl+A to select all items in the list, right-click and item > Cancel

21) Pause all (Downloads node > right-click > Pause all) fails to pause all downloads. It just pauses pending downloads and the queued items starts downloading (instead of the paused). It should pause all the queue.

=> Fixed in 2195


2019-09-05 19:31

developer   ~0054521

Last edited: 2019-09-06 13:50

View 4 revisions

22) Downloads node sometimes isn't visible in the tree (after restart or after downloads init) until a node is clicked/expanded in the tree

23) Download queue cannot be cancelled on Barry's database (sent me over PM)

24) possible crashes when closing app while downloading is pending

=> Fixed in 2195


2019-09-17 10:26

developer   ~0054663

Last edited: 2019-09-17 16:13

View 3 revisions

25) User reports that tags are scrambled in 2197:

EDIT: The key factor to replicate is to check:
[x] Only include content that matches files already in the database
-- with this option checked MM5 silently fails to add the tracks into library at first (before downloading) -- which results in the described issues.

=> Fixed in 2198