Add Metadata to Playlist Files

[PranjalSurana]

Title

Add Metadata to Playlist Files

Description

Adding new setting to enhance the playlist (M3U) file generation by including #EXTINF metadata tag.

Related Issue

#2126

Motivation and Context

Enhancing playlist (M3U) file generation by including #EXTINF metadata tag . This would enrich the playlist files by including additional information like track duration and title, thereby providing a better user experience.

How Has This Been Tested?

Ran spotDL many times, to test various scenarios

Screenshots (if appropriate)

Types of Changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the CONTRIBUTING document
• I have read the CORE VALUES document
• I have added tests to cover my changes
• All new and existing tests passed

[PranjalSurana]

The failed pylint tests is failing, even though it shows "Your code has been rated at 10.00/10 (previous run: 10.00/10, -0.00)"

How should I address this?

[PranjalSurana]

Also, failing test-vcr

If this url updated according to the assertion, other tests fail.

How should this be addressed?

[xnetcat]

Don't worry about tests, they are currently being improved. I will check this PR later today. Ping me so I don't forget :)

[xnetcat]

You should also add an cli argument

[PranjalSurana]

Ok, so to enhance M3U file generation, I shld create a new CLI arg, and reuse the existing function for m3u in the new cli arg, rt?

[PranjalSurana]

@xnetcat Can u plz recheck this PR, added new CLI arg

[Silverarmor]

@PranjalSurana is there any reason not to simply change the default --m3u files to this enhanced version? Any downside? Don't see why we need another separate CLI arg for it

[PranjalSurana]

@Silverarmor, I can use the default --m3u CLI arg, there is no downside to it.

[Silverarmor]

copying in all users who have interacted with the m3u file issue recently.
@jessicah @jnxr @redfast00 @PranjalSurana @xnetcat

Thanks all for your input on this bug that was introduced. In my opinion, the best solution is to remove the option (i.e. the CLI flag) to allow for customising metadata.
Reviewing the file format, we should have an m3u / m3u8 file as follows

#EXTM3U
#EXTINF:123,Artist Name - Track Title
Artist Name - Track title.mp3
#EXTINF:123,TestTwo- TestTwo
TestTwo.mp3

There appears to be no reason to allow customisation of these tags. Devices that do not support it simply ignore the metadata due to the # comment operator.

Are there any disagreements on this? Apologies for the delay in merging PRs resolving this, as some of them didn't solve the root cause.

[jessicah]

The part after the comma is the display name, so I left that in as configurable for those that really want it, but happy either way.

On Mon, Dec 9, 2024, at 7:40 PM, Jayden wrote: copying in all users who have interacted with the m3u file issue recently. @jessicah <https://github.com/jessicah> @jnxr <https://github.com/jnxr> @redfast00 <https://github.com/redfast00> @PranjalSurana <https://github.com/PranjalSurana> @xnetcat <https://github.com/xnetcat> Thanks all for your input on this bug that was introduced. In my opinion, the best solution is to remove the *option* (i.e. the CLI flag) to allow for customising metadata. Reviewing the file format <https://en.wikipedia.org/wiki/M3U>, we should have an m3u / m3u8 file as follows `#EXTM3U #EXTINF:123,Artist Name - Track Title Artist Name - Track title.mp3 #EXTINF:123,TestTwo- TestTwo TestTwo.mp3

`

…

There appears to be no reason to allow customisation of these tags. Devices that do not support it simply ignore the metadata due to the `#` comment operator. Are there any disagreements on this? Apologies for the delay in merging PRs resolving this, as some of them didn't solve the root cause. — Reply to this email directly, view it on GitHub <#2215 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACC5IUXJBPGYTK5MLEEWP32EU3MLAVCNFSM6AAAAABQB2CPNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRXGA3DINJSGU>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[redfast00]

My two cents: a recent upgrade of spotDL changed the format that files are saved in if there are multiple authors of a song. This caused a bunch of duplicate files (one with only one author that was downloaded before the change, one with multiple authors that was downloaded after the change (or vice versa)). The simple format of the m3u file, where each line contains a filename, allowed me to easily write a commandline that moved the duplicate files that aren't in the m3u to a separate folder; for that purpose, the simpler m3u format was useful.

I realize this is a real edge case, so I'd say, disregard that usecase (woudn't be that hard to ignore lines starting with # anyways); I agree with just removing the CLI flag and using a default format.

[jnxr]

In my opinion, the best solution is to remove the option (i.e. the CLI flag) to allow for customising metadata.

The m3u customization can be used to hard code paths into the playlist file. The saved playlist files can then be placed outside of the folder and still work. You could play stuff from your NAS or something directly from the playlist file.

Right now, it would require one to go to the path the files are within or else the playlist file won't work.

The issue is solvable, the entire feature doesn't need to be removed outright.

[Silverarmor]

@jnxr The m3u8 is created from the defined --output that is set. If you use a relative filepath output, then the m3u8 file uses a relative filepath.

e.g. Using spotdl --output "D:\spotdl" <link> --m3u will create an m3u file with lines reading D:\spotdl\filename.mp3

[jnxr]

@Silverarmor
Doesn't this make it imperative that the --output directory matches the final organization directory, what if they are different?
People might have use cases which match the above scenario. For eg. I download playlists to a temporary scratch drive before sending it over to the Disk to reduce the need for defragmentation.

[Silverarmor]

@Silverarmor Doesn't this make it imperative that the --output directory matches the final organization directory, what if they are different? People might have use cases which match the above scenario. For eg. I download playlists to a temporary scratch drive before sending it over to the Disk to reduce the need for defragmentation.

Hmm that's true. However I don't see it as a crucial feature that many users must have.
spotDL as a project is facing issues of unmanageable codebase and too many features for users. I think your use case is too minor for me (currently, the entire dev team) to allocate time to.

copy past:
sorry i'm a one man team working on the project rn, on top of full time work & other things in life.
We are humans as well, and my work on spotDL over the last 4+ years is completely voluntary.