Transaction details won't open. Traceback: Traceback (most recent call last):
File "ArmoryQt.py", line 3290, in showContextMenuLedger
self.showLedgerTx()
File "ArmoryQt.py", line 3267, in showLedgerTx
DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5571, in __init__
self.txInModel = TxInDispModel(pytx, self.data[FIELDS.InList], self.main)
File "/home/andy/bitcoin/BitcoinArmory/armorymodels.py", line 1125, in __init__
dispInfo = self.main.getDisplayStringForScript(script, 60)
File "ArmoryQt.py", line 4763, in getDisplayStringForScript
prefIDOverAddr, lblTrunc, lastTrunc)
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/UserAddressUtils.py", line 172, in getDisplayStringForScript
if iterWlt.hasScrAddr(scrAddr):
File "/home/andy/bitcoin/BitcoinArmory/armoryengine/PyBtcWallet.py", line 538, in hasScrAddr
return self.cppWallet.hasScrAddr(scrAddr)
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 3727, in hasScrAddr
return _CppBlockUtils.WalletContainer_hasScrAddr(self, scrAddr)
RuntimeError: invalid char in b58 string
Works for me. Is there only a few select transactions it cannot display? |
|
|
|
...the wallet is deleted, but only after shutdown/restart
I'm aware of this one, pissed me off at one point so I left it on the back burner. Will fix the rest, dunno about this one atm, high cost to reward ratio for something that can be done by just deleting the underlying file manually and restarting the client. |
|
|
|
- Coin Control seems to be broken. I have to specify which UTXOs I want to use, otherwise Armory complains. I can get the exact message if you need it.
Please do - After ~7-8 blocks come in, Armory seems to stop picking up new blocks even though Core keeps chugging along. No messages on the command line. When I close, I have to force quit. The blocks seem to be picked up upon restart.
Try to narrow it down. I'll try to reproduce on my end. Feel free to add verbose if you got an idea of where it's happening. (ERROR) ArmoryUtils.py:3741 - Unsupported language specified. Defaulting to English (en)
This is a false positive from the translation PR. I'm guessing it should set the default the first time, which it isn't doing. (ERROR) ArmoryQt.py:2129 - ***WARNING: Wallet could not be loaded: /home/droark/.armory/testnet3/armory_22LowGmee_.WatchOnly.wallet (skipping)
Traceback (most recent call last):
File "ArmoryQt.py", line 2089, in loadWalletsAndSettings
reportProgress=reportProgress)
File "/home/droark/Projects/BitcoinArmory/armoryengine/Timer.py", line 99, in inner
ret = func(*args, **kwargs)
File "/home/droark/Projects/BitcoinArmory/armoryengine/PyBtcWallet.py", line 2110, in readWalletFile
self.unpackHeader(wltdata)
File "/home/droark/Projects/BitcoinArmory/armoryengine/PyBtcWallet.py", line 1997, in unpackHeader
self.unpackWalletFlags(binUnpacker)
File "/home/droark/Projects/BitcoinArmory/armoryengine/PyBtcWallet.py", line 1929, in unpackWalletFlags
raise isMSWallet('Cannot Open MS Wallets')
isMSWallet: Cannot Open MS Wallets
That's quorum's MS wallets, don't cheat now =D |
|
|
|
Should the git submodule update command not produce some delta feedback in respect of the changes ? I got a new prompt with nothing. Do I need to make clean first?
It should. I'm not an expert with submodules though, first time trying it. There are other ways to get the submodules to update with a command from the top most repo: http://stackoverflow.com/questions/1030169/easy-way-pull-latest-of-all-submodulesOtherwise, the "brute force" method is to git pull in the submodule repo. Once I'll more familiar with it I'll update the readme with the most convenient method. No idea why the DB would be already running, I only see that one process running.
Anything I can do on my side?
No idea why the DB would be already running, I only see that one process running.
That line just means the client successfully probed the ip:port you gave it for a listening socket and won't start a local DB. Anything I can do on my side?
Do you have some python or C++ in you? EDIT: also please detail your setup. If you dont have any coding in you, I'll make you a separate branch with extra verbose in there for you to paste back here. |
|
|
|
|
Should be good now. Make sure to make clean and autogen again, quite a lot of stuff has changed. Also make sure the submodule is up to date.
|
|
|
|
- Editing tx comments from main window yielded QString::arg: 1 argument(s) missing in Add %2 %2:
- Using the wallet filters produced overlapping or incomplete results accompanied by -INFO - 1487508653: (SocketObject.cpp:517) POLLIN recv return 0
Fixed - A little messing around with the "Use only selected UTXOs" option ended up with a bunch of AttributeError: 'DlgWalletDetails' object has no attribute 'wltAddrModel' with differing tracebacks, followed by the fee adjustment failing altogether. Clicking Send! in that state produced an Insufficient Fee dialog with this text featuring "Your specified fee results in a rate of %d satoshis per byte/b>. This is much lower than the median satoshi/byte rate of %s BTC"
Can't reproduce the coin control thing, you're gonna have to narrow it down. I got some other bug on the fee part that may cover what you found, more on that when that fix is out. Both the Create Wallet button and dropdown selection yields this: Traceback (most recent call last):
File "ArmoryQt.py", line 3456, in startWalletWizard
walletWizard = WalletWizard(self, self)
File "/home/user/BitcoinArmory/ui/Wizards.py", line 103, in __init__
self.walletBackupPage = WalletBackupPage(self)
File "/home/user/BitcoinArmory/ui/Wizards.py", line 307, in __init__
WalletBackupFrame(wizard, wizard.main, wizard.tr("Backup Wallet")))
File "/home/user/BitcoinArmory/ui/WalletFrames.py", line 807, in __init__
self.featuresLbls[F.ProtGen] = MkFeatLabel(self.tr('Protects All Future Addresses'))
File "/home/user/BitcoinArmory/ui/WalletFrames.py", line 806, in <lambda>
MkFeatLabel = lambda x: QRichLabel(tr(x), doWrap=False)
NameError: global name 'tr' is not defined
...and no Create Wallet dialog Fixed Another problem (and one that seems to have been around for years): The transaction export feature is broken. There are two problems. - In qtdialogs.py, order_ascending and order_descending aren't defined. - There's something wrong with SWIG. I got the following error on the command line when running the export command after defining the two order values. (ERROR) Traceback (most recent call last):
File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/qtdialogs.py", line 9504, in accept
if self.createFile_CSV():
File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/qtdialogs.py", line 9631, in createFile_CSV
walletGroup = TheBDM.bdv().getStandAloneWalletGroup(wltIDList, order)
File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 2453, in <lambda>
__getattr__ = lambda self, name: _swig_getattr(self, BlockDataViewer, name)
File "/Users/droark/Projects/private-goatpig-BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 80, in _swig_getattr
raise AttributeError("'%s' object has no attribute '%s'" % (class_type.__name__, name))
AttributeError: 'BlockDataViewer' object has no attribute 'getStandAloneWalletGroup' This probably has to do with order_ascending and order_descending, which need to be HistoryOrdering objects. I can't seem to find examples in Git. Will keep looking and submit a PR if I can. EDIT: Okay, I think I found it. The Python code relies on code in BlockDataViewer.h/cpp. However, that code goes into ArmoryDB. SwigClient.h/cpp appears to have its own BlockDataViewer. This is what Python accesses. The Python BDV doesn't have the code required for the Tx exporting. I'll look into that and see if how easy it would be to copy the code over. Fixed |
|
|
|
Just an update - was going to roll back to 0.93 when I decided on a whim to start up 0.95 again.
And... it worked!
I had wiped the database directory entirely, started and synced bitcoind prior to launching Armory. My guess is one of my prior actions had fixed something, but I didn't bother to reboot the linux box since that is not usually needed. I guess I had to power-cycle it, because that did the trick.
Anyway, its much faster, so thanks very much for that!
Please consider participating in the 0.96 testing phase =) |
|
|
|
Thank you for the tl;dr of what's going on in fcgi in general and armorydb too.
Sorry, Igoatpig, didn't want to hint that you should do some nonsense like making armorydb directly accessible from outside, I asked to understand the role of a webserver in between in this case. Honestly, never heard of fcgi before, and only know cgi from web
addresses.
Sorry if I came out harsh, wasn't my intention. Maybe think of fcgi as an ancestor of websockets? CGI goes over stdout and stdin. The idea is that the daemon isn't meant to deal with custom requests. It can just serve files. So protocols were developed for daemons to tunnel certain requests to services sitting behind them for processing. That's dynamic content and PHP in a nutshell. FCGI took the same data as CGI, but over sockets instead, and allowed for resident services, i.e. you don't need to spawn a service per request, but can streamline all requests over sockets, and let the one service sort things out. However, armoryqt doesn't seem to do anything, "preparing databases", scanning history at "0%" and "1 sec".
In other cases, where armorydb and armoryqt were on the same machine, this indicated that armorydb wasn't running.
How can I make sure armoryqt is really reaching armorydb?
In the logs I only see the ip and port as parameters handed over at the start of armoryqt, but no other message like "connected" or similar.
Assuming you correctly proxied the DB service with a daemon, opened the proper ports and pointed the clients to the right ip and port, then you have a bug. I'd suggest you get into the 0.96 testing phase and help me identify and fix the issue. |
|
|
|
What exactly does that do? To me it looks like it does nothing else than hosting localhost:9001 on network:80 with a few fastcgi options?
FCGI is a webstack interface that carries CGI over a socket. The DB speaks FCGI, the daemon receives HTTP, converts to FCGI and passes it to the DB. The daemon is explosed to the LAN/WAN, the DB sits behind the daemon. Among other things, this how PHP and MySQL interface with HTTP daemons. If that's all, why not just let armorydb listen on all interfaces?
Daemons are well established and dedicated tools that deploy well understood services with widely documented features and settings. I would have to reproduce that code in ArmoryDB to do what you are asking for. It is not only more work for me, it is also undesirable. The DB is meant to operate in a trusted environment. HTTP daemons are built to be exposed to the public and tunnel packets to services behind them on the trusted environment. That's how the web works. I don't presume to reinvent nor sidestep current proper practices. |
|
|
|
Found two more problems. - There seems to be some sort of repo cloning issue. Every time I've cloned onto my Ubuntu VM, the FCGI subproject never downloads. I got around it by manually downloading the code and copying it over. Still, something's up, and I'm not sure what it is. (OSX is fine.) - The C++ wallet mirroring seemed to pause when it hit an error. (ERROR) ArmoryUtils.py:3217 - Error in pybkgdthread: 'WalletComparisonClass' object has no attribute 'tr'
Traceback (most recent call last):
File "/home/droark/Projects/PersonalGitRepo/BitcoinArmory/armoryengine/ArmoryUtils.py", line 3215, in run
self.output = self.func()
File "/home/droark/Projects/PersonalGitRepo/BitcoinArmory/armoryengine/ArmoryUtils.py", line 3152, in funcPartial
return thefunc(*args, **kwargs)
File "/home/droark/Projects/PersonalGitRepo/BitcoinArmory/ui/WalletMirrorDialog.py", line 91, in walletComputation
reportTextProgress(self.tr("Checking imports for wallet %s").arg(wltID))
AttributeError: 'WalletComparisonClass' object has no attribute 'tr'
I'm also seeing some other errors on startup. The first one is repeated once, and the second is repeating multiple times. (ERROR) Traceback (most recent call last):
File "ArmoryQt.py", line 4797, in handleCppNotification
self.finishLoadBlockchainGUI()
File "ArmoryQt.py", line 2437, in finishLoadBlockchainGUI
self.createCombinedLedger()
File "ArmoryQt.py", line 2510, in createCombinedLedger
totalFunds += wlt.getBalance('Total')
TypeError: unsupported operand type(s) for +=: 'int' and 'SwigPyObject'
(...)
(ERROR) Traceback (most recent call last):
File "/home/droark/Projects/PersonalGitRepo/BitcoinArmory/armorymodels.py", line 81, in data
dispStr = coin2str(bal, maxZeros=2)
File "/home/droark/Projects/PersonalGitRepo/BitcoinArmory/armoryengine/ArmoryUtils.py", line 1322, in coin2str
nBtc = float(nSatoshi) / float(ONE_BTC)
TypeError: float() argument must be a string or a number
These errors are fixed in dev |
|
|
|
cp cppForSwig/.libs/libCppBlockUtils.so ./_CppBlockUtils.so
cp: cppForSwig/.libs/libCppBlockUtils.so: No such file or directory
What folder does libtool build on OSX? Try replacing /cppForSwig/.libs with $(builddir) |
|
|
|
|
Try with Core, see if it fails too. You can also participate to the 0.96 testing phase to help me fix the issue for the next version.
|
|
|
|
Thanks for your reply. Sure, I will make a new vm to test the testing version. I will let you know.
Just to be clear, the code is in the dev and autotools branches atm. |
|
|
|
I have been using Armory for some years and recently I installed this new version. I installed it in fresh ubuntu install and I got many problems to make it work. One of the problems was Armory not being able to talk to bitcoind (RPC error in log). I saw some people had this issue and fixed it unchecking the option (Let armory execute bitcoind.....). I did this and it appears is working... but I am still not sure 100% is working.
This should improve a lot in 0.96 What happens now is. Having Armory empty (without wallets), it says is online and synced. I close armory, I open it again. It starts building databases, just a few minutes (around 5) and then starts "Organizing blockchain". Problem is... it take hours! Even having Armory synced and online, if I close it, and in order to having working again I have to wait 3h. This does not make too much sense as you have the wallet online, and suddenly if you close you have to wait 3h again.. so is this an issue? normal behavior? Just in case, I run armory in virtual machine, but I have always done this without problems like this one.
Sounds like a bug. You should participate to the 0.96 testing phase going on atm and help me debug the issue: https://bitcointalk.org/index.php?topic=1784442.0 |
|
|
|
Can do. Is autotools not a dependency for gitian, or is that wrong?
It is, and that's end game here. But autotools itself is a messy thing, that got me spending the best part of a week just to get Armory back into the state it was with plain makefiles. So... baby steps =) |
|
|
|
Both the Create Wallet button and dropdown selection yields this: Traceback (most recent call last):
File "ArmoryQt.py", line 3456, in startWalletWizard
walletWizard = WalletWizard(self, self)
File "/home/user/BitcoinArmory/ui/Wizards.py", line 103, in __init__
self.walletBackupPage = WalletBackupPage(self)
File "/home/user/BitcoinArmory/ui/Wizards.py", line 307, in __init__
WalletBackupFrame(wizard, wizard.main, wizard.tr("Backup Wallet")))
File "/home/user/BitcoinArmory/ui/WalletFrames.py", line 807, in __init__
self.featuresLbls[F.ProtGen] = MkFeatLabel(self.tr('Protects All Future Addresses'))
File "/home/user/BitcoinArmory/ui/WalletFrames.py", line 806, in <lambda>
MkFeatLabel = lambda x: QRichLabel(tr(x), doWrap=False)
NameError: global name 'tr' is not defined
...and no Create Wallet dialog Will go over these once the autotools branch is ready. On that note, would you mind pulling that branch and trying it out? You need to setup git submodules this way once you check out the branch: git submodule init
git submodule update
Then you can build the usual autotools way: sh autogen.sh
./configure
make
make dist works, but make install doesn't yet. |
|
|
|
OK.
Do you know how the block data get corrupted? I'd think there's some kind of verification process after the block has been downloaded, for example a hash of the block that can be verified, and if it's not adding up, then it should be downloaded over again?
And there is not some kind of repair tool that can fix only the blocks that are wrong? Would save a lot of bandwidth for the bitcoin network.
Core downloads blocks, verifies them, then appends to disk. It does not verify what goes on disk, and this is where you are having trouble. It is possible your machine is unstable as well. I would suggest you try to rebuild the database with a lower thread count (--thread-count) and record where/if the build fails again. If it always hits the same spot, then your blockchain data is damaged. If it doesn't, then your system is not stable enough to handle a heavy CPU load. |
|
|
|
Hi, I just wrote it down by hand, maybe thats the most secure anyway  Sure I can help you debugging, so I am in for beta. Don't forget to write down the wallet ID and version as well. |
|
|
|
|
Show Posts
