Android Remote crashes RuneOS

[Dohmar]

Hi Guys
Over the last few weeks I've been playing around with RuneOS extensively, and I've had hard lockups when using the remote control.

My hardware is;
Raspberry Pi3, bluetooth disabled, power management turned off, using wireless onboard for streaming music and control
Suptronics x400 DAC HAT, fed via 12v 5amp converting to stabilized 5v 3amp to Pi via onboard power converters.
Phone is Samsung Galaxy S5 with Rune App. Not using stock android OS (omegamod). Shouldn't make a difference.

When playing music, I can have uptimes of days when only connecting to the pi via ssh or www. The pi is connected to my network via wireless as I dont have cables handy, plus it only cosumes 1/3rd of the wireless bandwidth when streaming flac from my smb share.

Long story short, I can play music, or have the pi idling for days, but the moment i start playing with it using the android remote, it crashes the system. Hard lockup, I cant ssh to it, nothing. I know the pi is getting a sufficient power supply, and it doesnt time out via ssh or www via my PC, so I wonder why this android app keeps making it lock up? I thought it was connected peripherals so I disconnected my DAB+ dongle, my HDD and the USB hub, but I'm almost always guaranteed to have a hardware lockup when using the android app. What gives?

Happy to turn on extensive logging to troubleshoot if someone can guide me through it

-D

[PeteB]

With respect, it might be a WiFi issue and not the remote, or RuneAudio. I say this because this:

I have two Raspberry Pi 2's, one with a hat DAC+ and one with a DIGI+, with RuneAudio on one, Xbian on the other, side-by-side, WiFi dongles, Samsung Galaxy Prime with browser GIU, old Nexus Tablet w. RuneAudio App, HP EliteBook laptop. Both Xbian and RuneAudio sometimes (not always) suffer from communications dropped errors, and lose connection to their UI (unless on the local console). Xbian resets (sometimes in the middle of playing a video), or shows errors.

RuneAudio does not handle those kinds of problems the same way. At least not when the WiFi droputs happen. Adding MPD watchdog improved the web radio experience greatly, but RuneAudio GUI still gets "lost". No worse than Xbian, or Ubuntu Mate, but different symptoms. The more I use the Browser UI or the remote app, the more noticable it is.

As an aside, which Android remote do you have?

edit:

Using Bubble UPnP is the most annoying (or easiest to break), probably because it uses the network more extensively than a remote UI for Xbian or RuneAudio. Other than that, using RuneAudio as a UPnP renderer works like a charm....

[hondagx35]

[Dohmar]

Hi Pete
Its a samsung galaxy s5 with the android rune os software.
Network interruptions are a common occurrence, it shouldnt hard crash the OS though. The webclient and ssh never crash RuneOS, only the remote. SSH uses hardly any traffic, but the webclient traffic should be the same/similar as the remote.

In any case, a loss of network connectivity should only result in a temporary lack of display and an inability to control the pi, it shouldn't crash it. I'm wondering if there are any drivers in development that the pi3 uses (maybe the wifi?) that isn't handling something right. Programs in userspace shouldn't crash the OS.

-D

[PeteB]

Hi,

I agree with what you said about an app should not crash the OS. The app in this case, is running on a separate piece of hardware and communicating over WiFi.

I did not think that RuneOS, running on a Pi, distinguished between if you are using a web browser on a laptop or the Android App on a phone/tablet (?)

...and perhaps I spoke too soon, but your symptoms sounded similar to what I had seen, and in my case at least seemed to coincide with poor WiFi reception in my location, which I can't do anything about for the time being. I will keep an eye out in case I notice anything else that might be helpful.

(back to the Physical Kids' house for me now... )

P.

[Dohmar]

From what I understand, the remote sends traffic to the pi using WebUI code directly, rather than letting a browser interpret it. The remote removes a layer and talks more directly with the server (possibly means more traffic) but this is mostly so the UI of the remote app can stay more responsive than a web interface, and that the UI on the mobile can be customized depending on the screen rotation / portrait or landscape. The UI of the remote is a better interface than the web imho but theres something there that the pi doesnt like, and I'm leaning towards network traffic at the moment.

When I said the userspace apps shouldn't cause the OS to crash, I didn't mean the remote - thats its own program, what I meant specifically was mpd and the discovery agent and the network stack - mpd and the discovery agent run in userspace (i think) and the network stack is part of the kernel. If the network stack is getting too many packets sent from the remote and saturates the wlan buffer, it could cause it to crash if the driver for the network hasnt got collision detection and throttling. Naturally you'd definately see this less often on a wired connection but the wireless is convenient for the time being while it sits on my build desk

-D

[PeteB]

If it is JUST network traffic, then I would try any test that generates lots of it. Even just file copy from a PC to the Pi (which should be limited by either the WiFi network, or the USB2 at the Pi). I have tried this, and the Pi does not crash in my case, but as they say - your mileage may vary.

[Dohmar]

I can rule out network saturation - if it were merely that, then the system would crash the moment it updated an SMB share via WLAN, which is where the network is thrashed out the most. If you install nload you can see a graphic representation of how the network fares.

-D

[ACX]

Hi Dohmar, your issue is both vert strange and interesting. Could you tell me please if you atill suffer from the same behavior also when using a cabled LAN connection? I'd like to remove some variables from the equation before starting to dig into it.

[Dohmar]

Hi ACX
Will give it a shot over the weekend and let you know how I go. Will also be attaching a screen to it when it arrives, so Ill be able to determine whether it becomes inaccessible due to the network stack/drivers dying or whether there is a kernel panic

-D