Strange problem with PDFs loading slowly

So for no good reason, starting last week some time, all items with PDFs started loading really slowly or not at all (just hanging). :frowning: This seems to be true no matter which computer, browser, or connection we’re using - so it’s either our server or Omeka. We have our own server space that I control, but it isn’t throwing any errors… Is there anything I can check out on the back end related to how Omeka loads PDFs? Is it possible that a server-side update (which the off-site company automatically runs) could be causing this? I am not even sure where to begin.

Perhaps a related issue: noticed that both the main site’s CSS file and the thumbnails on the admin side don’t load until I hit refresh.

What version of Omeka and which plugins are you running?

Hi Megan, Here’s the system info page:

Omeka	2.3
PHP	5.6.30 (fpm-fcgi)
OS	Linux 3.10.0-042stab120.20 x86_64
MySQL Server	5.5.44
MySQL Client	mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $
PHP Extensions
Regular	bcmath, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dba, dom, enchant, ereg, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, imagick, imap, intl, ionCube Loader, json, ldap, libxml, mbstring, mcrypt, mysql, mysqli, mysqlnd, odbc, openssl, pcre, PDO, pdo_mysql, PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, redis, Reflection, session, SimpleXML, soap, sockets, SPL, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib
Zend	the ionCube PHP Loader (enabled) + Intrusion Protection from (unconfigured), Zend OPcache
BrowseValues	(inactive)
Carta	2.1.1 (inactive)
Corrections	1.0
CreatorBrowse	1.0
DerivativeImages	2.0
Dropbox	0.7.2
ExhibitBuilder	3.2
GuestUser	1.1.1
HideElements	1.3
HistoryLog	1.1.5
ItemRelations	2.0.2
Neatline	2.5.1
NeatlineFeatures	2.0.5
NeatlineSimile	2.0.2
NeatlineText	0.2
NeatlineTime	2.0.4 (inactive)
NeatlineWaypoints	2.0.2
PdfText	1.3
RecordRelations	2.0.1
Scripto	2.2
SearchByMetadata	1.2.1
SimplePages	3.0.5
SimpleVocab	2.0.1
SolrSearch	2.3.0
SubjectBrowse	2.3
TCsDialogue	0.3 (inactive)
TextAnnotation	0.2 (inactive)
UserProfiles	1.1.1
berlin	2.3
default	2.3
seasons	2.3 (current)

Here are some screenshots. The first is from the results page, all of these are PDF files, but for some reason only some show up the first time before I refresh (I guess they must be stored in the cache?). The second image is what I see when I click on the item to see the file - either a black PDF window or the spinning white one you see in my screenshot. If I download the file it’s fine; the files aren’t that big and I get it quickly without issue. So there’s something happening with rendering the images in the browser such that it never displays in the PDF window itself.

Some more information. When I look in the browser, I see the following errors - this is really odd because I have not seen these before. I’m now thinking this must be some kind of server error or conflict, not Omeka. Still have no idea what I can do to fix it… wish I knew more about servers.

Uncaught TypeError: Cannot read property 'call' of undefined
    at Ia (js:28)
    at new _.Ig (js:97)
    at tile.stamen.js:176
    at tile.stamen.js:179
l10n.js:108 Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check
xhrLoadText @ l10n.js:108 Failed to load resource: the server responded with a status of 403 (Forbidden)
pdf.worker.js:1690 The provided value 'moz-chunked-arraybuffer' is not a valid enum value of type XMLHttpRequestResponseType.
NetworkManager_request @ pdf.worker.js:1690
pdf.worker.js:1690 The provided value 'moz-chunked-arraybuffer' is not a valid enum value of type XMLHttpRequestResponseType.
NetworkManager_request @ pdf.worker.js:1690
viewer.js:3595 PDF 245b541ff56cddd8bc156bab5ed67598 [1.5 ABBYY FineReader 14 / ABBYY FineReader 14] (PDF.js: 1.0.837)
/omeka/files/original/5fb62f5802f563b94268a6d4abbf0054.pdf Failed to load resource: net::ERR_EMPTY_RESPONSE Google Maps API warning: NoApiKeys
iB.j @ Google Maps API warning: RetiredVersion
iB.j @ Google Maps API warning: SensorNotRequired
iB.j @ Failed to load resource: the server responded with a status of 403 (Forbidden)
/omeka/web/images/toolbarButton-zoomOut@2x.png:1 GET http://[domain]/omeka/web/images/toolbarButton-zoomOut@2x.png net::ERR_EMPTY_RESPONSE
/omeka/web/images/toolbarButton-secondaryToolbarToggle@2x.png:1 GET http://[domain]/omeka/web/images/toolbarButton-secondaryToolbarToggle@2x.png net::ERR_EMPTY_RESPONSE
/omeka/web/images/toolbarButton-pageUp@2x.png:1 GET http://[domain]/omeka/web/images/toolbarButton-pageUp@2x.png net::ERR_EMPTY_RESPONSE
/omeka/web/images/toolbarButton-viewOutline@2x.png:1 GET http://[domain]/omeka/web/images/toolbarButton-viewOutline@2x.png net::ERR_EMPTY_RESPONSE
/omeka/web/images/toolbarButton-viewThumbnail@2x.png:1 GET http://[domain]/omeka/web/images/toolbarButton-viewThumbnail@2x.png net::ERR_EMPTY_RESPONSE

There is a link to inside the javascript, but the content is restricted, so you have to check it.

Thanks for responding, but I don’t understand what I have to check exactly? And are the 403 warnings related to permissions?

I’m so confused because up until a week ago I didn’t have any trouble with these files…

Your site tries to access to Which plugin do you use that uses it? This is an open source gallery, so you probably know why you need to access to the data, or parameter it to not access it.

It looks like my predecessor customized this in the show.php page. The code checks to see whether or not the file extension is .jpg and then proceeds from there to create the javascript object. I’ve never had an issue with it before, so I haven’t touched it; it appears to still work without a problem on pages with jpgs, which do seem to be loading fine.

Just an update… I checked my server’s error logs and for this domain I seem to randomly get 401 and 206 errors (they seem sporadic and not related to any particular files or items). All the PDF files are 206. However, I’m going to try and find some server help online, I think this isn’t an Omeka issue.

FWIW, it was a server problem related to an outdated security certificate. The log files were showing that sometimes requests were trying to access http:// and other times https:// and so far as I can tell, that was creating the issue. What fixed it was creating a new certificate… fingers crossed!