v0.20.0 (BREAKING CHANGES, ACTION REQUIRED)

[alexjustesen]

Warning

This release requires you to change your container's image and make changes to your environment variables for Speedtest Tracker to continue to function and receive updates.

Important

If you have an problem which resulted from this release please open an issue with as much detail as possible, if you have a question or need clarification use the linked discussion topic.

Action Items

With the switch to using environment variables for the application's general settings action is required to update your environment. Below are all the changes that you might need to make.

🐋 Docker image

To get this update and future updates you will need to switch to using LSIO's images, as of v0.20.0 I am no longer building mine. Details on how to switch can be found here #1117.

🔑 Application key

The app key is no longer generated when you start the container and should always be set in your environment variables. You can generate a key here: https://speedtest-tracker.dev.

- APP_KEY= # use the entire base64 string including the "base64" prefix

⏰ Timezone

I think I finally have a better solution for handling timezones, especially for those of you that like to watch the world burn and your database isn't set to UTC.

My database is set to my local timezone

Set APP_TIMEZONE AND DISPLAY_TIMEZONE to your local timezone, this ensures the application writes the correct timestamp to the database and then displays it.

This was tested with both MySQL and Postgres with the container's TZ set to the same timezone.

- APP_TIMEZONE=America/New_York
- DISPLAY_TIMEZONE=America/New_York

My database is set to UTC / I don't know or use SQLite

Set DISPLAY_TIMEZONE to your local timezone, this ensures the application will display timestamps correctly.

- DISPLAY_TIMEZONE=America/New_York

🐇 Speedtests

Speedtest settings have also been moved to environment variables, SPEEDTEST_SCHEDULE, SPEEDTEST_SERVERS and optionally PRUNE_RESULTS_OLDER_THAN should be added to your configuration.

- SPEEDTEST_SCHEDULE= # can be represented as a cron schedule same as before.
- SPEEDTEST_SERVERS= # you can add one or many servers separated by a comma (i.e. "123456,654321,987654").
- PRUNE_RESULTS_OLDER_THAN=0 # the default is 0 which disables result pruning, this value is in days.

How do I find a list of servers now?

There is a new CLI command in the container that you can run which will return a list of the "best" speedtest servers based on your location. To get the list follow the steps below:

1. Open a terminal into the running speedtest container
2. Navigate to the app directory cd app/www
3. Run php artisan app:ookla-list-servers or provide a search term as the first argument php artisan app:ookla-list-servers "frontier"
4. Using the list provided you can add the server IDs to the SPEEDTEST_SERVERS environment variable

I am working on a centralized, searchable and community driven list of servers which will be available later this summer.

What's New

• Laravel 11.x Shift by @alexjustesen in Laravel 11.x Shift #1389
• [Feature] Removed general settings page (BREAKING CHANGE) by @alexjustesen in [Feature] Removed general settings page (BREAKING CHANGE) #1464
• [Feature] Custom 500 server error page by @alexjustesen in [Feature] Custom 500 server error page #1417
• [Feature] Unique Ookla speedtest job and increased timeout by @alexjustesen in [Feature] Unique Ookla speedtest job and increased timeout #1418
• [Feature] Check for internet connection before running a test by @alexjustesen in [Feature] Check for internet connection before running a test #1444
• [Feature] added filament user profile by @alexjustesen in [Feature] added filament user profile #1466
• Add App url and Packet loss to the notifications by @svenvg93 in Add App url and Packet loss to the notifications #1390

What's Changed

• removed version from docker compose by @alexjustesen in removed version from docker compose #1388
• [Bug] Added point background color by @alexjustesen in [Bug] Added point background color #1416
• [Chore] Removed ffmeg from dev image by @alexjustesen in [Chore] Removed ffmeg from dev image #1421
• [Chore] Disabled test workflow job by @alexjustesen in [Chore] Disabled test workflow job #1422
• Laravel 11.7.0 Shift by @alexjustesen in Laravel 11.7.0 Shift #1420
• Laravel 11.8.0 Shift by @alexjustesen in Laravel 11.8.0 Shift #1437
• [Chore] Removed pipeline image builds by @alexjustesen in [Chore] Removed pipeline image builds #1442
• [Bug] Fixed updating the result record when a test fails by @alexjustesen in [Bug] Fixed updating the result record when a test fails #1443
• Laravel 11.9.1 Shift by @alexjustesen in Laravel 11.9.1 Shift #1451
• [Bug] removed extra $ in password reset error message by @alexjustesen in [Bug] removed extra $ in password reset error message #1457
• Refactor app commands by @alexjustesen in Refactor app commands #1458
• Laravel 11.10.0 Shift by @alexjustesen in Laravel 11.10.0 Shift #1456
• [Chore] Use Cloudflare instead of google for internet checks by @alexjustesen in [Chore] Use Cloudflare instead of google for internet checks #1459
• [Chore] Removed remaining docker assets by @alexjustesen in [Chore] Removed remaining docker assets #1460
• [Docs] Updated readme for 0.20.0 release by @alexjustesen in [Docs] Updated readme for 0.20.0 release #1461
• [Chore] Use SQLite for development env by @alexjustesen in [Chore] Use SQLite for development env #1462
• gh actions: bump tighten/duster-action from 2 to 3 by @dependabot in gh actions: bump tighten/duster-action from 2 to 3 #1463
• [Chore] Removed bundled assets by @alexjustesen in [Chore] Removed bundled assets #1465
• [Docs] updated generate app key url by @alexjustesen in [Docs] updated generate app key url #1468
• Release v0.20.0 by @alexjustesen in Release v0.20.0 #1469

Full Changelog: v0.19.0...v0.20.0

[jacotec]

Does this mean that every change of speedtest servers and schedule must be done in the environment variables (including container restart)? What is the reason for this huge step back?

The general settings page was absolutely perfect!

[alexjustesen]

I understand the reasons but I also feel this is a big step back in UX. I have to update the server lists every few weeks as some seem to disappear (which then cause "silent" failures) and it was always very easy to see which ones were gone and remove them and then add in one or two others. That whole process is now way more hassle.

I've got a notification for this coming soon so if a server is unreachable or seems to have gone offline it'll be proactive on notifying you.

[Investigamer]

So if I understand this correctly, as of the current version there is no way to manage speedtest schedule as well as locations from the UI anymore?... With no plans to return this feature? Man, that's a shame, always loved this container.

[scottb721]

Man, that's a shame, always loved this container.

I know nothing about coding and I was able to get it working as it was prior by adding some stuff to the compose script.

[Investigamer]

I know nothing about coding and I was able to get it working as it was prior by adding some stuff to the compose script.

I just reverted for now, I could certainly throw in the env variables to setup the configuration as I had it before, I just prefer having these various settings be part of the interface. Will keep tabs on this project for the foreseeable future to see where it heads with the new implementation, for now I might spin up the MySpeed container and give that a whirl. Not as pretty to look at, but the interface seems to suit my needs.

[pjdubya]

Yeah, count me in as someone who thinks the schedule and servers at least should be in the UI still. Understood of course about other dev priorities and that this is your product to decide what to do with, but just from a usability perspective it's quite a hassle to have to ssh into my docker host, find my docker compose for this, make the change, sudo docker down / up, then try to validate that I got the syntax right. I'm trying to imagine what about the schedule and server list information would really be needed at boot and couldn't still live in the DB and/or be pulled from the DB at boot. Anyway, just some feedback. While I'm here, the app itself is really beautiful and, once I figured out how to use it properly, integrates well with my HomeAssistant instance using webhooks, so definite kudos for the great work.

[richelo]

Where do we set these new environment variables? The docker-compose-yml file?

This is a little over my head to be honest.

[alexjustesen]

Correct, examples for both Docker and Docker Compose installs can be found here: https://docs.speedtest-tracker.dev/getting-started/installation/installation

[scottb721]

I don't understand the reason for the 2 different methods but here's an example of mine in the other compose style without the dashes.
environment:
DISPLAY_TIMEZONE: Australia/Sydney
SPEEDTEST_SCHEDULE: 0 */2 * * * #2hrly scan
SPEEDTEST_SERVERS: 15132 #Aussie BB
PRUNE_RESULTS_OLDER_THAN: 0

[alexjustesen]

Formatting of the environment variables doesn't really matter, just stay consistent to your preference.

[hornickj]

Is there a way using docker or docker compose to update the currently installed version so it keeps the history?

[scottb721]

Is there a way using docker or docker compose to update the currently installed version so it keeps the history?

Mine maintained my history.
I deleted the container, updated the environment variables and reran the compose pulling the new image.

Formatting of the environment variables doesn't really matter, just stay consistent to your preference.

Thanks.

[edd080]

Hello alexjustesen, I have updated the environment variables, as per your instructions above; all is working except for when I run a speedtest, it completes fine but no email is sent. The strange thing is that when I test the email channel I receive the test, but I do not receive the actual speedtest result, this was working fine before updating to the newest version, is there anything I might need to check please?
Thank you.

[alexjustesen]

Fixed in #1492 , thanks for opening a separate issue

[scottb721]

I'm only a newb but for what it's worth I was able to get my preferred server ID from previous tests in the Results tab.

[alexjustesen]

Correct, you can also run the two following command to get the CLI to return a list of servers:

# navigate to the app directory
cd /app/www

# list Ookla servers
php artisan app:ookla-list-servers

[svenvg93]

FWIW, for the list it might be easier to use https://www.speedtest.net/api/js/servers as it returns the 10 closest servers.

[scottb721]

Awesome, thanks for that.

[alexjustesen]

🤏 little more advanced but you can also bump the limit (20 is the max) and add a search term:

https://www.speedtest.net/api/js/servers?limit=20&search=frontier

[skyeci-draytek]

Thanks for the info and your work. I managed to update my portainer stack and retain all my past data in stt. My grafana dashboard also seems to work ok after the changes.

[cicob]

Thanks for all the effort, I can see you make steady progress!

I had missed a few vital ENV-settings for v0.20.0, but it's now corrected. Perhaps make sure that the example-code is complete for each new feature added? The 'PRUNE_RESULTS_OLDER_THAN' was missing here at the time of writing this. Yes, this is not a show-stopper, but it helps to have a complete set as a reference, especially now when the config-GUI is castrated... ;-)

Since you argued for cutting back on the GUI-settings, perhaps adding a view of what actually has been configured could remedy the loss? This way, we would know that the various ENV-settings are properly digested by the server.

Sample docker-compose file:

#######################################################
# Ansible managed
#######################################################

services:
  #====================================================
  # Speedtest Tracker
  #====================================================
  speedtest-tracker:
    container_name: speedtest-tracker
    image: lscr.io/linuxserver/speedtest-tracker:${SPEED_VERSION:-latest}
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - DB_CONNECTION=sqlite
      - APP_KEY=${APP_KEY:-'base64:xxxxxxxxxxxxxxxxxx'}
      - SPEEDTEST_SCHEDULE=${SPEED_SERVERS:-'30 * * * *'}
      - SPEEDTEST_SERVERS=${SPEED_SERVERS:-''}
      - PRUNE_RESULTS_OLDER_THAN=90
      - APP_DEBUG=${APP_DEBUG:-true}
      - APP_TIMEZONE=${APP_TIMEZONE:-'Europe/Zurich'}
      - DISPLAY_TIMEZONE=${APP_TIMEZONE:-'Europe/Zurich'}
    ports:
      - '${SPEED_HTTP_PORT:-9080}:80'
      - '${SPEED_HTTPS_PORT:-9443}:443'
    volumes:
      - ./config:/config

[alexjustesen]

PRUNE_RESULTS_OLDER_THAN is optional and if you're like me I keep all my history. For a full list of env vars you can check out https://docs.speedtest-tracker.dev/getting-started/environment-variables and I'll add configuration confirmations either to the UI or the about command for the API in the next release.

Edit: fixed the url

[devanteweary]

Love the app but this seems like a step backward.
Why move settings out of the UI?

[alexjustesen]

#1470 (reply in thread)

[TheGroundZero]

I understand that having the configuration done in the UI adds complexity, but I don't fully agree with the move towards env vars.
I'd rather have a config file in /conf where I can list config options instead of having to create a seperate env-file are add numerous -e to my podman run command.

The advantage of a config file is that you're not limited to simple KEY=VALUE lines but you could e.g. format it in yaml to allow for nested configurations and config sections.

Would love for a next version to copy those env-vars into a config file (if the file doesn't already exist) and use that onwards.

[dawidp]

This project was nice "setup and forget" with easy setting via GUI, but now every time I want to change schedule or servers I have to reconfigure container... If all my container were to use only env vars for config I would spend whole week to change settings in them. For me this is huge step back in usability.

Another great project goes down the drain, from "Must have in your homelab" to "Must avoid at all cost"... sigh

[TheGroundZero]

To be fair: from a repeatability viewpoint, storing settings in a file you can manage externally is better than having them stored in a DB that's part of the application.

That being said, I rather have a config.yaml that I can edit and backup than having to define dozens of env vars, even if I could use an env var file.

[devanteweary]

To be fair: from a repeatability viewpoint, storing settings in a file you can manage externally is better than having them stored in a DB that's part of the application.

That being said, I rather have a config.yaml that I can edit and backup than having to define dozens of env vars, even if I could use an env var file.

I concur with the config.yaml!