Status
Not open for further replies.
Try blanking out the maximum times and limit period, and instead setting the paycheck interval to 30 instead of 1 - this will allow the system to do FAR less work, and allow it to issue the events it is supposed to, vs issuing 30 times too many and throwing away 29 of them.

For the sake of testing, since you are doing it every month and it will take awhile to verify, maybe the interval at 1 after the others are blank, so you can check daily that everyone is getting what they are supposed to, and after a few days, switching it to 30 and seeing how it looks next month.
 
Try blanking out the maximum times and limit period, and instead setting the paycheck interval to 30 instead of 1 - this will allow the system to do FAR less work, and allow it to issue the events it is supposed to, vs issuing 30 times too many and throwing away 29 of them.
Will this work as well for members who are more sporadic in their activity and may miss logging on when the interval hits 30?

For the sake of testing, since you are doing it every month and it will take awhile to verify, maybe the interval at 1 after the others are blank, so you can check daily that everyone is getting what they are supposed to, and after a few days, switching it to 30 and seeing how it looks next month.
I can't really test it that way because our currency has a standard of 1 per $1 of real currency. If everyone on our site got extra paychecks we'd be losing money :)

Just to make sure, I am setting the interval to 30 and leaving the frequency 1? How is this different than leaving the interval 1 (our server can handle it) and setting the frequency to 30?
 
When users login, the number of missed paychecks is calculated from between now and the last time they logged in, by seeing how many interval dates occurred within that timespan.

Yes - frequency of 1 and interval of 30. The system creates pending transactions and processes them against your frequency and limit settings - deliberately adding 29 out of 30 transactions means those will delay the processing of actually desired transactions, because it has to churn through those 29 just to decide it has to throw them away, when it could have been accepting Post events or something.

I guess let me know how it looks after the beginning of next month then.
 
To catch everyone up before I changed it to 30 day intervals I set it to 1 interval so that everyone would get paid today.

I checked the logs and only 28 members were paid by the system this morning. (Spread throughout various usergroups). My own account is one of the ones that didn't receive a paycheck even though I've logged on/posted etc...
 
Go to maintenance > update counters > process pending transactions (let it run through everyone) and let me know if additional users have been awarded their paychecks (especially yourself)
 
Ahh, tried and it showed an error.

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 122880 bytes) in /home/hortonst/public_html/vampire-larp/includes/functions.php(1539) : eval()'d code on line 60

I don't know why it's saying Allowed memory of 32 MB when my php.ini in the root folder of vbulletin is set to

memory_limit=64M
 
Might the memory size be related to MySQL as opposed to PHP? my.cnf file contains those details. Any changes require a restart of MySQL.
 
Strike out the MySQL/my.cnf idea... just thought of what might be the issue though... sometimes a local php.ini file is used. It might be that your adjusting a master value, when the local value supersedes it.
 
Go to maintenance > view phpinfo > locate memory_limit to verify it indeed has been updated locally to 64M
No it still says 32M there. I don't know why it's not pulling the limit from my php.ini but I added ini_set("memory_limit", "64M"); to my includes/config.php file and ran the proccess pending transactions. It was successful this time and went through 12k+ transactions but as far as I can tell still no paychecks went through (checked the transaction log).

This morning before I realized that the majority of the site didn't get a paycheck, I deactivated the paycheck actions thinking that they would stay off until the first when I change the interval to 30. I realized there was an issue and reactivated them a short time later. I don't know if that would make any difference.

It might be that your adjusting a master value, when the local value supersedes it.

Where would this local value be set at?
 
update: The usergroup I belong to has 3 members. As of my post this morning, only one was showing in the transaction log as being paid. Checking again after running the process pending transactions, it is now showing that two of the members have their paychecks. The third still was not even though there was logging in and posting.
 
I left it on one more night and it seems that as of this morning everyone who should get a paycheck received one. I will be deactivating the events and reactivating them on the first when I change the interval to 30. Thank you Darkwaltz and Mokonzi for the help.
 
Checking back in to update that we are still experiencing inconsistencies with our paycheck actions. It seems to completely skip some users without rhyme or reason. We've changed it to be every 7 days now instead of 30 so that we can monitor it and check changes without waiting a month, but still can't find a solution to when it does skip paying people.
 
Now that it's weekly we are seeing that it is the same members who are getting skipped by the system. We have tried resetting them to basic members and re-adding them to their proper usergroup but that doesn't fix the problem of VBCredits skipping their paycheck every week.
 
can you PM me the list of users who you have identified? also, if you changed the login stuff for your site please include that too.
 
Your settings looked fine, and the only common feature between them was one of the joinable groups, but the settings for that were still fine... so i dont have an idea why its not working for them yet.
 
After a few more weeks it has gone back to random. The members who were never getting paid have gotten paid and some members who have previously been paid get skipped. All are active.

It really would be a huge help to simply have a task I could run that would send out all checks like the old credits system did.
 
Status
Not open for further replies.

Legacy vBCredits II Deluxe

vBulletin 3.8.x vBulletin 4.x.x
Seller
DragonByte Technologies
Release date
Last update
Total downloads
845
Customer rating
0.00 star(s) 0 ratings
Back
Top