Multiple artists and/or genres

[655321]

Nope.
I ran:

docker run -d \
--name=lms \
--user 1000:1000 \
-e TZ=Europe/Berlin \
-p 5082:5082 \
-v /mnt/music:/music:ro \
-v /opt/lms:/var/lms \
--restart unless-stopped \
epoupon/lms

Then I logged in via admin credentials, entered /music and hit scan:

Same result as before.

Here are the logs from the container:

[2023-Oct-25 14:19:40.884] 1 - [error] - 140646178478904 [DB UPDATER] Cannot process entry '': No such file or directory

[2023-Oct-25 14:19:40.886] 1 - [info] - 140646178478904 [DB UPDATER] Scan complete. Changes = 0 (added = 0, removed = 0, updated = 0), Not changed = 0, Scanned = 0 (errors = 1), features fetched = 0,  duplicates = 0

[2023-Oct-25 14:19:40.886] 1 - [info] - 140646178478904 [DB] Analyzing database...

[2023-Oct-25 14:19:40.887] 1 - [info] - 140646178478904 [DB] Database Analyze complete

[2023-Oct-25 14:19:40.887] 1 - [info] - 140646178478904 [DB UPDATER] Auto scan disabled!

[itm]

Ok but in music you can list/read files and perms are correct?
Can you try to change log-config in lms.conf and set it to “*”?

[655321]

@itm

Ok but in music you can list/read files and perms are correct?

Certainly looks like I have read permissions within the container.

@itm

Can you try to change log-config in lms.conf and set it to “*”?

Where’s that file located?

I don’t see it in the persistent folder.

Edit:
This is how I connected to the container cli within portainer. However I doubt that it influences the permissions:

Edit 2:
I managed to supply an altered lms.conf file like this:

docker run -d \
--name=lms \
--user 1000:1000 \
-e TZ=Europe/Berlin \
-p 5082:5082 \
-v /mnt/music:/music:ro \
-v /opt/lms:/var/lms \
--restart unless-stopped \
epoupon/lms /var/lms/lms.conf

btw: The container seems to ignore the -e TZ=Europe/Berlin part. Logs are still off by 2 hours for me.

lms.conf

# LMS Sample configuration file

# Path to the working directory
# Must have write privileges in order to create and modify this directory
working-dir = "/var/lms/";

# ffmpeg location
ffmpeg-file = "/usr/bin/ffmpeg";

# Log files, empty means stdout
log-file = "";
access-log-file = "";
# Logger configuration, see log-config in https://webtoolkit.eu/wt/doc/reference/html/overview.html#config_general
log-config = "*";

# Listen port/addr of the web server
listen-port = 5082;
listen-addr = "0.0.0.0";
behind-reverse-proxy = false;

# If enabled, these files have to exist and have correct permissions
tls-enable = false;
tls-cert = "/var/lms/cert.pem";
tls-key = "/var/lms/privkey.pem";
tls-dh = "/var/lms/dh2048.pem";

# Path to the resources used by the web interface.
wt-resources = "/usr/share/Wt/resources";
docroot = "/usr/share/lms/docroot/;/resources,/css,/images,/js,/favicon.ico";
approot = "/usr/share/lms/approot";
# Location for deployment (See README if you want to deploy on a non root path)
deploy-path = "/";

# Number of threads to be used to dispatch http requests (0 means auto detect)
http-server-thread-count = 0;

# ListenBrainz root API
listenbrainz-api-base-url = "https://api.listenbrainz.org";
# How many listens to retrieve when syncing (0 to disable sync)
listenbrainz-max-sync-listen-count = 1000;
# How often to resync listens (0 to disable sync)
listenbrainz-sync-listens-period-hours = 1;
# How many feedbacks to retrieve when syncing (0 to disables sync)
listenbrainz-max-sync-feedback-count = 1000;
# How often to resync feedbacks (0 to disable sync)
listenbrainz-sync-feedbacks-period-hours = 1;

# Acousticbrainz root API
acousticbrainz-api-base-url = "https://acousticbrainz.org";

# Authentication
# Available backends: "internal", "PAM", "http-headers"
authentication-backend = "internal";
http-headers-login-field = "X-Forwarded-User";

# Max entries in the login throttler (1 entry per IP address. For IPv6, the whole /64 block is used)
login-throttler-max-entries = 10000;

# API
api-subsonic = true;

# Use this list to make the reported server version to 1.12.0 depending on the client's name
# Main usage is to make auto detections for the 'p' (password) parameter work
api-subsonic-report-old-server-protocol = ("DSub");

# Turn on this option to allow the demo account creation/use
demo = false;

# Max external cover file size in MBytes
cover-max-file-size = 10;

# Max cover cache size in MBytes
cover-max-cache-size = 30;

# JPEG quality for covers (range is 1-100)
cover-jpeg-quality = 75;

# Preferred file names for covers (order is important)
cover-preferred-file-names = ("cover", "front" );

# Playqueue max entry count
playqueue-max-entry-count = 1000;

# Set to true if you want to hide duplicate tracks
scanner-skip-duplicate-mbid = false;

# Scanner read style for metadata, maybe be 'fast', 'average' or 'accurate'
scanner-parser-read-style = "accurate";

These are the complete logs from starting the container, logging in, supplying /music as the root and hitting scan.
_lms_logs.txt (15,7 KB)

[655321]

@itm so is there anything else I can try? Otherwise I’ll bench using lms for now.

[itm]

From the logs, it looks like the root media directory is not set.
I guess you directly started the scanner without saving changes first?

[655321]

That’s hilarious and sad at the same time.

From the layout it looked to me like “Apply” only affects the “Tags” section of “Scan options”, which I did not change and thus I did not think of hitting “Apply” there.

Now it’s merrily scanning away.

[itm]

Indeed poor UI, will try to better isolate the scanner

[655321]

It managed to finish and the 3 errors it found were actually three 5KB tracks where something somewhere at some point went wrong. I was able to replace/fix all of them.

To put it mildly, with my amount of files the UI is laggy.

Or in other words: upon logging in the site freezes/loads for over 2 minutes before displaying random albums.

I’ll test how quick rescans are and also how it performs when used as a source for symfonium. On its own it is sadly not usable with my amount of files.

[itm]

Thanks for testing!
Does restarting the service actually help?

[Tolriq]

Ho yes I mentioned that to Itm when I tried after scanning the 300 000k songs I had to restart the server for it to work at normal speed.

[655321]

@itm

Does restarting the service actually help?

It does help. The site now loads after a few seconds. However “normal” use is still pretty much out of reach.
When searching for an artist and clicking on the result it takes 30+ seconds until the artist is loaded.

Rescan was quicker but still slower than jellyfin (that takes 15ish minutes).

And syncing Symfonium took 1,5 hours. Also a bit slower than jellyfin (takes around 1 hour).

So to sum up it’s a viable alternative to jellyfin, however it’s not really usable on its own via the GUI (same goes for jellyfin) and jellyfin is as of yet faster.

Edit:
Considering that the restart increased the performance I’ll redo the rescan and sync to symfonium to be sure that I give it the best possible shot.

[itm]

Thanks for this feedback. Will try to generate a big fake database locally to try to optimize.
Will tell you!

[655321]

@655321

Considering that the restart increased the performance I’ll redo the rescan and sync to symfonium to be sure that I give it the best possible shot.

That yielded no significant improvement so for now I’ll stick with jellyfin as the source for Symfonium.

@itm

Will tell you!

I’d be happy to test future versions. Stresstesting music players/servers has become kind of a hobby of mine ever since iTunes started collapsing when my collection was at ~100k tracks over a decade ago which made me look for alternatives.

[itm]

What are your server specs btw?

[655321]

The fileserver is running an Intel Xeon E5-2620v4 with 128GB of DDR4 2133 ECC RAM. The music resides on a 8x 8TB Z2 ZFS pool in TrueNAS Core.

The docker host runs an Intel i7 2600 with 16GB DDR3 1333 RAM (I look to replace it with a newer, faster machine with more RAM soon). That PC runs proxmox, which hosts a ubuntu server VM and within that I deployed the docker container. It has a 1GBit/s LAN connection to the file server. While scanning, none of the CPU cores are close to full load so I’m not sure if the compute performance of that PC is a limiting factor but it might be.

[itm]

Thanks!
The scanner is currently mono threaded, no effort has been put on it to make it faster (it is even scanning using the taglib’s “accurate” mode, the slowlest one). Will tackle this later, I already have some ideas.

What worries me now is the responsiveness of the UI. I tested on my old i5 3470 using a fake database of 1.8M songs and all the UI has sub second response times except for:

• searches by name, which are really slow when a lot or matches are found
• artist and album views, which are really slow (about 8s) because of the current similarity engine which does not scale.

Will try to make a version in which you can disable the similarity engine, to make sure there is no other problem.

[itm]

@655321 would you mind testing the docker 083652e image?
Warning: the db schema changed and is not backward compatible with 3.42.1
Once restarted, go to the media collection settings and disable to similarity engine. Apply and then restart the service.
Then the UI should always stay reactive in all views/tabs and even when searching.
If it is not the case, stop the service, run sqlite3 on the db and issue the analyze; command. And test again (I tweaked analyzis limit because value was too small)
Thanks!

[655321]

@itm

Apply and then restart the service.

Applying triggered a rescan. So I guess it’ll take a while.

@itm

would you mind testing the docker 083652e image?

I deleted the previous container and redeployed via:

version: '3.3'
services:
    lms:
        container_name: lms
        user: '1000:1000'
        environment:
            - TZ=Europe/Berlin
        ports:
            - '5082:5082'
        volumes:
            - '/mnt/music:/music:ro'
            - '/opt/lms:/var/lms'
        restart: unless-stopped
        image: epoupon/lms:083652e
        command: /var/lms/lms.conf

@itm

Warning: the db schema changed and is not backward compatible with 3.42.1

It didn’t seem to care, when I started up the new container it still showed me my albums.
Or should I have deleted the old database manually before redeploying?

[itm]

Yes applying triggers a rescan, which not needed in this particular case, hence the “then restart the service” to make it stop.

It’s fine to remove the container, since the db is stored within the persistent /opt/lms volume.

The db has been migrated to a new schema (you keep all your data), what I meant is that you won’t be able to run v3.42.1 using this db once the db is migrated, but I guess you don’t care

[655321]

@itm

Yes applying triggers a rescan, which not needed in this particular case, hence the “then restart the service” to make it stop.

I let it finish anyhow (I’ve added a couple hundred songs since the last scan).
Also now it scanned a lot quicker than last time. Might be because I updated and restarted the VM host.

The time is still off by 2 hours btw. so the container still ignores this:

environment:
            - TZ=Europe/Berlin

@itm

The db has been migrated to a new schema (you keep all your data), what I meant is that you won’t be able to run v3.42.1 using this db once the db is migrated, but I guess you don’t care

Thanks for clearing that up.

@itm

Then the UI should always stay reactive in all views/tabs and even when searching.

Indeed. I mean the covers load in slowly but that’s to be expected as each is usually 1400px+, often 2+MB per image. Otherwise it reacts within a few seconds, which is impressive.

One thing I’ve noticed now after searching a couple of artists is that it doesn’t recognize/use all of my multi value album artists.

Looking at the documentation I see that you only support albumartists albumartistssort as of yet.
My collection predates these tags and I’ve mainly used ; as a separator/delimiter for multi value tags. And lately I’ve also used multiple albumartist tags (which in mp3tag are shown as separated via \\). Upon further testing lms correctly uses multiple albumartist tags. Only those with ; aren’t recognized.

Do you plan to let the user choose 1 (or more) custom delimiters/separators to be used as well as albumartists & albumartistssort?
Jellyfin, MusicBee, Mediamonkey and Symfonium (with local files) all correctly recognize my multi value tags.

Edit:
Another thing I’ve noticed is that lms sometimes gets confused with multiple albums having the same name but different artists.

For example it lists the album “Home” by Delaney & Bonnie

Which has these tags.

under Butler, John instead of the actual album:

It also mixed the album “Flesh & Blood” by Maddy Prior in-between the album of the same name by The John Butler Trio.

I don’t even want to think about what kind of shuffling it’ll do with the album “Live” considering that I have 1634 tracks of different artists that have this exact album title.