Upload speed shouldn't be dependent on queue length
Maybe something wrong with my eyes, but I see the difference in this video (unfortunately video got removed, I can upload another one if needed)
Operating system: Windows 10 LTSB x64 (no Anniversary update)
Version of Telegram Desktop: 0.10.2 alpha
That might actually be your ISP, limiting individual connections.
I'm not sure whether it's placebo, but I think I can reproduce this: https://streamable.com/ftcl.
That might actually be your ISP, limiting individual connections.
That would only make sense if both files were uploaded at the same time. In this scenario the queue is just made longer without any additional parallel upload taking place AFAIK.
I can reproduce this on 0.10.6 also.
Drag/drop file â„–1 and have low upload speed. Add file â„–2, upload speed improves. (this can be repeated with more files)
When file â„–1 finishes, file â„–2 goes back to the low speed. If I add a file â„–3 the upload speed goes up again.
I also must add that if I open Telegram desktop and drag/drop a few files, file â„–1 will aways get the boosted speed, but file â„–2 and subsequent files get low speeds.
Hey there!
We're automatically closing this issue since there was no activity in this issue since 484 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked.
Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue.
Thanks!
(Please note that this is an automated comment.)
I'm not sure this was fixed, someone should test it, not only me
Hello everyone, last week I came across this issue. I can also reproduce the issue on version 1.3.9.
I use Windows 10 Version 1803 and I have 20MBit upload speed from my ISP.
While upload a single ~50MB file without any other files in queue. It takes around 42 seconds at ~ 9-12MBit/s.
When I put more files of any size in the queue the uploads speeds up and takes my connection at full speed with ~ 18-20MBit/s. The upload of the same file only takes around ~22 seconds.
This is still relevant btw. Please consider re-opening this issue.
@Aokromes ?
I still have the same problem.
@MasterGroosha Can you not reopen this yourself?
@Xalaxis nope :( I think @Aokromes can do this
It might need to be @john-preston
This is not fixed at all, still.
@john-preston @Aokromes Please re-open this issue, it makes using the desktop client unbearable.
The explanation by @foremtehan (here: https://github.com/telegramdesktop/tdesktop/issues/6583#issuecomment-534482074) makes no sense, as the problem doesn't appear on mobile clients, which use the same servers.
If you need more specific information, please provide me with the questions, I will do my best to answer.
I have the same issue on Android. If you need any info I'll gladly help
I have the same issue on tdesktop
@Aokromes Please can you re-open this issue?
There is unofficial client that I found have amazing feature "speed boost" and it's really works even when 1 file uloading/downloading:
https://github.com/TDesktop-x64/tdesktop/releases
Idk why this feature still not in official client.
Kotatogram has that option too
@Aokromes Could you please re-open this issue?
This should definitely be reopened! @Aokromes
Still not fixed, really slow uploading media...on ios phone
This issue is only for the problem in tdesktop, unless there's proof it
occurs in other platforms.
On Wed, 23 Sep 2020, 23:39 ijuliank, notifications@github.com wrote:
Still not fixed, really slow uploading media...on ios phone
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/telegramdesktop/tdesktop/issues/2390#issuecomment-698008196,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADCWV3BQ2T7IHIJMUJ2I3GTSHJ2JXANCNFSM4CN4524A
.
This issue is only for the problem in tdesktop, unless there's proof it
even after that this bugtracker is only for tdesktop
Most helpful comment
@Aokromes Could you please re-open this issue?