From e0804534c6e7d0e2e596138ba5c0385f8d786751 Mon Sep 17 00:00:00 2001 From: Cliff Hill Date: Sat, 16 May 2026 07:33:49 -0400 Subject: [PATCH] Removed notes.txt file which is no longer necessary. Signed-off-by: Cliff Hill --- notes.txt | 22 ---------------------- 1 file changed, 22 deletions(-) delete mode 100644 notes.txt diff --git a/notes.txt b/notes.txt deleted file mode 100644 index d077d98..0000000 --- a/notes.txt +++ /dev/null @@ -1,22 +0,0 @@ -Role: A Staff level software engineer with 29 years of experience, 24 of those specifically with Python, 10 with JavaScript/TypeScript. -Instructions: Using the existing project and branch in Git, we are going to construct a complete dynamic, realtime playlist generator for a Plex media server, using FastAPI as the backend and Vue with Typescript for the frontend. The database should be set up with Postgresql, and using SQLAlchemy All of this is orchestrated together with a compose.yml, which already exists, and a compose.dev.yml file for setting up a functioning dev environment for the system. The music system has potentially millions of songs, so good use of a process pool to divide up the loading/processing of music would be good. There are a few different important sections of the music that should be dealt with: First, music needs to be categoriezed, effectively partitioning the music. This should be a user-customizable frontend screen that allows the user to select one or more genres from the music that are available, and put them into a particular category. When the system is generating the playlist, these categories can be run concurrently as they will not interfere with each other's runtime. Next, there will be two passes through the subsequent subcategories I will be defining. The first pass is just for songs marked as a favorite by the user (in the plex system), the second is for ALL music that are in that category. The first subcategory of music to select from are those songs that have never been played, pick the songs that were the least recently added to the library. Next are songs that have been played, pick the songs that were the least recently played. Third are to randomly pick from songs that have been played the least. Note, the third categoru CAN be songs that are not played at all. These should be randomly selected from the least played count. The last category should equal the total number of songs from the Least Recently Added, Least Recently Played, and Least Often Played groups I just explained. These are completely randomly selected from the category. All four (Least recent Ladded, Least Recently Played, Least Often Played, and Random) should be processed once for just favorites, and then a second time for all tracks for that category. The playlist we are generating will consist of all of the tracks that have been selected for all categories, both "favorite only" and not from the categories. - -There should be 1 and only 1 track for each category, as a favorite, for each of Least Recently Added, Least Recently Played, and Least Often Played. For the "all songs" selection for the category, there should be 2. There always is an equal number of Random as there are of the sum of the Least Recently Added, Least Recently Played, and Least Often Played for the category (and favorite/all choice). So for favorites, there should be 3 tracks. For non-favorites, there should be 6 randoms. - -Also - if there is not enough tracks to choose from for the Least Recently Added or Least Recently Played subcats, because, for instance, all tracks have been played, or no tracks have been played (as an example), then the tracks that were not selected should be randomly picked from the appropriate favorite/all selection accordingly - this should keep the playlist consistently the same size. - -The system will also be monitorring the plex server, and recieving realtime updates when a track is played. If the track that is played is on the playlist, a new track from the same category and subcategory (and favorite status) will then be selected, and exchanged with the played track. This should be real-time updated so that the playlist always keeps new music in it. - -Do note that at any time, a single song can only exist once in the playlist. Also, at any time, any track that was played within 24 hours is automatically NOT to be configured. - -Beyond this, there needs to be a UI that when opened shows the current playlist, and maybe even shows which track is currently playing. It should be able to show things like what category and subcategory the track is a part of. It should change out in real time whenever a track is changed from the playlist. - -The playlist will need to be generated completely from scratch the first time. However, the system should be able to monitor real time changes from the plex server to keep itself in sync after that. - -Steps: Loading the music tracks should have enough information to be benefitial for the tool, and collected in the postgres database. This should be a model that has identifying information like album name, album artist name, track name, genre, track number, disc number, play count, and timestamps for when the track was added, and when it was last played - I would also recommend keeping track of the ID information from plex. There also needs to be a second model/table for the categories, and it should be a single category can map to multiple genres, but one genre can only match a single category (one-to-many relationship). - -There should be a full suite of unit tests for the frontend and backend. There also needs to be integration tests for the backend, and end-to-end tests set up and usable for the frontend. Testing should not need to talk to a real database - a test database can be created as needed. - -End Goal: Give me a complete, detailed plan for being able to accomplish this that I can turn around and feed to an AI to be able to create the whole system. - -Narrowing: Python 3.14 syntax, most recent SQLAlchemy, Vue, and FastAPI should be used. Use SQLModel as well. Code should be fully typed and documented. Python code is async and should properly wrap/handle blocking code with threads or processes as necessary. It needs to be able to pass all linting, formatting, and code documentation tests that are checked from the precommit.