search

jaedb / Iris

Discover, explore and manage your music library across multiple sources with this beautiful web-based interface. Iris is a Mopidy frontend extension.
Apache License 2.0
1.14k stars 133 forks source link

Unable to play podcasts #713

Closed orontee closed 3 years ago

orontee commented 3 years ago

Describe the bug

My mopidy server has the Mopidy-Podcast extension installed and configured. It used to work with Iris and musicbox webclient. It still works with musicbox webclient but not with Iris.

To Reproduce

  1. Install Mopidy-Podcast. Here is the related section of sudo mopidyctl config: 
    [podcast]
enabled = true
browse_root = Podcasts.opml
browse_order = desc
lookup_order = asc
cache_size = 64
cache_ttl = 86400
timeout = 10
  2. Configure Mopidy-Podcast. Here is my configuration file at /etc/mopidy/podcast/Podcast.opml: 
    matthias@argos:~ 
↳ cat /etc/mopidy/podcast/Podcasts.opml 
<?xml version="1.0" encoding="UTF-8"?>
<opml>
<body>
<outline text="Concordance des temps" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_16278.xml"/>
<outline text="La conversation scientifique" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_13957.xml"/>
<outline text="Le Feuilleton" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_11495.xml"/>
<outline text="Le masque et la plume" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_14007.xml"/>
<outline text="Les p'tits bateaux" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_10137.xml"/>
<outline text="Signes des temps" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_19489.xml"/>
<outline text="Le Cours de l'histoire" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_10076.xml" />
<outline text="Une histoire particulière" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_16408.xml" />
<outline text="La Compagnie des œuvres" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_15537.xml" />
<outline text="Open jazz" type="rss" xmlUrl="http://radiofrance-podcast.net/podcast09/rss_12283.xml" />
</body>
</opml>
  3. Click on "Browse / Podcasts", choose a podcast, then a track, click "play" from the track menu
  4. See the toast "Mopidy failed to add some track"

Expected behavior

The choosen track is played.

Console log

Object { message: "Mopidy: Failed to add some tracks", data: [] }
app.min.js:111:227792

Environment details:

tkem commented 3 years ago

Since this is similar to https://github.com/tkem/mopidy-podcast/issues/59, may I elaborate:

Mopidy-Podcast "track" URIs look like podcast+{podcast-uri}#{episode-guid}, i.e. it expects the URI fragment to contain the episode GUID (which may be a URI by itself), for example

podcast+https://metinalista.si/category/ldgd/feed/#https://metinalista.si/?p=34343

where https://metinalista.si/?p=34343 is the fragment. AFAICS, Iris somewhere encodes the # sign separating the fragment, so this becomes

podcast+https://metinalista.si/category/ldgd/feed/%23https://metinalista.si/?p=34343

Since this URI no longer contains a fragment, mopidy-podcast is not able to refer to a podcast episode any more.

As @orontee said, this apparently used to work with Iris. I can only confirm this works with current versions of Musicbox Webclient, Mopidy Mobile, and mpc.

tkem commented 3 years ago

To elaborate some more:

>>> from urllib.parse import urlsplit
>>> urlsplit("podcast+https://metinalista.si/category/ldgd/feed/#https://metinalista.si/?p=34343")
SplitResult(scheme='podcast+https', netloc='metinalista.si', path='/category/ldgd/feed/', query='', fragment='https://metinalista.si/?p=34343')
>>> urlsplit("podcast+https://metinalista.si/category/ldgd/feed/%23https://metinalista.si/?p=34343")
SplitResult(scheme='podcast+https', netloc='metinalista.si', path='/category/ldgd/feed/%23https://metinalista.si/', query='p=34343', fragment='')
tilllt commented 3 years ago

I do understand, that it's iris that encodes the hash sign to %23. What I don't understand is why that is wrong. Everything after the http(s) should be URL encoded, in my limited understanding, or it should not be used in an URL formatted string.

Either it is a URI, then it needs URI encoding, or it is not, then the query format string should be specified elsewhere.

https://tools.ietf.org/html/rfc3986

As I understand you are argumenting that it is merely an internal link, and therefore the need to url encoding does not apply, right?

I don't think it necessarily means that Iris is wrong, only because it works on other software. Maybe the other softwares is just ignoring the RFC, or they try to "help" the user by fixing an error. Browsers does this, a lot, to allow for a seemless user experience. The minimum they should handle is the the formatting from the RFCs though.

tkem commented 3 years ago

Everything after the http(s) should be URL encoded,

No, it definitley shouldn't be. Especially ? and # are used to separate query and fragment parts, and must not be encoded to act as such. RFC 3986 is pretty clear on this, also please have another look at the urlsplit examples I gave above.

rmalchow commented 3 years ago

so the difference appears to be the "#" as the delimiter of the "fragment" component of the URL vs the "#" as part of, for example, a request parameter value.

if i want to send a request parameter with key = "hashtag" and value = "#foobar", then i have to escape the "#", precisely because it is a reserved character in RFC3986.

if i want to use the "fragment" as it is intended in the RFC:

The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information.

then i must not escape it. in this case, when we're using the parts left of the fragment delimiter to identify a series of podcasts, and then use the fragment to identify an episode, i think it is save to assume that this is exactly the "identify a secondary resource" use case from the RFC. thus escaping the "#" is actually incorrect.

tkem commented 3 years ago

@rmalchow: Exactly. Just look at

>>> from urllib.parse import urldefrag
>>> urldefrag("podcast+https://metinalista.si/category/ldgd/feed/#https://metinalista.si/?p=34343").url
'podcast+https://metinalista.si/category/ldgd/feed/'
>>> urldefrag("podcast+https://metinalista.si/category/ldgd/feed/#https://metinalista.si/?p=34343").fragment
'https://metinalista.si/?p=34343'
>>> urldefrag("podcast+https://metinalista.si/category/ldgd/feed/%23https://metinalista.si/?p=34343").url
'podcast+https://metinalista.si/category/ldgd/feed/%23https://metinalista.si/?p=34343'
>>> urldefrag("podcast+https://metinalista.si/category/ldgd/feed/%23https://metinalista.si/?p=34343").fragment
''
samytichadou commented 3 years ago

hi i'm kind of a newbie here regarding parsing and rss feed/url, but having the same problem with Iris image

My podcast seems to be working, i can play them through any other frontend client (mowecl and musicbox_webclient for example) or even mpd player (like cantata or malp on android). I would like to use Iris because of its UI and spotify nice integration compared to the other ones i just mentioned, but podcast is a big part of my use here

When starting a podcast and looking at sudo systemctl status mopidy.server, i got a [PodcastBackend-9] error HTTP ERROR 404 with the podcast URL (for example http://radiofrance-podcast.net/podcast09/rss_14523.xml%239a0e8ae7-d986-40b3-84cd-bcadd939d9d8). From what i gather so far, these errors are some "known issue" aren't they ? I also get these same errors when playing from music box webclient, but somehow, the podcast is able to start and play correctly.

Any clue about this ?

Thanks for the hard work in mopidy/iris, great piece of software !

Cheers !

[edit] iris show correct playing podcast if launched from other frontend, if queued, it also allows to launch the play from "now playing" panel

jaedb commented 3 years ago

This is yet another issue due to using URIs in the browser URL (browsers do their own manipulation, creating inconsistencies). I have now enlisted encoding to base64 and preserving whatever encoding was provided by Mopidy itself. So, in theory, the issues described above should now be resolved.

@orontee and @samytichadou can you confirm whether the issue is solved by upgrading Iris to at least 3.57.3? You will need to restart Mopidy and clear your browser cache after upgrading.

samytichadou commented 3 years ago

Thanks a lot for the quick answer and fix, podcast are playing when launching them from browse in 3.57.3 ! Cheers !

jaedb commented 3 years ago

That's awesome to hear, glad it's working now :-) thanks for your help

mickeygoldsmith commented 2 years ago

i am having real problems getting podcasts to work…. I have this URI: “podcast+http://rabbisilber.com/classes/feed/recent” to get the latest podcast episodes, but i cannot figure out where to put it, how to have the pi zero W with pimoroni pirate audio HAT working to just play content from that source. What am I doing wrong?

I cannot find the config files to edit to add this as a source, nor can I find in IRIS where/how to listen to latest episodes from this source.