Any external dependency is an ocean current you have to keep up with or get left behind.

The external dependencies of this project are:

* Spotify API

* Spotify player (i.e. Raspotify)

* Airtable

* Micropython and Libraraies

Airtable is a legacy dependency to provide a convenient, though, overly heavy interface to manage you tags and spotify links. The experience of maintaining columns of tags and spotify URIs isn't great, but it was inherited from the original project I re-implemented. I probably should get rid of it, but support is there already...

Airtable decided to change the way they deal with API authentication. I noticed when I was writing the integration that the API authorization was all or nothing, which didn't seem right. They implemented Personal Access Tokens (PAT) https://airtable.com/developers/web/guides/personal-access-tokens which support scopes, and disabled all legacy api keys. The switch to PAT requires sending a Bearer Authorization HTTP Header, so implemented that and the settings form to support setting it.

Spotify decided to add a attribute "supports_volume" to their device JSON which the library I am using chokes on. This only is exposed during initial setup when we query all devices for you to choose from. I added "supports_volume" to the device model. I should change it to support whatever new attributes Spotify may come up or ignore all but the critical attributes (e.g. name and id)

Changes to the Spotify API disabled the username and password login pathway used by librespot, the open source library many spotify players use including Raspotify. Unfortunately with this change, the error output on older librespot versions indicates "incorrect password". Newer versions indicate user/password is depreciated in a log message. Updating to latest versions of librespot and going through the Spotify token generation process will get your player back up and running: https://github.com/librespot-org/librespot/wiki/Options#access-token

Micropython and libraries don't necessarily need to be updated, but always a good idea to stay current on connected devices. I built a micropython build off master with ESP-IDF 5.3.2 including all of the required libraries of this project frozen into the firmware via a manifest.py

```

git checkout tags/v5.3.2

./install.sh esp32

. ./export.sh

cd ~/git/micropython/ports/esp32

make submodules

make BOARD=ESP32_GENERIC BOARD_VARIANT=OTA FROZEN_MANIFEST=${HOME}/git/PlasticPlayerRedux/manifest.py

```

I often ran into TLS memory issues with Micropython on ESP32. This got worse with some of the new IDF versions, but the latest Micropython and IDF have not triggered the errors for me yet. Previously I had done some digging into the issue, especially for OTA updates with larger payloads. HTTP didn't have any issues in my experience (can negotiate down the record size and is accessible via TCP directly?) and allows smaller buffers. TLS has it's own maximum record size of *16 KiB* and most servers will rationally use that full record size for any bulk transfer. This includes packaging up a bunch of smaller HTTP packets into one giant one. TLS supports packet re-assembly as well. Significant RAM requirements for TLS comparative to straight HTTP. That is why the firmware OTA updates I run are over HTTP (despite the risks).

There is a setting on the client side in the ESP-IDF which uses mbedTLS MBEDTLS_SSL_MAX_CONTENT_LEN. There is "Maximum Fragment Length Negotiation" in https://datatracker.ietf.org/doc/html/rfc6066#page-8, but servers do not have to support this. This thread mentions changing the Fragment Length to tradeoff between latency and throughput https://issues.apache.org/jira/browse/TS-2503 including starting off with as small as a single TCP segment.

## Other News

I have been playing with some OLED screen scrolling and brighness to avoid burn in.

Added passing of the display object into the Spotify authentication flow to allow display of the Spotify OAuth links when pairing the device. I am not happy that I have to make the Spotify library aware of the display specifics (i.e. write to line 2), but that was easiest. I had done this before, but I don't think I committed the change. This exposed a gap in my update process in that I don't have a mechanism to update libraries (just the boot.py and main.py).

My git branches are a mess and will clean them up. I have been committing a lot directly to the OTA branch, which is a bad idea as that is the branch devices will pull updates, from, but there are only two devices that I know of and the update is not automatic.