Downloads stuck on 'Queued' #2926
Comments
|
This sort of issue could only be investigated by gathering debug logs to capture some examplar incidents of the problem. If you decide to help investigate this bug by gathering and providing logs, then I can provide an email address for sending them privately. Please don't post any private data (usernames, IP addresses and filenames etc) in this public forum. It's possible that is has something to do with your network environment, such as a firewall or the like. |
|
I would be happy to help debug. Please provide me with the email address and I will send over logs! |
|
Thanks that'd be great, use the email address on @mathiascode 's GitHub profile with logs attached as plain text file, please put the subject line the same as the title of this issue and issue number "Downloads stuck on 'Queued' #2926". I can confirm that I have observed similar behaviour but I don't know what is causing it nor how to investigate it. |
|
How many queued downloads? Judging by the logs, it looks like Nicotine+ is stuck sending (the same?) QueueUpload messages for several minutes. Does the GUI freeze at all when this happens? |
|
Hi Mat,
It was quite a lot of queued downloads. I was allowed to start downloading
a library so I had a few thousand files queued.
…On Sat, Mar 9, 2024 at 5:35 PM Mat ***@***.***> wrote:
How many queued downloads? Judging by the logs, it looks like Nicotine+ is
stuck sending (the same?) QueueUpload messages for several minutes.
—
Reply to this email directly, view it on GitHub
<#2926 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AVPSGKOTFSPBZBSQEGDDJODYXOFELAVCNFSM6AAAAABEF2ZK3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWHE4TQMZZGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
No, the interface is fully functional while one download is frozen on "Transferring" and the other three "Queued" uploads to the same user also are stuck as a result. The "Time Elapsed" doesn't increment nor does the displayed "Speed" value change except upon every few minutes, at which point it updates to show the correct amount of time and a nominal speed as if it wasn't stuck, even though in reality it is going at less than a few B/s. |
|
I suspect it's a performance issue in OP's case. Sending thousands of messages at once might cause a bottleneck somewhere in the networking code, effectively halting all other traffic. I'll do some profiling to see if this is the case. |
|
I don't think there's anything that should cause large bottlenecks (except if you're downloading to a really slow HDD or network share, perhaps), but I found a couple things to optimize in any case: 6e4325b @brandon-iomyers Could you try the latest development build and see if anything has changed? https://nicotine-plus.org/doc/TESTING.html#windows |
|
Hi, for some time I've also been getting the same issue of downloads getting stuck on queue, though with many different users and not cases of queuing a large amount at a time. Should I explain more here, or create a new issue? |
|
I apologize for not adding anything more but with the new reply @thep50 made, I felt it would be a good time. I have seen this issue with both large amounts of queued downloaded and only a few. I have also tried it with three different storage configurations. Now, none are flash but the method didn’t seem to make a difference. Two things to note, when this happens users also can not queue from my shares and state they get an error saying there was a problem connecting. Lastly, quitting the application and then restarting it will start downloads immediately, at least for a while. |
I will give this a shot tonight! |
There are two different issues:
Which issue are you experiencing? Could you send new debug logs? Enable all log categories, and send the log file to my email on my profile. Also point out which users and files have the issue. https://nicotine-plus.org/doc/DEVELOPING.html#debug-logging |
I'm experiencing the second - only certain files are stuck on queued, while others from the same user & other users all continue. What I've noticed usually triggers this is when I'm searching for a single file in the search tab, and right click one user and click "Download Folder(s)". Sometimes when taking this action and then looking at the new download in the Downloads tab, only the single file shows up at first while it's still trying to connect to the user for the rest of the folder. Sometimes it takes a while doing this and might say "Connection TImeout". Eventually when the rest of the folder comes up and the downloads start, it starts downloading on the second file down. It will then download the entire folder except for the first file that I had originally searched for, which is stuck on 'queued', or sometimes 'cancelled'. When I try hitting resume on this file, nothing usually happens after a long wait - however if I remove this file from from my download list, browse the user's files, and then add the file again to my downloads by queuing the whole folder, the file usually starts downloading instantly. I will turn on debug logs and try and recreate it and email you the results. |
Nicotine+ version: 3.3.3.dev1
Operating System/Distribution: Windows Server 2019
Describe the bug
I was given permission to download a library and have noticed an issue. After a few downloads, I will get put in a 'Queued' status. Nothing will change for up to hours. Sometimes it breaks itself from that status, other times I have to quite the application. If I quit the application and immediately restart it, the downloads start working.
I have also noticed that during this time, my upload number does not increase. I have also had users contact me asking me why I am not letting them download or why I am cancelling their downloads. I am not doing either.
Expected behavior
Steps to reproduce the bug
Additional context
Screenshots, logs, stacktraces or relevant information.
The text was updated successfully, but these errors were encountered: