I´m just going to chip in with one thing, just in case;
I am still under the impression that libcec is exactly the same as in Raspbmc.
The reason I say this is that popcornmix´s libcec version went into his Kodi backport branch even before Kodi 14.0 release and as I have built Helix for Raspbmc for a long time I can say that you cannot even build his backport branch without his libcec version.
It HAS to be the same version, otherwise the wrong libcec is being shipped for Raspbmc but at the same time the Kodi version for Raspbmc is being built with the “correct” version.
I don´t think that this is the case.
Edit: That said, you cannot just switch the lib versions as Kodi depends on them (Popcornmix´s backport branch has patches that depends on his version of libcec both when building and after).
Unless there are different dependencies between newclock4 and the backport branch (newclock4 has more libcec patches)???
Have you actually tested this on raspbmc though or are you just assuming this is the case ?
Have you manually set the time forwards on raspbmc then triggered an ntp sync to cause the time to jump back while you are using cec ?
As miappa has pointed out, libcec should be nearly identical if not identical between raspbmc and osmc - there shouldn’t be any significant differences between the two that would cause one to be vulnerable and the other not.
Until proven conclusively otherwise I am going to assume that the raspbmc version of libcec is just as vulnerable to time shifts and that it just doesn’t exhibit under raspbmc because there aren’t two ntp clients fighting to control the time with one connecting to your dodgy ntp server.
As I said earlier, we will see if we can disable the built in ntp client in connman for the next build.
About ntp - I wrote ealier that it is not ntp dependent issue. If I manually change time via date -s it triggers the “lost connection” too.
Please read my post regarding my testing procedure and test it yourself. It is completely harmless and you can test it on both osmc and raspbmc - I know I did
Logs even when there’s no crash and everything just works?
The pi has been on since yesterday so I can check if it crashed in the meanwhile (once I get home, in ~6 hours)
This is the Raspbmc library: You should be able to drop it in over /usr/lib/libcec.so.2.0.1 as follows:
sudo -s
systemctl stop mediacenter
wget http://download.raspbmc.com/downloads/bin/lib/libcec.so.2.0.1 -O /usr/lib/libcec.so.2.0.1```
My other comment was that ConnMan is likely getting time from DHCP time servers and 'fighting' with NTP. I will disable time updates in ConnMan for next release.
S
I suspected that it won’t work but I tested it anyway:
osmc@osmc:~$ cec-client
No device type given. Using 'recording device'
libcec.so.2: cannot open shared object file: No such file or directory
Cannot load libcec.so
osmc@osmc:~$ ls -la /usr/lib/*cec*
-rw-r--r-- 1 root root 7071368 gru 11 02:44 /usr/lib/libcec.a
-rwxr-xr-x 1 root root 988 gru 11 02:44 /usr/lib/libcec.la
lrwxrwxrwx 1 root root 15 sty 1 1970 /usr/lib/libcec.so -> libcec.so.2.0.1
-rwxr-xr-x 1 root root 3946431 lis 9 18:45 /usr/lib/libcec.so.2.0.1 <-- this is the new downloaded lib
-rwxr-xr-x 1 root root 3681584 gru 11 02:44 /usr/lib/libcec.so.2.0.1-osmc <-- this is the original osmc lib
Maybe it should be somehow compiled for the new system or register somewhere else in the system? Or maybe it depend on some other file that is not in osmc distro.
Please bare in mind that I know absolutely nothing about linux libraries
EDIT: Of course I restarted RPi after switching libs just to be sure.
Unfortunately the same issue occurs (connection to cec lost after time shift backwards). So it is not the libcec.so. Any other thought about the root cause of the problem?
Maybe firmware, or some other dependant libraries?
I mean, this is not critical right now. After addressing the timing issues cec will probably work ok. It is just something that shouldn’t behave like that and I believe the decision is up to you, whenever or not you what to fix it.
I’d categorize this bug as moderate/high because it is not disrupting anything (when the time is correct) but just because nobody can find the root cause.
I see earlier you mentioned tcpdump. If you could get me some captures when it happens I could look in Wireshark and confirm if the network really was causing the clock skew.
Of course it doesn’t really fix the problem, it’s a patch over an underlying problem.
Update: I pinged Lars Opdenkamp (CEC developer) on IRC and he has said that this is indeed a bug and he plans to fix it one day.
hehe finally someone acknowledged that my finding is indeed a bug
Sam if you really want me to i’ll provide the dump but it would require reconfiguration of my sagem router which is a pain in the neck.
Basically it looked like this:
and then the date in system changed to exactly the time that I could see on my routers web interface.
So YES, 100% it was another ntpclient-like process getting time from my router/dhcpd instead of servers listed in /etc/ntp.conf and that is why time changed back and forth.
If you need the tcpdump please let me know, I’ll try to get it for you.
Hey, sorry for not being to help a bit more.
My issue never repeated while I was looking at the tcp dumps running. It worked for a long time, but the next day it wasn’t working anymore, so it’s hard to pinpoint exactly when it fails.
Anyway, hoping the next release will fix it.
Unrelated: Do updates like this come in when updating the system via the UI or do I have to reflash?
and I believe the decision is up to you, whenever or not you what to fix it.