andrewatfornax
-
Posts
2007 -
Joined
-
Last visited
Posts posted by andrewatfornax
-
-
Take a look in your PHP, webserver and database logs as well, and check your server's performance monitoring information.
-
https://documentation.revive-adserver.com/display/DOCS/Revive+Adserver+Broken
https://documentation.revive-adserver.com/display/DOCS/No+Statistics
?
In addition to the above, @Turbo212, I notice that your oxcd_data_bkt_m table is MyISAM.
This table type only supports table level locking.
If you're under high load, it's possible that the table will be locked by delivery processes queued up to write their data when the hourly maintenance process wants to lock the table to make updates. Are you sure that's not happening? Your MySQL logs might give you more information on this.
-
-
-
From memory, PostgreSQL requires (or at least, required) that database names start with a letter or underscore - database names starting with a number are not permitted.
This may have been changed in more recent versions of PostgreSQL (I don't know if that's the case - it may or may not be), but I suspect that we need to keep this restriction in place to continue to support older versions of PostgreSQL.
So, in short:
1. I don't think we'd be willing to change the restriction, without confirmation that all supported versions of PostgreSQL now allow databases to start with a number;
2. Assuming it is still the case that PostgreSQL database names cannot start with a number, then your hosting provider is wrong, and you either need to convince them that they need to change, or find a better hosting provider.
-
13 hours ago, Peter Symes said:I tried to copy the existing configuration file (for version 4.1.3) into the var folder for the new ( 4.1.4.) install as instructed in alert below - even though there is no such instructions in the general upgrade guide
I think you should review the upgrade instructions again - copying your existing configuration file(s) from your existing installation to the new installation directory is a mandatory part of the upgrade process.
Without doing this, the new code base has no idea about your existing installation's details, and so cannot proceed with performing an upgrade.
-
Link the banner to a zone in the website first - then you should see the Delivery Rule available.
-
Help with setting up web server features like the .htaccess file is beyond the scope of this forum. However, in terms of what Revive Adserver can do, you could potentially use one of the Site Delivery Rules to limit where the banners are able to be shown. Please see: https://documentation.revive-adserver.com/display/DOCS/Site+Delivery+Rules
-
Hi @signs101,
I'm not entirely sure how what I've written could be interpreted in anything other than one way.
It means:
1. There is no need to upgrade from 3.0.2 to 3.2, before upgrading to 4.1.1 - you can upgrade directly from 3.0.2 to 4.1.1.
2. I was asking where the upgrade package was obtained from. We often have users have issues with performing upgrades when they have obtained a Revive Adserver package from somewhere other than our official downloads page, and I wanted to make sure that this was not the case for the user above.
-
-
No, I don't believe there is an option to allow advertisers to do this at present.
-
Which delivery rule have you used?
-
Okay - maybe start a new thread with a full breakdown of the issue you are seeing, rather than tacking a new problem onto the end of an existing thread, please. That would help to make things clearer for everyone.
-
What software redirects you to localhost? Sorry, but you've confused me. I thought we were talking about how to use cookie data and pass it into Revive Adserver for use with delivery rules? Are you talking about something else now?
-
I cannot, sorry. I don't know anything about Taboola or Outbrain.
-
-
There are both account types for Advertisers and Publishers, which have some degree of limitation around what they can see and do, yes.
-
My usual idea is - "what changed"?
Things don't just stop working - something changes to make them stop working.
Can you track down what that was?
-
@Matteo Beccati - MariaDB version issue?
-
Get the cookie data. Insert the cookie data into your invocation tag. Target in Revive Adserver accordingly.
-
The code needs to be embedded into a video player, as per https://documentation.revive-adserver.com/display/DOCS/Invocation+Code%3A+Zone+Level#InvocationCode:ZoneLevel-VideoInvocationcodeforInlineVideoadzoneorOverlayVideoadzone
So, you need to be starting from the position of already having a video player for the HTML page, which plays the video the user wants to see. Revive Adserver then provides the code that you need to add in the inline or overlay video add to that pre-existing system.
-
-
No, there's not one specifically for cookies - you'd need to extract the information you want from the cookie, and pass it into Revive Adserver, as either a Site - Source or Site - Variable parameter.
https://documentation.revive-adserver.com/display/DOCS/Site+Delivery+Rules
-
1. Revive Adserver doesn't support that out of the box.
2. See the troubleshooting guides.
3. In what sense?
Cannot proceed wtih upgrade from 4.1.3 to 4.1.4.
in Managing Revive Adserver
Posted
Hi @Peter Symes,
I'm always open to the possibility of there being a bug, but this looks to me like user error somewhere.
The issue is that during the upgrade process, the new Revive Adserver directory is not finding your configuration file, and so it's not automatically detecting the (copy) of your old database, and saying, yes, I can upgrade that.
Instead, it's asking you where the database should go, thinking that you're doing a new install, and when you tell it where the (copy) of your old database is, it's saying, hang on, this isn't right, there's already a database here - I thought I was doing a new install!
So, somewhere, your configuration file is missing / incorrect / not able to be read.....?