Strange behavior when scanning group folder

[lehboi]

Nextcloud 28.0.14
Music 2.1.1

Music library is a subfolder of a group folder. One user A doesn't see any music track, while two other users see all music tracks.

In Nextcloud log, there is one item after the user A change music library folder:
Warning One of the paths was invalid, erasing the previous collection content

The command music:scan --clean-obsolete gives "Found 0 music files to scan", even after the command user:setting music path

[paulijar]

That sounds weird indeed. Is it so that this user "A" can still browse this subfolder of the group folder via the Files app? And after such browsing, Music still doesn't find the tracks in that folder?

In Nextcloud log, there is one item after the user A change music library folder:
Warning One of the paths was invalid, erasing the previous collection content

There should not be log output exactly like that in the Music app. The closest thing I can think of is the debug level output "Old and new collection paths are unrelated, erasing the previous collection content". This just means that the user has selected a new music collection path which is neither contained in the previously configured path nor the predecessor of said path. For example, the path is first a/b/c and it's changed to be a/d. In that case, it's clear that none of the potentially previously scanned files can be within the new path, and all the previously scanned content should be discarded.

[lehboi]

That sounds weird indeed. Is it so that this user "A" can still browse this subfolder of the group folder via the Files app? And after such browsing, Music still doesn't find the tracks in that folder?

Yes, user "A" can still browse this subfolder of the group folder via the Files app. And after such browsing, Music still doesn't find the tracks in that folder.

In Nextcloud log, there is one item after the user A change music library folder:
Warning One of the paths was invalid, erasing the previous collection content

There should not be log output exactly like that in the Music app. The closest thing I can think of is the debug level output "Old and new collection paths are unrelated, erasing the previous collection content". This just means that the user has selected a new music collection path which is neither contained in the previously configured path nor the predecessor of said path. For example, the path is first a/b/c and it's changed to be a/d. In that case, it's clear that none of the potentially previously scanned files can be within the new path, and all the previously scanned content should be discarded.

The detail of that log item is:
[music] Warning: One of the paths was invalid, erasing the previous collection content POST /index.php/apps/music/api/settings/user/path from 192.168.1.21 by lhboi at Jan 7, 2025, 10:53:11 AM {"reqId":"s5x9glln98t1t2Ns62vf","level":2,"time":"2025-01-07T03:53:11+00:00","remoteAddr":"192.168.1.21","user":"lhboi","app":"music","method":"POST","url":"/index.php/apps/music/api/settings/user/path","message":"One of the paths was invalid, erasing the previous collection content","userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0","version":"28.0.14.1","data":{"app":"music"},"id":"677f3a9801c80"}

I've run reset-database, then disabled Music app, removed Music app. then re-installed Music app. Still not find any track.

[lehboi]

After changing the path to music collection to '/', Music finds all tracks, including tracks under the group folder.

[paulijar]

The detail of that log item is:
[music] Warning: One of the paths was invalid, erasing the previous collection content POST /index.php/apps/music/api/settings/user/path

Right, that log output actually comes just a few source code lines away from the one which I referred to, but the search function here on Github works in a bit funny way and it got hidden from my results. So my bad.

That error indicates that when Music app tried to fetch the folder matching the configured path, the system responded that no such file or folder exists. The folder not found may be either the one matching the previously configured path or the new configured path; this happens in the context where it is checked what is the relation of the new path to the previous one.

If occ user:setting was used to set the path, then it's technically possible that the path was somehow invalid, for example missing the leading slash /. When selecting the path via the Music app UI, it should be impossible to select an invalid path.

[paulijar]

If the user "A" now changes the music path again to point to the folder under the group folder, does that make the tracks vanish again? Or did the weird behavior now vanish for good?

[lehboi]

If the user "A" now changes the music path again to point to the folder under the group folder, does that make the tracks vanish again? Or did the weird behavior now vanish for good?

User "A" changes the music path again to the folder under the group folder, then the tracks vanish.
But when the user "A" changes the music path to the group folder, Music see all tracks.

[paulijar]

Okay, thanks. I now installed the Group folders app and managed to reproduce the problem: Using the group folder as library path works but using any of its subfolders does not.

My initial assessment is that the function Folder::searchByMime does not seem to work for the folders under the group folder. So likely this is a bug in the Group folders app, but I need to do some more testing when I have more time, before I'm ready to report a bug for them.

[paulijar]

The root cause is now reported to nextcloud/groupfolders#3537.