Article statistics showing 0 abstract views and 0 PDF downloads

@Gokmen_ARSLAN, where are the other log files form October – in which folder, in usageEventLogs or reject?
Do you use a cron job or Acron plugin? – One of them is necessary to run the scheduled tasks automatically.
Do you have an entry in your DB table scheduled_tasks with class_name = ‘plugins.generic.usageStats.UsageStatsLoader’ ? If so, what is the date in the column last_run?

Best,
Bozana

I activated the Acron plugin.
Yes, there is, see below with last_run: 2017-10-26 10:01:18

class_name

last_run

plugins.generic.usageStats.UsageStatsLoader 2017-10-26 10:01:18

Also,
There is no any record in rejected folder.

All files are in the files/usageStats/usageEventLogs and final record in achieved is the usage_events_20170909.log (files/usageStats/archive).

After this record, it have begun to record the data in the files/usageStats/usageEventLogs (usage_events_20170922.log)

bests

Hmmm… strange…
Can you double check the permissions in your files_dir? – so that the files are allowed to be created and moved…
Also, is there maybe a scheduled task log file (in the folder files/scheduledTaskLogs/) with a more recent date, e.g. from yesterday or today or so?

Hi @Gokmen_ARSLAN

I mean the access permission on the files_dir in the file system, s. https://pkp.sfu.ca/wiki/index.php/PKP_Frequently_Asked_Questions#I.27m_having_file_permission_problems.3B_how_should_I_set_file_permissions.3F.

Also: having the files_dir in your web i.e. ojs root is security issue – you can find some posts about that in this forum…

Do you have the file scheduledTaskLogs/Usagestatisticsfileloadertask-…-20171026.log (i.e. from yesterday)?

Best,
Bozana

Hi again,

Unfortunately, I cannot solve the problem.
I upgraded OJS 3.1, yet there is no change.
The usage statistics do not work.

Hi @Gokmen_ARSLAN

For some reason the scheduled task does not complete correctly for you – it looks like it is started daily and correctly, but nothing happens, i.e. the log files are not moved to be processed and the scheduled task log file not created :open_mouth:
Did you check the access permissions (user, group and their permissions) in your files_dir?

Hi Bozana

Unfortunately, I cannot found where the files_dir is.

Thanks.

It is your files directory, where all the files are saved – I believe you called it “files”

Hi @Gokmen_ARSLAN,

The web user should have write access to that folder and all the files and folder in it – the scheduled task process should be able to create a new file in the scheduledTaskLogs folder and to move the files from usageStats/usageEventLogs to other folders in usageEventLogs folder (stage, processing, reject, archive). Can you double check that?

You could maybe also test this:
remove the entry from your DB table scheduled_tasks where class_name = ‘plugins.generic.usageStats.UsageStatsLoader’.
Then, from a command line tool, run this command from your OJS folder:
php tools/runScheduledTasks.php lib/pkp/plugins/generic/usageStats/scheduledTasksAutoStage.xml.

Interestingly, after deleting the DB table scheduled_tasks where class_name = ‘plugins.generic.usageStats.UsageStatsLoader’, it has automatically begun to work :grinning:
I will checked during several days.

Thank you so much Bozana.

Gökmen

Hi @Gokmen_ARSLAN

Those PHP Strict Standards and PHP Deprecated errors/warnings/messages are not the problem – you can ignore them – the problem is somewhere else. What did not work this time? What is the result? Were any files processed and moved to archive or reject folder? Do you have a new file Usagestatisticsfileloadertask-…-20171030.log (from yesterday) in your folder scheduledTaskLogs?

Best,
Bozana

@Gokmen_ARSLAN

According to your images now everything seems to be fine: the log files are in archive folder and there are new entries in the DB table metrics. So I believe there is nothing more you should do.
See how it will be tomorrow, if the current log file usage_events_20171031.log will be correctly processed and archived.

Best,
Bozana

@Gokmen_ARSLAN

That is OK – the scheduled task is run only once per day and then it is logged when it starts, when the usage stats log file is processed or if an error occurred and when it stops. That is fine/correct.

I just do not understand why did you have to delete it from the DB table scheduled_tasks again – why it did not work automatically :-\ Hmmm… I have no idea at the moment… :-\

The Usagestatisticsfileloadertask-59f95f01c6d54-20171101.log was not created automatically. After deleting the the scheduled_tasks where class_name = ‘plugins.generic.usageStats.UsageStatsLoader’,
It was created the Usagestatisticsfileloadertask-59f95f01c6d54-20171101.log, and, then, the counter-abstract and PDF view changed.
I will check it tomorrow again.

Thank you,

Best,

Dear all,

We have just added the article statistics to our journal and to my surprise, most statistics for the last couple of issues are 0.

Usagestatisticsfileloadertask dated today shows all messages as below:

[2017-11-01 00:44:19] [Notice] Task process started.
[2017-11-01 00:44:20] [Warning] The line number 1 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 2 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 3 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 4 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 5 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 6 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 7 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 8 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 9 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 10 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 11 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 12 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 13 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 14 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.
[2017-11-01 00:44:20] [Warning] The line number 15 from the file /home/jlmcedun/uploads_207_131/usageStats/processing/usage_events_20171031.log contains an url that the system can't remove the base url from.

My base url settings in config.inc.php is as follows:

base_url = "https://jlmc.edu.np"
base_url[index] = "https://jlmc.edu.np/index"
base_url[jlmc] = "https://jlmc.edu.np/index.php/jlmc"

So, whats going on?

Regads,
@anupent

Hi @anupent

How the URLs look like in those usage stats log files?
You have only one journal, correct?
Your URL in the config.inc.php seems to be the default one – no changes/redirection, correct? In that case I think you do not need those two lines in the config.inc.php:

base_url[index] = “https://jlmc.edu.np/index
base_url[jlmc] = “https://jlmc.edu.np/index.php/jlmc

S. maybe also Usage stats warnings: system can't remove the base url - #7 by bozana

Best,
Bozana

1 Like

Thanks @bozana,

I tied looking into usage stats log file but the directory “processing” was empty. There was not a single file. May be I need to look several times to look into its contents.

I do have only one journal.

Only 301 permanent redirect for https://. Otherwise no redirection. I am going to delete the rest two lines and will see tomorrow whether the error persists.

Will follow the link you gave in above post.

Regards,

Now it is working fine. Yesterday’s all view and downloads are now shown.

Thanks @bozana.

How to get the total download counts of all the galley files together (XML and PDF in my case)?