Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nitephlight]

hi so like many others here, i am victim to intermittent, seemingly random drops in connectivity to my library server. i typically stream over 3/4G as i have unlimited data, so i thought my issues had to do with optimizing buffer sizes and hand offs as i drive through transitional signal areas.

i spent a month or so optimizing android streaming pathways, then realized by users here that the same issues occurred on strong wifi connections as well. after some long nights and lots of experimentation i believe there are steps that can be taken to minimize this occurrence (if not at least improve performance while it stays alive ^_^). if any devs/beta team could chime in and share some expertise in the matter i think this could be a great start to improving one of the greatest features of mc!

*the likely culprit*
don't worry, it's probably not (just) your service provider or device wifi radio (though from my tests, this will DEFINATELY affect playlist loading and song load times)

(common symptoms)
(as reported by users on this board)

gizmo stops playing and when returning to the phone or switching to the app we see a quick resume play (as if someone hit the stop button) and we are sent back to the connection screen. There is no delay in reconnecting as if the data connection was fine all along.


(for the techinical)
according to logcat, ActivityManager reports the death of our main process jriver.mediacenter.android
this seems to be due to jriver.mediacenter.android/jriver.shared.remote.MainService crashing, though the cause of this requires looking at system and event logs separately

i hope to provide as much technical evidence of this as possible, wading through debug logs takes a bit of time though

Code: [Select]

/(Unknown)(0): 08-15 20:47:52.913   839   854 I ActivityManager: Start proc jriver.mediacenter.android for service jriver.mediacenter.android/jriver.shared.remote.MainService: pid=15493 uid=10140 gids={3003, 1028}
/(Unknown)(0): 08-15 20:50:49.655   839  9803 I ActivityManager: START {flg=0x4000000 cmp=jriver.mediacenter.android/jriver.shared.remote.ConnectActivity (has extras) u=0} from pid 15493
/(Unknown)(0): 08-15 20:50:49.679   839  1471 W ActivityManager: Duplicate finish request for ActivityRecord{4200e410 jriver.mediacenter.android/jriver.shared.remote.BrowseLibraryActivity}
/(Unknown)(0): 08-15 20:50:53.999   839 10202 W ActivityManager: Duplicate finish request for ActivityRecord{414aa098 jriver.mediacenter.android/jriver.shared.remote.ConnectActivity}
/(Unknown)(0): 08-15 20:50:53.999   839  1836 I ActivityManager: START {flg=0x4000000 cmp=jriver.mediacenter.android/jriver.shared.remote.BrowseLibraryActivity (has extras) u=0} from pid 15493
/(Unknown)(0): 08-15 20:51:56.413   839  1836 I ActivityManager: START {cmp=jriver.mediacenter.android/jriver.shared.remote.BrowseLibraryActivity (has extras) u=0} from pid 15493
/(Unknown)(0): 08-15 20:51:57.913   839 10202 I ActivityManager: START {cmp=jriver.mediacenter.android/jriver.shared.remote.BrowseLibraryActivity (has extras) u=0} from pid 15493
/(Unknown)(0): 08-15 20:52:00.054   839  1471 I ActivityManager: START {flg=0x4000000 cmp=jriver.mediacenter.android/jriver.shared.remote.PlayingNowActivity u=0} from pid 15493
/(Unknown)(0): 08-15 20:53:20.687   839 10202 I WindowState: WIN DEATH: Window{41871208 jriver.mediacenter.android/jriver.shared.remote.BrowseLibraryActivity paused=false}
/(Unknown)(0): 08-15 20:53:20.687   839   849 I ActivityManager: Process jriver.mediacenter.android (pid 15493) has died.
/(Unknown)(0): 08-15 20:53:20.694   839   849 W ActivityManager: Scheduling restart of crashed service jriver.mediacenter.android/jriver.shared.remote.MainService in 5000ms

(what this means for the rest of us)
gizmo is grabbing image files and populating our browsing screen. For many of us, that entails a gigantic list of Artists, Albums and intricately designed views that only JRiver could allow us to create. This all happens in the background of the Android OS and is passed to the main Gizmo app once ready. *by switching to other applications and leaving Gizmo to play in the background, we are unintentionally increasing the chance that Android kills one of these activities in such a way that it causes the main app to crash.*

As a test, I began streaming audio over Wifi LAN and immediately switched over to a resource heavy app like Chrome. After approximately 2 minutes of light browsing and perhaps following a link or two over to Play Store, the music stopped. Accessing recent apps and switching back to Gizmo revealed a short glimpse of “Resume Playing”, then immediately restarts the Connection screen which seems to fly through the authentication process faster than the initial load.   


So there are some observations:

- Keeping the playing now screen open will keep (at least) the foreground activity alive

- Walking away from your phone or otherwise allowing it to go to sleep triggers any number of battery and CPU related profiles that can kill the activity

- And the obvious : interruption of data connection, or even transition from one source to another can drop the connection


Of course it doesn’t seem helpful or reasonable to avoid all these things. That being said, here are some suggestions:

BASIC: Settings and tips accessible to ALL user levels

- In your Android Wi-Fi settings, make sure "Keep Wi-Fi on during sleep" is set to "Always"
- In your Wi-Fi settings deactivate "Wi-Fi optimization" (certain devices)
- Disable "Avoid poor connections" under Advanced Wi-Fi settings (once your at home already!)
- Connecting your device to a power source can sometimes enable system profiles that will not sleep critical services!

• RELATED | Developer options > Stay awake: "Screen will never sleep while charging"

ADVANCED: App level settings and OS optimization tricks that can vary in location and efficacy depending on device
DISABLE ANY / ALL TASK KILLERS : I would be remiss if i did not state this explicity and in caps. no matter how much faster you claim TaskKiller makes your phone it is doing more damage than good.



- Avoid launcher redraws: this is one of the biggest sources of lag, sluggishness and hogging of main threads (which in turn may kill other processes to complete). When you rotate your phone from portrait to landscape, the entire home screen launcher must recompose and consume hefty resources in the process. Disable auto-rotation when using Gizmo in the background[/size][/b]. an alternative to limiting rotation (if your launcher supports) is the option "try to keep in RAM". the wording and location of this setting will be different for each launcher (sorry) but what it means is that it will attempt to preserve the launcher memory in RAM when Android tries to clear it when resources are needed.

- EXPERIMENTAL Destroy all activities: Under Android Settings > Developer Options there should be an option at the bottom of the list titled "Don't keep activities". i still have to logcat some evidence of this one, but the rationale behind this is if one of our activities is misbehaving when we're not looking, then just kill every activity as i leave it! this way, i know there's no funny business going on behind my back. the ramification of this slower user experience when using the Back buttons through applications, accessing recent apps, etc.

ROOTED DEVICES: settings and optimizations that require superuser permissions to enable (or even see for that matter)
COMING SOON

[icanrule]

It's nice to see someone trying to stop the constant crashed that I have been experiencing for years.

[Castius]

Android 4.3 doesn't seem to expose many controls regarding this.

I tried a free keep alive wifi app. But it had no affect.
I will see if plugging in helps next.

[nitephlight]

Android 4.3 doesn't seem to expose many controls regarding this.

I tried a free keep alive wifi app. But it had no affect.
I will see if plugging in helps next.

in order to enable developer options in 4.3 you must tap on the setting item that shows your system version 6 times in a row(or so) 

[Castius]

ahh ok
i'll try Stay awake with the power in and see what happens

[Castius]

Ok first try seems to work.
Plugged in with stay on while plugin in. I had not pauses or drops.
The next song after i unplugged and turned off screen. It paused on preparing until i picked up the phone and turned on the screen.