ArneVogel/listudy

Some studies won't import from lichess

IndeedLad opened this issue · 11 comments

So I am working on opening builder software and I've recently noticed that one study is not importing from lichess to listudy.

This is the study:
https://lichess.org/study/33XXz70a

This is how it looks:
https://user-images.githubusercontent.com/119752463/206889359-c3968718-8adf-424a-8e68-c050f07b8196.mp4

I don't have that issue when importing just a single chapter. It's a big study I know but in the past I imported almost equally big study from lichess to listudy without any issues. Since that time I've played around with PGN headers but it does not seem relevant.
I am KurKucy on listudy and lichess if you want to check my studies out.

Can you try importing again? It worked just fine for me.

Worked for me too..

I changed web browser from Chrome 108.0.5359.96 64 bit to native Edge and it worked. Weird stuff only this study had that issue.

This was a temporary solution. Today I wanted to upload this study: https://lichess.org/study/tgaKM6YZ, looks the same in every browser that I tested Chrome, Firefox, Edge and Opera.

On listudy https://listudy.org/en/studies/sokck1-test :
it looks like that with no chapters to select from drop down list and with small chessboard and clear visual bugs
image

Here is a pgn of that study exported from lichess
lichess_study_main-white-repertoire-1-e4-1_by_KurKucy_2023.01.08.txt

Edit: This is such a weird behavior sometimes it works sometime it's not different studies work on different browsers.

Out of curiosity I checked the scripts source code:

line: 8128 n = Math.min(n, trees.length - 1),

function() {
            var e = study_id + "_selected"
              , t = document.getElementById("chapter_select")
              , n = parseInt(localStorage.getItem(e) || 0);
            n = Math.min(n, trees.length - 1),
            window.chapter = n;
            for (var r = 0; r < trees.length; ++r) {
                var u = document.createElement("option");
                u.value = r;
                var o = je(r);
                u.innerText = o,
                r == n && (u.selected = !0),
                t.appendChild(u)
            }

Here I get an error
Uncaught TypeError: Cannot read properties of null (reading 'length')

I am not proficient in js at all so it is hard for me to tell why this is not working but maybe this will shed some light on the issue

Before getting that message I also get "DOMException: Failed to execute 'setItem' on 'Storage': Setting the value of 'pq9q1f_tree' exceeded the quota."

Your file is 487 Kb which is larger than anything I've tried, so we're probably running into some kind of limitation on the amount of stuff you can store in the browser's localstorage.

image

Now, it might be a limitation on the size of the PGN file, or it could be a limitation on total storage per website domain. So it's possible that you have already uploaded enough pgn files, and all of them have added to the amount of data stored. I am not sure if the localstorage data is cleared after you delete a study, I don't think it is. So deleting some studies won't help then.

What you could do in an attempt to get it working is look into clearing the localstorage of listudy.org, or just the keys ending with _tree. In chrome you open the developer tools (F12), then go to the Application tab, and here you can search for anything that ends with _tree (see screenshot below). Hitting Delete on the keyboard deletes these. But, when you do that the uploaded study in question breaks, so you then have to delete it and upload it again, or possibly just upload the PGN file to it again. Now, this will only fix the problem is the problem is the total storage limit. If the problem is in the size of the repertoire I am afraid that's going to require looking into storing the data for each study more efficiently, if it's at all possible.

image

Now, it might be a limitation on the size of the PGN file, or it could be a limitation on total storage per website domain. So it's possible that you have already uploaded enough pgn files, and all of them have added to the amount of data stored. I am not sure if the localstorage data is cleared after you delete a study, I don't think it is. So deleting some studies won't help then.

Yes, all previous uploaded studies were in local storage, I flushed them.

What you could do in an attempt to get it working is look into clearing the localstorage of listudy.org, or just the keys ending with _tree. In chrome you open the developer tools (F12), then go to the Application tab, and here you can search for anything that ends with _tree (see screenshot below). Hitting Delete on the keyboard deletes these. But, when you do that the uploaded study in question breaks, so you then have to delete it and upload it again, or possibly just upload the PGN file to it again. Now, this will only fix the problem is the problem is the total storage limit. If the problem is in the size of the repertoire I am afraid that's going to require looking into storing the data for each study more efficiently, if it's at all possible.

After flushing I tried to upload the first part of repertoire. It worked! Then after same steps (deleting study and local storage memories) uploading this study which is a whole white repertoire https://lichess.org/study/tgaKM6YZ, aprox 900 kB. Now it's not working. I guess the possible work around is to stick to smaller chunks of studies. Kudos to you for such elaborated answer and contribution to this project. You are awesome!

I think I may have some idea how we can get around this. Maybe we can just skip storing the tree in localstorage if we run into limit problems. I think it's only meant to speed up the loading. I made some modifications to some source lines and it seems to run ok.

But I need some time to look into this. And see what Arne thinks.

I see, the idea behind my project is to make automatic comprehensive full repertoire studies this means that studies are going to be big. I was looking for a platform to share and learn these studies. Listudy seems to be the best option out there.

Thanks by the way for the kind words IndeedLad. I hope this fix works for you.