Are you sure you completely exited (shut down) smartcoin, and not just detached?
You shouldn't have to remove ~/.smartcoin in your case, there were no schema changes in between those versions, so you should be fine
Topic: Smartcoin Linux mining administration. [MULTI-MACHINE SUPPORT NOW IN!] - page 25. (Read 105029 times)
July 08, 2011, 07:00:29 PM
July 08, 2011, 06:01:23 PM
I try to update from 362 to 370.
However I am stuck at the update breakpoint to 365. It says it will update to 365 now, succeeds, tells me to kill smartcoin and start it again. I will do, but printouts say it is still 362. When I start the update, it will again update from 362 to 365.
Edit: Just removed the whole directory and got it fresh from svn. I do not have to delete $HOME/.smartcoin/smartcoin.db?
However I am stuck at the update breakpoint to 365. It says it will update to 365 now, succeeds, tells me to kill smartcoin and start it again. I will do, but printouts say it is still 362. When I start the update, it will again update from 362 to 365.
Edit: Just removed the whole directory and got it fresh from svn. I do not have to delete $HOME/.smartcoin/smartcoin.db?
July 08, 2011, 12:02:44 PM
Dishwara:
It is possible that you saw donation mining because the current time happened to be somewhere between the randomly generated start time and starttime+donation_minutes. You can verify this by going to 4)Edit Settings, and check the settings for "Hashpower donation minutes per day", and "Time to start hashpower donation each day". These can also be changed to your liking, but the start time is randomly generated at install time and my best guess was just by pure chance, the donation cycle just happened to be during the time you were first running it. (This would be normal)
In fact, I would appreciate it if you could post both of those settings here, just so I can double-check that there is no issue.
[edit]
I think its likely that your donation minutes per day is set to 3030 instead of 30... On install, its already defaultly filled out to 30, so if you typed '30' again without backspacing over the 30 that was already there, then it probably got stored as '3030', which would pretty much cause it to be in autoDonate all the time. Can you confirm this in your settings entries?
Also, ragarding miners that hang. I used to have the problem, but started overclocking just a few mhz less and my miner hasn't hiccupped in over a month. I would try to make sure that you're not being too aggressive on the overclocking, as it is a very likely cause of the hangs
I use default 30 minutes not 3030, also now i manually change timing to 535.It is possible that you saw donation mining because the current time happened to be somewhere between the randomly generated start time and starttime+donation_minutes. You can verify this by going to 4)Edit Settings, and check the settings for "Hashpower donation minutes per day", and "Time to start hashpower donation each day". These can also be changed to your liking, but the start time is randomly generated at install time and my best guess was just by pure chance, the donation cycle just happened to be during the time you were first running it. (This would be normal)
In fact, I would appreciate it if you could post both of those settings here, just so I can double-check that there is no issue.
[edit]
I think its likely that your donation minutes per day is set to 3030 instead of 30... On install, its already defaultly filled out to 30, so if you typed '30' again without backspacing over the 30 that was already there, then it probably got stored as '3030', which would pretty much cause it to be in autoDonate all the time. Can you confirm this in your settings entries?
Also, ragarding miners that hang. I used to have the problem, but started overclocking just a few mhz less and my miner hasn't hiccupped in over a month. I would try to make sure that you're not being too aggressive on the overclocking, as it is a very likely cause of the hangs
I mean, is 535 means 5:35 AM & 1455 means 2:55 PM? or some other way.
I am using v350 so far, seems you have added many features. Have to try.
EDIT:
Find out about timing setting in 1st post.
July 08, 2011, 11:44:58 AM
Update to r367 available
- The Update/Patching system just got a pretty major update. There are now "update breakpoints". This means, that in some cases you will have to run a partial update, restart smartcoin, then run subsequent updates. This allows me to be sure that smartcoin is restarted at key points between doing updates (in fact, r365 will be a partial update, after which you will need to restart smartcoin then update to r367) A message will be displayed letting you know this, and in the future I will likely make a routine that restarts smartcoin for you, then goes back to continuing the update automatically.
- The stable/experimental update system goes live. By default, everyone is put into the stable updates. If you want to do experimental updates, go to 4) Edit Settings and change the "Development branch to follow" setting to 'experimental' after you've reached r367.
How future updates will work, is they will be available to the experimental people first. Once I can get a few reports back from them, then I will set a flag that will let the stable people grab the updates.
- The Update/Patching system just got a pretty major update. There are now "update breakpoints". This means, that in some cases you will have to run a partial update, restart smartcoin, then run subsequent updates. This allows me to be sure that smartcoin is restarted at key points between doing updates (in fact, r365 will be a partial update, after which you will need to restart smartcoin then update to r367) A message will be displayed letting you know this, and in the future I will likely make a routine that restarts smartcoin for you, then goes back to continuing the update automatically.
- The stable/experimental update system goes live. By default, everyone is put into the stable updates. If you want to do experimental updates, go to 4) Edit Settings and change the "Development branch to follow" setting to 'experimental' after you've reached r367.
How future updates will work, is they will be available to the experimental people first. Once I can get a few reports back from them, then I will set a flag that will let the stable people grab the updates.
July 08, 2011, 11:04:40 AM
Perhaps I'll just make a note in the post on page 4 that current instructions are to be found on the first post.
That should be the best solution!
July 08, 2011, 11:01:40 AM
Quote
Ok I went from 323 to 362 using the internal update function.
It definitely gave me an "ERROR" in capital letters, but it was so fast that I could not read the rest.
Afterwards, it asked if I want to take smartcoin.db and I answered tf, for getting your db.
Although I thought that it won't work anymore, it just works like a charm. And since the update I have a rejected of 0.00 %. This is weird. Normally, after starting smartcoin, I got ~12 % rejected, falling slowly to 3.25%.
The issue with having to accept "mine" or "theirs" on files should be remedied in future updates. I know it isn't exactly intuitiveIt definitely gave me an "ERROR" in capital letters, but it was so fast that I could not read the rest.
Afterwards, it asked if I want to take smartcoin.db and I answered tf, for getting your db.
Although I thought that it won't work anymore, it just works like a charm. And since the update I have a rejected of 0.00 %. This is weird. Normally, after starting smartcoin, I got ~12 % rejected, falling slowly to 3.25%.
It is possible to have no rejections at startup, though its rare. If you're lucky enough that your work is not yet out of date when you start mining, then you can see this happen. You should see this come back up to normal though with some time.
Quote
Suggestion: Merge all instructions into one post/place.
The instructions on page 1 and 4 are exactly the same. I normally update post 1, then copy/paste it into the post on page 4. I do it this way so that the information is available on the very first post of this thread, and the post where the beta release was announced. Perhaps I'll just make a note in the post on page 4 that current instructions are to be found on the first post. 
July 08, 2011, 06:47:53 AM
install instructions updated on pages 1 and 4. Includes new procmail dependency, as well as listing Failover support as implemented.
Suggestion: Merge all instructions into one post/place. July 08, 2011, 06:11:06 AM
Ok I went from 323 to 362 using the internal update function.
It definitely gave me an "ERROR" in capital letters, but it was so fast that I could not read the rest.
Afterwards, it asked if I want to take smartcoin.db and I answered tf, for getting your db.
Although I thought that it won't work anymore, it just works like a charm. And since the update I have a rejected of 0.00 %. This is weird. Normally, after starting smartcoin, I got ~12 % rejected, falling slowly to 3.25%.
It definitely gave me an "ERROR" in capital letters, but it was so fast that I could not read the rest.
Afterwards, it asked if I want to take smartcoin.db and I answered tf, for getting your db.
Although I thought that it won't work anymore, it just works like a charm. And since the update I have a rejected of 0.00 %. This is weird. Normally, after starting smartcoin, I got ~12 % rejected, falling slowly to 3.25%.
July 08, 2011, 03:45:23 AM
mono:
thanks for the report! Must be my lucky day
thanks for the report! Must be my lucky day
July 08, 2011, 03:11:52 AM
Just for a great praise and your info:
Update from r350 to r362 one minute ago without any problems.
Update from r350 to r362 one minute ago without any problems.
July 08, 2011, 01:36:47 AM
install instructions updated on pages 1 and 4. Includes new procmail dependency, as well as listing Failover support as implemented.
July 08, 2011, 01:09:05 AM
Ok it worked, but I had to manually apt-get procmail for the lockfile issue.
New svn installer didnt install procmail, other than that it all went smooth
New svn installer didnt install procmail, other than that it all went smooth
July 08, 2011, 01:00:58 AM
What distro are you running? Sounds like yours doesn't come with the lockfile command preinstalled (its part of the procmail package for some goofy reason)
I just did an update that adds the dependency and should install procmail package automatically (if your distro uses apt-get anyways), and fixes a quoting issue that caused the other error.
Let me know how it turns out
I just did an update that adds the dependency and should install procmail package automatically (if your distro uses apt-get anyways), and fixes a quoting issue that caused the other error.
Let me know how it turns out
July 08, 2011, 12:44:39 AM
mmm errors from hell 
before this it kept spewing, lockfile : command not found
./smartcoin_install.sh: line 162: syntax error near unexpected token `('
./smartcoin_install.sh: line 162: ` Q="INSERT INTO device (fk_machine,name,device,auto_allow,type,disabled) VALUES (1,'$devName',$id,1,'$devType',$devDisable);"'
before this it kept spewing, lockfile : command not found
Code:
./smartcoin_install.sh: line 162: syntax error near unexpected token `('
./smartcoin_install.sh: line 162: ` Q="INSERT INTO device (fk_machine,name,device,auto_allow,type,disabled) VALUES (1,'$devName',$id,1,'$devType',$devDisable);"'
July 08, 2011, 12:29:10 AM
Update r358 now available
- The database is now locked while in use, this should put an end to random spurious problems caused by multiple scripts trying to access the database at the same time. This was probably the cause of many bug reports! NOTE: The procmail package must be installed on your machine or you will get a bunch of lockfile errors. Please make sure to install procmail! [edit] - this should now be patched in with the update
- The installer was cleaned up a bit, and an option to automatically run 'ubdatedb' added. Options were also added to run autodetection for devices, miners and the AMD/ATI SDK path. This makes it easier to skip certain sections of the installer if you need to.
- The database is now locked while in use, this should put an end to random spurious problems caused by multiple scripts trying to access the database at the same time. This was probably the cause of many bug reports! NOTE: The procmail package must be installed on your machine or you will get a bunch of lockfile errors. Please make sure to install procmail! [edit] - this should now be patched in with the update
- The installer was cleaned up a bit, and an option to automatically run 'ubdatedb' added. Options were also added to run autodetection for devices, miners and the AMD/ATI SDK path. This makes it easier to skip certain sections of the installer if you need to.
July 08, 2011, 12:00:05 AM
I found the problem and will be committing a fix soon.
For now, run
before running the installer. That should let the locate command find the phoenix.py file
For now, run
Code:
sudo updatedb
before running the installer. That should let the locate command find the phoenix.py file
July 07, 2011, 11:36:26 PM
mmm trying new version (since the first beta) and during installer it gets to detecting miners (doesnt detect any) then I cant progress further since it asks to select detected miner(nothing detected) and cant move pass this?
Any work around?
Any work around?
July 07, 2011, 07:00:54 PM
Thanks for posting the output.
It looks like the schema update was only partially successful for you (only 2 out of 3 database alterations occurred). This is definitely related to the database locking I just talked about a few posts back. To fix it without a reinstall:
(Failover won't work completely reliably without this being done. A restart shouldn't be required)
This is the downside of using sqlite3 instead of MySQL. Though I'm sure these spurrious bugs will disappear after the locking mechanism is complete. This also explains why for most users, everything works like it should, then for some unknown reason every now and then I get a bug report that makes me scratch my head. Yep, this explains it all!
It looks like the schema update was only partially successful for you (only 2 out of 3 database alterations occurred). This is definitely related to the database locking I just talked about a few posts back. To fix it without a reinstall:
Code:
sqlite3 ~/.smartcoin/smartcoin.db "ALTER TABLE profile ADD failover_count int NOT NULL DFAULT(0);"
This is the downside of using sqlite3 instead of MySQL. Though I'm sure these spurrious bugs will disappear after the locking mechanism is complete. This also explains why for most users, everything works like it should, then for some unknown reason every now and then I get a bug report that makes me scratch my head. Yep, this explains it all!
July 07, 2011, 06:40:54 PM
Can you report back what you get if you run:
Code:
sqlite3 ~/.smartcoin/smartcoin.db ".schema profile"
I'm thinking that you don't have all of the schema updates....
Funny, the error messages seem to have disappeared, but just in case they decide to reappear, here's the output that you asked for:
Code:
CREATE TABLE profile (pk_profile integer primary key autoincrement, fk_machine int, name varchar(30),
auto_allow bool, down bool NOT NULL DEFAULT(0), failover_order int NOT NULL DEFAULT(0));
Thanks for implementing the failover profile so quickly, btw. Much appreciated!
July 07, 2011, 06:16:15 PM
sojolly:
Thanks for the feedback.
Thats kind of strange, I haven't personally seen a conflict on an update yet. Which file did it ask this on? Was this using the built-in update system?
Can you try to delete it again? I think I know what happened..
Its hard to explain, but there are multiple scripts which all independently use the same database. If multiple scripts try to change/read the database at the same time, one of them will fail with an error. This hapens pretty rarely, but its purlely based on timing (I.e. is the status script reading from the database at the same time you're trying to write changes to it from the control script?).
Right now I'm working on a Locking system in which a lock will be placed on the database before accessing it, and removed when finished. All other calls will have to respect the lock until it is cleared, after which the next call gets its turn. This will keep random errors like this from happening. I'm hoping to have the lock system done tomorrow!
Thanks for the feedback.
Quote
Update from r323 to r350 went fine when i selected tf(thier's full) on the patch. Others may not intuitively figure that out.
Thats kind of strange, I haven't personally seen a conflict on an update yet. Which file did it ask this on? Was this using the built-in update system?
Quote
I also noticed a small issue. When creating profiles, i created an extra erroneous one and deleted it, but on the select profile screen and the failover screen, the deleted profile is still in the list albeit blank.
Can you try to delete it again? I think I know what happened..
Its hard to explain, but there are multiple scripts which all independently use the same database. If multiple scripts try to change/read the database at the same time, one of them will fail with an error. This hapens pretty rarely, but its purlely based on timing (I.e. is the status script reading from the database at the same time you're trying to write changes to it from the control script?).
Right now I'm working on a Locking system in which a lock will be placed on the database before accessing it, and removed when finished. All other calls will have to respect the lock until it is cleared, after which the next call gets its turn. This will keep random errors like this from happening. I'm hoping to have the lock system done tomorrow!
Jump to: