2026-01-11 || Tags: programming
As part of a new years resolution sort of thing, I want to listen to more music and more "actively" listen to music. To help encourage this, I've written some scripts to track what I listen to optionally with ratings and reviews.
In figuring out the best way to do this, I looked at some other solutions like Musicboard (RIP their Android app), record.club, ListenBrainz (the better last.fm), and others. I've found them all lacking for a number of reasons including:
Because of what a relatively simple problem this is, I figured creating my own would be great little project to try out. My requirements were:
The hint is in the name... it is as simple as it says on the tip. Plaintext is simply plain... text. Like a .txt file. No specific encoding, no binary, nothing like that.
It is (or at least should be) human-readable and editable with even the most basic of text editors. Although I'm not going to suggest anyone start filling their by writing their data in ed.
There are so so many. Here's a select few:
So, plaintext is great, but at the end of the day, dealing with a plain old text file is not going to give you any easy way to reason about the data using database-like filters and functions.
This is where recutils is amazing. If you haven't tried it, you should. recutils provides a number of utility applications to insert, update, and delete (recins, recdel), select/filter your data (recsel), allows you to describe your record schema (types and required fields), check the integrity of the database according to those type and field requirements (recfix --check), sort (recfix --sort), import/export from/to csv, joins, encrypt fields, and more.
By arranging your human-readable plaintext files in Fields and Values, you have all largely all the database functionality you need.
One thing I have yet to test are the limitations of using recutils. I doubt I am going to encounter them any time soon. I feel like I could hit thousands of records without any issues.
It meant that for my simple music logger I am able to write my logs as commits anywhere and everywhere. That includes on my phone while I'm on the underground and have no internet. I can save this useful information locally in a useful format and upload later. And even if I forget to "commit" any previous reviews and end up out of sync, I can take advantage of easy to use and good tools for merging (i.e. git).
It gave me the ability to view my data with extreme ease. I don't need to create a custom website to do so. I don't need to download extra database viewers to do so. I don't need to scan through a hell of brackets and braces.
It gave me the ability to fearlessly commit my database in a sane and safe way. Before I make any substantial edits, I commit my DB, make the changes, do a git diff, check what I changed makes sense, then commit again. Even if it was wrong, I have the diff info to undo later.
Overall, gave me the ability to start building and verifying each build step quickly and easily.
SQLite is the go-to option for storing this sort of data. It's a single file, it's easy to write SQL commands to insert and update, it's standard across everything, small footprint, it's probably the most tested piece of software in the world.
When considering this option, the problem that kept coming up for me was there likely was no simple way to interact with a plain SQLite file itself from my phone which would then allow me to do add these listens to my other ones sitting on my desktop PC.
To interact with SQLite file on Android would require some sort of DB explorer or similar. again, not really a problem, would be offline, could very likely find a nice little open source one too.
When trying to figure out how to synchronise this local SQLite file with my desktop one though, I could really only think of either writing some sort of online tool to upload the listens to when I have internet again, or using git commits to push these.
Writing an online service would be fine - maybe a day of work. But it's just another thing to make sure is working.
Using git with SQLite files I'm not actually sure would work overly well. There are ways around this, but I didn't like my chances of getting that to work on my phone.
Thus, I came to the conclusion that SQLite wouldn't work for my phone requirement. At least not to get something up and running in a couple of evenings.
I did a little bit. Using this sort of file format would have fulfilled all my requirements too. The only "problem" I have with going down this route is the minor inconvenience of their quite specific formats. These are all would have worked just as well, but are much less human writable than the recfile format.