Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - modprobe

Pages: 1 2 3 4 5 [6] 7
This error is shown when LevelDB throws an error saying the database is locked by another process. The LOCK files in the _db folders do not appear to get deleted by LevelDB under any circumstances (which is weird) and deleting them has no apparent effect.

In practice, the GUI will *only* show this error if the CLI client is running with the data dir the GUI intends to use; when another instance of the GUI is running, it's smart enough to just bring up the old instance of the GUI rather than trying to start a second one and running into this issue.

Are you sure you don't have a CLI client running somewhere?

Yes, this is expected behavior until the softfork occurs later today. After that point you should be able to close your pre-interest margin position, but not before. This is to allow all delegates time to update; otherwise, delegates still on .21 will reject blocks which allow the cover.

General Discussion / Re: Help: insufficient relay fee
« on: October 13, 2014, 02:56:13 pm »
I am unable to reproduce this issue, but the functions placing market orders have been massively refactored already, so when DacSun pulls those changes, hopefully whatever you're seeing will be gone.

Yes, to get fc to interpret the enum name as the appropriate value, it must be enclosed in double-quotes. This is a quirk of how we do the argument parsing (everything is JSON) and there's no good way to fix it.

Yes. Volume measurements are always given in the base asset.

This is not a bug. Prices are defined to have pretty much arbitrarily high precision, as they represent the ratio between two assets, meaning the price needs greater precision than either asset. This command is not intended to be used by humans anyways (except for debugging) so whatever client code is calling it can do any rounding it needs to do.

General Discussion / Re: "insufficient funds" Help Thread
« on: September 23, 2014, 08:10:14 pm »
I don't think its safe to assume wallet_account_balance in the console is correct. In fact, it's almost surely wrong in some cases.

Recently, I installed 0.4.16 32-bit, and after importing a backup wallet, my BTSX and BitUSD balances disappeared. Also, a lot of the recent transactions are now to "UNKNOWN", and some of the transaction history after about a week ago is missing altogether. Regenerating keys, rescanning, etc. did not help.

The console command for wallet transactions history does seems to give the correct ending balance of xxx,000 BTSX. But both the GUI and the console command wallet_account_balance incorrectly display 0.00 BTSX.

I agree.  I just installed a fresh copy, imported via private key, regenerated keys, rescaned, and the balance from wallet_account_balance was way off or missing entirely from what I get if I import from a backup and do the exact same process.

Yes, this is expected behavior. Do not delete your wallet! There is more private data that needs to be kept in order to claim all of your balances than just the account private keys. Primarily, you need the wallet master private key, from which you can regenerate pretty much everything if necessary (though this should be done in emergencies only). If you just create a new wallet and import your account keys, you will not get all of your balances. If you've kept your original wallet, you should have everything you need.

The insufficient funds error you're seeing is hopefully fixed in -- when the next version of BTSX is released, try transferring your balances and see if you still get this issue.

Technical Support / Re: !!! Stupid Questions Thread !!!
« on: September 17, 2014, 06:34:06 pm »
2) How do I quit the client without being asked whether I want to reset the database. Happens about every second time I run it.

If you think you quit the client cleanly (quit cleanly by pressing Ctrl-Q [Command-Q on OSX] or using the Quit menu item), but get this message on the next start, most likely the client crashed on exit and you didn't notice. If this happens reliably, feel free to post a backtrace on GitHub's issue tracker.

Unfortunately, due to limitations in the backend, there is not a way to close the app via RPC. I'm not sure if Windows provides a 'kind' way to request an app exit or not, but yes, if you kill BitShares, it will assume it crashed and offer to nuke the database for you when it starts up again. This is strictly optional, you do not have to do it; just click the "Continue Normally" button and it won't rebuild the database unless it detects corruption in it.

I will look into adding a way to request the client exit by using a new instance as a remote control to a previously running instance. This should give you a nice way to quit BitShares X from your batch file.

Stakeholder Proposals / Re: Delegates SubOptimum Performance
« on: September 16, 2014, 10:50:52 pm »
Yeah, those are my delegates. My VPS host keeps changing the clock drifts on my VMs. It's getting a bit annoying. Fixed for now. Thanks for pointing this out.

Oh, yeah you need to nuke the CMakeCache.txt file (or edit it manually and set the compilers).

I'd be interested to know how to compile with clang myself .. can you give a quick howto?

It's really simple on Arch (but what isn't, really? :D). Just `pacman -Sy clang` and then `export CC=clang;export CXX=clang++` before running `make`.

Hu ... on ArchLinux I am getting this internal compiler error:
Code: [Select]
/home/delegate/bitsharesx/libraries/blockchain/chain_database.cpp: In member function 'void bts::blockchain::cha
in_database::open(const fc::path&, fc::optional<fc::path>, std::function<void(float)>)':
/home/delegate/bitsharesx/libraries/blockchain/chain_database.cpp:1145:63: internal compiler error: in calc_dfs_
tree, at dominance.c:401
    } FC_RETHROW_EXCEPTIONS( warn, "", ("data_dir",data_dir) ) }
Please submit a full bug report,
with preprocessed source if appropriate.
See <> for instructions.
libraries/blockchain/CMakeFiles/bts_blockchain.dir/build.make:570: recipe for target 'libraries/blockchain/CMakeFiles/bts_blockchain.dir/chain_database.cpp.o' failed
make[2]: *** [libraries/blockchain/CMakeFiles/bts_blockchain.dir/chain_database.cpp.o] Error 1
CMakeFiles/Makefile2:847: recipe for target 'libraries/blockchain/CMakeFiles/bts_blockchain.dir/all' failed
make[1]: *** [libraries/blockchain/CMakeFiles/bts_blockchain.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2
seems like I need to run my delegate on the (debian) backup server until this is resolved ... no idea what to do though :(

I got this error as well from a clean build. Building with clang works. If you like, I can give you a pkg.tar.xz. I'll also be updating my docker containers momentarily.

Immediately crashing on OSX 10.9.4

Getting error: "An error occurred while trying to start"

You should check your default.log in ~/Library/Application Support/BitShares X/logs/default -- The real reason for that error should be shown there. Most likely you just need to delete ~/Library/Application Support/BitShares X/chain/index to force a rebuild of the index. PM me if you need any more help.

General Discussion / Re: 0.4.11 Testers Wanted (not mandatory)
« on: September 03, 2014, 04:26:58 pm »
maybe,we could build the system on the "docker".this will reduce lots of bugs.

I maintain Docker images of BitSharesX. These are available at Note that nathanhourt/bitsharesx is probably the most interesting to others, but I also have an image which is preconfigured to run a chain server here.

Pages: 1 2 3 4 5 [6] 7