search

DxCx / XSPFDownloader

XSPF Downloader - replace xspf remote urls with locals.
GNU General Public License v2.0
0 stars 1 forks source link

Lost trackNum? #1

Open sethcohn opened 7 years ago

sethcohn commented 7 years ago

Best code I've found so far to do what I want (grab remote items and make em local files). Disliked the way it naming files (using just track-title) and that was an easy change to add creator (aka artist) into the filename... but I also want to remove the track num, and allow the xspf to define the tracknum, not the filename itself. The original xspfs I'm using use trackNum, and the xspfparser code recognizes it, but somehow it gets lost from the new xspf file. And it might also be nice to have an option to not override (or backup) the original xspf file... [took me a bit to figure out it was updating in place]

DxCx commented 7 years ago

hey @sethcohn , this is old thing i did for myself and said why not to open it, but im not maintaining actively. i don't mind ofcourse :D but im not into details.. can you eleborate more about what you are trying to achieve and how can i help you? PRs are welcome 👍

sethcohn commented 7 years ago

Yeah, I totally get and thank you for opening it, as I said, best code I found on github for doing what I wanted to do. I'll submit a PR soonish, once I get it working the way I want.

DxCx commented 7 years ago

alright, but how can i help you? :D

sethcohn commented 7 years ago

Oh, sorry, I thought it was clear: current behaviors: 1 - overwrites existing xspf file. Not a showstopper, but it would be nice to leave the original intact. Workaroundable, and unsure I'll 'fix' this. Just annoying. 2 - Downloaded files are currently named "tracknum-title". I want them to be "artist-title" (no tracknum), because at a glance that makes the files the most 'recognizable'. This is an easy fix, and I did so to the code already. 3 - related to 1 & 2, and the source/cause of this bug report:

In my original xspf file, there is along with the other track info, a trackNum field.

<track>
      <location>http://internetaddressblahblahblah.com/directories/filejunkname.m4a</location>
      <creator>Madonna</creator>
      <title>Justify My Love</title>
      <trackNum>3</trackNum>
    </track>
<track>

And then, as changed post download:

<track>
         <location>03-justify-my-love.m4a</location>
         <title>Justify My Love</title>
         <creator>Madonna</creator>
</track>

See what's missing? And since in #2 above I want to dump the tracknum from the filename, I really want the xspf to continue to control the ordering (Potentially to have multiple playlists sharing the same file/music, ie Track 4 in one playlist, Track 5 in a second playlist....)

sethcohn commented 7 years ago

hehehe, and I just looked at the xspf RFC http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.9 and it turns out that is purely for the trackNum for the original album, not playback within an xspf, so I'm ok with dropping it. Never mind. :) [It wasn't being used correctly in the xspf files I am sourcing from, so I had a false impression it was actually in use]

DxCx commented 7 years ago

alright!

just for the filename fix maybe you want to implement fileNamePattern in args? i just don't want it to be breaking change since i have scripts from long ago which is depneded on this..

DxCx commented 7 years ago

regarding the truckNum being lost, thinking of it, this downloader depends on my other xspf parsing library, maybe it is getting lost there.. (if you want to dig into it although rfc-wise it's ok)