Caching + New Search Algorithm + Update Liked Songs

[FlaShHolloway]

Description:

• Caching Video IDs: I’ve added caching functionality for video IDs in a JSON file. It's opt-in, so you’ll need to use the --use-cached flag to create or use the cache.
• Fix-Match Command: Introduced the fix-match command, which allows you to replace a bad match with a preferred video ID. This works only if you use the --use-cached flag to ensure consistency in fetching that ID.
• Cache Management: You can clear the cache by calling the cache-clear command, which removes the lookup file.
• Extended Search Algorithm: Implemented a new search algorithm with the --extended-search flag. You can adjust the confidence level (optional) (e.g. --confidence 0.6) for better match quality (range 0-1).
• Album Search: If you want to search for Spotify matches within albums, use the --search-albums flag. It’s slower as it searches through all albums but has a higher probability of yielding good matches.
• Fallback Option: The --enable-fallback optional flag can be used to fall back to the default search algorithm if no matches are found within the specified confidence level. It ensures that at least something is returned from YouTube Music, even if it’s not a perfect match.
• Searching: The search option can be used to search a Spotify's Youtube Music equivalent, all the same arguments as above can be used (i.e. --extended-search, --search-albums, etc.) to individually check matches or simply add a single song to lookup file using --use-cached flag.

Testing:

• Added test cases for the new functionality. Please review and let me know if there’s anything I can improve or change!

[FlaShHolloway]

In update argument, include liked argument instead of playlist_link will now allow you to update your YTM's liked playlist with Spotify's Liked Songs, include name of the YTM playlist as usual (If not changed, it would be Liked songs (Spotify)). This also means you can create a YTM playlist and use that playlist to sync your liked songs (or any other playlist). Note: there is a very likely chance of timeout if playlist is big, so --use-cached can come in handy. Also encountered an issue where, if fix-match id replacement used incorrectly and incorrect id is replaced, create or update will result in Error 400 Bad Request since ID(s) doesn`t exist(s).

[sigma67]

Hi man, I appreciate the effort, but this MR is way too big. The key in open source is to do incremental changes, not huge refactors doing everything at once

In addition it would be great if you could point out what problems with the existing lib you are trying to fix (esp. regarding song matching)

[FlaShHolloway]

Understood! I appreciate your response. Here is what I faced and trying to fix:

• Firstly use of caching. Since you had a made an attempt, I gave it a shot. I noticed the search results were not consistent at a time, a good matching track might not appear in the result every time, So I made it so that using caching, the good result can be retrieved consistently instead of it changing every time. It's opt-in so no need to force it use it if it works for you, plus for fixing incorrect matches directly in caching, will allow to maintain a lookup of correct tracks so it will help during updating of playlist, getting the track right every single time, while also enabling resuming if during search any error occurs.
• Secondly a new search algorithm, based off yours old. The reason I made this is because, duration match and title match works almost 70% of time if title is distinct and so is the duration. But problem arises when title is not distinct (i.e. Flowers by Miley Cyrus or GOATED By Armani White) I keep getting either totally wrong track or another version of track (i.e. I keep getting "Slowed" version of GOATED instead of original one). I also noticed that albums were not included in search for obvious reasons, I thought if I could include an opt-in option to include albums in search result at the cost of slow search, it could result in good matches, and that's what I got! Not only were albums search accurate but gave me the ATV versions that had really high quality audio (at least my ears agree). So the new algorithm searches for track with new criteria and handles many edge cases that I personally tested after a long observations of YT Music results and got a pretty good algorithm that is opt-in that can come in handy when needed. I added search argument to test matching of tracks so one can see which algorithm returns a track correctly.
• Lastly, I added the option to update liked songs, I saw an issue mentioning that wanted to update their liked songs so this was straight forward. But I also updated the way the update occurs. Your method was straight forward enough, and I had no problem, until I started updating the liked songs. I kept getting timed out at remove_songs. I guess removing 700+ songs at once is something YT doesn't appreciate. So I just made it so that only songs need to be removed (i.e. song in YT Music but not in Spotify) and songs need to be added are added/removed so the updating is fast and time out never happened. But this may also make the playlist order of tracks out of order and some folks wouldn't like it otherwise so I added an option (--reset) to completely wipe the playlist and re-add the tracks (ofc the traditional way). I really didn't plan to add this one but thought it would be helpful.

You're correct, this all should've been incremental changes and not huge refactors, I'll keep that in mind next time. If you want, I can remove/revert any changes that doesn't seem important. I've added tests for new features. Lessons learned!