BPanther's Neutrino Forum

OK. I worked for over 20 years for Siemens in CNC (Computer Numerical Control) department as first line support. And a lot of times, time hazardous between concurrently running/starting processes was the most frequent and major problem. So my "obsession" about that.
At this moment I run Neutrino form USB (much easy to change/test) and I added such script:
I down satbox to deep standby and boot again. Reason - time is always sync, tuners starts without problems

But I use VERY old and slow 1 GB Kingston pen. I will reboot unit several times more. But until now - its OK.

Both commands are already build-in. ntp is used by neutrino if time sync set to NTP and the other see extra menu. Why twice?

What "both commands" You mean?
ntpd is not running in original soft. Instead of ntpd You use rdata. I had several problems with rdata implementation so I kill it and run ntpd instead. And please notice that I changed the name of os-cam to "os-cam.1" so it does not starts from any Neutrino build-in script. But it starts after time is sync from user defined script.
It was my suspicion that starting time must be sync for proper tuner operation. Does not matter via net or DVB.

Whats the problem with rdate?
If rdate fails, the date of the image will be used for a first initalisation so os-cam have no problems with an "too old" date or disable the date check in the config of os-cam. And renaming ins not needed if you have the start option off.


EDIT: If THIS really all your bootargs (plus mine for neutrino start), then it's clear why rdate not working! serverip and gatewayip not defined, only boxip (ipaddr) is defined.

Yep. You are right. serverip and gatewayip not defined in bootargs so it can not connect to any server. So the solution is to edit bootargs (more complicated and dangerous) or move start of rdate a little bit later in time. The problem with rdate I notice during my work in Siemens is that if first trial of time syncing fails (because undefined serverip and gatewayip like in our example), the next trials will fails in most cases too. ntpd is much more reliable in the way it work. Thats my conclusion at this moment, but I will test today another thinks too.
By the way. As I see, it is possible to start (by editing bootargs) image form USB pen, using only one ext2/3 partition on US mem, without extra FAT with uImage copied on it. Any expert for bootargs rules editing necessary!

As I say'd you can use the (start with av7000.cmd), or manually with fw_printenv (shows the bootargs) and fw_setenv <what you need to change/add/del>.

OK. I changed vormeutrino.sh script in internal flash and problem wit non starting tuners in back. When I boot image from VERY slow USB mem - its OK. Tuners are always tune.

Strange that you need an slow usb pen for the tuner. Do you start with an uncrypted channel?

Does not matter. Encrypted or FTA. Simply tuners are not correctly tune and signal and/or S/N ratio shows zero.
So I am back to my "obsession" about time hazardous between processes. My theory is, that slow USB mem means that processes during boot procedure had a lot of time to run before nest binary for next process will be loaded. Loading Neutrino from internal flash is much faster (10 times or more in my case). So - for example (but I don know I am right or not) - initialisation of tuners will not ends and another process wants to access once. This is only my personal theory but I have to mention once more that booting from deep standby from slow USB mem, will ALWAYS ends with success.

Well then try in extras to aktivate the param boot delay.
It is especially for slow usb devices, but may be it helps.
The stb waits the choosen seconds in rcS.
But loading tuner driver and other modules will act afterwards, of couse with the same Speed.

Bootdelay will not resolve the problem - i think. Because in my meaning, loading drivers and/or other modules and waiting to finish one before starting another is a problem.

Yes you are right....but this "boot delay" is a delay in rcS for waiting if the usb device fs is ready.
It´s just a try..

OK, wait and be "on the line"

Just the same. I increase delay from 1 to 10 and result is the same.
My suggestion is, that rcS must to be inspected. I mean that for example (but it is only suggestion!) tuner initialisation must ends before next process will access tuners.
And even with my script included in vorneutrino.sh, time is not syncing (does not matter DVB or NTP) when Neutrino boots from internal flash (very fast comparing to USB mem I use).

I revised once more Maxibootloader possibility of configuration. There is no way to define DNS server. So rdata or ntpd can not sync time. Or maybe it is undocumented parameter I dont know about. Its because serverip is an IP address of PC with AAF Recovery Tool running on it. But it is only for recovery procedure.

I found another two issues, but at this moment correct starting from internal flash is most important, lets say "basic" for Ocatagon/Atevio and clones.
I try to "dig" in to rcS, without success so far....