(I am posting this message as a new thread and as a reply to a thread that seems relevant, if only outdated/about a different version, mods please feel free to delete either post/reply if they are misplaced!)
I just upgraded to v2.1.46 from v2.1.35 on linux desktop; now using the v3 scheduler and I’d like to report a bug.
I very much prefer the parent decks to respect the limits of child decks. If I’m not mistaken the v3 scheduler is supposed to do just that, as stated in the “the 2021 scheduler” section of the FAQs: “…each child deck’s limit is also enforced.”[0]
[0]https://faqs.ankiweb.net/the-2021-scheduler.html#daily-limits
While this does seem to be the case for a parent deck with only 1 level deep of child decks, when children are nested 2 levels deep or more the top parent only respects the limits of the bottom level decks and not the limits of the middle decks.
Anki shows 10 cards when studying the Parent deck: 5 from Grandchild A + 5 from Grandchild B (assuming that the Child_1 deck contains no cards, only subdecks)
What you say makes sense; If parent decks only consider the limits of decks which contain cards directly, then that would lead to ignoring the middle decks which are just intended for structure (and controlling review limits…). I hope this is not the intended behavior though because I think it would also leave me with no way to achieve my desired behavior.
BTW here is another example to maybe make it more clear why this is important for me:
In this example, I want to be able to study the entire “Parent” deck together and get all cards due for “Child_1” as well as up to 5 cards due from both “Grandchild_A” and “…_B” but not more.
If you set Child_1 deck to 0 new cards, 0 reviews, and study the Parent deck, you should still get 10 cards (Child_1 limits are ignored)
Tested and confirmed, the Parent deck still includes the grandchildren while Child_1 shows nothing to review (both in the decks view and when entering the deck for review i.e. “Congratulations! You have finished this deck for now.”)
In this case, you could set Grandchild_A limit to 3 and Grandchild_B limit to 2. Would that work for you?
No this would not work because if Grandchild A has 0 cards due I will only get a max 2 cards from Grandchild_B and vice versa. I would have to change the deck limits every day to make sure I got up to 5 of the available due cards.
For me one of the major benefits of anki is that I can set it once and then have 0 friction on a daily basis when it comes to doing my reviews. (Of course I love to tweak it in my free time! But from day to day I can just open a deck and go.)
I see. In that particular case an option could be using tags instead of subdecks. You could, for example add a descriptive tag to the cards in Grandchild_A and another one to cards in Grandchild_B, merge the two subdecks into one (Child_2), and you should be done.
I see. I that particular case an option could be using tags instead of subdecks. You could, for example add a descriptive tag to Grandchild_A and another one to Grandchild_B, merge the two subdecks into one (Child_2) and you should be done.
While this would be a workaround (and admittedly I haven’t made great use of tags), it would mean duplicating a lot of work that is already done by separating cards into decks. Also some decks that I use are shared decks from other people which I prefer to keep separate and in their shared form (aside from my intervals/scheduling of course). And most importantly it just isn’t how I am used to organizing my information. Decks are intuitive to me and tags simply are not. Tags are powerful in their ability to maintain interconnected webs of information and for that I would really like to get more proficient with them but for things that are strictly hierarchical decks are better (and I believe that is what this situation calls for).
Thank you for the suggestion. I do believe this would technically workaround the specific issue, if not a solution to my use case.
Also the examples given are the simplest form of this issue, in some cases deck gran_A and gran_B are also just parent decks with their cards divided into further sub-decks. You can see how converting to tags could become a rather tedious undertaking, rife with chances to screw up the organization of the cards. And again I wouldn’t want to consider that for shared decks not made by me (would make updating a hassle to say the least).
Another issue is if I ever want to study a sub-deck individually I have to now create a filtered deck rather than just being able to click the deck and get going (0 friction).
Also I cannot see at a glance from the decks view how many cards from each sub-deck are due if they are only separated by tags and not decks.
… I think you can see I’m pretty resistant to using tags fir this.
I do think some of those drawbacks are significant though and not just my discomfort with the paradigm shift.
Edit 4: geez sorry for the essay!
… Another drawback is if I ever want to change the review limits to specific gran decks I now have to reseperate them out into their own decks and while it’s not that hard to create a new empty deck. filter by a tag, and the move them to the new deck, it’s a lot easier to drag and drop an existing deck.
I’m afraid this was an intentional change. I understand the appeal here - it means you can click on the top-level deck and have subtotal limits on each subject you’re studying, while also imposing limits on individual grandchild decks. But such flexibility came at a cost - it made it harder for users to reason about the number of cards that will be shown (parent limits were a common source of confusion), and it also considerably complicated the implementation.
While it’s disappointing to hear that this behavior is intentional I can definitely see how it is easier to implement. Can you tell me, is this functionality written in the Rust language portion of the code? For me this way of counting the review limit is much more confusing, and (as anyone who has read this thread to this point knows) blocks me from organizing my decks and their limits as I would like. Perhaps, if the devs are open to it, I could contribute the logic to allow my preferred implementation as an opt in alternative.
I imagine something along the lines of, first check the limits on deepest sub-decks, then for each parent deck only consider what the top level child allows through…
Anyway, while I am bummed about this particular feature, I am so very grateful to you all who have worked on this project for the many other wonderful features! This last big update (2.1.45) in particular has some really fantastic improvements and the good far outweighs the bad. So, thanks again!
Yes, v3 is implemented in the Rust backend. I’m afraid I’m not really keen on a PR that adds this as an optional feature, as it means another option users would need to think about, and it means the code will be even harder to maintain, as we now need to deal with two different approaches. That said, I will keep an eye on demand for this as v3 receives more uptake, and can revisit the decision in the future if necessary. Sorry to not have better news there, but happy to hear that you like other aspects of 2.1.45 - thanks for taking the time to say so
I want to chime in and say that I am incredibly disappointed with this change. I have been using Anki since 2014 and my collection has always been organized in such a way that I can limit my workload by changing the parent decks. I probably have hundreds of subdecks, so I can not just change the limits on all of them individually or move them out of the parent decks…
Ok same here, im not really sure who was having confusion on deck hierarchy but i have a feeling it was people new to anki or people who do not use it often, and honestly that’s just because there’s so much going on in anki as a whole, when you first get started that nested decks as a whole are probably quite confusing. Outside of that, and for people who use it often its quite the opposite, for a nested deck to only take into account the parent deck and not any of the parents children or grandchildren seems extremely counterintuitive, and although I acknowledge that it probably is quite a bit easier to design and maintain, it’s just not a good structure. It completely and totally destroyed all ability to organize decks, and ruins deck nesting for any decks nested more than one level deep (which is all of my decks, lol) also as far as i can tell this new change doesn’t help at all. I need parent decks to respect the limits of there children, and not the other way around. 2.1.5 doesnt do that. Here is the implementation that i think would be best, and most intuitive, please let me know what you think. The current deck has control at what you see at that level. That goes up (parents) as well as down (children). Neither parents nor children take priorsty, the think that takes priority is whatever the least number of cards is. If child or grandchild deck has a limit less than a parent deck than it gets respected all the way up (meaning if i click on a parent, than the child deck should still only show the lower amount (min) between the child and parent max cards) and same goes for a parent deck with a limit lower than its child or grandchild. Lower limits should define structure not deck hierarchy, or at the very least it should follow the same rules as the new cards. That is very confusing to me as well, why is the behavior so different for new cards as apposed to review cards?
