Soulseek lost configuration after VM crash.

[realies]

Soulseek lost configuration after VM crash.

[realies]

@HairyOtter, soulseek-client.dat.timestamp files appear to be the application settings that are backed up every so often on the filesystem. Not sure why the client is not recognising them unless they are improperly mounted or there is filesystem data corruption.

I've not seen screen issues or unresponsiveness in the way you describe them. Is the performance bad when you start a clean instance?

[HairyOtter]

These are my mounts. The user config is mounted to storage within the VM so I doubt that it would cause problems as the VM storage resides on a raidz2 pool with zfs which does error correction and scrubs once per month. Unless the VM itself corrupted the data, which would be unfortunate.

The performance has been really bad for me ever since I started using soulseek in docker months ago. It often freezes and creates these weird window effects until it reacts again.

I set up a new container that pointed to empty directories within the VM. This one was responsive.

I then pointed it to the existing folders of the old container. Didn't start but I got a "CIFS VFS: Close unmatched open" error on my VM which makes me suspect that something with my share mounts isn't working properly.

As a last step I used the existing appdata + logs folders of my old container but pointed "shared" + "downloads" to empty directories within the VM to avoid the SMB mounts. That started up and was responsive, but sadly neither my chats nor anything else of my config showed up. Which is odd since I can browse to the logs and see the individual chat files from within soulseek.

I don't know why it refuses to recognise the existing logs + config files. I'll do further testing with the SMB mounts. I'll report back if I find something reproducible.

[malventano]

soulseek-client.dat.timestamp files appear to be the application settings that are backed up every so often on the filesystem.

Any idea why these contents are only updated 'every so often'? I've noticed that restarting the container loses any recently changed config, queued downloads, etc. Perhaps SoulseekQt is not shut down cleanly when the container is stopped or restarted?

edit I didn't realize update frequency was in the UI config. Confirmed updates are more frequent if changed.

Is there a way to restore one of these files?

@HairyOtter It appears the full config is present in all three files. Perhaps try without the most recent (possibly corrupted) file present.

[HairyOtter]

It appears the full config is present in all three files. Perhaps try without the most recent (possibly corrupted) file present.

I did that with a copy of the secondmost recent config file and got it working again. But only to a degree. Now it refuses to start when I add back the volume for my shared music folder.
I have mounted my music folder in the ubuntu VM as read-only (there's no need for soulseek to write to the files that I share) and it used to work like this.
Although I changed this share in no way, the container plays dead every time I add it and redeploy.

To test if the SMB share was at fault I also created an NFS share of the same folder (also read-only) and mounted that.
Now all soulseek does on start is display

"chown: changing ownership of "/data/Soulseek Shared Folder/: Read-only file system"
for every single file in my shares in the log. I think it's attempting to take ownership over the files needlessly and fails because they are read-only. As I have close to a million files in my share folder I wasn't patient enough to see if it only attempts that once for every file or starts over when it reaches the end as that could take literally half a day.

My old samba share is accessible from within the VM, as is the new NFS share. I've also just browsed to the mounted volume from within the container's cli and confirmed that I can freely browse all the folders and files within. I've also given the new soulseek container the same UID and GID as the old one and used the exact same mount points. I don't know why it refuses to start with my old share mounted and why it insists on taking ownership of every single file with my new share although both the NFS permissions as well as the volume permissions tell it that the volume is read-only.

Is there a way to prevent it from trying to take ownership of my shared files?

Update:
Removing the GUID and UID completely (noticed they were optional) resolved the issue with the NFS share. Once it's done rescanning my shares I'll switch it back to the SMB share and see if that also works now.

Also the very laggy experience seems to be due to the amount of files that I share. When the shares weren't working the program was responsive. Now it's back to waiting for 10+ seconds for it to register a click. Sad as the VM storage is on an m2 ssd, I've given the VM 16GB of RAM and 4 Cores + 8 Threads of my Xeon. Surprising that it still lags this bad. But I'm happy that it works again at all.

[malventano]

Removing the GUID and UID completely (noticed they were optional) resolved

Yeah I made that same mistake initially - if set, the container will do a chown -R across its mounts on every startup, which takes a while.

Also the very laggy experience seems to be due to the amount of files that I share.

That's likely less the fault of the docker and more just how SoulseekQT works. It's not really multithreaded at all and will get bogged down with indexing large shares. If you ever switch over to TrueNAS Scale, maybe try running the docker on bare metal instead of in a VM. Might help a bit.

[17huiwei]

after "docker restart soulseek",i lost all my new config. why.......

[HairyOtter]

if set, the container will do a chown -R across its mounts on every startup, which takes a while

The weird part is that my SMB share was also always read-only and it used to work like this while having a GUID and UID defined without spamming the "chown: changing ownership of "/data/Soulseek Shared Folder/: Read-only file system" on startup (I still have my old container untouched).

That's likely less the fault of the docker and more just how SoulseekQT works.

That's why I'm currently checking out slskd to see if it performs better with my amount of files. I'll report back with any additional findings.

[realies]

Soulseek saves its config file periodically, and the interval is outlined in its settings. Unfortunately, I can't replicate the UI bug in the screenshot. If GUID and PUID are not set, it will not chown the mounted shares. Please feel free to comment on this issue if you have any related updates.