• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Pandora on the EVO

You know, I was holding off - but you are going thru a proxy server to get media.

So you never really connect directly. Sprint says it's ok to bypass that. Maybe a good idea to see:

http://androidforums.com/evo-4g-support-troubleshooting/239470-sirius-xm-not-working.html

And Mr. Ed, since you're rooted - MSL Reader. ;)

PS - I made a unilateral call and submitted for resolution of your profile/PM - third time's a charm, so be on the lookout for that.

EDIT - I'll save the lookup

##DATA# (aka ##3282#)
Edit mode
(enter MSL)
Advanced
http proxy proxy_port=0
http proxy proxy_host=0.0.0.0

If issues or worse, change back to setting shown in readout above.

Interesting...made the change, will report my results.
 
Thanks for remembering the profile issue. U rock

I noticed the proxy in the log as well. Prior to my testing these past couple of days, while I was on myns rsl5...I did edit the proxy info and it had no effect on the skip issue. I do think it will resolve the slew of extra issues I experienced today on the stock Rom. I still think there is some sort of buffer issue going on.
 
Reposting for accuracy, was in a rush before -

##DATA# (aka ##3282#)
Edit mode
(enter MSL)
Advanced
http pd proxy port=0
http pd proxy host=0.0.0.0

They're the last two entries on the advanced page.
 
OK, just a minute, instead of scanning - I read, and your log says:

then
01-14 16:33:59.285 E/HTTPStream( 64): recv failed, errno = 11 (Try again)
01-14 16:33:59.285 I/HTTPDataSource( 64): Retry ... 2 times left

Unless I'm terribly mistaken, that means that you've lost the server connection. errno=11 usually means a resource is lost - be it socket connection, memory, or the ability to spawn a thread - usually.

It's still a "too busy" error - but that doesn't look terribly like a buffer overflow. It looks more like a connection issue.

On 3G - do you have mobile data always on?
 
My original settings:
RTSP proxy port: 554
RTSP proxy address: rtsp.vog.sprintpcs.com
HTTP PD Proxy Port: 8085
HTTP PD Proxy Address: pd.vog.sprintpcs.com

My new settings:
RTSP proxy port: 0
RTSP proxy address: 0
HTTP PD Proxy Port: 0
HTTP PD Proxy Address: 0

Holy crap, how did we not figure this out before. All mobile data applications appear to operate much smoother and faster. Even if this doesn't help Pandora, everyone should do this anyway. I didn't do a speed test before hand but these are my results now:
800kbps down / 300kbps up and ping is ~120ms

I have Pandora running right now. Typically it fails in the first or second song. So far no failures. And the application loads and gets going MUCH faster. No long delays between songs either. Continuing to test all evening.
 
Change those proxy addresses to 0.0.0.0 and the software will love you for not falling into that part of the lookup, if my guess is right. Might make no difference, but it would be what we call canonically correct. ;)



edit - oh yeah, RTSP - real time streaming protocol (forehead slap - I _knew_ that)

Probably would a difference where the http proxy might not...

Very good catch - this might be it.
 
I doubt there is a difference between 0 and 0.0.0.0 since it is working. Frankly, it is working great now and I'm not going to touch it! The internet, facebook, Google Maps, e-mail, everything is working better. I've been through these settings menus before and it never clicked in my head. DUUUHHHH!
 
The buffer is more so the reason we haven't noticed it more.


I am going to check the aria and see of it has anything listed in proxy. Any one have a hero laying around.



And as I mentioned before....I changed these settings previously and Pandora was unaffected.
EDIT....i don't think that when they were changed, all 4 were changed. we will see how this affects it. I am so excited ...and I just can't hide it....

Mobil data is always on. OR is it? What if it sleeps? Much like the factory WiFi sleep policy. Songs buffer...3g sleeps...connection lost somewhere in between. That is one of a few things i am seeing in the log....but I honestly don't know what I am doing lol
 
I know Pandora has its moments of "look at me, I'm working fine now". Then it goes to hell again. So I'm going to run it pretty hard tonight and this weekend and see what it does. Even if Pandora doesn't work better, everything else will....
 
here is my post from the other thread

I am not sure how many noticed my post in the Pandora thread....if you let Pandora start a song and then immediately turn on airplane mode, the song will play through entirely prior to giving an error code. So one of my speculations is this...and appears to match up with my log from today...phone communicates with Pandora and grabs the music which is placed in a buffer.. the amount and location of buffer is currently unknown. It plays the music from that buffer not actually from the realtime stream. Somewhere in this process the 3g radio goes idle. Buffer runs out, 3g wakes but the few second process confuses Pandora server and it picks up a new song. Skips through a few due to confusion until buffer is full again...then repeats. From the duration standpoint this buffer may contain anywhere from 5 mins to 1 hours worth of music. In the event that other services are accessing 3g coincidentally....there is even greater confusion. Not helping matters is the proxy setting Sprint has on the phone. Though my tests on myns with the modified proxy settings made no difference in the skip issue...it still may ne a good idea to fix those at call Sprint and have them send the proxy update to your phone. For those diy out there the fix is in the other Pandora thread and the series xm thread. Those settings may be affecting a number of things and could quite possibly fix web related errors like stream quality page loads etc
 
I doubt there is a difference between 0 and 0.0.0.0 since it is working.

Correct, with well-written code there won't be a difference. That said, I've seen poorly written code (not usual in the Linux world, now that I think of it) - it's your decision. If they're smart, they sense off of port=0 and if it is don't even evaluate the dotted quad. Having seen every measure of screwup and being a ninny, I advocate the 0.0.0.0 setting - for that one day somebuddy writing code just goofs. But yes, dotted quad says you can imply 1, 2, or 3 of the settings.

Mr. Ed - On buffering and 3G mobile data always on: as I recall what I _thought_ I knew, always on will start getting busy when you hit whatever the radios are considering to be the beginning of kinda fringy. (I hope someone more experienced in this will confirm or correct.) We do know that it tends to have an adverse effect on battery life, so it causes something to get busy. You mentioned:

Somewhere in this process the 3g radio goes idle. Buffer runs out, 3g wakes but the few second process confuses Pandora server and it picks up a new song. Skips through a few due to confusion until buffer is full again...then repeats. From the duration standpoint this buffer may contain anywhere from 5 mins to 1 hours worth of music. In the event that other services are accessing 3g coincidentally....there is even greater confusion.
So, what are the possible causes of buffer starvation:


  • poor look-ahead algorithm (app level issue)
    • possible it's not robust in this area, but I'd expect more complaints were that the case - not that there's not enough already, I'm just saying... still, could be
    • really lousy buffer management - hey it happens...
  • service not satisfied (due to net-related processes)
    • cannot establish a connection or takes too long to re-establish
    • pipeline too slow (from server waits, or proxy hops, not related to lookahead)
    • too many errors causing excessive packet re-send requests
  • service not receiving resources as required (due to an OS-related issue)
    • too many tasks
    • some other task is cpu hogging
    • too little memory or some memory issue is causing the OS / processor to work more than normal (a dirty cache or data issue for example)

Don't have a crystal ball, but maybe that list can help your process of elimination. Also, once clearing those, good idea to check both the stock rom as well as your custom one (I think you already mentioned that was your plan) - I saw a very similar attachment as part of (I believe) a defect or test report both at google and at cyanogen (not specific to pandora, tho).

Probably I'm just jawboning but I hope this helps, somehow.
 
thanks EarlyMon..

so far my focus has been

"service not satisfied (due to net-related processes)
cannot establish a connection or takes too long to re-establish
pipeline too slow (from server waits, or proxy hops, not related to lookahead)
too many errors causing excessive packet re-send requests"

just trying to find why.


side note...no increase in internet speeds here at the house after the proxy fix. wifi is unchanged 10dl 2.5 up ...

for whatever reason dload speeds are about half of normal on 3g tonight, I know that is unrelated.
we have been running tests aria vs evo since last friday they have been evo 1 dl and .7 up (tonight upload speeds consistent with what they have been all week.) I'm not going to tell you what the aria has been lol

web based apps and web pages are definitely loading faster though. you tube is blazing.
 
I ran Pandora for about 4hrs before I fell asleep with no failures. And it ran all night. It was running fine when I woke up this morning. I quit and restarted Pandora again. Still running great with no skips. This proxy thing is looking more and more hopeful as being real.
 
Mine skipped on first two songs last night then didn't work at all after that but it was the generic technical difficulty error msg. This was on 3g and WiFi. Going to test on 3g while out and about today. Will post last nights log and a log from today later tonight.


Earlymon, background data is on.

As of right this moment....Pandora no workie on 3g. Only WiFi.
 
Will be testing this proxy settings change myself today after I get off of work. So much for me thinking it wasn;t a network issue (seems like it may have been)!

So can someone enlighten me why all our data is routed through a proxy as a default setting?
 
Earlymon, background data is on.

I can't imagine that's a good idea.

From what very little I've noticed, it's happy to prioritize syncing functions with whatever else is going on. The background doesn't seem to imply - trickle the info in - but rather - this is important, too, handle it for me without me asking.

Maybe entirely moot in this case, but I've had my phone slow down while I knew it was syncing a lot of stuff.

Hey, if I knew I would say, so, not trying to come across as know-it-all, just tossing out ideas.
 
Just gave it a shot. I get this error:
"sorry. I'm unable to retreive music from Pandora.com"
This is over 3G

I switched the settings back to standard and it works fine. So setting things to zero's doesn't seem to work for me at all :confused:

RTSP proxy port: 554
RTSP proxy address: rtsp.vog.sprintpcs.com
HTTP PD Proxy Port: 8085
HTTP PD Proxy Address: pd.vog.sprintpcs.com
Is what I changed it back to
 
I continued to use Pandora all day today. Went for a 17 mile bike ride with. Took the subway home with it. Had it going in the apartment. Not a single skip with the proxy settings at 0
 
I don't think background data can be claimed to have a known response time.

I'm wondering - your background data transactions didn't nail you - so far as you know - because a speed increase fixed it for you.

You don't know - do you? I'm asking - that simply turning off background data to relieve that pipe wouldn't have had the same effect. Or that if you did try that, that it still wasn't a combination of the two, dominated in speed in your case.

Because syncing is variable in scope for each of our particular uses, one person might suffer no issue with background data on while another does.

That's a working suspicion I developed as soon as Mr. Ed said his was on and no-proxy had no effect.

That seems all logical to me.
 
Back
Top Bottom