Newly having this problem. macOS Big Sur 11.2.3.
Happens in both safari and Firefox, with or without user scripts.
Tried turning autoplay off and on, didn’t change it.
3 Likes
This is also happening for me. Rather annoying to say the least.
Firefox 89, MacOS Big Sur 11.0.1, seems to be independent of userscripts. 12 hours ago this was not a problem afaik. What happened during that time period?
Edit: also happens in Brave 1.25.72 (Chromium: 91.0.4472.101)
This suddenly started happening to me today as well. I’m on Chrome with no user scripts or WK extensions installed.
It’s especially frustrating since this is the second major bug in WK in the last week.
1 Like
Interesting; I was sure earlier I couldn’t reproduce on vanilla WK but maybe something changed that made it more common. I’ll retest when my reviews come up later today.
So far all the new reports are on Big Sur (I only tested on Windows 10 previously)
I’m experiencing this on Windows 10, Chrome 91. It worked yesterday.
im experiencing this on linux on firefox
1 Like
I am also having this problem on Windows 10 on Firefox.
1 Like
Same problem on Big Sur 11.4 / Chrome Version 91.0.4472.77. No user scripts involved.
1 Like
Chiming in to say I have the same problem, chrome user.
I think the issue people are experiencing today might be caused by the fact that they now stop all audio playback whenever the question changes in reviews by calling Howler.unload(). The modified version of DoubleCheck here disables that feature in order to fix a problem it caused with DoubleCheck, so it might also fix the issues people in this thread are seeing. I’ve also packaged that change into its own script below if you don’t want DoubleCheck.
UserScript to Fix the Issue
// ==UserScript==
// @name Audio Cutoff Fix
// @namespace wkdoublecheck
// @include /^https://(www|preview).wanikani.com/
// @version 1.0.1
// @run-at document-end
// @grant none
// ==/UserScript==
// don't remove audio that is currently playing or queued to play
void function() {
function main() {
waitProperty(window, 'Howler', function () {
window.Howler.unload = function() {
let howls = window.Howler._howls;
for (let i=howls.length - 1; i >= 0; i--) {
if (!howls[i].playing() && howls[i]._queue.length == 0) {
howls[i].unload();
}
}
// might need to add something here if wk ever switches to web audio
};
});
}
// helper method for waiting for a property to be defined on an element
// callback is called synchronously immediately after the property is defined
if (!window.waitProperty) {
let objPropCallbacks = new Map();
window.waitProperty = function (obj, prop, callback) {
if (obj[prop] !== undefined) {
callback(obj[prop]);
return;
}
if (!objPropCallbacks.has(obj))
objPropCallbacks.set(obj, new Map());
let propCallbacks = objPropCallbacks.get(obj);
let callbacks;
if (!propCallbacks.has(prop)) {
propCallbacks.set(prop, []);
function runCallbacks(val) {
for (let callback of callbacks) {
callback(val);
}
}
let _val;
Object.defineProperty(obj, prop, {
get: () => _val,
set: function(val) {_val = val; delete obj[prop]; obj[prop] = val; runCallbacks(val); callbacks.length = 0;},
configurable: true,
enumerable: true
});
}
callbacks = propCallbacks.get(prop);
callbacks.push(callback);
}
}
main();
}();
@WaniKaniJavi, maybe it would make sense to allow audio to continue to play after the user moves on to the next review question?
4 Likes
Yeah, I believe it only gets cut off when you move to the next question. If I take my reviews slower and let the whole sound play before hitting enter and moving on, it’s fine. So if you don’t want to use a script but want to hear the full audio, you’ll have to go through your reviews a bit slower until this gets fixed.
Thank you for identifying the problem, @est_fills_cando!
I couldn’t figure out why the script didn’t work and after many console.logs, finally noticed the typo when I came here to report my findings.
howls[0].unload();
should be
howls[i].unload();
2 Likes
We are currently checking this and will report back!
7 Likes
So glad to see this thread! I thought I was going nuts!
2 Likes
Thanks, I’ve fixed it. Sorry for the trouble!
Sorry about that, the original change was to address slowdown reported by some iOS users. I just updated production now with a better fix that lets the audio finish first before unloading.
11 Likes
Thank you for fixing this issue! I really appreciate being able to hear the vocab without having to slow my reviews down.
I don’t know if this is related, but now the audio does not play automatically when having vocab in lessons. The speaker icon for the first speaker is lit up, but no audio plays and clicking on it does nothing. The other voice line works fine when clicking on it though. I’m using WK vanilla on 89.0 Firefox (Win 10)
Edit: I also noticed it doesn’t play at all when answering the “reviews” just after learning the items
1 Like
For me using win 10 on Chrome 91, I noticed that vanilla WK the audio played normally, if a bit slow. But it was quite broken with my usual scripts. It would either not play at all or start playing a bit and then immediately stop even before I went to the next item.
I didn’t test a lot since I don’t like messing my actual reviews. (There should be a wanikani staging server for testing!)
If you are talking about regular reviews, they are working fine for me since the fix from WaniKaniJavi. problems occurs only in lessons and the following reviews that puts them in my SRS queue