Jump to content

andrewatfornax

Administrators
  • Content Count

    1,883
  • Joined

  • Last visited

About andrewatfornax

  • Rank
    Master

Contact Methods

  • Website URL
    www.revive-adserver.com

Recent Profile Visitors

3,759 profile views
  1. Follow the debugging guide for banners not displaying for further ideas, but my immediate guess would be that your web server isn't configured for the new domain, and therefore isn't passing the request through to Revive Adserver?
  2. Actually, I take that back. I set up a new development environment recently, and ran into the issue with MySQL 8. I spent some time looking into the issues, and there is no simple solution, so I am afraid that for now, we have updated the requirements to note that MySQL 8 is not currently supported.
  3. HI @firstimpression, No, no documentation on this. 1. You should only have leftovers in the event that data arrives in the tables AFTER the maintenance engine has run to summarise stats for that hour. If you fail to run maintenance for a given hour (or two, or however many), then the next run is supposed to figure out when it was last run, and summarise stats for all the required hours between then and now. 2. The point that you are running distributed stats is probably the reason you have leftovers - I would guess that central maintenance runs on the hour, but the system to transfer stats from distributed-mode "slaves" (they are not really DB slaves) fails, so the data doesn't arrive in time for central maintenance to see it. That's why you have to use the republish script to deal with the missing data. There is no solution to this, but as a suggestion to make it happen less frequently: 1. Put good monitoring and alerting in place to ensure that the data transfer works; and 2. Delay when central maintenance runs to give the data transfer process more time to complete. If you can, you can even hook #2 up to #1, and only run central maintenance once you know the data transfer is done. But this would have to all be your own custom code....
  4. That definitely sounds like a good starting point, then. The plugins/etc directory should not be empty in the existing installation that you are attempting to upgrade from. You may need to go back to the existing installation, and resolve the issue with the plugins there (there are details on how to do that in the troubleshooting documentation on our site) before attempting the upgrade again. The upgrade process expects your existing installation's plugins to be present, and copies them over from there as part of the upgrade process. (We do this because you may have 3rd party plugins installed that Revive Adserver otherwise wouldn't know about; if we didn't copy them over, all those 3rd party plugins would be missing after ever upgrade.) Then you might have the same problem, or you might not, because you don't really give us any details about your problem other than "me too". You might be better off starting a new thread that provides some details about exactly what you did to get the issue you have, and provide some details about what you have tried/what you see in the logs.
  5. HTTP 503 errors are returned by the web server, under which PHP (and then Revive Adserver) runs. If you are getting HTTP 503 errors, you will need to investigate your web server logs, and use the web server documentation to track down why the web server is returning this, and resolve that issue. This is potentially (but not definitely) due to a performance issue with running the Revive Adserver code, but it's something you will need to confirm at the webserver - unfortunately, it's very unlikely to be due to a Revive Adserver code issue.
  6. I meant more that the directory includes "%clientname%" in it. That looks like it's supposed to be a variable that hasn't been replaced correctly. Is that really the literal name of the directory?
  7. Okay, unfortunately, neither do we, nor can we. 5xx errors are due to your server/webserver. They have nothing to do with Revive Adserver.
  8. That's clearly a log file spanning multiple days - only the parts that appear when you perform the action that isn't working are of any interest. Please edit the above post to remove all the data, and only leave what's relevant to the issue.
  9. Strange. No ad blockers installed? Details on checking the log file for errors here: https://documentation.revive-adserver.com/display/DOCS/Revive+Adserver+Broken#ReviveAdserverBroken-Step8:CheckyourLogFiles
  10. Just noticed in the log files in the original post that there are lines like this: Failed to find package definition file /home/%clientname%/public_html/openx-421/plugins/etc/openXBannerTypes.xml They don't look right - is that really the correct path to the location of Revive Adserver 4.2.1?
  11. https://documentation.revive-adserver.com/display/DOCS/Revive+Adserver+Broken
  12. "Nothing showed up". Can you please be more clear, with a screenshot? Did you get a blank screen? Did you get an error message? Did you tail the log files to see if anything appeared during this process?
  13. See our troubleshooting guide! https://documentation.revive-adserver.com/display/DOCS/Revive+Adserver+Broken#ReviveAdserverBroken-HTTP500ErrorCode
  14. At the time of my reply, no, this is still on the todo list.
  15. Hi @stapel_eliz, This is intended functionality of Revive Adserver - advertiser accounts are there to allow advertisers to see what campaigns/banners they have, and view the statistics of their delivery, etc. Their account is not intended to have the ability to see details of zones etc. that relate to the independent website account(s) to which the banners have been linked.
×
×
  • Create New...