I reinstalled osmc 2 days ago and noticed something today. When the pi is on dim mode (sometimes) i can’t access it from my PC. Neither vnc,ssh,or kodi web interface works…but if I press a button on the remote and wake it everything works again.
So is there a sleep function for the wifi? Btw it doesn’t show on my router’s dhcp page as well.
This is highly dependent on your chipset
With that said, by ‘sleep mode’ I understand power management which doesn’t inhibit connectivity but performance.
Sam
yeah, i understand that, i mean the linux distro of osmc…has it been tweaked or has an option to do that ? (deactivate wifi to save power when the device is idle).
Does it have a keep alive option ? some way that checks every X minutes if there is no wifi to try and reconnect ?
-Thanks
Nope. Some logs may help here.
Sam
same thing happened today, twice…
I’ll try this for now (the wicd-curses solution) and report back tomorrow: wireless - How to automatically reconnect WiFi? - Raspberry Pi Stack Exchange
Try adding this to /etc/rc.local before exit 0
iwconfig wlan0 power off
If this helps, then the situation is caused by RT2800 power saving. I can fix it if that is the case.
Sam
Thanks, will try it now…its easy to reproduce the problem, so i’ll post back the result
So far so good, not a single hiccup. Before i could see that its losing connection cause my putty would get disconnected.
I think that fixes the power save mode on the chip.
Isnt it safer to add a small sleep above that, to make sure the pi is connected to the wifi router?
The power management is independent of connection status. I will fix it properly, in the kernel shortly.
Sam
1 Like
unfortunately it did it again today 
I turned the tv on and went to the pi screen and saw that it wasnt connected to the router anymore…actually it couldnt find any networks to connect to. And nothing useful in the logs either: http://paste.osmc.io/urilonehux
Whats the equivalent of ifdown in osmc ? I wanna try something like this:
#!/bin/bash
# Which Interface do you want to check
wlan='wlan0'
# Which address do you want to ping to see if you can connect
pingip='192.168.1.1'
# Perform the network check and reset if necessary
/bin/ping -c 2 -I $wlan $pingip > /dev/null 2> /dev/null
if [ $? -ge 1 ] ; then
echo "Network is DOWN. Perform a reset."
/sbin/ifdown $wlan
sleep 5
/sbin/ifup --force $wlan
else
echo "Network is UP. Just exit the program."
fi
Yes, because rc.local will typically actually run before connman even loads, let alone before wlan0 exists. So it’s very likely that without a 10 second sleep the effect of that command is placebo…
1 Like
In June update, i was getting lots of crashes…with august update i got no wifi…
I can see the usb stick powering off…no lights are flashing, but when i press any button on the remote and move around a bit…it turns back to life after 3-4 seconds…
Latest logs: http://paste.osmc.io/ibahoyelem still no obvious reason for this
This very much sounds like a power supply issue to me
Sam
An issue that occurs with osmc only ? Is that possible ? xbian and openelec didnt do that…neither did the june version.
I did a fresh install now with the August update and this happens.
We clock higher than XBian and OE, so it’s definitely possible. There aren’t many other reports to suggest a widespread problem. I’d definitely try and rule out the power supply as the issue, as all of your issues (with exception of the distorted splash screen) sound like symptoms of an underspecced PSU
Sam
I bought my pi with a 5v2A power supply in Feb…just checked it with the multimeter and the volts are fine. I only got the wifi stick and the wifi keyboard on it…I highly doubt it that 2A isnt enough for only these 2.
This has to be a software issue…it didnt exist in June’s update 
Are you on a Pi 2?
Where did you measure the voltage at?
Sam
Did you measure the voltage while the Pi was running and under full load ? (EG high CPU usage and/or high network usage ?)
If you only measured the voltage with the Pi not connected the measurement is meaningless.
A Pi 2 has no TP1/TP2 so you would have to measure the 5v rail on the GPIO header.
BTW in a previous kernel update we changed a kernel setting which causes the CPU to go into turbo mode on disk access - this means the CPU will be in turbo mode much more often than before, if there is a power issue it is much more likely to occur when the system is in turbo mode a much higher percentage of time.
This was added here:
Add
echo 0 | sudo tee /sys/devices/system/cpu*/cpufreq/ondemand/io_is_busy
to /etc/rc.local. If things improve, then it is a power issue