Question Reset newsletter to start scanning again from user #1

Status
Not open for further replies.

djbaxter

Customer
Wer have currently disabled the cron job (scheduled task).

The owner wants to restart the newsletter to begin mail-outs Wednesday morning.

What would I need to reset to ensure that when we restart the newsletter it begins again at the top of the memberlist?
 
Run a query like this:
Code:
UPDATE user SET dbtech_newsletter_lastreceive = 0

Remember to add your table prefix if you use one :)
 
That didn't work.

I want to restart the sending from user #1 on the forum. I ran the query and when it restarted it sent out newsletters but it didn't start from user #1. I assumed it started from wherever it left off the last time it ran.,
 
That query does work, it sends the newsletter to the first user in your database that has not unsubscribed. The column you updated is the only measure for whether someone has previously received the newsletter.
 
But it's not a large member list and it took a good 17 hours until user #1 received the newsletter.

How does the scheduled task know where to start if it's been disabled for a while and then is enabled again? Is there a way to reset the marker for the scheduled task back to #1?
 
How does the scheduled task know where to start if it's been disabled for a while and then is enabled again?
The scheduled task selects 250 users that have not received the list for a week (or whatever you changed the interval to), ordered by User ID in ascending order.

Is there a way to reset the marker for the scheduled task back to #1?
The query I posted above is the method for that.
 
Okay. Thank you. I guess I need to look elsewhere for the "bottleneck", e.g., vBulletin mail settings.
 
Okay. Thank you. I guess I need to look elsewhere for the "bottleneck", e.g., vBulletin mail settings.
Ah yeah, I didn't think to mention that - this mod uses vBulletin's mail queue system, so if your forum has low activity (so the scheduled task doesn't get processed often) or the mails per cron run is set very low (I think by default it's set at 10), then that could be a cause for delay.
 
Does it use the vBulletin mail queue system even if that is turned off in the vBulletin email settings?

Or does this product REQUIRE that the vBulletin mail system be turned on?
 
This mod respects whatever your settings are. We use the standard vbmail() function for sending email, which does its own thing based on your vBulletin settings.
 
Hello djbaxter,

This ticket has now been closed with the status Answered.

We hope your issue or question has been addressed to your satisfaction. If not, please feel free to re-open it by clicking this link.

If you have any further issues or questions, please feel free to start a new support ticket via the button at the top of every page.

Thank you!
 
I have tried the SQL query you gave me several times. The query seems to run successfully.

However, after turning off the scheduled task and re-starting it, or disabling the newsletter add-on entirely and then re-enabling it, it is taking an unusually long time to send out the newsletter on one forum.

At Local Search Forum (owned by Linda Buquet who purchased a license here under her own name), I am the technical admin there. I am user #1 and Linda is user #2 on that forum.

I enabled the newsletter add-on last Sunday night after stopping it and running the SQL query. I would expect that I would have received my copy of the newsletter no later than the next morning. In fact, it did not arrive until yesterday (Friday April 29) late evening. Linda is reporting the same experience.

We have now tried this three times. We have double checked the vBulletin email settings as well as her server settings (VPS). There are no mail throttles in place.

This is a forum with 3,039 mostly active members, i.e., very active Monday through Friday and somewhat slower on the weekends. There are even more non-logged in daily visitors. Thus, there is no reason to suspect that the scheduled task would not be fired by the vBulletin pixel.

I am baffled. The newsletter should obviously not take almost 6 full days to reach me, user #1, after running the reset SQL query.

Any advice or ideas?
 
Hmm, I think we need to enable more detailed logging in order to get to the bottom of this. I've made appropriate changes and re-uploaded v1.1.1 to the Client Area.

Could you re-download, re-upload, then re-run the queries?

The reason why this is so weird is that this is the exact query used when fetching users:
Code:
SELECT * FROM user
WHERE dbtech_newsletter_receive = 1
	AND dbtech_newsletter_lastreceive <= (1461974400 - (dbtech_newsletter_frequency * 604800))
ORDER BY userid ASC
LIMIT 250

That's for midnight tonight. The order in which the results appear determines the order in which people receive their newsletters. What the "lastreceive" line means is; "include users who have not received the newsletter for X weeks, where X is their chosen frequency setting".

So if you set dbtech_newsletter_receive to 1 and dbtech_newsletter_lastreceive to 0 for your user, then it will tell the mod this user has never received the newsletter. Once they receive it, it'll take at least 1 week before they receive it again.

Hope this helps.
 
Sorry for the delay in getting back to you... got bogged down in a few other projects.

I have now uploaded the new version of 1.1.1 to one of the forums for testing.

I just re-ran the query

Code:
UPDATE user SET dbtech_newsletter_lastreceive = 0

Where do I look for the new "debugging" information?

All of the forums using the Pro version are now showing signs of "slippage", with the newsletter showing up on days that gradually slide toward the weekend and then into the next week.

I'm wondering about increasing the number of newsletters sent out at a time and/or decreasing the intervals between sending. These are dedicated servers and can handle the load but we need more predictability on when the newsletters will be delivered. Having them show up on a Friday night or weekend for a business forum isn't acceptable.
 
Last edited:
I have been running the query via the AdminCP <strong>Execute SQL Query</strong> option<strong></strong> up to now:

Code:
UPDATE user SET dbtech_newsletter_lastreceive = 0

However, I just tried running it via phpMyAdmin and I get this error:

Code:
#1054 - Unknown column 'dbtech_newsletter_lastreceive' in 'field list'

This is with the latest version of 1.1.1 with debugging.

????

This is on a forum using your debug version.

I just tried the same query on another forum using Newsletter Pro 1.1.1, the version prior to your debug version, and I don't get that error.

Any suggestions?
 
Last edited:
All of the forums using the Pro version are now showing signs of "slippage", with the newsletter showing up on days that gradually slide toward the weekend and then into the next week.
Can you check your vBulletin Options under Email Options that the "mail per scheduled task run" is set to a respectable amount (default is 10 I believe, I recommend 250)?

This is the most common reason for this. You can check if this is the case by checking if the mailqueue table is full.

Any suggestions?
Did you remember to include your table prefix?
 
Can you check your vBulletin Options under Email Options that the "mail per scheduled task run" is set to a respectable amount (default is 10 I believe, I recommend 250)?

This is the most common reason for this. You can check if this is the case by checking if the mailqueue table is full.

We haven't been using the mailqueue system but the number per batch was set at 500.

There are no emails in the queue.

Did you remember to include your table prefix?

Yes, for that forum there is no prefix. And after installing your debug version I don't think it's running at all because the table doesn't exist.
 
I manually re-added the three dbtech_ tables by comparing them with another forum with the non-debug version installed.

I turned off the newsletter and the scheduled task temporarily.

I then set up the forum in question to use the vBulletin email queue with 250 as the default.

I will restart the newsletter next week and see how it goes...

Can you please replace v 1.1.1 with the previous version? I'm not sure how it deleted the tables (I had it set to overwrite) but now I no longer have a copy of the non-debug 1.1.1 version.
 
Nothing has changed in the updated v1.1.1 version other than adding more logging to the scheduled task. The installer has not changed in any way, shape or form.

Could you try uninstalling it and re-installing it?
 
Status
Not open for further replies.

Legacy DragonByte Newsletter

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