|
jammers
|
 |
January 12, 2015, 11:52:22 PM |
|
This takes 1/2 an hour to fix, if you need a walkthrough, I'm happy to help  You just need to get the links that are broken, create page's, configure them to be the URL that's now broken, and then use page links to, to send them to the correct (working) page. This would broken links across old builds, as well as this new build. |
|
|
|
goatpig
Moderator
Legendary
 Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
January 13, 2015, 01:56:27 AM |
|
This takes 1/2 an hour to fix, if you need a walkthrough, I'm happy to help You just need to get the links that are broken, create page's, configure them to be the URL that's now broken, and then use page links to, to send them to the correct (working) page. This would broken links across old builds, as well as this new build. There is a wealth of solutions and yours certainly is an acceptable one. Thank you for your concern. However, the issue is about segregation of duties, not implementation. This simply is not a part of the codebase I deal with right now, and every time I ran across this bug in the past few months, I failed to pass it on to the right person. CircusPeanut is keeping track of everything being reported in this thread and assigning tasks to the proper personnel. This may sound selfish, but I deal with the DB issues, not the rest. Maybe 90% of the DB code was changed this time around and I am solely focusing on getting that part solid. Also I don't usually answer unless the issue is dire or I have at least some sort of a fix worked in already. However I do read all the posts in this thread. I'm already working on a couple bugs I found on my own a few days ago, although I don't expect any of you will run into those. I'm also paying attention to DB building speed with the different machines you guys run on. From that I will decide if there is need to make anything faster. Keep in mind that I expect most private users will be running fullnode, not supernode, so give that DB type some love too =) |
|
|
|
|
jammers
|
|
January 13, 2015, 02:05:20 AM |
|
I completely understand And btw, I'm just running normal armory, not the supernode. still scanning transactions, up to 46% now and reporting 11 hours to go |
|
|
|
|
japerry
|
|
January 13, 2015, 08:11:05 AM |
|
This is my very first time to report an Armory issue so if I'm doing it wrong please be gentle and forgive me.
OS: Windows 7 Premium Home Edition.
Armory Version: 0.92.99.1
Bitcoin Version 0.1+
For starters I have Bitcoin and Armory set up to write to a USB 1TB drive due to space restrictions on my local hard drive. I'm using the commands:
Armory: "C:\Program Files (x86)\Armory\ArmoryQt.exe" --settings="G:\Armory\ArmorySettings.txt" --satoshi-datadir="G:\Armory" --datadir="G:\Bitcoin"
Bitcoin: "C:\Program Files\Bitcoin\bitcoin-qt.exe" -conf="G:\Bitcoin\bitcoin.conf" -datadir="G:\Bitcoin"
What I am seeing is that if you let Armory call bitcoind (via Armory Settings) then everything works as it should. But If I try to run in the configuration where Armory expects Bitcoin-QT or bitcoind to already be running as a separate process and attach to it on start-up, the Armory screen flashes up briefly and then disappears. By doing a Ctrl-Alt-Del to see the process table, I can see that Armory-QT is still running even though the GUI has died. I have to manually kill Armory-QT in order to stop the process. I have tried this about 5 times in order to make sure the problem is re-producible. After killing the process I can restart Armory-QT and tell it to call bitcoind itself setting the Bitcoin Install Dir to "C:\Program Files\Bitcoin" and the Bitcoin Home Dir to "G:\Bitcoin" and everything works as it should.
I hope I reported this correctly.
|
|
|
|
|
jammers
|
|
January 13, 2015, 08:23:27 AM |
|
69% now after continuing to run overnight, now nearly 2 days
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
January 13, 2015, 12:03:23 PM |
|
I completely understand And btw, I'm just running normal armory, not the supernode. still scanning transactions, up to 46% now and reporting 11 hours to go What's your RAM and CPU usage at again? |
|
|
|
|
jammers
|
|
January 13, 2015, 12:28:57 PM |
|
Power settings are on high performance  on  Up to 78% now. |
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
January 13, 2015, 01:51:48 PM |
|
HDD is getting murdered I see. I'll test building on a HDD and optimize fullnode for that. Supernode is hopeless on a HDD to begin with.
|
|
|
|
|
jammers
|
|
January 13, 2015, 03:26:01 PM |
|
85%, reporting 4 hours now, although the number randomly just jumps around.
maybe incorporate some sort of mini-game for the wait, or a value/total transactions counting down (or up) until it's up to date? The time doesn't make sense, so are there other options on the dashboard screen to show something else?
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
January 13, 2015, 04:29:27 PM |
|
85%, reporting 4 hours now, although the number randomly just jumps around.
maybe incorporate some sort of mini-game for the wait, or a value/total transactions counting down (or up) until it's up to date? The time doesn't make sense, so are there other options on the dashboard screen to show something else?
Nothing more on the dashboard. If you were running this on Linux, you'd see a report in the terminal for each 2500 block milestone. We'll adjust the progress bar granularity eventually. |
|
|
|
|
jammers
|
|
January 13, 2015, 06:00:59 PM |
|
should this process in a release version take this long? Up to 91% now, reporting 4 hours to go
|
|
|
|
|
jammers
|
|
January 13, 2015, 08:47:03 PM |
|
97% now reporting 1 hour to go
|
|
|
|
|
jammers
|
|
January 13, 2015, 10:11:14 PM
Last edit: January 13, 2015, 10:22:16 PM by jammers |
|
come on armory, you can do it   Right, that finished It then started on this block  and it's currently on block  So 96 blocks behind, which is about when I restarted things after changing the pagefile. I'll see if it now syncs up to the current block on it's own. Yep, after a few minutes it did find the next block and now it's up to date. |
|
|
|
|
jammers
|
|
January 13, 2015, 10:29:58 PM |
|
Right, now for some more bugs sortable headers in transactions screen do nothing. I click them and the arrow changes, but nothing moves something weird is also happening with the balance column in wallet settings When default size the balance column centers weird  Then when you shrink the screen, it jumps over the place  |
|
|
|
|
jammers
|
|
January 13, 2015, 11:26:22 PM |
|
|
|
|
|
bitpeep
Newbie
Offline
Activity: 4
Merit: 0
|
|
January 13, 2015, 11:37:24 PM |
|
This is my very first time to report an Armory issue so if I'm doing it wrong please be gentle and forgive me.
OS: Windows 7 Premium Home Edition.
Armory Version: 0.92.99.1
Bitcoin Version 0.1+
For starters I have Bitcoin and Armory set up to write to a USB 1TB drive due to space restrictions on my local hard drive. I'm using the commands:
Armory: "C:\Program Files (x86)\Armory\ArmoryQt.exe" --settings="G:\Armory\ArmorySettings.txt" --satoshi-datadir="G:\Armory" --datadir="G:\Bitcoin"
Bitcoin: "C:\Program Files\Bitcoin\bitcoin-qt.exe" -conf="G:\Bitcoin\bitcoin.conf" -datadir="G:\Bitcoin"
What I am seeing is that if you let Armory call bitcoind (via Armory Settings) then everything works as it should. But If I try to run in the configuration where Armory expects Bitcoin-QT or bitcoind to already be running as a separate process and attach to it on start-up, the Armory screen flashes up briefly and then disappears. By doing a Ctrl-Alt-Del to see the process table, I can see that Armory-QT is still running even though the GUI has died. I have to manually kill Armory-QT in order to stop the process. I have tried this about 5 times in order to make sure the problem is re-producible. After killing the process I can restart Armory-QT and tell it to call bitcoind itself setting the Bitcoin Install Dir to "C:\Program Files\Bitcoin" and the Bitcoin Home Dir to "G:\Bitcoin" and everything works as it should.
I hope I reported this correctly.
I can confirm this. Mine is acting the same way. Can't run the Bitcoin-QT client separately without Armory-QT crashing the GUI. I also show the Armory-QT client still running in the process table. |
|
|
|
|
|
jammers
|
|
January 14, 2015, 12:08:01 AM |
|
is this build supposed to let you send a transaction without the fee?
Up to now, it always forced me to put in 0.0001, but in this build, I can send zero fee transactions.
|
|
|
|
|
picobit
|
|
January 14, 2015, 12:50:53 PM |
|
is this build supposed to let you send a transaction without the fee?
Up to now, it always forced me to put in 0.0001, but in this build, I can send zero fee transactions.
That has been possible for a while, but probably only if your coins are old enough that no fee is required by the network to propagate your transaction. |
|
|
|
|
|
TimS
|
|
January 14, 2015, 01:13:24 PM
Last edit: January 14, 2015, 02:24:41 PM by TimS |
|
During the transaction scanning of my new supernode, if I close Armory, it attempts to shut down, then crashes. http://imgur.com/a/t63L7The logs don't record any errors, just that a stop was requested: 2015-01-14 06:56 (INFO) -- ArmoryQt.py:6570 - BDM state is scanning -- force shutdown BDM
-INFO - 1421240169: (..\BDM_mainthread.cpp:273) Stop requested detected
-INFO - 1421240533: (..\BDM_mainthread.cpp:273) Stop requested detected
|
|
|
|
|
|
TimS
|
|
January 14, 2015, 02:16:11 PM |
|
Also, an update on the transaction scanning: I moved it from my HDD to SSD and now the estimate is 8 hours, and disk IO is about 30-80 MB/s. Maybe there's a lot of random access going on, not just linear access? That would explain why it's running so much faster, even though my HDD's linear access is much higher than 1-3 MB/s.
|
|
|
|
|
|
