Stuck downloading Spotify Playlist

[whirly1227]

• My operating system is: Windows 10 Home 64 bit;
• My AllToMP3 version is: 0.3.11.128;

I'm trying to download https://open.spotify.com/playlist/37i9dQZF1DWXRqgorJj26U?si=lNSCdje7TqyhlSeTYeVOSw which contains 150 songs. I get a range of 35-45 songs to download each try.

Using Windows Resource Manager, I can tell that the network usage slowly goes down and stops. I have tried other playlists but the same problem happens every time.

[dnewman113]

I am having the exact same problem

[opravdin]

+1, same issue here

[virgiliomsilva]

Same problem. tested in Windows 10 Home 64 bit and Windows 10 Pro 64 bit;. AllToMP3 version: 0.3.11

Tried previous versions but no success

EDIT: congrats on this project!

[Thijzer]

Might be because of the memory limit issues, the application doesn't garbage collect while scraping. Effect is that after 50 songs the memory in used is around 2 GB on my system.

Im using linux btw.

[Thijzer]

It's also a bad idea to download multiple lists at ones. The CPU might throttle as it will consume all your cores for the workload. You might end up with a white screen of death on the application window.

[virgiliomsilva]

Might be because of the memory limit issues, the application doesn't garbage collect while scraping. Effect is that after 50 songs the memory in used is around 2 GB on my system.

Im using linux btw.

This sounds to be a possibility. I ended up adding the playlist single tracks one by one without any waiting to previous ones end and no problem.

[whirly1227]

I have 32GB DDR4 RAM. Memory isn't the issue. I have also monitored the network connection with Resource Manager. After only downloading 1 playlist at a time, around song 35 the connection doesn't exist anymore. My CPU, Memory and all other resources are not nearly maxed.

On Tue, Dec 3, 2019 at 9:11 AM virgiliomsilva [email protected] wrote:

Might be because of the memory limit issues, the application doesn't garbage collect while scraping. Effect is that after 50 songs the memory in used is around 2 GB on my system.

Im using linux btw.

This sounds to be a possibility. I ended up adding the playlist single tracks one by one without any waiting to previous ones end and no problem.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/AllToMP3/alltomp3-app/issues/139?email_source=notifications&email_token=AIFTHVWGFMUHBTTX7IKP653QWZSJVA5CNFSM4JPTQOQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFZP6QI#issuecomment-561184577, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIFTHVQKYSMNN5BTE3LZT63QWZSJVANCNFSM4JPTQOQA .

[JeroenBos]

I tracked down the issue while debugging, and was about to submit a PR, but found that it was already fixed in a PR. The problem is that that fix is in a different library and hasn't been published to npm yet.

Why downloading a playlist seems to stop somewhere in the middle is due to the following: There are initially 4 concurrent downloads, and when a download finishes, it is converted using ffmpeg. Error handlers are in place for when a download fails, which will trigger the next attempt/song to be downloaded. However, when a conversion fails*, this next download is not triggered. So after each failed conversion you have one fewer concurrent download, and after 4 failures, there's no downloading going on any more. Hence the PR, which redirects the conversion failure to the download failure handler.

*: in my case the error was of the form Error: ffmpeg exited with code 1: /tmp/<...>.mp3.video: Invalid data found when processing input The root cause of invalid data remains a mystery to me, for that you need to be an ffmpeg expert, I reckon.

[ghost]

I tracked down the issue while debugging, and was about to submit a PR, but found that it was already fixed in a PR. The problem is that that fix is in a different library and hasn't been published to npm yet.

Why downloading a playlist seems to stop somewhere in the middle is due to the following: There are initially 4 concurrent downloads, and when a download finishes, it is converted using ffmpeg. Error handlers are in place for when a download fails, which will trigger the next attempt/song to be downloaded. However, when a conversion fails*, this next download is not triggered. So after each failed conversion you have one fewer concurrent download, and after 4 failures, there's no downloading going on any more. Hence the PR, which redirects the conversion failure to the download failure handler.

*: in my case the error was of the form Error: ffmpeg exited with code 1: /tmp/<...>.mp3.video: Invalid data found when processing input The root cause of invalid data remains a mystery to me, for that you need to be an ffmpeg expert, I reckon.

This looks like good news! But could anyone please explain in layman terms what I have to do to patch the original files (I'm on windows 10). The only "index.js" file I found is located in C:......\AppData\Local\Programs\AllToMP3\resources\app.asar.unpacked\node_modules\sharp\lib\index.js

Upon inspection it looks like a completely different file. Replacing it predictably didn't work. I'll copy/paste this onto the PR page as well and wait for an answer. My program version is 0.3.11.128

[NTag]

I released a new version 0.3.12 which should improve this issue.