Extended m3u track information is ignored by listplaylistinfo

[crocket]

Radio.m3u8

#EXTM3U

#EXTINF:-1,name 1
http://url 1:8000

#EXTINF:-1,name 2
http://url 2:443

#EXTINF:-1,name 3
http://www.url 3.com

With mpd-0.21.8

mpc playlist Radio
name 1
name 2
name 3

With mopidy-2.2.2

mpc playlist Radio
url 1
url 2
url 3

I added http://* and https://* to stream/metadata_blacklist to prevent it from meddling with stream names.

[kingosticks]

mpc playlist Radio uses MPD's listplaylistinfo to return all available metadata for each track in the playlist. I changed the behaviour of this as part of mopidy/mopidy#1621 to explicitly lookup the metadata for every track; I think that was because in the particular case of an m3u playlist, we could do track lookups to obtain richer metadata than m3u can otherwise provide.

But it turns out in the case when they are streams, it can be slow to do those lookups. And in the general case, the new metadata will "meddle" with any 'EXTINF' name that was already specified. Furthermore, if you use metadata_blacklist you even lose the specified 'EXTINF' name and are left with only the URI. That is not very nice.

Since the goal of the MPD frontend is to mimic mpd's behaviour - this seems wrong. Our listplaylistinfo should not do track lookups, it should just return the playlist data as is. So when they are Spotify etc playlists, you'll get the full track data - great!. But when they are m3u playlists you'll only get the track's 'uri' and 'name', regardless of what the actual tracks are (Spotify, Stream, Local etc) and regardless of any richer metadata Mopidy has available. If your MPD client wants the full metadata, it'll have to do some extra work to get it.

[crocket]

Most radio streams that I have don't give metadata. So, I just see URLs.

[kingosticks]

Internet radio stations are a complete mess when it comes to metadata, some do it properly and others don't bother. It's a shame to lose the rich track metadata from other backends over this but I think it's the right thing to do. It's a shame XSPF or something else didn't really take off.

[crocket]

Are there MPD commands for track lookups?

[kingosticks]

I think you'd have to do individual find commands in the old version of MPD we support, which is horrible. But as soon as you add the tracks to the tracklist they'll get a full lookup then.

However, at that point you'll lose your 'EXTINF' name again and we are back to square one.

[audetto]

I might have a very similar issue:

I create a xspf playlisy

        <track>
            <creator>Radio France</creator>
            <location>http://direct.franceinfo.fr/live/franceinfo-midfi.mp3</location>
            <title>France Info</title>
            <album>France Info</album>
        </track>

then I display information with

mpc playlist -f "%position% - %name% - %title%"

All good at the begin, but as soon as the stream plays mpc replaces all my metadata with stream metadata, which as someone said is a mess, but I do not want to use it.

Before:

19 - - France Info

After:

19 - franceinfo-midfi.mp3 -

Is there a way to tell mpc / mpd not to use the metadata of the stream and stick to the one I provided?

Some stations have usable metadata, some not, but I really would like to use what I put in the playlist. Is it possible?

[Kryophilos]

I am suffering from the same issue (messed up metadata from internet radio stations). After looking into the Wikipedia page on M3U I would like to propose a tweak (hope my thinking is not too naive): Could one add an (optional) parameter to the EXTINF entry (it seems to be non-standard M3U but e.g. used for IPTV) like
#EXTINF:-1,station name,lookup=no
so the M3U extension (and/or Mopidy itself) know whether to look up metadata for this entry or not?

[audetto]

I opened an issue but it was closed immediately as my version of mpd is old.

MusicPlayerDaemon/MPD#1069 (comment)

See if you can reopen it with a newer one.

[kingosticks]

mpd is a different project. Opening issues there is nothing to do with issues with Mopidy-MPD.

I think I've explained what happens quite clearly already and where the problem is. I understand the proposed tweak, adding extra params is fine because there's no such thing as a standard for M3U. But can you see a way to communicate your new parameter from the m3u backend to the MPD frontend where the metadata gets overwritten? That's the problem.