Shared folders will not update

I set my shared folders to

  Code:

/library/torrent/downloads/2020
/library/torrent/downloads/2021

.
The latter folder would not populate despite the files having similar permissions and the directories having the same permissions/owners.

I tried to change the shared folder to the parent directory of the two above, i.e., /library/torrent/downloads multiple times but all that happens is that I change the shared folder, click save, and there's a spinning animation intimating that Serviio is doing something, when, in fact, it is not. I go back a day later and the spinning animation is still there and when I click cancel, there's no change.

I understand there's no "configuration file" I can access so aside from removing Serviio, how do I get around this most basic of issues?

[atc98092]

Have you looked at the Serviio log? Under Windows, it's found in C:\Program Files\Serviio\Log. Under a different OS, it will be found in the same folder structure where Serviio was installed. There's two files in that folder, labeled Derby.log and Serviio.log. Only need to see the Serviio log.

No, I didn't think to look there for a log. Thanks for the tip. On my install it is /opt/serviio/log/serviio.log

Well, I don't know how the log files are getting rotated, but none of them were compressed so I manually did a log rotate w/compression.
I restarted after seeing some really weird directory recursion that appeared to be a result of WINE (which I corrected), it still doesn't seem to want to listen to me about what directory I want it to look in.

As for my log file? Let me see what it else it contains besides UUIDs, ethernet device info, ip address, every file i'm adding...

Oh, now it is going through and removing everything. I need to wipe out the database and start over... also, I need to know how to get it to stop following symlinks!

[atc98092]

The best way to wipe the DB is to just remove Serviio and make a clean install. Once the DB gets messed up, it's not worth the effort to attempt anything.

I would tend to agree with you on the rebuild thing: my old /library/.serviio/library (which was symlinked to /opt/serviio/library) is 5.7 GB... two orders of magnitude smaller, the entire /opt/serviio on the new install is 58 MB (including an unlinked /opt/serviio/library). FWIW: /opt is on an SSD; /library is on a 4 TB HDD.

I think what was happening is that there was a recurse going on that caused real problems...and presumably a ton of duplicate entries.

  Code:

2021-09-10 21:38:53,692 WARN  [MetadataExtractionCoordinator] Skipping processing metadata for an unsupported file (/library/torrent/downloads/2020/Ebooks Collections 19 Jan 2020/drive_c/users/winuser/My Documents/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/drive_c/users/winuser/Downloads/books/00-incoming/dosdevices/z:/proc/1/cwd/library/backup/root-incremental-daily/usr/lib/grub/x86_64-efi/bitmap.mod). Message: Unknown video file type.


So all the drive_c/users bullshit is from WINE as is the dosdevices directory. Why it recursed the one WINE directory in /library/books/00-incoming, I don't know, but it appears that 'drive_c/users/winuser/My Documents' was symlinked to ~/books which is itself symlinked to /library/books. The dosdevices/z:/proc/1/cwd/library/backup/root-incremental-daily/usb/... is also a symlink. Not sure why z: is showing proc/1/cwd/... but he whole dosdevices directory is basically just a symlink interface for WINE to interact with the local file system. Preventing Serviio from following symlinks would probably prevent this.