Request: configurable filenames

[kousu]

As far as I can tell, the current logic for picking filenames is roughly

link = {enclosure["href"], entry.link}
downloadlinks[urlparse(link).path.split("/")[-1]] = link
for podname in downloadlinks:
   ...
   Placeholders(..., ..., filename=podname, ..., ...)

All the CD rippers I've used, and also EasyTag, let me normalize filename formats using variables. There's a comment in the config file "# {filename} the name of the file to be downloaded (which need not be the name under which you will save it locally)" which sounds like it is implying I should be able to do this with greg, but I can't figure out how to change the local filename, and unless I'm misreading the code badly this logic insists filename == link.split("/")[-1] (ii.e. $(basename $link)) and gives no way to change it.

I would like a new config option filename_format with default

filename_format = {filename}

I would also like a new variable {n} for the podcast entry's ID number, and {-n} for the podcast entry's ID in reverse -- that is, counting from the start of the podcast -- that is, like its track number; for podcasts like history and audiobooks it is really important to be able to number them in order like this:

filename_format = {-n} - {title}.{ext}

[kousu]

I was able to get halfway to what I want with

downloadhandler = wget {link} -P {directory} -O "{title}.mp3" 

but it doesn't know about the track number and if any podcast doesn't podcast in mp3 this will be wrong, and wget apparently doesn't respect -P when used with -O.

[n8willis]

I'd also second the need for this, since a few of the feeds I subscribe to have (apparently) started naming all of their files "audio.mp3" which means that, by default, greg pulls down a bunch in the same per-feed directory and starts stacking underscore after underscore after the '3' on the extension, which in turn makes the files not recognized as audio by some (admittedly naive) utilities.

[albang]

I was able to get halfway to what I want with

downloadhandler = wget {link} -P {directory} -O "{title}.mp3" 

but it doesn't know about the track number and if any podcast doesn't podcast in mp3 this will be wrong, and wget apparently doesn't respect -P when used with -O.

downloadhandler = wget {link} -O "{directory}/{title}.mp3" works for me

[kousu]

Oh amazing, I didn't think to try it that way. Thanks albang!! ⭐

[n8willis]

I was able to get halfway to what I want with

downloadhandler = wget {link} -P {directory} -O "{title}.mp3" 

but it doesn't know about the track number and if any podcast doesn't podcast in mp3 this will be wrong, and wget apparently doesn't respect -P when used with -O.

downloadhandler = wget {link} -O "{directory}/{title}.mp3" works for me

Hmm. This does not work if you enable Tag = yes on the feed of interest. Instead, greg does all the tagging to the un-adjusted filename (here, "audio.mp3"), and saves the as-downloaded file under the filename pattern specified, with none of the tagging performed.

[manolomartinez]

Doesn't file_to_tag help with this? From the default config file:

Finally, if you are using a custom download handler (see below), you need to tell
greg how to figure out the name of the podcast files, using the file_to_tag option. For example if your download handler saves podcasts under a name such as "entry title.ogg", you will need to add the following to the podcast's config section:

file_to_tag = {entry}.ogg

[n8willis]

Doesn't file_to_tag help with this? From the default config file:

Well, the feed has since died, and it doesn't look like it's going to come back, so it's hard for me to test. I have used file_to_tag just fine in other feeds; if anything in the feed was causing the issue, I suspect that it was special characters in the filenames (I recall it had segments that were clearly cloudflare/CDN URLs that had been sanitized ... if imperfectly).

That said, can't file_to_tag be dispensed with entirely? I mean, it's fragile as a mechanism, because you have to know a-prioi what the file extension is (which isn't always guaranteed, and definitely breaks for feeds that contain audio and video). But why does it have to be separated out to begin with anyway? There's never any other file to get tagged besides the one that's being downloaded .... Why can't greg keep track of what file is returned by the downloader and automatically pass that to the tagger? I'm really not seeing a use case where greg would download file X but need to tag file Y instead.

[manolomartinez]

Why can't greg keep track of what file is returned by the downloader and automatically pass that to the tagger?

The discussion above provides an example: if you use wget with the -D flag, the name of the file to tag is whatever the user chooses. Greg cannot be expected to know the syntax of any and all possible download handlers. Am I missing an easy way to do without file_to_tag?

[Simon818]

I'd also like to emphasize the need for both these things. There's no good way around the file extension issue or the index issue without writing my own code. I could make a special download handler that strips off the extension from the original filename and then renames it, and I could count the number of files in the folder and increment by 1 since Greg downloads in reverse order, but neither of these things are possible directly with wget. I have a working copy of Greg from 2016 which has a {filename_template} placeholder, and it's extremely useful for downloading different podcasts with different filenames. Sometimes the default one is sufficient, sometimes the title works best, and other times it makes the most sense to just add a date to the beginning so they remain in chronological order. I'd love for this all to be integrated so I don't have to write an external downloader or keep adding my own code, and I know not everyone knows how to do either of those things.

Also, thanks for this project; I spent a good long time looking for a way to hoard podcasts locally and this is working well.

[manolomartinez]

Could those interested in having configurable filenames please check if this PR works for them?