Spreaker feeds not working - [EDIT - youtube-DL extension is the culprit]

[joesmith222]

any chance to fix it?

it works on another app i have called Tapin Radio fwiw.

thx

[mhussaincov93]

hi,
could you give us a feed for testing?
this will enable us to check what errors are spawned.
could you conferm:
does this feed function in your browser?
what version of gpodder are you rocking?
are you running the gui /gtk ui or the gpo cli interface?
a thought could this be a user agent issue?
post us a feed and we'll give it a look.
Majid

[joesmith222]

thanks for the reply Majid

here is a random Spreaker feed:

https://www.spreaker.com/show/4768672/episodes/feed

the feed sort of works in the browser but it doesnt look great, but again it works fine in the Tapin Radio app but that program doesn't have the renaming add-ons that I really like in gPodder

i'm using the latest GUI version of gPodder [v3.10.21] installed on Win10
i don't know about user agent

[tpikonen]

The feed above works for me on gPodder master, but only if the youtube-dl extension is off. With the extension on, episode downloads fail. This looks like a bug in the extension.

Do you have the youtube-dl extension enabled, @joesmith222 ?

[joesmith222]

Do you have the youtube-dl extension enabled, @joesmith222 ?

yes

edit: yeah that's it, as soon as i unchecked it works now, thanks

[joesmith222]

changed title of thread so if the maker of the youtube-DL extension browses issues, they may notice it

[auouymous]

Any site youtube-dl supports causes the manage_downloads setting to fail if youtube.preferred_fmt_ids doesn't have a format for it. You can manually download with youtube-dl by right clicking episodes and using the Download with Youtube-DL option. Or add mp3 to youtube.preferred_fmt_ids, along with any comma-separated youtube formats, and then set preferred youtube format to custom and re-enable manage_downloads.

[tpikonen]

Should we just add a default fallback format 'best' to add_format() the youtube-dl extension? It would prevent downloads failing with this site and probably many others as well. Something like this:

diff --git a/share/gpodder/extensions/youtube-dl.py b/share/gpodder/extensions/youtube-dl.py
index a5d903c2..7fed3945 100644
--- a/share/gpodder/extensions/youtube-dl.py
+++ b/share/gpodder/extensions/youtube-dl.py
@@ -277,7 +277,7 @@ class gPodderYoutubeDL(download.CustomDownloader):
             logger.debug('no stdout, setting YoutubeDL logger')
             self._ydl_opts['logger'] = logger
 
-    def add_format(self, gpodder_config, opts, fallback=None):
+    def add_format(self, gpodder_config, opts, fallback='best'):
         """ construct youtube-dl -f argument from configured format. """
         # You can set a custom format or custom formats by editing the config for key
         # `youtube.preferred_fmt_ids`

[auouymous]

Good idea! The youtube formats menu should cover every format below what you choose, so there should never be a case where it doesn't find a format, and possibly chooses a much higher format. However, if someone only wants format 22, and sets that in custom formats, this would fallback to something else. And a new video usually gets the DASH formats before 18 and 22, so this could end up downloading an 8K video. Right, or did I misunderstand the fallback parameter?

But we could add a fallback to best option in the extension, and change fallback to best if option is set and fallback is None. Edit: The option would be enabled by default.

[tpikonen]

Yes, 'best' has the problem that it selects the highest bitrate / resolution format, if the exact selected format is not available. This is probably not what most people want nowadays.

I've been running with a patch which sets a more elaborate format like bestvideo[height<=720]+bestaudio[abr<=256]/bestaudio[abr<=256]/best[height<=720], but that's an individual preference of course. Maybe there should be a configurable fallback string with a reasonable default?

Something similar was discussed starting from here, but that went nowhere.

[auouymous]

Reopening due to #1347 being reverted.