Hello,
i have installed Mopidy + Mopidy-Spotify on my raspberry pi 3.
My intention is to start music via MPC command line.
I use M3U for playback ob MP3 or livestreams.
I use a Spotify URI für Spotify content.
Following scenario:
mpc load “playlist”
…this could take up to 10 seconds, until MPD is ready
mpc load “playlist”
…MPD is ready in less than 1 second.
Why is MPD so slow, when using mopidy?
So I think I how understand your situation. You are comparing the speed of using mpc talking to mpd and mpc taking to Mopidy, and finding mpd is much faster. They are different programs, they work differently. That said, the next major release of Mopidy should see some performance improvements when it comes to the MPD interface. That should effect all MPD commands and not just playlist load. It probably still won’t be as fast as mpd, but mpd does not have Mopidy’s numerous extensions and that’s the tradeoff you have to live with.
Ok, i understand…
I thought that MPD is included in mopidy and that i can use it like the standalone version.
So, the only way is, to user mopidy+mpd+mpc for spotify and create a second mpd server where i can use mpd+mpc for MP3, playlists and livestreams on a different port.
Correct?
I saw, that these local playlist are shown in MOPIDY. When i select them there, the loading time is 10 seconds to for a 20 track M3U list. My spotify lists with 80 tracks are loaded faster in mopidy (1 second)…can local playlists buffered in background after server startup like the spotify playlists?
I’m not sure I understand. Let’s try again.
Mopidy has an MPD frontend which understands the MPD protocol. mpd is another program that also understands the MPD protocol. mpc is an MPD client which can talk to either Mopidy or mpd.
I thought your 2nd situation described uninstalling Mopidy and using mpd instead. I guess I misunderstood somehow.
Your single Mopidy server can handle all types of music, you do not need separate servers. You should see and be able to load both m3u and spotify playlists.
No, local playlists do not “buffer in the background”. An m3u playlist containing live streams may take a bit of time to load if the particular streams require numerous http requests to resolve them. EDIT: To expand on this more, we need to lookup each stream and extract the track info/metadata so we can add it to the tracklist. This lookup requires us to open the stream (as if for playback) and this is slow, and sometimes really slow depending on the type of stream, server speed etc. It’s even slower if any of the streams are down/broken since the connections will timeout after x seconds. Maybe we could improve this a little but it’s not trivial since the stream metadata may be outdated very quickly so you cannot simply cache it for any useful length of time.
An m3u playlist containing just local tracks should load quickly but it may depend a bit on what local backend you are using (sqlite is best).
It would probably help if you could provide an example m3u playlist that takes a long time to load. And provide the exact commands you used to load it. Better yet, also include a debug log showing the slow load occurring.
Yes, you understood.
I did same action once in MPD service standalone and then same command, but with mopidy service installed (the standalone MPD service was removed before installing mopidy).
I surely can send you a m3u8 file, which need 10 seconds to load.
Can you tell me, which DEBUG-File of mopidy you need, and which options of debug i habe to activate??
Ok, here is the content of the “Giraffenaffen 1.M3U8” file, which is in the playlists folder.
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/01 Wir sind da (Giraffenaffensong).mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/02 Hejo, spann den Wagen an.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/03 Hätt_ ich Dich heut_ erwartet [feat. Roman Lob].mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/04 Der, die, das.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/05 Grün, grün, grün.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/06 Weißt Du wieviel Sternlein stehen.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/07 Was müssen das für Bäume sein.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/08 Seeräuber-Opa Fabian.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/09 Manah Mannah.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/10 Einfach genial.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/11 Die Affen rasen durch den Wald.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/12 Doof gebor_n ist keiner.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/13 Idas Sommerlied [feat. Nika].mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/14 Der Mond ist aufgegangen.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/15 Old McDonald.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/16 Meine Oma fährt im Hühnerstall Motorrad.mp3
/home/pi/RPi-Jukebox-RFID/shared/audiofolders/Giraffenaffen 1/17 La-Le-Lu.mp3
The command was:
mpc load “Giraffenaffen 1” && mpc play
Logfile:
/var/log/mopidy/mopidy.log
2018-10-19 21:45:04,974 INFO [30301:MpdSession-17] mopidy.mpd.session: New MPD connection from [::ffff:127.0.0.1]:6600
2018-10-19 21:45:13,429 INFO [30301:MpdSession-18] mopidy.mpd.session: New MPD connection from [::ffff:127.0.0.1]:6600
You see, the first action, loading playlist took 8,5 seconds. Play starts fast.
In my MPD Standalone test, i took the same M3U8 and the same command.
Loading + Play < 1 second!!
Any idea, why playlist files are slow?
Do you find if you clear that playlist (mpc clear) and then load it again with the exact same command, it’s quick?
If so, that’s because the first time you load any playlist via MPD, Mopidy has to loop through all the playlists and build a mapping of playlist names to URIs. Once it has the mapping it can reuse it and that’s why the next load is quick.
It’s the mopidy-spotify playlists that are to blame here - they are taking a while to load, despite supposedly being cached. I think that’s because I’ve messed up the Etag parsing and they are not fully cached. You can see this for yourself if you run without mopidy-spotify (mopidy -o spotify/enabled=false) it’s also quick. I see my mistake and I’ve pushed a fix.
But on top of that, it’s still horribly slow due to an old issue that will be fixed in v3.0 when we make some breaking API changes to Mopidy. I think I originally found that issue due to Spotify playlists.
There isn’t really a work-around for this one yet… unless we start overriding the cache control directives and I’m not sure that’s a good idea.
EDIT: And just for reference, I can get the time down to where it should be if I hack at the issue. Note this is not on a Raspberry Pi so it’ll be a bit slower there. Bring on Mopidy v3.0!
INFO 2018-10-23 00:21:12,308 [28458:MpdSession-19] mopidy.mpd.session
New MPD connection from [::ffff:127.0.0.1]:6600
INFO 2018-10-23 00:21:12,898 [28458:MpdSession-20] mopidy.mpd.session
New MPD connection from [::ffff:127.0.0.1]:6600
@kingosticks
Thanks for your answer.
I tested it on many ways now.
It doesn’t have an effect, if i use (mopidy -o spotify/enabled=false).
The loading time is nearly 10 seconds, like before.
So, mopidy-spotify is not the problem i think.
There is anything what mopidy does with local M3U playlists, what takes more time than with MPD.
I know, MPD and Mopidy are two different things, but what could mopidy do, what takes this long time, what MPD not do?
Spotify playlists are very quick with mopidy (less than 1 second). Only local playlists are the problem…
and i have to say that the loading time is slow, too, if i use the web interface (Iris).
I’m certain what I wrote before (both parts) is correct. But feel free to investigate further if you wish, the source code is yours to examine.
@kingosticks
Ok, i have just found out a little bit.
i changed a part of “mopidy.conf” and after that change, the playlists are loaded very fast.
[file]
#enabled = true
metadata_timeout = 10
I activated metadata_timeout and set it to 10 (miliseconds i think).
Now, playlists are loaded very very fast, but no metadata are loaded from the files.
Is it possible, to read metadata after loading and while playing?
File paths in an m3u playlist will use the File backend which must scan the file to extract the metadata, much like what happens for an internet stream. It could potentially be slow if the CPU slow and the filesystem is slow i.e a Raspberry Pi. I don’t think what you want to do is possible, the File backend is going to keep using the 10 ms timeout which has proved to be too short.
However, you should be able to populate the playlists with local URIs rather than file paths. Mopidy will then use the metadata already present in the local database rather than doing a scan. The files in the playlist would need to live under your local/media_dir directory but that restriction might not matter to you. You would need to:
media_dir config setting to something like /home/pi/RPi-Jukebox-RFID/shared/audiofoldersmopidy local scan (or sudo mopidyctl local scan) to create/update the Local databaselocal URIs (and URL encode the file paths relative to your media_dir). For example:local:track:Giraffenaffen%201/01%20Wir%20sind%20da%20%28Giraffenaffensong%29.mp3
local:track:Giraffenaffen%201/02%20Hejo%2C%20spann%20den%20Wagen%20an.mp3
...
GREAT!!!
My first tests show, that could be the solution for me!
Perfect and many thanks!
No worries. Thanks for your help highlighting those issues earlier and for sticking with it.