Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Request] Bring back Queue and Rank sorting column in v4.3.0 #11843

Open
Drugwash2 opened this issue Jan 8, 2020 · 20 comments
Open

[Request] Bring back Queue and Rank sorting column in v4.3.0 #11843

Drugwash2 opened this issue Jan 8, 2020 · 20 comments

Comments

@Drugwash2
Copy link

@Drugwash2 Drugwash2 commented Jan 8, 2020

• qBittorrent 4.3.0 alpha1 (4.3.0201912180417-6813-a25ed5fubuntu18.04.1)
• Linux Mint 19.2 x64
• libtorrent-rasterbar10 1.2.3+git20191216.68196dceae-1ppa118.04
• libtorrent-rasterbar9 1.1.13+git20191027.909211888e+patched-configure-1ppa1
18.04
• qt5 5.9.5

Alpha versions of qBT after 20191218 were stripped of the Queue toolbar buttons and the first Ranking column in Transfers list. To me this is unacceptable as I make heavy use of both features.
So please bring them both back. I stopped updating qBT precisely because of this issue and I will forever remain on the 20191218 alpha if those features will not be brought back.

What is the expected behavior

Ability to group/sort download items by user's own ranking system.

Steps to reproduce

Install the 20191218 deb package from Launchpad, check out the Queue toolbar buttons, the available columns in the Transfers list and enable Ranking (#) if not enabled, then install any other later deb package - the Ranking column is missing, as well as the toolbar Queue buttons.

@thalieht

This comment has been minimized.

Copy link
Contributor

@thalieht thalieht commented Jan 8, 2020

qBt never had a "Ranking" column. I suspect you meant the "#" (queue position) column in which case both of those things will reappear when you enable Options>BitTorrent>Torrent Queueing

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 8, 2020

I suspect you meant the "#" (queue position) column in which case both of those things will reappear when you enable Options>BitTorrent>Torrent Queueing

Yes, that's the column - didn't know how to properly call it.
Torrent Queueing has always been enabled here since many versions before, it would be weird if later versions would automatically disable it without user request or acknowledgement. Granted I haven't looked there after updating, and when I saw the column+buttons missing for a few alphas I just downgraded and stopped accepting updates. Why would queueing get unconditionally disabled in newer alphas?

Anyway, I'll try updating again as soon as traffic allows me, see if the Torrent Queueing option gets disabled and if re-enabling it brings back the column+buttons. The issue will remain open until your fix is confirmed (or not).

Thank you for your help.

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 8, 2020

OK, I updated to latest alpha at the time of writing this (4.3.0~202001080448-6829-45ed31f~ubuntu18.04.1) and indeed Torrent Queueing gets automatically and unconditionally disabled. Huge mistake! Enabling it brings back the column+buttons, but - and this is a huge 'but' - previous queue sorting gets completely screwed up. :(

There is no logic whatsoever in the new sorting - not alphabetically, not by downloaded percent, not by date - not by anything. So basically the user ends up with a total mess of a list, whereas before there was a certain logic to the sorting of the items.

And what tops it is that the bad sorting propagates when downgrading back to the nicely working version (20191218), so the user is finally screwed, left without any chance to get back their preferred sorting order other than trying to recreate it manually (in a list of hundreds or thousands of items).

Got no words to express my dissapointment. 👎

@xavier2k6

This comment has been minimized.

Copy link

@xavier2k6 xavier2k6 commented Jan 8, 2020

Unsure if the 4.3.0 Alpha builds are created from master etc but below may be relevant.

(Introduced) Disable Torrent Queue by default
PR#11678

(Bringing it back) Revert "Disable Torrent Queue by default"
PR#11808

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 8, 2020

Thanks, could be so. However, main problem here is not the default disabling of queue, but the erasing of the queue/sorting order when disabling/enabling.

I have updated and downgraded a few times before without ever touching the Torrent Queue checkbox in the process, and everytime the order was kept intact after downgrading back to 20191218.
Now, after updating and re-enabling Torrent Queue, the previous order got completely messed up and remained so after downgrade. This is a big issue for large lists (and bad memory like mine).

@xavier2k6

This comment has been minimized.

Copy link

@xavier2k6 xavier2k6 commented Jan 8, 2020

@an0n666 maybe those PR's broke something inadvertently?!

Thanks, could be so. However, main problem here is not the default disabling of queue, but the erasing of the queue/sorting order when disabling/enabling.

@glassez @Chocobo1 @sledgehammer999 early stages of 4.3.0............but something to look into?!

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 8, 2020

Most likely there is no check for an existing queue, or if it exists it may be faulty. I've seen discussion about telling apart old from new user - hence queue existing or not - based on some legal notice agreement; maybe that is not implemented or doesn't work as it should.
Either way, losing a (very) large queue upon update - or even upon disabling/enabling queue - is bad, so please triple check all related code.
Thank you for your help, @xavier2k6 .

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Jan 9, 2020

@an0n666 maybe those PR's broke something inadvertently?!

Thanks, could be so. However, main problem here is not the default disabling of queue, but the erasing of the queue/sorting order when disabling/enabling.

@glassez @Chocobo1 @sledgehammer999 early stages of 4.3.0............but something to look into?!

I think his issue is regarding the sorting order which probably broke due to some other PR.

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 11, 2020

I think his issue is regarding the sorting order which probably broke due to some other PR.

It's about sorting by queue (the # column). #11678 unconditionally disabled queueing in settings but on manual reenable it probably didn't check for an existing queue and just initialized it as blank or something. As a result, the existing queue from a previous qBT version was completely and forever lost.
Hopefully #11847 will fix this properly.

@glassez

This comment has been minimized.

Copy link
Member

@glassez glassez commented Jan 11, 2020

Hopefully #11847 will fix this properly.

Once Queuing subsystem is disabled qBittorrent doesn't keep queue anymore. So it won't restore your old queue, it just re-enable Queuing subsystem for those existing users that use it by default (i.e. that never touched corresponding option).

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 11, 2020

Uhm, sorry... I'm a bit confused here. There are a few user cases possible and I'm fairly certain nobody would want to lose their queue either by accident or by faulty programming. I've been through this - not nice.

1. Existing user, old qBT version, has queue, never touched Queue checkbox, upgrades; default: enabled.
2. Existing user, old qBT version, has queue, had disabled and then enabled Queue, upgrades; currently: enabled.
3. Existing user, old qBT version, has queue, never touched Queue checkbox, upgrades to new version, modifies queue, doesn't touch Queue checkbox, downgrades; default: enabled.
4. Existing user, old qBT version, has queue, never touched Queue checkbox, upgrades to new version, modifies queue, disables then enables Queue checkbox, downgrades; currently: enabled.
5. First time user, new qBT version, doesn't touch Queue checkbox, creates queue, downgrades, modifies queue, upgrades; default: enabled.
6. Old qBT version, has queue, disables then enables Queue checkbox.
7. New qBT version, has queue, disables then enables Queue checkbox.

Now, can you please tell what exactly happens to the queue in each of the above situations?
Because experienced or novice, user may just inadvertently/accidentally/for testing purposes/etc toggle the queue setting - or any other similar setting, for that matter - without expressly wanting to lose respective data. They may want to revert the change after seeing its effect. They may not want to kill the cat for stepping on the keyboard (I have 20 cats in the house, take my word for it).

So I'd say: don't erase the queue - just keep it hidden and in sync. For those who really, really want to get rid of it, add a button in settings called "Clear queue", visible only when checkbox is disabled and a queue exists. This way everybody should be happy - except for qBT programmers, I suppose - and accidents would hopefully be avoided.

@glassez

This comment has been minimized.

Copy link
Member

@glassez glassez commented Jan 11, 2020

So I'd say: don't erase the queue - just keep it hidden and in sync. For those who really, really want to get rid of it, add a button in settings called "Clear queue", visible only when checkbox is disabled and a queue exists.

Sorry, Queuing mechanism isn't yet another column for sorting... we can't have Queuing subsystem disabled and manages queue at the same time. It's nonsense.
The only issue is we inadvertently changed the default settings for existing users, although this should only affect new ones.

@glassez

This comment has been minimized.

Copy link
Member

@glassez glassez commented Jan 11, 2020

BTW, this issue isn't released yet and it will be fixed before upcoming release.

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 11, 2020

Well then, remove the option to disable queueing and there won't be any more problems.

But I still think it can be done. Just keep the sorting order according to when queue was last enabled, and restore it when enabled again, minus the completed/deleted items. Dunno how to explain this in detail, I just see it in my mind.

Thing is, the queue is the only way of grouping/sorting items by more than one feature, so categories clearly don't cut it. You can't imagine how I felt when I saw the list completely haywire after upgrade, and much worse when re-enabling Queue in new version destroyed the existing queue. That checkbox toggle should never destroy the existing queue - if it's not possible to keep it, then just remove the option to disable queue. Please!

@NotTsunami

This comment has been minimized.

Copy link
Contributor

@NotTsunami NotTsunami commented Jan 12, 2020

Well then, remove the option to disable queueing and there won't be any more problems.

That's not going to solve any problems, you know.

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 12, 2020

Why not? If one can't disable queue they can't lose it, be it by accident or by code bugs.
Even upgrade/downgrade with the faulty alpha that implemented #11678 didn't lose the queue until one messed with that particular setting by enabling it.
So if that checkbox goes, problems go. Or is there anything deeper than that? If so, please elaborate.

@glassez

This comment has been minimized.

Copy link
Member

@glassez glassez commented Jan 12, 2020

Well then, remove the option to disable queueing and there won't be any more problems.
...
Why not? If one can't disable queue they can't lose it, be it by accident or by code bugs.

Look, are you serious?.. This is very selfish. Other users can tell "why Queuing is needed at all? I just want to download some torrents, not caring about some sort of queuing, order, etc." Then why not just get rid of Queuing subsystem? (another selfish opinion)

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 12, 2020

Whoever "just wants to download some torrents" wouldn't even know a queue exists because - as you said - they wouldn't even care.
But there are people who know what a queue is and do want it expressly. And if that queue gets lost for whatever reason they'll be upset. The others would just be ignorantly happy, with or without the queue. And maybe, just maybe, at some point they'll learn what a queue is and what's it good for, and they'll start using it.
So why risk upsetting some people...? Isn't that selfish? Just sayin'...

@glassez

This comment has been minimized.

Copy link
Member

@glassez glassez commented Jan 13, 2020

I personally don't care what the default value is here. I don't belong to the category of users who never look into the settings.
But what I'm sure of is that if someone really uses Queuing and cares about its queue, it won't turn Queuing off on purpose just to see what happens.
And I strictly believe that managing a queue when it is disabled is absolutely illogical and pointless. Otherwise, what is the point of being able to disable it? Someone who does not use it clearly does not want to spend computing resources to maintain it, especially in such an unclear way. The one possible exception could be if "temporary disabling queuing" is regular (and valid) use case. IMO, it isn't.

As I said before:

The only issue is we inadvertently changed the default settings for existing users, although this should only affect new ones.

It will be fixed before upcoming version is released.

If you really believe that qBittorrent should manages queue behind the scenes when Queuing subsystem is disabled, please open appropriate Issue and argue your point of view there.

@Drugwash2

This comment has been minimized.

Copy link
Author

@Drugwash2 Drugwash2 commented Jan 13, 2020

Let me take another approach.
The queue is the only way to achieve a real custom sorting order by whatever criteria the user may think of. Then, on top of this there is the download priority and the whole behind-the-scenes queueing stuff.
All I'm saying is, if one disables queueing - and only queueing - for whatever reason, the custom sorting order should not dissapear. The items in the list should retain their current position and the user should be able to move items freely as before. Just disable the queue-related code.
And if later on the user chooses to re-enable queueing, the current sorting order will become the queue.
This could very well accomodate the idea of temporarily disable queueing that you mentioned above.

Thing is, you can't always know what the user is thinking and what their usage patterns are. In your opinion temporarily disabling the queue may not be regular or valid, but some users may disagree. A good application should be prepared for most - if not all - use cases, however improbable they may seem. Very few people may step up and ask for options or features, but that doesn't mean there aren't many more of them that for some reason can't or won't speak up.

Hopefully I made myself clear this time. Won't bring up this issue again. Thank you for your time and consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.