Closed craigsapp closed 1 year ago
The source of the problem is that the Siglum spreadsheet had a blank header cell instead of "Siglum" I noticed and fixed this sometime before Jan 10, but I have not remade the data server contents since then, so the index was missing a Siglum
header. So the index on the data server remained having a problem.
Here is the siglum index file:
https://humdrum.nifc.pl/siglum-index.json
Here is an example of the work pages now:
http://127.0.0.1:3434/?id=pl-kozmzk--mzk-m-10-ii
Also tooltips for library sigla on the browse page are working again:
There are still some problems with the Siglum index. When you load the work page (eg. https://polishscores.org/?id=pl-kozmzk--mzk-m-10-ii) index is downloaded properly, and the Library information is displayed:
Then if you go back to the browse page by clicking on up-arrow the index works as expected (short names are displayed when hovering over a list of siglum works, Library info is displayed on other work pages).
But if you load the browse page first (https://polishscores.org), there's still an error reported in the console:
Therefore hovering over the siglum list returns dummy info:
And the library info is missing:
After reloading the work page the information is back (https://polishscores.org/?id=16xx:900):
Yes, it is annoying. I think this was also the state of affairs in December. Trying it today, sometimes the siglum index is downloaded successfully and sometimes not. I have tried several things so far and it does not make a difference:
Access-Control-Allow-Origin: *
to the data serving script and that causes an error due to it being included twoce : from the Apache server and from the script that where I try to add it just before sending the data. In any case a transient behavior would not be caused by CORS.It is could a suble bug in the data server script. For example I store the indexes in zipped format, and maybe I am adding an extra space at the end/beginning of the file which the web browser somehow ignore sometimes and not others. Also it seems to behave as a timeout when getting the file, which is either related to Apache or the Web browser. I found documentation that Chrome only downloads 6 resource files from any server at a time, and it pauses request for more files until some of the 6 it is downloading has been received. Perhaps Apache does something similar, but it takes too long until it gets around to the siglum index. I was thinking in December about merging the indexes for the works/sigla/composer/instruments into a single file to see if that fixes the problem (but haven't done that yet). Firefox has a higher resource limit download, but it still has the same problem as Chrome.
I moved the download of the siglum and instrument indexes before download of the main score index and this seems to fix the problem. My current guess is that the problem occurs in the Apache server, where there is some default limit on connections.
Another possibility is to use .then
:
https://stackoverflow.com/questions/40981040/using-a-fetch-inside-another-fetch-in-javascript
Seems to be working always now.
Library information does not always load:
The archive for the physical object is NIFC, and it should be displaying on the right side of the page after the NIFC building logo and above the scan link.
The problem is that Chome only allows downloading six resources at a time from any particular website, and the library index is loaded after at least six other resources. And often downloading of the library index times out before it is loaded. (Firefox allows more simultaneous downloads from a particular website address).
The solution (which is partially implemented) is to embed the library and composer indices into the main index for the works. Then this delayed downloading and timeout will be avoided (or minimized).