Thanks. I hadn’t realized all that info on the database structure was available on github. I should have found it myself.
I guess when a card is manually set the due date changes but not the interval, which explains they’re the same… but when I look at the due date for that same card (set to 25 days) it says 1690. If I search in the browser for cards due in 25 days, there it is.
Since you’re doing this to try to work with FSRS, you might also want to consider that the FSRS doesn’t use current or past intervals in its computations. So there wouldn’t be much benefit to changing those.
…
If your problem is as simple as “misuse” of Hard (for incorrect answers instead of just for correct answers) – have you thought about trying the existing solutions first? A feature was added to the FSRS Helper add-on that converts those Hard’s in the deck history to Again’s – Reddit - Dive into anything – which is at least worth a shot.
I did use Hard that way sometimes but there are also a lot of cards that have been manually rescheduled time and time again, so I would need to extend that approach to cover them. The problem is you can’t tell what button they should be changed to unless you can compare the interval / due date before and after rescheduling. One card might have had an interval of a year and been rescheduled to 14 days (not sure whether that should be Hard or Again), another card might be the other way round (so I guess Easy). So I’m not sure if I need to change this data, but I do need to look at it in order to change the button code (ease value) in the revlog table. My understanding is that FSRS looks at when the card was reviewed and which button was pressed, but can’t do anything if the button code / ease value is 0, which it is for manually rescheduled cards.
Now that I read the info on your link I see that the db doesn’t work quite the way I thought and actually the rescheduled date for past reviews isn’t captured because rescheduling doesn’t change the ival value in the revlog table and the due value in the card table is a current value. But you can still work out more or less what the new due date was by looking at when the card was next reviewed. For cards that were rescheduled last time they came up, I would have thought you could just look at the current due date, but as I say the card that is due in 25 days has a due value of 1690 (in the card table) and I haven’t understood that yet.
Also, don’t I need to change the interval to reflect the rescheduled due date? Say the interval is one year but the due date [I set on the previous review was] 14 days. If I switch to FSRS and the algorithm sees the card answered correctly after 14 days, it will want to increase the interval from one year when I want it to increase it from 14 days. I will see this on the buttons and manually reschedule, and then I’m back in the same loop I’m trying to get out of.