shit, i was too early too happy.
the folder was rescanning.
then i removed it.
now its back again as STOPED 
i guess i need to let it scan up to 100% (it takes 12 hours ) then i can remove it, hjopefully
REMOVING the shared (receive only) folder in Syncthing GUI, it seems to only delete the .stfolder , can this be true?
when i restart SC, the folder is back and STOPPED.
how to get rid of it? ( to reAdd it with the right folderdiscription?
Removing the folder from within the syncthing UI causes syncthing to “forget” about it. This includes deleting the folder marker, yes.
It’s not clear to me what you’re trying to achieve. The docs clearly explain that the folder marker must always be there. You shall never delete it, that will always cause the folder to stop.
https://docs.syncthing.net/users/faq.html#marker-faq
If you want to remove a folder from within the syncthing UI, click on the folder, press Edit and then Remove.
1 Like
i reactivated my RASPI and SYNOLOGY and wanted to reConnect them again with syncthing, the Folder ID’s of one huge folder were not the same, i think i have forgotten to match it when readding a folder.
icalso had deleted the .stfolder when cleaning the files.
so one folder got STOPPED
i was able to REMOVE it in SC GUI, then SC gave me an error. i restarted SC the folder was back. i deleted it, restarted, folder is always back. i was not able to rescan it.
i followed your advise, recreated an .stfolder, was abled to rescan it. it takes 12hours or more. so i clicked PAUSE, and EDIT, REMOVE. the folder is always back in the GUI.
at the end i need to get the STOPPED error fixed, and the Folder ID matched at both SC sides.
Thats my goal 
thank you very much for your patients
its scaning since yesterday, its only at 7% now, outch… i would really like to make it quicker somehow
i moved all files inside my shared folder “o” to another location,
let it rescan, so the scan would be very quick.
but it just does not come to an end
at the end, i just want to rREMOVE the folder from the GUI (to reAdd it with the right folder ID, matching the senders folder id)
It’s not clear to me what you’re trying to accomplish or what the problem is. Nothing will be faster by deleting Synchting’s database, but things will certainly break.
Press “edit” on the folder, then “remove”. Then restart Syncthing to be sure that it clears out the information from the database.
Yeah, I don’t know. I see you’re running the 32 bit version, which is not great for larger amounts data. Maybe check the logs, see what it says.
can i run a 64bit version on raspi?
i have emptied the folder, rescanned it.
it still comes back when REMOVEing it and restarting SC.
can i somehow delete it from SC database?
It’s not in the database, it’s in the config file. If you remove it from the GUI and it comes back on a restart I have no idea what’s going on. I’ve never seen that happen. I suspect Syncthing maybe doesn’t have write permissions to the config file.
i had write permissions all time in the past.
can i just remove the folder in the config file?
could that solve my prob?
(hope i find the config file 
)
in my database folder i also do have 3000k small ldb files. (its 7,2GB now) can i purge, reDo my database, is there any optimization that you could advise me?
I did remove it from the CONFIG file, the folder is gone now.
I do add the folder again and let it scan. first with just few files in it, then with more or all.
QUESTION: is there a way to optimize the SC database? is it necessary?
thank you in advance!
QUESTION: is there a way to optimize the SC database? is it necessary?
to purge it? rebuild? defragment somehow?
Syncthing provides a –reset-database option for purging its database.
Syncthing offers the option to tune how it uses its database, but I suspect that you are asking about doing what is common procedure for relational databases.
For the latter, the storage engine underneath LevelDB is nothing like the ones for PostgreSQL, MySQL, DB2, MS SQL, SQLite, etc.
In a nutshell…
(If you are familiar with managing a Apache Cassandra database, the following concepts are very similar.)
With LevelDB, new changes cached in RAM are written to a log file (files named *.log found in Syncthing’s index-*.db directory). Then at a specific threshold, the contents of the log file are flushed to a new SST file (the *.ldb files).
Once written, no further changes are made to a SST file. If compaction kicks in, the contents of a SST file are written to a new SST file in the process.
One benefit is avoiding file fragmentation. However, if the underlying filesystem is heavily fragmented, so will Syncthing’s *.log and *.ldb files due to a lack of contiguous filesystem blocks. There’s nothing that Syncthing can do about it. The choice of storage medium, filesystem and operating system for the database can be very important the more files there are being synced and the more frequently there are changes to the database.
1 Like
For what it’s worth I remember a problem from years back with database sprawl on 32 bit systems, I don’t recall if or how it was solved, perhaps some searching might yield something.
Right, Many small LDB files with database tuning. We handle this correctly in the auto case, make sure you haven’t manually set the database tuning to large because that won’t work. Or use a 64 bit build for large setups.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.