Podcast downloads with modified endings

50 views
Skip to first unread message

TonyK

unread,
Oct 10, 2016, 1:38:13 PM10/10/16
to newsbeuter
I've recently installed Linux (Lubutnu 16.04) on a new computer, upgrading from my aging hardware.  I backed up my newsbeuter directory and switched it to my new installation with out any difficulties.  However I am noticing that my RSS feeds for a couple of podcasts are saving the mp3 files to /tmp directory with endings that appear to conflict with podbeuter or moc recognizing them.  After I download a podcast ending in (as an example) "podcast.mp3?dest-id=175971" , when I try to open it with moc, moc doesn't recognize the files with modified endings.  I'm not sure if the RSS feeds have changed their link name formats or if podbeuter is not downloading them properly, but it is annoying to have to go into /tmp and manually rename files to eliminate the "?dest-id= ..." tails on the mp3 podcasts.  Both of the podcasts I'm having trouble with are libsyn.com podcasts.

Anyone else encountering this or know a fix?

Alexander Batischev

unread,
Oct 10, 2016, 3:17:33 PM10/10/16
to newsb...@googlegroups.com
Hi TonyK,

On Mon, Oct 10, 2016 at 10:38:13AM -0700, TonyK wrote:
>I'm not sure if the RSS feeds have changed their link name formats or
>if podbeuter is not downloading them properly, […] Both of the podcasts
>I'm having trouble with are libsyn.com podcasts.

Libsyn.com indeed specifies the names that way. If you didn't have
trouble with these feeds before, then libsyn must've just changed
something, because the relevant parts of Newsbeuter haven't been touched
since 2008 when they were written. (For those curious: I mean the
function controller::generate_enqueue_filename.)

I'm not aware of the way around the issue, save for patching Newsbeuter
to strip the query parameters (i.e. the question mark and what follows
after it). But maybe I'm just not familiar enough with the docs and how
Podbeuter really works (haven't looked at its code yet), so let's wait
and see if others have any advice.

--
Regards,
Alexander Batischev

PGP key 356961A20C8BFD03
Fingerprint: CE6C 4307 9348 58E3 FD94 A00F 3569 61A2 0C8B FD03

signature.asc

TonyK

unread,
Oct 12, 2016, 7:55:13 AM10/12/16
to newsbeuter
The other thing I am wondering is if the podcast maintainer can make specifications to their settings.  One of the podcasts on libsyn.com I don't remember having any difficulties with until very recently (during my upgrade).  So, I'm wondering if the podcasters have their own settings that turns this "dest-id" parameter off and on.

TonyK

unread,
Oct 12, 2016, 8:06:15 AM10/12/16
to newsbeuter
I've checked several other feeds from libsync.com.  I didn't have problem with them earlier.  They all appear to have this "dest-id" parameter tacked on the end of their download links from their feeds.  So this must be something new as I didn't have a problem with them earlier.  The only other thing I can think if is if there is a setting in MOC that can be switched to ignore these endings.  If all of libsyn.com podcasts have this problem, I wonder what other feed readers, audio players are running into this issue and if libsync.com is aware of this problem?

Alexander Batischev

unread,
Oct 16, 2016, 4:04:37 AM10/16/16
to newsb...@googlegroups.com
On Wed, Oct 12, 2016 at 05:06:15AM -0700, TonyK wrote:
>If all of libsyn.com podcasts have this problem, I wonder what other
>feed readers, audio players are running into this issue and if
>libsync.com is aware of this problem?

I wouldn't regard that as a problem of libsyn.com; they have right to
refer to files however they want :) It's more like Newsbeuter is doing
suboptimal job by not stripping the stuff that comes after the question
mark out.

I filed an issue[1], but don't have an ETA for the solution. If you're
on GitHub, you can click "Subscribe" button in the issue to receive
notifications about any changes, but I'll probably post here as well
when there's something to test.

  1. https://github.com/akrennmair/newsbeuter/issues/376

Thanks for reporting this!
signature.asc
Reply all
Reply to author
Forward
0 new messages