@cluelessfr

Devlog 39:

I was finally able to get the Linux guards in place, and also packaged the new builds and released them to GitHub has a new version. The guards were mostly simple, as they were just a few checks that asked what operating system the user was on. And depending on that it decided whether or not to install the Spicetify extensions.

Devlog 38:

I worked on functions that helped install the Spicetify extension into the Spicetify configuration. I had to ensure Spicetify was installer, had to find its path, had to find its extensions path, then finally copy over the extension.
I also added system tray behavior and multiple instance detection for the app, so that now when you close the app it doesn’t close but instead goes to the system tray. This allows the Spotify integration to work even if the app itself isn’t visible. The multiple instance detection ensures the app runs properly, and ensures that the app doesn’t try to use the same http port twice, resulting in errors.
This did take a while but now all I have to do is create guards for Linux, so that the Spotify integration only works on Windows and doesn’t create unexpected errors on Linux.

Devlog 37:

I am very close to shipping now. I added the Spotify status/progress update messages, so now you can see when the tracks have finished downloading. I also fixed three (kinda major) bugs. First of all there was an error when searching for the songs on YouTube/YouTube Music. Basically what happened was that the title didn’t follow the same ASCII conventions that was used by YouTube. Because of this the app would reject good title matches even though they were the same. This produced quite a few errors, especially when trying to download songs with apostrophes. The second error I fixed was the some songs would automatically have the clean version downloaded. To fix this I switched to the ytmusicapi python package. This package also returned whether the song was explicit or not. Because of this I was able to check whether or not the song was intended to be that way, and if not I could prevent that match from being downloaded. I did have to edit a few functions to accept the new format, but in the end everything worked. Third I fixed a simple error that messed up the searching. This time it wasn’t really a bug, but instead an edge case that I missed. I was catching keywords like “feat.” and “featuring”, but I didn’t catch words like “From (and tv show, etc.)”. Because of this some matches were getting left out. I fixed this by adding another regex pattern that removes this as well.

Devlog 36:

I am almost done with the first phase of the integration. When the download button is clicked inside of Spotify, Spicetify intercepts it and now posts a request to the open web server. Then the python script gets notified of that request, decodes it, then automatically starts downloading the song/playlist/album. The only thing is that the myMusic app has to be open while doing this, but I will remove that requirement in the future (not now). The next step would be to add status reports to Spotify so that the user knows what the status of their download is.

Devlog 35:

The app now creates its own server on a very distant and far port so that your other local host stuff doesn’t get affected. I did this with uvicorn and threading, so that creating the port doesn’t make the app freeze. With this functionality the app can get the requests made inside Spotify and automatically download them. The next step is to get the app to report the statuses of the download jobs (queued, downloading, completed, failed, etc.). Then I would actually have to connect both parts, let Spotify send messages and the app receive the message.

Devlog 34:

I have been working on creating a queue for the requests. This ensures that the user can download multiple songs at once without having to wait for the previous ones to be finished. So far I have been able to create a request id for each request. The app can update the attributes of each request, such as its status, and error message. On top of this once a request is completed the app also automatically removes that request.

Devlog 33:

The app is now able to understand and automatically download any received links. Now the problem is that Spotify isn’t able to send any normal requests to via the computer. Because of this I need to find a way for Spotify to send and get data. I know that Spotify (using Spicetify) can send and get http requests. Because of that I am planning to use FastAPI and a local http server to be able to send and get data so the app can automatically download tracks. I will ensure to keep the server in a high index to ensure it doesn’t get in the way of any other local servers.

Devlog 32:

(sorry for the late post)
I have been working on a really cool feature for the app. Basically what I am trying to do is integrate the myMusic pipeline into the windows Spotify app itself. When you right click a playlist or album, there will be a menu that pops up. Usually for normal Spotify users (not on premium) there will be a greyed out download button. What I am trying to do is two things: add a download button for tracks (because there isn’t one right now), and make the playlist/album button actually work.

Right now what I have accomplished is adding a new button for the track and making the playlist/album button clickable. I was able to do this by using Spicetify and its framework. Because I already have it installed on my computer I am using it to test everything out but later I will bundle it with my app. What I did was build a custom Spicetify extension (I had to learn JavaScript) that creates a new button.

I was able to make the original playlist/album button work because it was only “aria-disabled”, not actually disabled. This means that it was only disabled at the UI level, but Spotify still recorded clicks. By applying some UI changes I was able to make the button look enabled and still record clicks.

My next step is to actually hook this up to the Python script. I think this is a really cool feature.

Devlog 31:

This devlog was mainly focused on the efficiency and speed of updating the app. Before the data would come in really small packets, meaning the cpu would have to write to the drive about 130,000 times in total (I know 😭). I adjusted this so it now comes in larger packets so the cpu doesn’t have to do more work. I also adjusted the compression and a few other Inno Setup settings (number of threads, etc.) to make the app more efficient in general.

Another issue that I found is that once the app updated (specifically in Windows, idk about other platforms) the settings app would still show the older version for some time. This was an issue with the timing, so I had to adjust some of the delays to get it to work properly. Overall I think this is a pretty good update.

Devlog 30:

I FINALLY implemented playlist and album support. At first I thought it would be simple, just looping though each song in the playlist/album. Oh was I wrong.

First I had to add two more methods that looped though each song, one for playlists and one for albums. There had to be two different ones because each returned metadata differently. Then I had to kind of change the format of the whole thing, because I had to store all of the songs in a list, but currently I was only returning dictionaries from all of my methods.

After getting all of that sorted out I had to actually fix the GUI/downloading part. I had to update the downloading method to handle playlist/album links, then I had to properly handle all of the status message for each song (“Ready”, “Downloading”, “Failed”).

Finally I had to work on fixing the bugs I had introduced and handling the edge cases. After all of that I FINALLY had playlist and album support.

One thing that was sorta tough was handling the status for each track individually. Before I was just looping through the entire list and setting all of the statuses to the same thing, but I was able to create a new method and change each song status as it was being downloaded, not for every song as a whole.

Devlog 29:

This is kind of a messy devlog, so I’ll lay it out as best as I can.
First, I update the UI in preparation for playlist/album support. Before it was three static text fields that could only display one song at a time. Now I replaced it with a scrollable frame, with the ability to add more sections inside the frame for more songs. This frame also has the ability to display metadata. I also introduced a status message that shows different messages and colors depending on the status.
While I was doing that (and I am not done with it), I decided to stop in the middle and fix another bug. This bug (that was reported by other people as well as my testing) prevented good matches from ranked properly. This was a problem with how I compared the titles in my ranker. To fix this I added two new functions, one that normalizes the candidate title, and another that normalizes the actual Spotify song name (mainly to exclude features and get just the song name). To do this I messed around a lot with regex patterns, so I learned a lot.
Now I have to go back and continue working on the new UI for playlists and albums.

Devlog 28:

Based on feedback from my first ship, I have decided to introduce Linux support. I thought it would be easy, but it turned out to be a little harder than I thought. The first thing I had to do was rewrite some of the Path code that saves the users download directory. This is because Linux and Windows have different file systems, and I had to account for both. Then came the hard part, Packaging.
For ARM, I decided to do this on my Raspberry Pi, where I downloaded the project files from git, downloaded the OS specific FFMPEG and Deno, then repackaged the app as a .tar.gz. I decided to do it this way because this is sort of simply an experimental release.
For x64 I decided to use GitHub Actions, which allowed me to download the dependencies and compile without having to spin up a new Virtual Machine. I also decided to keep this as a .tar.gz.
Later, once I get more feedback about the Linux versions, I am planning to release a more universal app package (.flatpak).
I also had to change the update checkers, because each OS version has to check its own corresponding file.

In the end this was a very unique experience and I learned a lot of things about packaging apps on Linux.

Devlog 27:

This is a pretty major update. The myMusic can now automatically download and install updates, without the user having to go and download the github repository. Before, the user would manually have to go and download the installer from github, and set it up like a completely new install. Now, the app itself has a “Check for Updates” button. This button checks the github for the latest version, and if there is a newer version available it gives the user an option to download and install that. If they change their mind during the download, there is a cancel option as well.

This works by first getting the github version (latest), then seeing if the current app version matches that. If it does, the app is up to date. If not, then the app can fetch the executable using the github API and automatically download the latest installer. On top of this some inno setup tools allow the app to close the app, install the new version, and reopen the app by itself. The only caveat is that this only works starting from v1.2.0. This means that if you have an older version you will have to manually download v1.2.0 in order to start getting automatic app updates.

Devlog 26:

Added a function to help with auto-downloading new updates. I haven’t hooked it up to the UI yet, but that is my next step. The function takes in the name of the installer and the link to download it. It first downloads the installer to a temp file, then once everything is good it saves it to a real executable.

Devlog 25:

This update was about implementing the update checker from the last devlog. Now there is an in-app button that allows you to check for new updates. The implementation was similar to all the other buttons and didn’t take too long because I already had the function ready. The next step is to allow the app to actually download and install the update, instead of just pointing out it is available.

Devlog 24:

I have started adding implementations that checks for the latest version of the app from github. It uses the github API endpoint for my specific project, then reads the json to get any version information. Using that we can compare the current version to the latest version on the github to see if there are any updates available. Currently I have only created the function and am yet to implement this feature into the actual app/GUI.

Devlog 23:

Today I added the feature that embeds cover art into the mp3 files. To do this I had to first use the requests library in Python to get the image itself. Instead of downloading the image I kept it in memory using the ‘io’ library. This made the metadata tagging safer and faster. Finally the app uses mutagen to embed the cover art into the mp3 file. I used a try and except loop, which ensures that even if the cover art adding fails the mp3 file still gets returned, just without the art.

Devlog 22

This update was about further increasing the matching strength. Before the program would automatically download the highest ranked candidate, even if it was very low. Now the app downloads the highest ranked candidate only if its ranked above a certain thresh hold. If there are no qualifying matches then the app simply returns a no matches found error.

This wasn’t that complicated, but I had to modify a few functions so that the score was returned properly and in a usable format.