Filesystem playlist take a long time to load

[wolfsongz]

I've noticed that since the major update (end of year/beginning of year) playlists from the Filesystem provider take a very long time to populate. I've also noticed that even after they load, at some point they'll be empty again. I've tried with both local and remote and the experience is the same. Are these cached at all? Shouldn't the sync keep them up to date? This didn't seem to be an issue prior to the major update.

[OzGav]

Is the filesystem share always available?

[OzGav]

OK is this only a problem on the in development Android App?

[wolfsongz]

No, I'm using the HA mobile app. This seems to be related to authentication. If for instance I switch between MA and Settings or Dashboard after viewing a playlist, I have to wait for the tracks in a playlist to reload. The one exception I found was if a player is currently playing a playlist, the tracks are loaded. Is this expected behavior?

I'm not entirely sure but I feel that this has impacted automations. The HA logs show that the automation was successful but MA doesn't play anything. I usually try at that point to select the playlist and notice that the tracks aren't listed.

You helped me set up the automation. I have a single track that plays first and that part is successful. Then it adds a playlist to the queue and that's the music that doesn't play. Last night this happened but I had already ensured the tracks were loaded on my phone before triggering the automation. When I selected the speaker and then play, nothing happened. Again, I could see the tracks in the playlist at this point so I tried a few times. It finally started playing about 2-3 minutes later.

2026-03-02 22:54:53.475 INFO (MainThread) [music_assistant.player_queues] Fetching tracks to play for playlist Sleep
2026-03-02 22:54:58.682 INFO (MainThread) [music_assistant.player_queues] Fetching tracks to play for playlist Sleep
2026-03-02 22:55:01.862 WARNING (MainThread) [music_assistant.filesystem_smb] Could not parse "/mnt/$($matches[1].ToLower())" /Music/iTunes/Music/Soundtrack/[2013] Pure Imagination/01 Pure Imagination.mp3 to track: Invalid path/uri
2026-03-02 22:56:17.902 WARNING (MainThread) [music_assistant.tags] ARTISTS tag count (1) does not match MusicBrainz Artist ID count (2): ['Voctave/Tituss Burgess']
2026-03-02 22:56:47.099 INFO (MainThread) [music_assistant.player_queues] Resumed queue Bedroom speaker from playlog (userid + queue_id match)
2026-03-02 22:56:47.104 INFO (MainThread) [music_assistant.players] Ignore PLAY request to player Bedroom speaker: player is already playing
2026-03-02 22:56:47.111 INFO (MainThread) [music_assistant.players] Ignore PLAY request to player Bedroom speaker: player is already playing
2026-03-02 22:56:47.112 INFO (MainThread) [music_assistant.players] Ignore PLAY request to player Bedroom speaker: player is already playing

I do see the path error and I know why that one is happening. I have no idea why the tag warning is happening and there are a lot of those errors in the logs. All of my files are tagged with Picard.
music-assistant.log

[OzGav]

I have a think and look more soon. On the tagging problem it looks like a MusicBrainz problem then. I recently added more logging to highlight when there are disconnects between what is shown in the various artist related tag fields. So there is ARTIST, ARTISTS and the MB identifiers. In this case

ARTISTS tag count (1) does not match MusicBrainz Artist ID count (2): ['Max Richter/Grace Davidson']

It looks like ARTIST has Max Richter/Grace Davidson but there is something different in ARTISTS. ARTISTS should be Max Richter;Grace Davidson and then there should be two IDs in MUSICBRAINZ_ARTIST_ID as well

[wolfsongz]

Picard has a setting for separators. I'll change mine to semicolon to fix that.

[OzGav]

Yeah we do mention that here https://www.music-assistant.io/music-providers/filesystem/#tagging-files

[wolfsongz]

Some additional info. I have an automation that changes the playlist at 8am. When it triggered, the current playlist stopped as expected but it took 18 minutes for the new playlist to start playing. Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. Sent from [Proton Mail](https://proton.me/mail/home) for Android.

…

-------- Original Message --------

On Tuesday, 03/03/26 at 07:54 OzGav ***@***.***> wrote: I have a think and look more soon. On the tagging problem it looks like a MusicBrainz problem then. I recently added more logging to highlight when there are disconnects between what is shown in the various artist related tag fields. So there is ARTIST, ARTISTS and the MB identifiers. In this case ARTISTS tag count (1) does not match MusicBrainz Artist ID count (2): ['Max Richter/Grace Davidson'] It looks like ARTIST has Max Richter/Grace Davidson but there is something different in ARTISTS. ARTISTS should be Max Richter;Grace Davidson and then there should be two IDs in MUSICBRAINZ_ARTIST_ID as well — Reply to this email directly, [view it on GitHub](#4995 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ATQWFAJDPU5LXFXSNEYOEST4O3P3FAVCNFSM6AAAAACV6ZG6Q2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJYGUZTGOI). You are receiving this because you authored the thread.Message ID: ***@***.***>

[OzGav]

If you have fixed the tagging problems then please restart the server, recreate the problem and then attach the log here

[wolfsongz]

I can't access the logs.

[OzGav]

If you can access the logs now then have a look for clues with this problem