EdTGuy
-
Posts
13 -
Joined
-
Last visited
About EdTGuy
EdTGuy's Achievements
Newbie (1/5)
0
Reputation
-
I poked around a bit, and decided to write one specific to this particular need <?php $host = ''; $usr = ''; $pwd = ''; $db = ''; $crArray = array(); $mysqli = new mysqli($host,$usr,$pwd,$db,3306); if(!$mysqli->connect_error) { $result = $mysqli->query("select campaignid,coalesce(revenue,0) as revenue from rv_campaigns"); $mysqli->close(); while($row = $result->fetch_assoc()) { $crArray[] = $row; } } header("Content-Type: application/json"); echo json_encode($crArray); exit(); ?>
-
When I request a banner via the rest api, https://{my host}/www/delivery/fc.php?script=bannerTypeHtml:vastInlineBannerTypeHtml:vastJson&format=json&zones=' + {zone id}, it returns quite a bit of useful information, including campaign id, but excluding the campaign revenue value. Is there some other endpoint I can use to get this information?
-
I've defined a zone with type Inline Video ad. The VAST2 Invocation Code is https://{myHost}/www/delivery/fc.php?script=apVideo:vast2&zoneid=1 If I enter this in the url field of Microsoft Edge, it returns an XML document; however, if I use it as the url argument to fetch, it returns an empty object. I created a simple test html file, and still does not return the xml contents that are returned by directly accessing the url via a browser. What is the difference? <html> <head> <meta http-equiv="Content-Security-Policy" content="script-src 'unsafe-inline'"> <script type="text/javascript"> async function fetchVideo() { var url = 'https://{myHost}/www/delivery/fc.php?script=apVideo:vast2&zoneid=1' let response = await fetch(url, { mode: 'no-cors' }) let xmlText = await response.text() return xmlText } console.log(`fetchVideo: ${fetchVideo()}`) </script> </head> <body> Happy Happy Joy Joy </body> </html>
-
Revive 5.5.0 Campaign shows linked Zone, but not vice versa
EdTGuy replied to EdTGuy's topic in Managing Revive Adserver
I resolved my issue. I had set up the zone for video, but did not did not set up my banner references to my videos correctly. Once I did that, the campaign was selectable to link to the zone. -
I just installed Revive 5.5.0 I've created a campaign, two banners a website and a zone. I linked the zone to the campaign. Under the Linked Zones tab of the campaign, it shows the website and zone under Linked Zones on the right side of the window; however, just under the "Linked Zones" header, it shows Linked: 0 Showing: 1. When I navigate to Zones and click on "Linked Banners" for that zone, nothing appears under the section "Campaigns linked to the zone:" Is there some additional configuration I'm missing, to allow this campaign to be linked to this zone, so its banners can be displayed?
-
The debug file is no longer blowing up, but the hourly maintenance process modifies the priority column value in rv_ad_zone_assoc in a way I don't understand. I have one campaign for one advertiser with nine banners and another campaign for a second advertiser with one banner. Everything has the same weight. The maintenance process sets all the priority values to 0.005. The result is that most requests for a banner return blank. I can manually modify this by running this sql command, update rv_ad_zone_assoc set priority = 0.1; then every request returns a banner, but in the next hour, the maintenance process returns all values to 0.005. I don't see anything in the UI settings that gives me a clue why the maintenance process sets such a low value.
-
I may have resolved my issue. I truncated rv_log_maintenance_statistics, which only had rows up to 2020-03-20 from the old 4.1.4 version of Revive. I shutdown the mariadb service truncated the debug.log and restarted the service. Besides info and debug statements, It spit out a bunch of error statements like: PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_c using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_c : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_a using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_a : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_m using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_m : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_r using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_r : PEAR::raiseError: PEAR :: DB_DataObject Error: autoload:Could not find class DataObjects_Data_bkt_vast_e using class_location value : PEAR::raiseError: PEAR :: DB_DataObject Error: factory could not find class from data_bkt_vast_e : It repeated the above sequence a second time. The first time was for OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the operation interval and the second time was for OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the hour After that, there were many info and debug entries, finishing with Automatic Maintenance Task Completed I'll continue to monitor the debug.log file, but so far, it's not blowing up. :
-
More info: This morning I found that the server had crashed. It was out of disk space. I traced it to the var/debug.log file. I replaced this file with a zero byte copy and restarted the mariadb service. The server resumed, but after a few minutes, I noticed that debug.log was blowing up again. I stopped the mariadb service and the debug.log stopped increasing. Looking at the contents of debug.log, it's running a maintenance task, but it thinks it needs to go back to the last day before the previous version was shutdown, over three years ago. Does anyone know how to reset the starting point? Below is a summary of the log, without all the php trace info. Running Automatic Maintenance Task Running Maintenance Engine OA_Maintenance_Auto::run: Running Maintenance Statistics Engine OX_Maintenance->run: Task begin: OX_Maintenance_Statistics_Task_SetUpdateRequirements OX_Maintenance->_runMSE: - Maintenance start run time is 2023-09-08 13:29:20 UTC OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the operation interval OX_Maintenance->_runMSE: - Maintenance statistics last updated intermediate table statistics to 2020-03-20 20:59:59 UTC OX_Maintenance->_runMSE: - Current time must be after 2020-03-20 21:59:59 UTC for the next intermediate table update to happen OX_Maintenance_Statistics->run: - Getting the details of when maintenance statistics last ran on the basis of the hour OX_Maintenance->_runMSE: - Maintenance statistics last updated final table statistics to 2020-03-20 20:59:59 UTC OX_Maintenance->_runMSE: - Current time must be after 2020-03-20 21:59:59 UTC for the next intermediate table update to happen OX_Maintenance->_runMSE: - Maintenance statistics will be run OX_Maintenance->_runMSE: - The intermediate table statistics will be updated OX_Maintenance->_runMSE: - The final table statistics will be updated OX_Maintenance->run: Task complete: OX_Maintenance_Statistics_Task_SetUpdateRequirements OX_Maintenance->run: Task begin: OX_Maintenance_Statistics_Task_MigrateBucketData This next section repeats for every hour between 2020-03-20 21:00:00 and 2023-09-08 12:00:00 OX_Maintenance->_runMSE: - Migrating raw bucket data from the 'rv_data_bkt_a' bucket table OX_Maintenance->_runMSE: to the 'rv_data_intermediate_ad_connection' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_a table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OA_Task_Runner->runTasks: - The rv_data_bkt_a table is a raw data table. Data logged in real-time, not operation intervals. OA_Task_Runner->runTasks: - Accordingly, pruning of the rv_data_bkt_a table will be performed based on data that has a logged date between OA_Task_Runner->runTasks: 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) The next section is similar, for the same date range OX_Maintenance->_runMSE: - Migrating supplementary raw bucket data from the 'rv_data_bkt_a_var' bucket table OX_Maintenance->_runMSE: to the 'rv_data_intermediate_ad_variable_value' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_a_var table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OA_Task_Runner->runTasks: - The rv_data_bkt_a_var table is a raw data table. Data logged in real-time, not operation intervals. OA_Task_Runner->runTasks: - Accordingly, pruning of the rv_data_bkt_a_var table will be performed based on data that has a logged date between OA_Task_Runner->runTasks: 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) Another similar section for the same date range OX_Maintenance->_runMSE: - Migrating aggregate bucket data from the 'rv_data_bkt_vast_e' bucket table(s) OX_Maintenance->_runMSE: to the 'rv_stats_vast' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_vast_e table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) The next section is slightly different (pruning 3 tables), but for the same date range OX_Maintenance->_runMSE: - Migrating aggregate bucket data from the 'rv_data_bkt_c', 'rv_data_bkt_m', 'rv_data_bkt_r' bucket table(s) OX_Maintenance->_runMSE: to the 'rv_data_intermediate_ad' table, for operation interval range OX_Maintenance->_runMSE: 2020-03-20 21:00:00 UTC to 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Migrated 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_c table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_m table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) OA_Task_Runner->runTasks: - Pruning the rv_data_bkt_r table for data with operation interval start between 2020-03-20 21:00:00 UTC and 2020-03-20 21:59:59 UTC OX_Maintenance->_runMSE: - Pruned 0 row(s) The debug.log ends in the middle of this process, as this is where I stopped the mariadb service. I'm not sure what else it would have tried to process.
-
Follow up: I'm no longer getting the security warnings. I'm not sure if it was cause by some of the additions I made to httpd.conf, and .htaccess, some permissions I changed via chmod, or from running sudo yum update.
-
More info: It seems like nothing in the database is advancing from the program. I updated the value of account_id for the new row in rv_accounts from 0 to 17, which caused it to appear in the UI and I was able to create a campaign, but again, the campaignid was 0 so I had to manually update it to the next consecutive value. I've also noticed that the date_time value in rv_data_summary_ad_hourly is not advancing past '2020-03-20 21:00:00', where it keeps accumulating more rows every hour around ten past the hour, ever since I restarted the server a little over a week ago. It's as though it's missing some bit of logic that should be advancing primary key values and dates. The value in the updated column of rv_data_summary_ad_hourly is where I see a block of rows for every hour around ten past the hour.
-
Additional info: I looked directly at the database. rv_accounts has a new row for the advertiser I created, but the account_id value is 0. The other sixteen rows have values 1 through 16. Is there some other table that is supposed to keep track of the id sequence?
-
Our 4.1.4 Revive server (AWS EC2 instance) was dormant for an extended period of time. I recently spun it back up, upgraded it to 5.4.1 and switched from an AWS RDS database to a local mariadb MySQL database on the EC2 instance. All data shows in the UI, but none of the changes I attempt to make are saved. I created a new advertiser, the change appeared to be successful, but it didn't appear in the list. When I tried to create the campaign, I received the message below . Any suggestions? PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY PEAR Error DB_DataObject Error: update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY rl_admin Help Support Logout An error occurred Working as An error occurred while accessing the database Due to a problem with the database Revive Adserver couldn't retrieve or store data. If this problem is reproducable it might be caused by a bug in Revive Adserver. Please report the following information to the creators of Revive Adserver. Also try to describe the actions that led to this error as clearly as possible. Version: Revive Adserver v5.4.1 PHP/DB: PHP 7.2.24 / MySQL 5.5.68-MariaDB Page: /www/admin/campaign-modify.php Error: Query: $_POST: Empty $_GET: Array ( [token] => 011a57562904eb222acafa62239a0c0a [duplicate] => 1 [clientid] => 1 [campaignid] => 3 [returnurl] => campaign-zone.php )
-
I'm having the same issue. I recently "revived" an old 4.1.4 server and upgraded it to 5.4.1 When I log in, it displays this message: Your browser was able to fetch some files that should not be accessible. For example: var/cache/README.txt etc/database_action.xml plugins/etc/openXDeliveryLog.xml var/INSTALLED Click here to find more information on how to secure your installation. I followed the suggestion in the link, adding the segment below to /etc/httpd/conf/httpd.conf, but it had no effect. Any suggestions are appreciated. <Directory /var/www/revive-adserver-5.4.1> AllowOverride AuthConfig Limit </Directory>