2164: strange issue when downloading from GPM

[Barry4679]

when I did my test yesterday of GPM download I got this error
https://www.dropbox.com/s/7jxhxcjqg4nkk ... 1.png?dl=0
nb: as you may see in the error log I had an typo in my Download Location at Tools|Options|Downloads ... I had set the file mask to <AlbumArtist> instead of <Album Artist>

I tried to retest this today to see if the error message was triggered by incomplete tags in the track being downloaded

I deleted the whole album from the MM db, Ie. I used MM5 to "remove" it ... local copy only

I then tried to download it again, this time with a valid file path mask

I got error 33D37CFB ... also with the followup message of "too many threads for indexing" ... yesterday you said this was triggered by too large a download back, or too many downloads in the one session ... or something like that

https://www.dropbox.com/s/grd89isb7viyqda/xtc2.png?dl=0
https://www.dropbox.com/s/wh5jhdq3mtr6coh/xtc3.png?dl=0

This was the only download I have tried today ... I rebooted this morning .. the download batch was just two albums by XTC ... "Oranges & Lemons" ... and "Skylarking" ... the problem happened in the 1st album

Maybe you could try downloading them to see if any of this happens to you?

nb: for path masks, maybe you could accept <AlbumArtist> == <Album Artist>? ... for those of us who know the MM db structure, the column name is AlbumArtist
or perhaps you could syntax check requests to set path masks?

[Ludek]

Hi,
thanks for reporting, I will look into the issues.

Re: 33D37CFB: This was supposed to be fixed in 2163 as item 16) here https://www.ventismedia.com/mantis/view.php?id=15133 , but by evidence it is still not fixed for you in 2164.

The only way how I see that the "Too many threads for indexing" error could still appear is by selecting the files (say 20 files) under the 'Downloads' node and right-click > Resume them at once. Is this what you have done??

[Ludek]

Could you please tell me what is your value in
Options > Downloads/Podcasts > Number of concurrent downloads: [4]

It should be 4 by default, but in your log I see that there are 23 concurrent download threads, by testing (+ code revision) this can now happen only when:
a) the value in options in increased (> 23 in your case)
b) you have a "large" list (> 23) of queued (paused) download items in Downloads node and you select them all, right-click > resume

Was a) or b) the case at the time of error 33D37CFB ??

[Barry4679]

I did not alter the value for " Number of concurrent downloads"

I selected those two XTC albums for download, so 30 tracks in total.

Have not (intentionally) experimented with download pause|resume.

[Barry4679]

Extra thoughts:

I was playing with FilesToEdit>Out-Of-Date-Tags yesterday ... comparing results to MM4 etc

Do you have a centralised module to handle db IO?

Maybe I had another MM5 tab which was building the Out-Of-date display? ... I can't be sure ... it broke a couple of times ... and when uou restart MM it tries to restore tabs which were open ... could that have caused the overload?

Or do you temporarily expand the limiter that is set by "number of concurrent downloads" during build of out-of-date-tags? ... maybe there is bug where this was left in an overridden state?

[Barry4679]

Extra thoughts:

I was playing with FilesToEdit>Out-Of-Date-Tags yesterday ... comparing results to MM4 etc

Do you have a centralised module to handle db IO?

Maybe I had another MM5 tab which was building the Out-Of-date display? ... I can't be sure ... it broke a couple of times ... and when uou restart MM it tries to restore tabs which were open ... could that have contributed to the overload?

Or do you temporarily expand the limiter that is set by "number of concurrent downloads" during build of out-of-date-tags? ... maybe there is bug where this was left in an overridden state?

[Ludek]

Hi,
thanks for the info.

By code revision I see some ways how this could happen, it will be fixed in the next build (2165).