72 replies to this topic

[s3n0]

Hi. Why such a big time difference - so many minutes ? After all, rebooting doesn't take that long, even on old set-top boxes. Rebooting the Linux set-top box takes a maximum of 2-3 minutes. Or does it have some other meaning that there is a difference of 15 and 25 minutes ? A difference of 5 minutes or even less (eg 2-4 minutes) would really be enough. And not 10 minutes.

[daviddrf]

OK @s3n0, then I will edit the crontab to go to standby only five minutes after reboot instead of ten (08:20 instead of 08:25). Thanks in advance for your advice.

Edited by daviddrf, 9 March 2024 - 12:47.

[s3n0]

Why do you actually want to perform this reboot ? What is the reason ? Is something not working correctly ? Maybe it could be solved in another way. Hmmm...

[daviddrf]

Everything is working fine, thank you.

[Qu@rk]

OpenPLi 8.3

root@vuduo4k:~# opkg list | grep cron
busybox-cron - 1.31.0-r0.89 - Tiny versions of many common UNIX utilities in a single small executable
cronie - 1.5.4-r0.0 - Cron daemon for executing programs at set times
cronie-dbg - 1.5.4-r0.0 - Cron daemon for executing programs at set times - Debugging files
cronie-dev - 1.5.4-r0.0 - Cron daemon for executing programs at set times - Development files
cronie-doc - 1.5.4-r0.0 - Cron daemon for executing programs at set times - Documentation files

root@vuduo4k:~# ps | grep cron
 1399 root      2756 S    /usr/sbin/crond -c /var/spool/cron/crontabs

I use crontab -e to edit my crontab.

 

My crontab entry:

5 3 * * 0-6   /sbin/fstrim -v /media/hdd | awk '{ print strftime("%c: "), $0; fflush(); }' | tee -a /var/log/fstrim_cron.log

The "0-6" is for testing only, my plan was to do this once a week at Sunday (0).

 

My box starts every morning at 03:00 for EPGRefresh. EPGRefresh needs 10 minutes.

 

The cronjob works if I set it for example every 2 minutes (*/2 * * * *  ...).

If the box is running already and I change the time to something in the near future, it works.

 

Yesterday EPGRefresh started the box at 03:00, but the cronjob was not started.

Tonight the box recorded a docu from 02:25 to 05:19 but the cronjob was not started.

 

What am I missing here? Thanks.

[s3n0]

Hi.

 

I don't understand exactly what doesn't work. I don't know if it is possible to "pipe redirect" the output on the CRON command line. Maybe it would be better to make a shell script and do everything necessary in it. And then you start only this one shell script in the CRON scheduler.

 

However, if I understood it correctly, your entry of sheduled time is also wrong. It is also bad for testing. If you want to test, then test only at a certain hour and minute... and always wait to see if it works (that the command line was launched as you wished). So you just set the hours and minutes... of course forward +5 minutes and then just wait for the command line to start.

 

You are try the following: https://crontab.guru/#5_3_*_*_0-6

It means:   05=min   03=hour   day=all    month=all    workingday=0-6only

 

So, for the purpose of testing, if the time of the clock is, for example, right now 9:50, 19.8.2024, then... I will set the time planning there as:
55 09 * * *            /some-command-line

Explanation here: https://crontab.guru/#55_09_*_*_*

 

Don't forget to restart the CRON service after each change:
OpenPLi:   /etc/init.d/busybox-cron restart
OpenATV:   /etc/init.d/crond restart

 

Please write more precisely what you want to achieve or what exactly does not work.

Edited by s3n0, 19 August 2024 - 08:48.

[Qu@rk]

Thank you very much for your immediate reply. 

 

As I mentioned in my previous post, the cronjob works perfectly fine if I set a fixed time in the near future while the box is running already.

 

For example for testing as you suggested

 

55 9 * * * /sbin/fstrim... 

 

But if the box was started for EPGRefresh or for a recording the cronjob would not run. 

Edited by Qu@rk, 19 August 2024 - 09:12.

[s3n0]

So your question is not about CRON scheduling, but about start of the recording via the command line ?

 

Why don't you use GUI (SKIN, with the help of the RCU) to set the planned video recording from DVB reception ? :-P

 

Or use the debugger for CRON and try to see what errors CRON makes - more precisely what errors this command line makes in CRON. However, I don't know OpenPLi very well. I don't know how to use the debugger for CRON in OpenPLi.

 

In case no one writes how to start or how to debug CRON in the case of OpenPLi, try starting a shell script instead of a complex command line. For example:

55 09 * * *    /bin/bash /usr/script/start_video_recording.sh

 

- content of the "start_video_recording.sh" file:

#!/bin/bash
/sbin/fstrim -v /media/hdd | awk '{ print strftime("%c: "), $0; fflush(); }' | tee -a /var/log/fstrim_cron.log

And of course don't forget to assign shell script attributes to the file:

chmod a+x /usr/script/start_video_recording.sh

..or..

chmod 755 /usr/script/start_video_recording.sh

 

 

EDIT:

 

I still don't understand exactly what you write. In one sentence you write that CRON works perfectly. However, in the next line, it does not work at all EPGrefresh launch as well as video recording from DVB.

Edited by s3n0, 19 August 2024 - 09:36.

[Qu@rk]

Thank you very much. 

 

I want to execute the fstrim command at a specific time of day and write the output of the command in my own logfile.

 

If the box is up and running and I create the corresponding crontab entry for testing for a point in time in the near future the job works perfectly fine.

 

If I set the time to 03:05 (5 3 * * 0-6) and the box is started by an EPGRefresh event at 03:00 or a recording event before 03:05 the job will not be executed. 

 

I will test this again with a crontab entry for 03:05 with no specific day of week tonight. 

 

5 3 * * * /sbin/fstrim... 

 

My box starts every morning at 03:00 for EPGRefresh unless of course there is a recording already running. 

 

I hope that's clearer now. 

Edited by Qu@rk, 19 August 2024 - 10:00.

[WanWizard]

If it is started from deep standby ( = off ), it is possible that the box doesn't have the correct time yet, the box doesn't have a realtime clock chip, like PC's have.

 

You can check this in /var/log/messages:

grep cron /var/log/messages

it should show all cron activity, and the timestamp.
 

[Qu@rk]

Thank you, that's what I assumed. My box starts from deep standby.

 

How long does OpenPLi 8.3 need to get the correct time (it's connected to the internet)? 

There is also a cronjob for ntptime but set to 30 * * *. 

 

Is there a timesync directly after boot? 

 

Tonight the box started at 02:25 for a recording and still did not execute the cronjob set at 03:05.

 

That's why I set the job to 03:05 to give the box enough time if the EPGRefresh event starts it at 03:00.

 

At an event the box starts from deep standby to "normal" standby. 

Is there a difference regarding time sync between "normal" standby and fully active (ON)?

 

I will check the messages log the next time when I start the box.

Edited by Qu@rk, 19 August 2024 - 10:17.

[WanWizard]

If the box is configured for NTP, it will fire an ntpdate command as soon as the network interface comes up via a post-up script, and after that once an hour via a cron job.

 

The log will show you what ntpdate does, and the effect it has on the time (i.e. the value of the log timestamp).

 

If the box is configured for transponder time, it will sync with the transponder on every zap.

 

On a VU+ 4K box, the only difference between standby and on is that in standby, the tuning is not active, and on non-FBC tuners, the power on the LNB is turned off.

[Qu@rk]

Thank you very much. Great explanation and nice hints.

Yes NTP (should) is configured and a cronjob with 30 minutes interval has been created.

I will check the logs.

Edited by Qu@rk, 19 August 2024 - 10:31.

[s3n0]

Well, you should have written that right away... that the problem occurs when the box wakes up from deep standby.

 

It would immediately be clear that the problem will be in the unset real-time clock .

 

Most set-top boxes do not have their own RTC chip - i.e. a battery-powered chip that would work independently of the Linux system and Enigma2.

 

This means that when the microprocessor is suspended, the clock synchronization does not work. Therefore, it is necessary that Linux be put into operation - at least in classic standby mode, not deep standby. In other words, even in standby mode, then of course the microprocessor works - and then the real-time clock synchronization in the Linux system also works.

Edited by s3n0, 19 August 2024 - 12:30.

[Qu@rk]

If the box is configured for NTP, it will fire an ntpdate command as soon as the network interface comes up via a post-up script, and after that once an hour via a cron job.

 

The log will show you what ntpdate does, and the effect it has on the time (i.e. the value of the log timestamp).

 

If the box is configured for transponder time, it will sync with the transponder on every zap.

 

On a VU+ 4K box, the only difference between standby and on is that in standby, the tuning is not active, and on non-FBC tuners, the power on the LNB is turned off.

 

The box has the correct time immediately.

Aug 19 13:17:29 vuduo4k syslog.info syslogd started: BusyBox v1.31.0
Aug 19 13:17:29 vuduo4k user.notice kernel: klogd started: BusyBox v1.31.0 (2022-05-04 23:45:55 UTC)
Aug 19 13:17:29 vuduo4k user.info kernel: [    0.000000] Booting Linux on physical CPU 0x0
Aug 19 13:17:29 vuduo4k user.notice kernel: [    0.000000] Linux version 4.1.45-1.17 (oe-user@oe-host) (gcc version 9.2.0 (GCC) ) #1 SMP Sun Jun 16 19:08:06 UTC 20>
Aug 19 13:17:29 vuduo4k user.info kernel: [    0.000000] CPU: ARMv7 Processor [420f1000] revision 0 (ARMv7), cr=30c5383d
Aug 19 13:17:29 vuduo4k user.info kernel: [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Aug 19 13:17:29 vuduo4k user.info kernel: [    0.000000] Machine model: DUO4K

And 7 seconds later ntpdate was executed.

Aug 19 13:17:36 vuduo4k daemon.notice ntpdate[1380]: step time server 131.188.3.221 offset 1.728197 sec

I have no idea why my cronjob is not started.

 

My crontab:

30 * * * *    /usr/bin/ntpdate-sync silent
# run fstrim jeden Tag um 03:05 Uhr
5 3 * * *    /sbin/fstrim -v /media/hdd | awk '{ print strftime("%c: "), $0; fflush(); }' | tee -a /var/log/fstrim_cron.log
# min hour day month dayofweek command

I changed the day of week to * but it shouldn't make a difference. Let's see if the job runs tonight when EPGRefresh event starts the box at 3:00.

Edited by Qu@rk, 19 August 2024 - 13:37.

[WanWizard]

My guess is that you rebooted, and not switched the box into deep standby ( i.e. off ).

 

The box does have a clock circuit, but it isn't powered by a battery, as @S3no already mentioned, but with a small capacitor. Which means it won't loose the time on reboots, but it will if the box has been switched off for more than a few seconds.

[Qu@rk]

The box was in deep standby for about 3 hours.

But it is possible that the capacitor is big enough to bridge this time.

 

I performed another cycle from deep standby to ON with only a few minutes in deep standby.

The time was still correct.

I wanted to test whether ntpdate is executed again shortly after startup. 

After 8 seconds ntpdate was executed.

 

The time should therefore be correct shortly after system startup.
Correct?

 

If it still doesn't work I will have to write a init.d script. Maybe also a test script that creates a backup of the messages log. Or is there a way to preserve the messages logfile between reboots?

Edited by Qu@rk, 19 August 2024 - 15:53.

[mrvica]

it is a feature, otherweise the timer recordings from the deep standby wouldn´t work at all, maybe I missed the point you are talking about

[WanWizard]

The box was in deep standby for about 3 hours.

But it is possible that the capacitor is big enough to bridge this time.

 

No, it isn't, it lasts seconds ( i.e. just enough to keep time on a warm boot).

[WanWizard]

Just to be complete: you have checked if

/sbin/fstrim -v /media/hdd

works, before trying this? If it outputs an error, the rest of the command won't execute.