Spotify issues

spotify issues featured image

I’ve been a Spotify subscriber on and off for at least 12 years now. Things started off pretty great but there have been a number of bumps in the road where I have temporarily cancelled my subscription. These Spotify issues have again put my subscription back into a ‘cancelled’ state. The last time I cancelled (a month ago), my reasoning was two-fold. Price increases, and pushing in-app ads on me as a premium subscriber.

Spotify Issue 1

The ad I’ve been getting is a pop-up in the app trying to get me to listen to certain podcasts, or subscribe to Premium Duo. As a paying customer this is ludicrous. I don’t pay to be served up marketing and up-selling ads.

I’m not the only one getting this. It seems like a wide-spread issue. See:

  • https://community.spotify.com/t5/Accounts/Popup-podcast-notifications-in-app/td-p/4926947
  • https://community.spotify.com/t5/Closed-Ideas/Mobile-Let-Premium-users-disable-fullscreen-popup-quot/idi-p/5277678

These forums have numerous threads where people are having Spotify issues like this. The responses from Spotify are mostly always weak, miss the point, or simply suggest raising an ‘idea’.

Spotify Issue 2

The Spotify desktop client is a bit rubbish. It uses Electron / chromium and suffers in terms of performance and the amount of memory it consumes as a result. For those unaware, Electron is essentially a web browser (mostly the engine) used to write cross-platform desktop applications with JavaScript, HTML, CSS, etc… They used to have a much better native client. I’m not sure what happened with the move to electron, but it has resulted in a significantly worse user experience in my opinion.

Here’s a recommendation for anyone who hates the current Spotify Desktop client and it’s massive memory usage (and sluggish performance). Get Psst. You’ll need to have a Spotify Premium account, but this desktop app is far superior if you just want a clean, basic music listening experience.

Psst is written in Rust. It’s lean and performant. You can get a release from the Psst GitHub Releases page, or you can download the source and compile it yourself with Rust. Here’s how I did that (make sure you have the rust tool chain / cargo installed):

git clone https://github.com/jpochyla/psst.git
cd psst
git submodule update --recursive --init
cargo build --release

You can then launch it by running:

./target/release/psst-gui

Sign in using your Spotify Premium account credentials and you’ll have a clean, native running app where you can listen to your music and playlists without the bad parts of the official Spotify desktop client.

Spotify Issue 3

As with many Software-as-a-Service (SaaS) apps, you don’t own the music you listen to on Spotify. You simply subscribe and get access to the music. As soon as you cancel your subscription, that’s it, no more music, unless you hobble along with a free plan that throws even more advertising your way.

I have slowly been moving my essential services I have previously used in the ‘cloud’ back to my own self-hosted infrastructure. I’m now considering using this approach for my music too. It seems like a better idea to outright purchase any new music from a service like Bandcamp, and then self-host a streaming platform myself. Something like navidrome.

To quote the GitHub page:

Navidrome is an open source web-based music collection server and streamer. It gives you freedom to listen to your music collection from any browser or mobile device. It’s like your personal Spotify!

https://github.com/navidrome/navidrome

Closing thoughts

The Spotify experience has been getting progressively worse, whilst it’s subscription fees have been getting progressively higher. Further Spotify issues have lead to me cancelling my subscription once again.

I will be trying out Navidrome to self-host my own personal music, augmented with music purchased from bandcamp and other indie platforms (or direct from artists).

FreeNAS to TrueNAS upgrade

A while ago I posted my home storage server build which at the time was setup to run FreeNAS. Things have moved on in that space and FreeNAS has been replaced with TrueNAS Core. I thought I would post my FreeNAS to TrueNAS upgrade experience.

First off the recommendation is to ensure you’re on the latest FreeNAS version (the last official release, which was FreeNAS 11.3-U5). I had already been running this version for a while so I was set there.

FreeNAS to TrueNAS Upgrade Process

I started off by creating a full, manual backup of all my storage pools to an external disk. I verified a bunch of files in various locations on the backup disk to be extra sure they looked good.

Next was to switch release trains to TrueNAS-12.0-STABLE. At the time of posting, the current release is TrueNAS-12.0-U8.

freenas to truenas upgrade release train

Clicking Download Updates started the download and upgrade process. Before starting you’re offered the chance to download your configuration backup. Definitely do this. It contains all your configuration as well as an optional password secret seed. This is important if you need to re-install the OS or change to a new boot device.

Once the upgrade completes the UI should reconnect after reboot, showing off the shiny new dashboard.

freenas to truenas upgrade - the new dashboard

Updating ZFS Feature Flags

After verifying I could still access my SMB shares and that my NFS provisioner for my Kubernetes cluster was still working as expected I decided to lock in TrueNAS 12.0 by updating my ZFS pool feature flags across all zpools.

In a shell, I ran zpool status to take a look. Each pool is listed and should shows that some new features are not yet enabled. By leaving them as is, you retain the ability to roll back to your old FreeNAS version. Updating them locks you into the ZFS version that they were introduced with.

Updating to use the latest feature flags is something you should personally decide on. Do you need the newer feature flags?

According to this post, TrueNAS 12.0 supports the Feature Flags listed below. (Bold are read-only backwards compatible, and italicized flags are very easy to return to the enabled state):

  • Allocation Classes
  • Bookmarks v2
  • Bookmark written
  • Sequential Rebuilds [device_rebuild]
  • Encryption
  • Large dnodes
  • Livelist
  • Log Spacemap
  • Project Quota
  • Redacted datasets
  • Redaction bookmarks
  • Resilver defer
  • Userobj accounting
  • zstd compression

Updating ZFS feature flags is then as simple as running the zpool upgrade command.

E.g. sudo zpool upgrade my-pool

zfs feature flags updated

The last step is to upgrade any jails you might be running. Use the iocage upgrade command to get going with.

iocage upgrade -r 12.0-RELEASE your_jail_name

error TS2582: Missing types in a TypeScript project

This is a quick note as a pointer to anyone running into type errors like error TS2582. You might be working with Jest, TypeScript, and a monorepo setup, using something like lerna. I was porting over some projects into a monorepo and had a tsconfig.json issue which was cause for this error. You might be seeing errors similar to: error TS2582: Cannot find name 'test'. Do you need to install type definitions for a test runner? Try npm i --save-dev @types/jest or npm i --save-dev @types/mocha.

As it turns out, my issue was that I had a tsconfig.json file with typeRoots configured to point to the package’s own node_modules directory. Like this:

{
  "compilerOptions": {
    "...": "...",
    "typeRoots": ["./node_modules/@types"]
}

As this was a monorepo, common types such as those from jest were installed in the repository root. Meaning a package tsconfig.json file under package/example-package, referencing the location of “./node_modules/@types” was incorrect.

The fix was to simply remove the typeRoots setting from the package, or change it to point a further level down to the root: “../../node_modules/@types“.

To quote the docs on typeRoots, if you explicitly set typeRoots, then you’re narrowing down the locations that these will be pulled in from (compared to the default of not setting them).

By default all visible@types” packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible. For example, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.

TypeScript TSConfig Reference

Making a Retro Screensaver in QBasic

qbasic IDE

I recently had a wave of nostalgia which led to my purchase of an old Pentium Compaq Armada 1592DT Notebook, (and also building an AMD K6-2 gaming PC, complete with a 3dfx Voodoo 2!) Continuing this journey, I decided to revisit a small part of my childhood – programming with QBasic on DOS.

My first steps in programming as a child were with QBasic on an older 486 system that only had DOS 6.22 and Windows 3.1. A group of friends and I discovered QBasic (probably via a bunch of old paper manuals that came with our parent’s PCs) and began writing primitive programs that would prompt for input, save the answer in variables and lead the user through a series of questions, printing out answers in return.

For fun, I decided to look into the effort required to write a simple screen saver (remember those) using QBasic. It turns out there is not much effort required at all.

QBasic on a Modern System

The easiest approach is to use DOSBox. I installed it on my Windows 10 machine. From there, I configured it using the DOSBox configuration file to run in a larger sized window. It is as simple as adding this to the .conf file:

windowresolution=1920x1080
output=ddraw

Next, I setup automatic mounting of a “DOS Apps” folder I setup on my D: drive. Locate the [autoexec] section in the DOSBox conf file and add something like this:

mount C D:\Tools\DOS_APPS
C:
cd QB45
qb.exe

This will mount everything under D:\Tools\DOS_APPS to the C:\ drive of your DOSBox machine. It then changes directory to the contained QB45 directory to run the QBasic executable.

Ripples, The Retro QBasic Screensaver

a simple screensaver written in QBasic

I wrote a simple SCREEN 13 mode (320×200 VGA) screensaver that I named Ripples. It simply draws outer and inner circles which expand and fade out at random locations. I’ve used a basic circle drawing algorithm, and POKE to set values at specific locations in memory. (In SCREEN 13 mode, each pixel is represented by 1 byte).

The reason I didn’t use the much simpler CIRCLE routine, is because I wanted to have multiple circles drawn out (inner loops) and also prevent screen clears after every concentric circle. (Also, the added complexity of the circle creation routine itself was fun to add).

You can take a look at the quickly hacked together source code here. I’m sure there are far more efficient ways of doing some of these things, but I didn’t want to spend too long digging deep into screen drawing. (Maybe using DATA could improve things, or perhaps even writing inline machine code to perform the loops and pixel setting that POKE does).

Running it on an actual Retro System

I copied QBasic and the source code across to my actual retro system (the old Pentium laptop).

Next I configured QBasic to be able to use a linker to compile an executable. It’s a case of simply ensuring your Paths are set correctly under Options.

qbasic paths options

I opened and compiled the source, disabling debug symbols to vastly improve speed too. Windows 98 has a DOS mode built-in that can execute DOS applications directly from Windows. QBasic and the program ran perfectly like this. After booting into MS-DOS mode I confirmed that the compiled source ran perfectly there too.

This was a mostly pointless exercise, other than to experience a bit of nostalgia. It certainly was a blast from the past. The experience also helps me to appreciate the modern tooling and IDEs we use today. Having said that though, I did find myself quickly iterating through edits in QBasic using the edit and search options. It wasn’t too bad after all.

Systems Programming with Nim

black sand

Nim is a statically typed compiled systems programming language. I’ve seen a few posts about Nim popping up on HackerNews recently and was curious enough to give it a go.

My go-to tool / application to implement when trying out a new language these days is a simple CLI tool.

Recently I had a go at trying Rust – creating fstojson-rust. Sticking to systems programming languages, Nim came up next.

Here are the things I initially liked about Nim:

  • Statically typed, compiled language.
  • The Nim compiler and generated executables work on all the major operating systems. i.e. Linux, macOS, Windows, BSD.
  • Lots of documentation and tutorials.
  • An online Playground.
Some Nim code in my IDE
Getting started with Nim

Getting Started With Nim

Installation is really simple regardless of your OS. On macOS I chose to run the choosenim installation script. (Remember, always check and inspect scripts that you cURL / run directly from online sources):

curl https://nim-lang.org/choosenim/init.sh -sSf | sh

You can also download pre-built binaries for your OS at the main Nim Download page, or use a myriad of other methods to get it running such as Homebrew, Docker images, etc…

Nimble is a package manager that is bundled with Nim (since version 0.15.0). It is very similar in what it does as what npm does for node for example.

If you wanted to upgrade nimble itself, you can simply do:

nimble install nimble

Just like an npm update!

To create a new project, you can use the init command. An interactive CLI wizard guides you through creating a Library, Binary, or Hybrid project type.

nimble init [pkgname]
nimble init guide for new projects

A Nim project can use a .nimble file, which is equivalent to package.json in the Node.js world. Nimble is used to work with the project’s .nimble file.

To check the validity of your project and dependencies, you can run the check command:

nimble check

Then to install a new package you use the install command with nimble (the default is to install latest, but you can also install a specific version of a package, e.g. one from a git repository):

$ nimble install package@#head

Getting Acquainted with Nim

I started off with a really simple program that simply reads from stdin and then echos back a message.

echo "What's your name? "
var name: string = readLine(stdin)
echo "Hi, ", name, "!"

Building and running locally is simple. You can run nimble build or nimble install. The build command will create a debug version of your program which includes stack traces, while install will create a release version.

You can also pass Nim flags to these commands, though for anything permanent you can add a configuration file and specify them there.

You use nimble run to build and run your program in one go.

There are many more command options available for nimble. Just run the command without anything else to access the list.

fstojson-nim

Next, I jumped into writing my go-to application for traversing the file system and collecting directory and files in a designated path to output to a JSON hierarchy.

You can take a look at my code in GitHub.

My overall experience was that I found Nim to be a lot more foregiving in terms of safety checks and recursive functions than what Rust was.

I was able to use a single function (in Nim these are called procedures and are defined with the proc keyword), which could recursively call itself for traversing a nested directory hierarchy.

I created a simple object (PathObjectNode) which would store the information about each file or directory, with a children property that is used to hold a list (seq) of more PathObjectNode objects if they object is a directory (files of course do not have children).

A single hierarchy is created at the start of traversal and all directory or file object nodes are added to this.

var hierarchy = newSeq[PathObjectNode]()

At the end of traversal I simply echo out the JSON representation of the root hierarchy node (along with all children). Optionally, this can be prettified JSON.

Speaking of options, I used a handy package called docopt to provide the CLI interface. It was a case of simply adding this to my project’s .nimble file dependencies.

The interface can then be specified by providing a docopt string. For example:

let doc = """
traversefs

Usage:
  traversefs [-p | --pretty] [-r | --recurse] PATH

Arguments:
  PATH          The path to begin traversing

Options:
  -h --help     Show this screen.
  --version     Show version.
  -p --pretty   Pretty print JSON
  -r --recurse  Recusively traverse paths.
"""

With that done, and a simple nimble build later, I could run the binary directly to use it.

Closing Thoughts

Nim feels like an easily accessible systems programming language to me. Although I haven’t really used it enough to have an informed opinion, my thoughts are that it strikes a nice balance between usablity, ease of entry, performance, and type safety.

I’ll definitely consider exploring it further for other projects when I get the chance.