A post was split to a new topic: Problems after November release
A post was split to a new topic: Not booting after December update
A post was split to a new topic: Issue playing files after december update
Season’s greetings to you and your team and thanks for all the hard work…
Thanks a lot
I updated yesterday without any problems. Everything works fine on my RPI2.
GREAT JOB ! ! !
I wish you a happy new year!
@sam_nazarko I think you made the boot time too fast!
I have some scripts I launch from rc.local. After this upgrade, I noticed they now fail with network problems. I guess it has something to do with network state when rc.local is triggered (i.e. must now launch before network connection is ready, while this was never a problem before). Anyways, solved this by undoing your good work by putting in a manual delay
Thanks for the update!!
Can you share more about the performance tunables for the Pi 1 and 2? Thanks.
Performance tunables are now definable at a per-device level as well as the existing OSMC userland level. This means that we can set some global tunables and override them specifically for Pi 1 and Pi 2 depending on the device for some more fine tuned workloads.
Is there documentation anywhere that shows what these tunables are? Eager to start playing around with configs.
rc.local is not synchronised to the network going up in any way - on my systems rc.local has always run before the network is up. It waits until the network manager starts, but not for the network to actually go up.
If you want to run services after the network is up your best option is to enable “wait for network” in the networking GUI, then create a systemd service to run your scripts, and specify:
In the [Unit] section of the service.
Another option is you could change rc.local to not run until the network is up by creating a file called /etc/systemd/system/rc-local.service.d/local.conf and adding only these lines in it:
[Unit] After=network-online.target Wants=network-online.target
This will delay all scripts run by /etc/rc.local until the network is up, or after a 60 second delay if the network never comes up.
@DBMandrake this is very interesting - thanks for sharing!
I did not think rc.local was synchronized to the network status. It’s just that the boot time sequencing always worked out before (by luck, I suppose), and immediately after the December update the scripts failed every time with network errors. So the boot timing must have changed, at least on my Pi (i.e. the network is now coming up later than it was before)?
Slowing down rc.local with
sleep=10 “solved” the problem. But obviously that is an ugly hack, so I will gladly try your suggestions in order to learn something new.
A post was split to a new topic: Pi b crashing
Just a note- the update to Samba required keyboard input during configuration, but I don’t have a keyboard or easy physical access to the Pi. I had to SSH in and run apt-get upgrade and then do the update through OSMC. I was afraid to run dist-upgrade on its own.
It’s a know issue that surfaced in the last couple of days
However, I already had problems with Airplay before (irregularities when playing music, dropped connections, etc.), but now it doesn’t play anything anymore! For me, Airplay was the most important feature of OSMC/Kodi, so I was hoping it would work flawlessly when I decided not to go for an AppleTV.
Please start a new thread. Did you update your iOS? You should check the OSMC Wiki for iOS compatibility info
Does this fix apply to an issue with PPTP VPN client I posted in November?
Your post does not reference an issue, but rather default, expected behaviour of a network manager. If you would like to enjoy VPN (reliably) with OSMC, you should configure a VPN connection with OSMC’s connection manager, ConnMan. Then your routing table will be persistent and reliable.
I backported some patches that may have caused ConnMan to behave in a less than stellar fashion when a VPN was used.
Is there any documentation or manual that explains how to setup VPN connection with ConnMan on OSMC?
For now, you must create a config file by hand: http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/vpn-config-format.txt
We would love to support VPN in the future, but we’ve not got a VPN setup for us to test. We’ll see what can be done in the future.