-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Soulseek lost configuration after VM crash. #60
Comments
@HairyOtter, I've not seen screen issues or unresponsiveness in the way you describe them. Is the performance bad when you start a clean instance? |
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.
@HairyOtter It appears the full config is present in all three files. Perhaps try without the most recent (possibly corrupted) file present. |
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.
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. |
after "docker restart soulseek",i lost all my new config. why....... |
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 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. |
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 |
Is this still true? After updating the container today vnc only showed a black window. Taking a look at the logs revealed: I changed nothing in my compose and neither PUID nor PGID are set.
As my music folder is mounted read-only on the VM level, trying to chown every music file is pointless and time consuming. Is there a way to prevent it from doing this? |
@AverageHoarder, this has been changed. People have had issues with downloading files when the container process that runs Soulseek tries to write to mounted folders. This is why, at the moment, when starting the container, the container user is assigned the PUID/PGID IDs, and folders and files get their ownership and permissions updated to match the UMASK and IDs: Happy to take any suggestions on improving this. |
A solution would be to only try to claim ownership of folders that will actually be written to. Which is not true for the shared folder that works perfectly fine read-only. However I'd already be happy if there was an environment variable to globally skip changing ownership of any folder as it's not needed for a correctly configured setup. That would restore the previous behavior when not specifying a PUID and GUID. |
The ubuntu 22.04 VM on my truenas core server recently crashed and now Soulseek wants me to re-enter my credentials, has lost my user list, chats, shares etc..
I've looked in the /data/.SoulseekQt folder and there are 3 files named soulseek-client.dat+a lot of numbers as the extension. They range from 48MB to 89MB in size. Opening one of them in a text editor confirmed my suspicion that they contain the user list and everything else I've "lost".
Is there a way to restore one of these files? I had hundreds of users in my list and even rescanning my shares alone would take literal days.
Also the performance was always bad (often freezes for literally 20+ seconds before it registers a keypress or click) but now it's even worse. I've recreated the container with the latest image, restarted both server and VM but nothing seems to resolve the performance issues.
Example image of a freeze:
Is that expected behavior? I've given the VM 4C8T of my Xeon, 16GB of DDR4 RAM and 150GB of m2 SSD storage.
The text was updated successfully, but these errors were encountered: