Repeated Errors

On Windows 10, I am getting the following error repeatedly.

That means that either Syncthing is not running, or it is running but not accepting HTTP connections on port 8080.

I believe the current default port is 8384, so try connecting to 127.0.0.1:8384

Thanks for the response. The problem is every few minutes I get this message and then it starts working on its own without any action from my side. It starts scanning and then again does this.

I have been using Syncthing on this system since many months and have started facing this issue only since the last few days. Windows 10 was updated on 29th July so its been running well even under Windows 10 for a month before this error started cropping up.

If you know how to use chrome debugging tools, print screen the network tab and post it here, with the failing network request selected for details.

Is this what you are looking for?

maybe a service or something else is listening on the same port? Have you tried running Syncthing on a different port, e.g. 9090?

Tried with 8081, still the same issue. Keeps coming on and off.

Can you take a peek in the config directory (somewhere in your profile) and see if there’s a panic log of some kind?

There are many panic logs there

Since the first panic log was with Version 22, I replaced that with Version 21 and also stopped it from auto updating. But now I am getting the same error in Ver 21 also. I was just trying to check if it a version issue. Please find attached the last and the first panic log

panic-20150827-105045.log (6.9 KB) panic-20150831-181203.log (85.6 KB) Blockquote

panic: leveldb/table: corruption on data-block

you can try to reset the Syncthing index cache: shutdown Syncthing, delete/rename the index-v0.11.0.db folder in your Syncthing profile and start Syncthing. It will rescan/index all files again. If the logs show a similar error again, your disk is probably failing

@calmh can Syncthing recover from this automatically?

Not in this case, no. The database is corrupt. Usual suspects are bad memory and bad disk. :confused:

Thanks, I did what you said and it seems to be working fine. However, I am not facing any issues with the disk or memory. Not sure what must have gone wrong. Thanks for the help.

Not to pick on you personally - but people keep saying this and variants of it, when reading bad data from disk is exactly that. :wink: It’s just that most programs and filesystems don’t actually verify that what they read is what it’s supposed to be, so much corruption goes unnoticed until something crashes completely.

No offense taken. I am a fairly advanced user and haven’t been seeing any issues with my disk or memory. Th reason I made that comment was to let the team to know that so that alternative reasons can be evaluated.

Yeah, noted. Thing is, we’ve been hunting for this one for a long time, looking in all the dark and nasty places for a bug that would cause it. It’s difficult to trigger on demand (for analysis) and none of us developers have ever seen it in person. The maintainer of the database library has managed to reproduce it once or twice during stress testing on a VM, and noted that the corruption in those cases were single bit flips on the data - something typical of memory problems and unlikely to be caused by a software bug.

In the few support instances here on the forum where it has been resolved, it’s been fixed by replacing a broken disk, disabling a “weird” hybrid SSD disk caching driver and in one case by replacing memory (IIRC). The rest of the cases have never been resolved…

But it also seems to be the case that most users never see this, and the ones that do see it fairly regularly on their machine. So at the very least it seems tied to something very machine specific, be it OS, drivers or hardware.