Similar problems raise when URL is changed in URL list or meta data. I would split this into 2 or 3 feature request/todo items. This scenario is a bit outstretched and I wouldn't support it in early implementations. Based on hash of section, we can determine which section changed and ask user what to do, to remove the entry from the other section, to undo change or to add new data (new meta entry, or new URL depending which one is missing). An entry is removed from URL array or from meta data section.Both URL array and meta data are hashed, and hashes are stored as "last known good configuration".Playlist is imported and mpsyt generates meta data, and each meta data entry has it's URL.Playlist is created using just required part of JSON/YAML format playlist.insist to use only YAML style playlistsĭeleting an url could be made failsafe by copying URL into meta info.make some sort of convert script (built separate tool, I don't like this either).make parser guess which format is used (easier for users but a bit more complex code and I think that it's not worth it).add header, like #mpsyt-raw and #mpsyt-yaml, and trigger needed parser based on that.those two features implemented separately (I don't like this one).I would still like to support that way and I see a few solutions. In example, only song title is required, and playlist loader should expand and add other fields upon loading the file, so a user can type in the rest or fill it interactively (either manually or automatically).Īlso, I implemented a basic playlist reconstruction from text files in #361. In that case, our playlist could be implemented in such way that it can work on playlist with only some information available. I prefer YAML when there is need for users to build such files manually. I find writing JSON files by hand a bit difficult. Let user search for item and pick desired or let him skip that item if alternative is really not available. Manual matching if match confidence is low.A nice feature would be to check playlist integrity (check if all items are available) and search for substitutions (manually or automatically).I think that video title isn't good enough to use it as is, but we can strip it down using some common words (video, vevo, album, live, rare.) There's an open ended question how to extract song title from the video title. A song matcher is already implemented in album search, so we can rely on that one. In case link is broken (in example, the video is deleted) we should have enough information to search for alternative.Items should have ytid, URL or something so we can quickly load them without querying yt API.
0 Comments
Leave a Reply. |