Yeah, I've completely rebuilt the server 3 times now with the same issues.  Its got me baffled.  Thanks for looking at it. :)

oh .. then maybe you should delete the database with your old peers ..
  rm -rf .BitSharesX/peers.leveldb/
and let the client fetch new peers from the seed nodes ..

besides that I have no clue :-(

Quote from: xeroc on September 15, 2014, 04:34:09 PM

Quote from: Xeldal on September 15, 2014, 04:31:59 PM
right. I don't use this wallet for anything but the delegate.

How else can you produce blocks without setting block production true. 

Maybe I'm not understanding what your saying.

once you have an active delegate that produces blocks ... the wallet does not scan incoming transaction weather they are intended for you or not .. so if you wanted to "trade" or "transfer" funds from within that wallet you will certainly fail seeing it in the transaction history .. as a result the funds seem lost/not transfered ...

isn't that the issue you are having?

If you really want to use the wallet as a regular user (non-delegate) .. you should not have a delegate imported and should also therefor not habe block production enabled ... then everything should work as intended

All the other issues I'm having are with a separate wallet.  Widows gui v0.4.15a.  completely separate. different machines etc.  I'm only speaking about the Ubuntu 14.04 VPS delegate wallet here. : )

Quote from: Xeldal on September 15, 2014, 04:31:59 PM
right. I don't use this wallet for anything but the delegate.

How else can you produce blocks without setting block production true. 

Maybe I'm not understanding what your saying.

once you have an active delegate that produces blocks ... the wallet does not scan incoming transaction weather they are intended for you or not .. so if you wanted to "trade" or "transfer" funds from within that wallet you will certainly fail seeing it in the transaction history .. as a result the funds seem lost/not transfered ...

isn't that the issue you are having?

If you really want to use the wallet as a regular user (non-delegate) .. you should not have a delegate imported and should also therefor not habe block production enabled ... then everything should work as intended

right. I don't use this wallet for anything but the delegate.

How else can you produce blocks without setting block production true. 

Maybe I'm not understanding what your saying.

GOTCHA:


******** Lock old VPS wallet

wallet_delegate_set_block_production delegate.xeldal true


the wallet is NOT parsing transactions when you have an active delegate / ie block production enabled.

delegate wallets are NOT meant to be 'for-use'!!!


Either you run a second wallet independently or you enable transaction scanning by hand
wallet_set_transaction_scanning treu


@running via root .. that's only an issue if you didn't trust DSL or I3 .. because they could introduce malware easily if you run the wallet as root ..
it will work as regular user also

I initially was running v0.4.15a but I was getting both the loss of all connections as well as random missed blocks so I decided to try going back to v0.4.15 but I got the loss of connections there as well.

With the latest build I've done nothing unusual.  Here is my process. I run a DO VPS 4GB RAM

sudo apt-get update
sudo apt-get install cmake git libreadline-dev uuid-dev g++ libdb++-dev libdb-dev zip libssl-dev openssl build-essential python-dev autotools-dev libicu-dev libbz2-dev libboost-dev libboost-all-dev ntp

git clone https://github.com/dacsunlimited/bitsharesx.git
git clone https://github.com/Bitsuperlab/operation_tools.git
cd bitsharesx
git checkout v0.4.15

git submodule init
git submodule update
cmake .
make

cd ~/bitsharesx/programs/client
screen -S delegate

./bitshares_client --server --httpport 9989 --rpcuser user --rpcpassword pass


******** wait for chain to sync

wallet_create xeldal

unlock 99999999

wallet_import_private_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


******** Lock old VPS wallet

wallet_delegate_set_block_production delegate.xeldal true

******** exit delegate screen (Ctrl + A + D)

screen -S feeds
cd ~/operation_tools/btsxfeed/
nano config.json.sample

******** edit with delegate info etc
******** save to config.json (F3)
******** exit nano (Ctrl X)

./btsx_feed_auto.py USD BTC CNY GLD

******** exit feeds screen (Ctrl + A + D)



for this most recent version I decided to not run the feeds to narrow down what could be causing the random connection loss and random missed block.  I still got the connection loss so that is not it.

Please let me know if there is anything you notice in this process that may lead to error.  It has worked flawlessly on prior versions.
I also limit the connections to 20 , this has seemed to help with these issues in the past.

network_set_advanced_node_parameters { "desired_number_of_connections": 20, "maximum_number_of_connections": 20 }

Quote from: xeroc on September 15, 2014, 04:20:00 PM
wow .. you are running this as ROOT?? not recommended!!
besides that it looks ok to me although your fc_revision_age looks rather 'old'

have you run "git submodule update" too? or are you running the windows binary?

I am fairly new to linux.  Can you explain how I would use something other than root? thanks.
Is it as simple as just loging in as anything else?

wow .. you are running this as ROOT?? not recommended!!
besides that it looks ok to me although your fc_revision_age looks rather 'old'

have you run "git submodule update" too? or are you running the windows binary?

"client_data_dir": "/root/.BitSharesX",
  "client_version": "v0.4.15",
  "network_num_connections": 15,
  "network_num_connections_max": 20,


xeldal (unlocked) >>> about
{
  "blockchain_name": "BitShares X",
  "blockchain_description": "Decentralized Autonomous Exchange",
  "client_version": "v0.4.15",
  "bitshares_toolkit_revision": "26ea35eb21d67763ade4d2344afced0d60f7fbd2",
  "bitshares_toolkit_revision_age": "38 hours ago",
  "fc_revision": "3ee5f756fbbb0bd115442eceac2273c060d6b21a",
  "fc_revision_age": "64 hours ago",
  "compile_date": "compiled on Sep 15 2014 at 09:41:21"
}


could you check with "getinfo" that you are REALLY running 0.4.15?

v0.4.15
Just lost all connections again
-- there are now 28 active connections to the p2p network
--- there are now 29 active connections to the p2p network
--- there are now 30 active connections to the p2p network
--- there are now 29 active connections to the p2p network
--- there are now 30 active connections to the p2p network
--- there are now 29 active connections to the p2p network
--- there are now 0 active connections to the p2p network
--- there are now 1 active connections to the p2p network
--- there are now 0 active connections to the p2p network
--- there are now 1 active connections to the p2p network


Quote from: tonyk on September 15, 2014, 08:10:02 AM
Downloaded  0.4.15 x86.

For the first time Kaspersky did not flag it as 'potentially dangerous software'. I do not know if it because of the code itself, or because I have downloaded 14 of the 16 versions before that...

Or they finally added it to their safe list.

Downloaded  0.4.15 x86.

For the first time Kaspersky did not flag it as 'potentially dangerous software'. I do not know if it because of the code itself, or because I have downloaded 14 of the 16 versions before that...

upgrated

x.ebit rose.ebit

:D

0.4.15-a , missed another block, 17 - 19 connections. no idea.