If you want, you can PM me your IP, and I can try to connect my node to yours. Maybe my side will have some more info in the debug log.
2 Likes
I do the db location change through config.yaml, so it is true that I need to copy from both locations separately (and already forgot once). Although, you can also create a junction, and that will work as you want still having files on a separate drive.
For some reason, my feeling is that on Win the same drive performs differently when used as a boot vs. a different drive (yeah, it was a bug earlier with Win 11, and not sure whether it got fully fixed). My node is just a wimpy i5 8250U (mobile CPU - Gigabyte NUC), so that helped it a bit.
As far as that original post, it was just to reuse what he already had on hand, nothing more.
this guy
while ur at it let me get ur ss # so I can sync ur node
actually I do have a GitHub tool that will fix it for you.
will open ur port wide open so all connection flow through,… and non of the bad ones
Lol, he’s asking for an ip.
We all broadcast our ip to the network anyway.
Really little risk here.
@jacek is OK, he’s helped many many here, nothing nefarious going on.
2 Likes
PM sent, thanks again!
The v2 database file is already 65 GB! We shall need v3 soon??
1 Like
Really, will need another zip app soon!!!
Thank you for that!
By the way @jonnys setup looks fine, although kind of weird. Port is open, and when I first time tried to manually connect, I got in my logs few connected / closed / disconnected sets in a quick sequence, although no reason for that (yeah, there was a normal disconnection, so there was no error). However, on my third try after a couple of those sets, the last one was successful!! And the connections stays stable (nodes are exchanging data). He is still checking his log whether there is more info about why my first connections were dropped. Maybe that will shed some light.
However, it means that ISP, router, firewall are all good, as nothing was blocked or forcefully aborted. It looks that the fact that ISP acted up was just a coincidence (not seeing his logs).
It kind of suggests (to me) that this is a similar problem that other people have - it takes really long time to get up to the specified max connections, and potentially for some the process is really painful. I think that this is a fairly new bug.
By the way, it would be good for someone that has similar problems to post it on github. Although, one may consider it as a feature that helps during dust storms for those low spec nodes 
1 Like
the more peers connected the more wallets you will see. I usually have 3 to 5 out of 80 peers.
If you go to your Wallet page, at the bottom there is Connections section. It shows what peers your wallet connects to. How many connections do you have there? I only have one (127.0…).
Me also, just checked only local host 127.0.0.1
1 Like
The reason I asked is that if we have only a local connection, that implies that our wallets are not connecting to other nodes (potentially the local node is a “trusted” one, as such preferred). I saw other peers in that section when I was upgrading to 1.3.1, and my node was still bc syncing and on v1 db.
Saying that, I think that on the Farm page in that Connection section there should be not that many wallets, as potentially only those that are upgrading or are pure wallets (no bc behind) are trying to connect somewhere. So, I don’t really understand how @Normanvelez can get up to 50 wallets connected to his node. Max what I saw on my node was 3 or so. Still kind of high, considering that there are 180k nodes out there and potentially just a small fraction of stand-alone wallets. Also, base d on Chia data only about 1% (or less) of nodes are upgrading to v1.3 daily. So, that is just a couple of thousands of wallets in transition looking for a fast sync.
I would really not want to have my wallet connecting somewhere, if it sits behind my node, regardless how safe that could be.
I don’t think thats ideal…
not wallet !!
peers. you can change number of peers you can connect to in cionfig.yaml file.
i have 3 to 5 which is is standard in config.yaml. please forgive, a typo…