I have implemented web-audio-api and I am tracking the changes in volume across the file. The volume stops being tracked after 60 minutes. How can I ensure the audio is tracked for the full length of the file (or set the parameter to be something unreachable)?
audioPeak stops after 60 minutes:
It Seems it working perfectly. Please look at db and update
ALTER TABLE tbl_filesforengineprocessing CHANGE COLUMN audio_peak audio_peak LONGTEXT NULL AFTER user_id;
Related
I'm so confused with the pm2-logrotate configuration, i need some help. I've search for documentation and googled with zero result. I just want to rotate the log every week.
I've tried using pm2 set pm2-logrotate:rotateInverval 0 0 * * 0 but the log file generated daily.
I just don't understand that cron stuff and i need some explaination, can somebody explain it to me?
thank you in advance.
While your cronjob seems fine. But there are some other configurations also associated with pm2-logrotate. Like max_size, the default max size of log is 10 MB, if your log exceeds that then pm2 will rotate it. Say, you want to change it to 10GB, then issue this command pm2 set pm2-logrotate:max_size 10G. You can specify the size as you wish 10K, 10M, 10G. I have faced a similar problem when the log got rotated 3-4 times a day instead of following the specified frequency.
Without being wrapped in quotation marks, it's likely that only the first 0 is being read in your interval. So instead of interpreting the interval as 0 0 * * 0, it is interpreted just as 0.
The following should do the trick:
pm2 set pm2-logrotate:rotateInverval "0 0 * * 0"
As for understanding the cron syntax, try pasting the values in here for an explanation: https://crontab.guru/#0_0___0
Your problem is caused because you spelled rotateInterval wrong.
I'm trying to insert timestamp with milli seconds into a database. I tried following steps but haven't had any luck.
Extend field value to milli seconds , with length 26 and scale 3.
Used StringToTimestamp(timestampInString,"%yyyy-%mm-%dd %hh:%nn:%ss.3"), Resulting null value in output.
Modified the default time Stamp in job properties to %yyyy-%mm-%dd %hh:%nn:%ss.3
Design :
Sequential file --> TX --> destination (SQL/Seq file)
Could you please assist a solution for this?
What you tried looks good so far with one exception:
length 26 and scale 3
Using Db2 for example you would need to specify length 26 precision 6.
26 and 3 do not fit as
%yyyy-%mm-%dd %hh:%nn:%ss has length of 20
Specifying microsenonds is extended attriute is also necessary.
Have a try and provide more details of the target system if you still have problems
try below command in transformer stage and set the target data type as per the requirement, it will give the required result:
StringToTimestamp(Columnname,"%yyyy-%mm-%dd %hh:%nn:%ss.3")
Most important thing is to override the default NLS settings in the job with expected format (%yyyy-%mm-%dd %hh:%nn:%ss.3) which you have already completed.
Now, for the microseconds part which is not being displayed, you can enable the Microseconds extended attribute for the field in the target stage used.
Also you can refer this link from IBM which explains a similar scenario
My container registry (gitlab.com) shows to two containers that always have null bytes, no tag id and has been created less than a minute ago. (It does not matter when I log in / refresh the page). If I try to remove them, an error appears
"Something went wrong on our end."
The registry table looks like this:
Tag Tag ID Size Created
c283b7ecd36cead64bb3690a19db96e322722b25 ea3c52324 39.33 MiB 6 minutes ago
e54f14ea1206df27635d09aef6a304ed5c26ede1 null bytes less than a minute ago
ededb73145bf6faef200cbcd49c2d186b47173f2 null bytes less than a minute ago
I can't delete them manually - any idea about this?
Please see https://gitlab.com/gitlab-com/support-forum/issues/3031. We may have to manually wipe these Docker tags until there's a better way.
I am using Meteor 1.5 and package percolate:synced-cron to run a task every day once. After some days I noticed that my previous records inside "cronHistory" collection got automatically deleted (without me personally deleting the records), and shows only past 2 days history.
I am not sure what is wrong with the cronHistory collection. Any suggestions would be deeply apprciated.
I would recommend you to do a little research yourself and read the docs of packages you use. Even better, read the source to understand what kind of code you accept into your codebase. From the docs:
SyncedCron.config({
...
/*
TTL in seconds for history records in collection to expire
NOTE: Unset to remove expiry but ensure you remove the index from
mongo by hand
ALSO: SyncedCron can't use the `_ensureIndex` command to modify
the TTL index. The best way to modify the default value of
`collectionTTL` is to remove the index by hand (in the mongo shell
run `db.cronHistory.dropIndex({startedAt: 1})`) and re-run your
project. SyncedCron will recreate the index with the updated TTL.
*/
collectionTTL: 172800
});
Note the collectionTTL option is set to 2 days.
I have a strange problem. I have a cron set up to check a database for a given date that is entered. If today's date matches the db recond, it supposed to change a value in a db table.
now, for some reason if the cron is set to go off every minute, it works like a charm. If it's set to a certain time, it doesn't fire at all.
(MYDOMAIN is set to the proper domain. )
works with:
* * * * * php -q /var/www/vhosts/MYDOMAIN.com/httpdocs/admin/scripts/includes/check_date.php
doesn't work with:
40 16 * * * php -q /var/www/vhosts/MYDOMAIN.com/httpdocs/admin/scripts/includes/check_date.php
or any variation of that time
any idea why it wont fire on anything else then every minute?
Check that your system time matches the timezone you are expect it to fire in by running
date
Did you try 59 23 * * * ? try the last minute of the day. Maybe the script only works late in the day ...