Hey, it seems like the WaniKani Improve script isn’t working for me. I tried turning it off, doing some reviews, and turning it on again, and it worked for the first item then stopped working again.
I still get the WK Improve style burn notifications though (down on the previous item button). It just doesn’t skip forward automatically.
Edit: Oh, I just realised my Jitai script is stuck on one font too! I didn’t even notice until I read the previous post 
It shouldn’t be stuck on one, but there is only one other than the default.
Yes, that’s it. It uses just one of the Jitai fonts, along with the default font.
I don’t think that’s a bug. It’s probably just an outdated version of the script.
EDIT: It would be nice if the other fonts could get added though.
I’ve started experiencing an issue today where every time I try to start a session to do reviews, I’m logged out and forced to log back in again. And then once I do this, the font on the reviews is extremely small and the “ignore answer” button is missing. Exiting and restarting the session fixes this (mostly, since the app is still running bit slower than normal), but it’s inconvenient to have to go through this process every time it’s time to do my reviews again. Is anyone else having this issue?
This actually happens to me with both Mobile AlliCrab and with the iPhone discourse app. Very annoying! I think I logged into Discourse like 5 times today already on the phone.
I have no concerns about modifying the scripts I include, but I try to modify them as little as possible. Mostly for the practical reason that’s easier to update them to newer versions, but also so that people who use scripts on both desktop and mobile have a similar experience.
Not sure about having tap change the font. I’d still like to keep the ability to quickly return to the default font, rather than having to tap through the fonts until you find it. Will give it a try and see what I think it’s like in action.
It is a bug, related to the change in web component. It now runs out-of-process (where the old one ran in-process) and thus can no longer see the fonts I have packaged with the app. I’ve found a workaround for this, so will get this into the next release.
I’ve had a few complaints about this the past day or so. It works until the first wrong answer, then stops automatically skipping forward. I can’t remember if it was working for me or not because I kept turning it on and off to test other things. I will need to have a look at it to see what’s going on. It may be related to the workaround they put in place for Japanese keyboards crashing Safari since the timing is quite coincidental.
The missing scripts after logging in is a long-standing bug I keep meaning to look into. You don’t have to exit and restart the session, reloading the page should be sufficient.
Not sure why it’s logging you out though. I presume you tick the “Remember Me” box when you log in?
I realised earlier today it stops working as soon as you hit the arrow button that moves you to the next item; you don’t have to get the item wrong. I’m a butterfingers and sometimes accidentally mash that button with my thumb before typing in an answer. The answer field wiggles and the lightning mode stops working after that. If I get the item right it shows the green bar and I have to manually move forward.
Anyway, thanks for your continued hard work. 
Looks like it will stop working as soon as you tap anywhere on the page. Once a tap is registered, a 200ms delay is inserted between when an answer is submitted and when it’s marked as correct or incorrect. I assume this was the workaround for crashing when using a Japanese keyboard. WK Improve is now running its answer checking routine in that 200ms gap, so because the answer hasn’t yet been marked correct or incorrect it does nothing. Should be pretty straightforward to fix this so it works again. Unlikely I’ll be able to look at making this change before tomorrow evening.
Hey @cplaverty, more data n the music thread issue:
Noticed tonight that it happens after playing an embedded video in that thread, the next control I touch ( a heart or reply or play another video) the damn thing jumps up twenty posts.
Also, it just did it to me on the watermelon awards thread. Played an embedded video, went to hit the heart, it jumped up 20 posts.
Thanks, that’s very useful. Haven’t yet had a chance to look at this, but hope to soon.
A new issue came up today, possibly related to the WaniKani update. When I had done my reviews this morning, I had to refresh like five times to make it acknowledge that I just did my reviews. Now my review timeline tells me that I have 46 reviews due, but the review count says 0 and stays like that even after refreshing quite often. WaniKani webpage also says 46 are due, I checked.
One more little detail I noticed: the click (well, touch) that causes the jump does actually happen first, as in when I scroll back down, the heart I touched has been “made red”. It’s not always an EXACT 20 post scroll, but it’s always ± 1.
Now back to why setting --set-max-dex-number=50000 still results in a single dex referencing 64,000 methods.
Edit: dex silly app, nobody here named Dexter…I won’t even comment on the other autocorrect lol!
Possibly related to this issue which happened yesterday:
Are you still seeing incorrect counts in the app?
I’ve finally had some time to look at this. I can reproduce this if I play a video using YouTube’s embedded HTML5 player, then just tap any space outside the video. (Doesn’t even need to be a control, just the empty space will do.) There’s something that happens when that player loses focus that causes the scroll, but I haven’t yet isolated it. Neither can I explain why the web view behaves differently to Safari. Am still debugging through this trying to find the underlying cause.
Last i messed with a webview in iOS (it’s been well over a year) I found quite a few ways in which it behaves differently from Safari or Chrome (both webkit). Good luck!
…might override the event listener in a web client and prevent the event’s propagation as a hack or something like that…i dunno, it’s early…
Just a thought and probably most unlikely. How often do the apps hit the API? We updated the throttling from 100 RPH to 40 RPM and 240 RPH.
edit: Nevermind… The timestamp of Tygers post is 24 hours ago.
Yeah, Tyger’s post came through during that time period where others had posted with similar experiences on the thread I linked, which is why I assumed it was related. I’m hoping it’s the same issue and as such is now resolved.
However, for completeness, AlliCrab’s item download algorithm:
First, a check is done to see if any reviews or lessons have been done since the last download:
Otherwise, the app requests:
The first two happen in parallel, then the last three happen in parallel. A given level’s SRS item data is only downloaded if:
The list of levels to be downloaded is determined independently for each of the item types. Once the list of levels to be downloaded has been determined, this is then batched using the following maximum batch sizes: radicals 30, kanji 20, vocabulary 5. (I’m increasing these batch sizes in the next version after the API performance improvements, so that radicals and kanji requests are unbatched and vocabulary is batched with a max size of 15.)
This download process is only automatically done at most once every 15 minutes, scheduled to happen at a random time between 5 and 30 seconds after the quarter hour. However, the user can refresh manually at any time, though it will still do the projected study queue check to determine whether anything actually gets downloaded.
Worst case scenario, a level 60 user who has just downloaded the app will perform 20 API requests in relatively rapid succession (study queue, level progression, SRS distribution, 2 radical batches, 3 kanji batches, and 12 vocabulary batches). But further fetches in general I would expect to be substantially smaller.