No tracklist metadata when using MPD load with M3U playlists

[FallenHorseman]

I begun to work with playlists and encountered some minor issues:
if using playlists, no artists and time informations are available.
Also the Webinterface isn't showing the Artists, cover image and time-scroll-bar isn't usable. (Max Time showing (n/a))

using the current version of mopidy.

mpc -h raspimopidy version : mpd version: 0.19.0

How to create bug:
Creating playlist with:

mpc -h raspimopidy search artist "Alkbottle" | mpc -h raspimopidy add --wait
mpc -h raspimopidy play 

Executing mpc -h raspimopidy status

Alkbottle - No Sleep Till Meidling
[playing] #16/39   0:02/2:50 (1%)
volume: 15%   repeat: off   random: on    single: off   consume: off

-> Everything is fine.

If I load&play the identical Playlist, and execute status again:

No Sleep Till Meidling
[playing] #4/39   0:07/0:00 (0%)
volume: 15%   repeat: off   random: on    single: off   consume: off

-> No Artist shown and Song length is 0

[adamcik]

Since mopidy has a number of backends/extensions this is not enough information to easily reproduce. Could you please tell us if this is the M3U playlist backend and what backend the tracks are coming from.

This might just be a known limitation in the M3U backend and/or how the current core playlist API works, but without more specifics it's hard to check.

[chises]

Hello i have the same issue.

Mopidy 2.0.0 (apt.mopidy Installation)

i am using local files and loading the Playlist with the
"mpc load " command
i have the m3u Extension installed
here the output
root@xxx:~# mpc Sohn Der Leere [playing] #2/29 0:47/0:00 (0%) volume:100% repeat: off random: off single: off consume: off

The Artist is missing and the Duration.
If i load the song not via Playlist it is working great.
root@xxx:~# mpc Die Ärzte - Sohn Der Leere [playing] #2/29 0:05/4:36 (1%) volume:100% repeat: off random: off single: off consume: off

The Problem seems to be the Details in the m3u file:
#EXTINF:-1,Sohn Der Leere local:track:Die%20%3Frzte%20-%20Cpt.%20Metal.mp3

This Playlist was created with mopidy as saved with mopidy.

[unimatrix27]

I can confirm the issue. I am using the M3U backend. The files are coming from the file-backend. I am not using the local backend, just file.

[m3u]
playlists_dir = /var/lib/mopidy/playlists
base_dir = $XDG_MUSIC_DIR
[file]
enabled = true
media_dirs = /mnt/data2/music/
show_dotfiles = false
follow_symlinks = false
metadata_timeout = 1000

Playlist has all lines like this one:
file:///mnt/data2/music/xxxxx/01.mp3

[kingosticks]

We don't lookup each track's metadata when we lookup an m3u playlist, we just grab whatever metadata accompanies each entry in the playlist file. I think this is because we want to avoid the really slow lookups when the playlist is a bunch of streams. But if we are loading a playlist into the tracklist then surely we do want to get the full track metadata too...? Does anyone remember the reasoning here?

[adamcik]

Mostly this was an API design flaw on our part. We want to have playlists return uri/refs and then we could lookup afterwards. But as it is now we expect the backend to return full tracks, and if the current backend can't populate it would need to ask core to check with other backends. Which risks deadlocks. So we don't support that.

[kingosticks]

But in this particular case (mpd load) we can just lookup the tracks as we add them to the tracklist, right?

[adamcik]

For MPD probably, also I didn't double check any of this now. Just went off memory for now :-)

[kingosticks]

I'm pretty sure you are right, it sounds very familiar.

…

On 16 Jan 2017 12:33 a.m., "Thomas Adamcik" ***@***.***> wrote: For MPD probably, also I didn't double check any of this now. Just went off memory for now :-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1511 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5DqA6BwoN5oRF_C2olPFgPxr-vzNchks5rSrrjgaJpZM4IfJWD> .

[unimatrix27]

The issue for me is, that the information is not even available for the currently playing track out of a playlist. This makes it impossible to seek within a track. Would it be better to have a cron job run through playlists and add metadata to them so that it is available when mopidy loads them?

[kingosticks]

We do understand your issue (thanks to the extra info provided here now) and we shouldn't need to resort to anything like that.

[kingosticks]

The problem also manifests when using MPD's listplaylistinfo

[kingosticks]

So I did a fix for this in my branch ages ago but for reasons I can't fathom right now, I didn't submit a PR with it....

[elmtreecomputers]

I am still facing the problem with missing track metadata, when I load playlist saved through MPD through MPC, NCMPC or similar clients. Loading is working fine when the list is created in Spotify desktop app. I installed mopidy through Arch community repo. Is it updated with your latest fixed? If not what is the workaround?
Mopidy Arch repo: https://www.archlinux.org/packages/community/any/mopidy/

[kingosticks]

It's fixed in #1621 but until that's merged the workaround is to use that code.

[elmtreecomputers]

So replacing the file with this will work? https://github.com/mopidy/mopidy/pull/1621/files/a4a1c4f05bfec60ecaf4c656366cb79e41be92da#diff-1e6b1c6ad5724e8e69b074e7c1bb9fb2