[GH-ISSUE #34] [Feature Request] Named & Extendable M3U8s for Playlists #30

Closed
opened 2026-02-27 04:57:11 +03:00 by kerem · 6 comments
Owner

Originally created by @LaneSBarnes on GitHub (Jul 26, 2025).
Original GitHub issue: https://github.com/Googolplexed0/zotify/issues/34

Originally assigned to: @Googolplexed0 on GitHub.

When I set EXPORT_M3U8 = true and I download a playlist called "MyPlaylist", I'd like to be able to set the name of the file to MyPlaylist.m3u8

When I add more songs to "MyPlaylist" and then I try downloading the playlist again, it will skip all the existing songs and only add the new ones, which is great. However, it currently creates a new .m3u8 file when I would like to have the old one overwritten. If I can tell Zotify to name my .m3u8 file as MyPlaylist.m3u8, this will happen automatically.

It appears this functionality is how downloading "Liked Songs" works. I download my Liked Songs, it creates a "Liked Songs.m3u8". When I add more songs and then download again, "Liked Songs.m3u8" is overwritten with the updated version. I'd like this to happen with playlists too.

Originally created by @LaneSBarnes on GitHub (Jul 26, 2025). Original GitHub issue: https://github.com/Googolplexed0/zotify/issues/34 Originally assigned to: @Googolplexed0 on GitHub. When I set EXPORT_M3U8 = true and I download a playlist called "MyPlaylist", I'd like to be able to set the name of the file to MyPlaylist.m3u8 When I add more songs to "MyPlaylist" and then I try downloading the playlist again, it will skip all the existing songs and only add the new ones, which is great. However, it currently creates a new .m3u8 file when I would like to have the old one overwritten. If I can tell Zotify to name my .m3u8 file as MyPlaylist.m3u8, this will happen automatically. It appears this functionality is how downloading "Liked Songs" works. I download my Liked Songs, it creates a "Liked Songs.m3u8". When I add more songs and then download again, "Liked Songs.m3u8" is overwritten with the updated version. I'd like this to happen with playlists too.
kerem 2026-02-27 04:57:11 +03:00
Author
Owner

@LaneSBarnes commented on GitHub (Jul 26, 2025):

I just learned that the "LIKED_SONGS_ARCHIVE_M3U8": "True" config file is the reason why the Liked Songs m3u8 file is extendable. Maybe a new config file that is something along the lines of "PLAYLIST_ARCHIVE_M3U8" that achieves the same result

<!-- gh-comment-id:3122177199 --> @LaneSBarnes commented on GitHub (Jul 26, 2025): I just learned that the "LIKED_SONGS_ARCHIVE_M3U8": "True" config file is the reason why the Liked Songs m3u8 file is extendable. Maybe a new config file that is something along the lines of "PLAYLIST_ARCHIVE_M3U8" that achieves the same result
Author
Owner

@Googolplexed0 commented on GitHub (Jul 26, 2025):

I just learned that the "LIKED_SONGS_ARCHIVE_M3U8": "True" config file is the reason why the Liked Songs m3u8 file is extendable.

This config setting exists because we need to append newly liked songs to the top of the existing Liked Songs.m3u8 file (think of it as a reverse-order playlist), which adds a lot of complexity and opportunity for errors. The current functionality detects when the first track in the Liked Songs.m3u8 matches what is about to be downloaded and appends the temporary m3u8 to the top of Liked Songs.m3u8.

This approach is naïve and assumes that no removals have been made below this cutoff point in the time since the previous generation/update of Liked Songs.m3u8 (hence the use of "archive" in the config name). As a result, I cannot guarantee it will remain consistent with the actual state of a user's Liked Songs after arbitrary changes and is fairly specialized.

Thankfully, it should be pretty easy to make playlist m3u8s overwrite each time, as the m3u8-related functions are called before skipping an existing song. Just need to allow for higher-level functions to pass down a path for an m3u8 file. I will commit the change for this enhancement today. Please help bug test it for me.

<!-- gh-comment-id:3122942096 --> @Googolplexed0 commented on GitHub (Jul 26, 2025): > I just learned that the "LIKED_SONGS_ARCHIVE_M3U8": "True" config file is the reason why the Liked Songs m3u8 file is extendable. This config setting exists because we need to append newly liked songs to the top of the existing `Liked Songs.m3u8` file (think of it as a reverse-order playlist), which adds a lot of complexity and opportunity for errors. The current functionality detects when the first track in the `Liked Songs.m3u8` matches what is about to be downloaded and appends the temporary m3u8 to the top of `Liked Songs.m3u8`. This approach is naïve and assumes that no removals have been made below this cutoff point in the time since the previous generation/update of `Liked Songs.m3u8` (hence the use of "archive" in the config name). As a result, I cannot guarantee it will remain consistent with the actual state of a user's Liked Songs after arbitrary changes and is fairly specialized. Thankfully, it should be pretty easy to make playlist m3u8s overwrite each time, as the m3u8-related functions are called before skipping an existing song. Just need to allow for higher-level functions to pass down a path for an m3u8 file. I will commit the change for this enhancement today. Please help bug test it for me.
Author
Owner

@Googolplexed0 commented on GitHub (Jul 27, 2025):

@LaneSBarnes, let me know how ad25e3a works for you. No issues across all my various tests runs.

<!-- gh-comment-id:3123641642 --> @Googolplexed0 commented on GitHub (Jul 27, 2025): @LaneSBarnes, let me know how ad25e3a works for you. No issues across all my various tests runs.
Author
Owner

@LaneSBarnes commented on GitHub (Jul 27, 2025):

@Googolplexed0
I think all is well!
Here is the happy path I am wanting to use Zotify for and I put together a small test for it:

In my config, I tell zotify to download ALL songs to a single folder. This folder is my "single source of truth" that has all my music from various playlists. I have everything in one folder because it is important to me that I never download duplicates and the single folder structure makes this easy.

I have a file called "trackedPlaylists.txt" and inside it are the Spotify URLs for two playlists called "Playlist1" and "Playlist2".
Playlist1 contains song "A" and song "B".
Playlist2 contains song "A" and song "C".

I run "zotify -f trackedPlaylists.txt"
and zotify downloads both playlists. When it is done, I get three songs in the folder (A, B, and C) and A is not being duplicated.
I get two playlist files "Playlist1.m3u8" and "Playlist2.m3u8".

"Playlist1.m3u8" contains references to song A and B.
"Playlist2.m3u8" contains references to song A and C.

This is all excellent so far.
Finally I add a new song "D" to Playlist1.

I run "zotify -f trackedPlaylists.txt" again
zotify skips over every song in each playlist EXCEPT the newly added song "D".
When its over, the folder is filled with songs A, B, C, and D.

"Playlist1.m3u8" contains references to song A, B, and D.
"Playlist2.m3u8" is not changed at all and still contains references to song A and C.

Not only can I create an initial song directory with correctly labeled playlists, I can update these playlist in Spotify and then have updated downloaded versions after running zotify in the future.

This test basically has everything I want to keep my local library up to date.

Thankyou SO MUCH for adding this feature. I forked the repo myself and was poking around on how to get this functionality working but I was sure I was going to make some mistakes in the process haha.

Ill try to think of ways to QA this further 😁

<!-- gh-comment-id:3124570066 --> @LaneSBarnes commented on GitHub (Jul 27, 2025): @Googolplexed0 I think all is well! Here is the happy path I am wanting to use Zotify for and I put together a small test for it: In my config, I tell zotify to download ALL songs to a single folder. This folder is my "single source of truth" that has all my music from various playlists. I have everything in one folder because it is important to me that I never download duplicates and the single folder structure makes this easy. I have a file called "trackedPlaylists.txt" and inside it are the Spotify URLs for two playlists called "Playlist1" and "Playlist2". Playlist1 contains song "A" and song "B". Playlist2 contains song "A" and song "C". I run "zotify -f trackedPlaylists.txt" and zotify downloads both playlists. When it is done, I get three songs in the folder (A, B, and C) and A is not being duplicated. I get two playlist files "Playlist1.m3u8" and "Playlist2.m3u8". "Playlist1.m3u8" contains references to song A and B. "Playlist2.m3u8" contains references to song A and C. This is all excellent so far. Finally I add a new song "D" to Playlist1. I run "zotify -f trackedPlaylists.txt" again zotify skips over every song in each playlist EXCEPT the newly added song "D". When its over, the folder is filled with songs A, B, C, and D. "Playlist1.m3u8" contains references to song A, B, and D. "Playlist2.m3u8" is not changed at all and still contains references to song A and C. Not only can I create an initial song directory with correctly labeled playlists, I can update these playlist in Spotify and then have updated downloaded versions after running zotify in the future. This test basically has everything I want to keep my local library up to date. Thankyou SO MUCH for adding this feature. I forked the repo myself and was poking around on how to get this functionality working but I was sure I was going to make some mistakes in the process haha. Ill try to think of ways to QA this further 😁
Author
Owner

@LaneSBarnes commented on GitHub (Jul 27, 2025):

I removed song D from Playlist1 and then ran zotify again.

Playlist1.m3u8 now only contains reference to A and B. The reference to D is now gone.

This is great!
Removing songs from playlists isn't something I do often but i'm glad it will update the local playlist files to reflect the song removal!

<!-- gh-comment-id:3124616843 --> @LaneSBarnes commented on GitHub (Jul 27, 2025): I removed song D from Playlist1 and then ran zotify again. Playlist1.m3u8 now only contains reference to A and B. The reference to D is now gone. This is great! Removing songs from playlists isn't something I do often but i'm glad it will update the local playlist files to reflect the song removal!
Author
Owner

@StephanX commented on GitHub (Jul 28, 2025):

LOL I was just now about to submit a PR to fix this issue, but when I diffed HEAD to my tasks, I saw it had already been done. Thanks!

<!-- gh-comment-id:3128925523 --> @StephanX commented on GitHub (Jul 28, 2025): LOL I was _just now_ about to submit a PR to fix this issue, but when I diffed HEAD to my tasks, I saw it had already been done. Thanks!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/zotify#30
No description provided.