@cluelessfr

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.

Devlog 21: Now added real YouTube (YT) to the match finding instead of just YouTube Music (YTM). Before the songs were found only on YTM, but I realist that normal YT has a larger list of songs, so I decided to add that to the algorithm as well. Now, the program takes 3 songs from YTM and 3 songs from YT, and uses the ranking function I created before to sort them from best to worst. Then the program starts by trying to download the best match. If it can’t, it goes through the list until if finds one it can download. If none of them download, then it sends an error message. One thing with this step was that I tried not to repeat big chunks of code, as a lot of this was similar to the original YTM downloading method.

Devlog 20: Added the Spotify OEmbed fallback. Now even if the SpotifyScraper python package fails we have a fallback to get as much metadata as we can. This wasn’t that hard, as I already had the file from a previous time. The hard part was accounting for all the different cases, such as the title being missing or an empty string. I had to account for all of those while integrating the new file.

Devlog 19: Implemented the ranking feature from the last devlog. Now, the best candidates are ranked in order from best to worst, and that is the order in which they are downloaded.

Devlog 18: I implemented a way to start scoring the candidates returned by YT-DLP. This ensures that even if the first candidate returned is not the best, the program can automatically filter out the bad ones using key words and ensure the best candidate is always selected. I have only coded this function for now, and I have to wire it in to the real app soon.

Devlog 17: Did some major code cleanups. No new features, but made the code more efficient. Also reorganized some files. The hard part was keeping the functionality the same while trying to make the code non-repetitive and more efficient. I also tried to fix any warnings that were present in the code that were caught by the IDE.

Devlog 16: Simple update, but I added a new error message to account for a yt-dlp botting error. Now, when YouTube sends an error saying that the request was blocked due to botting being suspected, it sends a properly formatted error message instead of the raw yt-dlp text. I retested everything to ensure the previous functionality of the app remained the same.

Devlog 15: Improved song selection algorithm, so it selects the next best track if the first selection is invalid. Before if the first track selected by YT-DLP didn’t work/was invalid, then the whole program would fail. Now it moves on to the next if the first one doesn’t work. I also update the progress messages, so it shows which match it is trying.