Digging further, I find that OpenSans is defined in theme-triton-all_2.css which is called by theme-triton-all.css. It should be very easy to just replace OpenSans with a non-problematic font, but it is not, because all this stuff is fetched from cdn.traccar.org instead of being served locally by the traccar server. What is the reason for this?
Then again, it seems I also missed the news. At which server version did this change?
The latest version is serving everything locally.
By the way, the CDN is open source. If you think something needs fixing there, you can potentially submit a pull request.
Update:
downloadable font: kern: Too large subtable (font-family: "Open Sans" style:normal weight:300 stretch:100 src index:0) source: http://track.qdh.nl:8082/lib/extjs/classic/theme-triton/resources/fonts/ClearSans-Light.ttf
Unknown property ‘-moz-box-shadow’. Declaration dropped. charts-all.css:1:1950
Unknown property ‘-moz-border-radius’. Declaration dropped. theme-triton-all_2.css:1:18837
Uncaught TypeError: Cannot read properties of undefined (reading 'getAttribute')
at new FilterContent (chrome-extension://bgpmiljelfnilfcfmoppijdkmccbccel/filter_content.js:23)
at chrome-extension://bgpmiljelfnilfcfmoppijdkmccbccel/filter_content.js:274
I assumed that the font errror caused the empty panels, but I can't trust that assumption that any more; the problem might very well be caused by something completely unrelated. Yet "grep -v INFO traccar/logs/tracker-server.log" shows no errors and only two warnings:
2021-12-28 17:04:04 WARN: Registered driver with driverClassName=com.mysql.jdbc.Driver was not found, trying direct instantiation.
2021-12-28 17:04:10 WARN: JAXBContext implementation could not be found. WADL feature is disabled.
I can log in on the web interface, which means that database connection works as it should.
Update:
Following a tip here, I installed FiraSans. That solved the "too large subtable" problem. A patch against 4.14 to use FiraSans instead of OpenSans can be fetched here.
However, I was barking up the wrong tree because the "Devices" and "State" panels are still empty. tc_devices is populated exactly as it should be and the traccar user can log in on the database. Firefox still spits out a pile of warnings ("unknown property xyz declaration dropped", "unreachable code after return statement"). I also get an error:
Source map error: Error: request failed with status 404
Resource URL: http://track.qdh.nl:8082/lib/ol/ol.js
Source Map URL: ol.js.map
ol.js.map on the last line of ol.js is commented out, so I'm assuming that this error is intentional and irrelevant.
Anton, any ideas how to troubleshoot this? Which part of the code reads tc_devices and populates the "Devices" panel?
Have you checked API requests? Do you get a list of devices?
So I logged out of traccar, enabled query logging on the database, and logged back in on traccar. After the traccar interface has been fully loaded, I see one single traccar query in the mariadb log: Query SELECT * FROM tc_users
. There is no query for devices.
Have you checked API requests?
I don't know how to do that.
Is that an answer to my questions? Or just random unrelated comment? Because it seems like you are checking something completely unrelated to the problem. Traccar has an internal cache, so you won't see any database queries.
I don't know how to do that.
Open network tab in your browser developer tools and search for /api/devices
.
There are no calls to the API. It loads a bunch of icons locally and then the map tiles from osm.org. Nothing else.
Care to provide some proof? Like a screenshot.
I can't screenshot the full network traffic because it doesn't fit in a window, but I can do better: here you have a screen video. (I forgot to switch off sound while recording; sorry for that.)
I see that you have a filter set to "Images". Obviously an API call won't be an image.
Bah, I hadn't noticed that. Thanks for catching it. New video on the same URL, this time without sound.
I am seeing something similar to this, though I don't have a touch screen and I'm using Firefox 91.3.0esr on Centos 7.9. On this same system everything worked fine until recently. I have no idea what might have changed in the meanwhile, other than Firefox being updated.
I found similar problems with OpenSans floating around, for example here and here, though nothing recent and nothing identical.