Out of sync ? #207

Closed
yem127 opened this Issue Jan 12, 2012 · 22 comments

Comments

Projects
None yet
4 participants

yem127 commented Jan 12, 2012

Using pianobar-2012.01.10-3-gb5664c8 (2012.01.10-dev)

When I attempt to login, after I put in my pandora password, I get:

[?] Password:
(i) Login... Error: Out of sync. Please correct your system's time.

Tried on 2 different systems, timed synced with NTP if it matters ...

yem127 commented Jan 12, 2012

I referred to issue #204, but still get the same error

yem127 commented Jan 12, 2012

I'll try by using a proxy again and retest ... odd it wasn't needed for the past little while ...

@ghost

ghost commented Jan 12, 2012

Same here, pianobar (2012.01.10-dev), it just started happening over 4 hours ago.

(i) Login... Error: Out of sync. Please correct your system's time.
@ghost

ghost commented Jan 12, 2012

The commit from issue #205 fixes this problem.

Owner

PromyLOPh commented Jan 12, 2012

Strange. Can you apply this patch[1] and post the output (with the patch
from #205 and without) as well as the timezone you’re in?

This is what I get:
timestamp: 1200252595, local time 1326396595, offset 126144000

The offset is quite large, but without the correction it does not work
for me.

[1] https://gist.github.com/1602545

I've run into this problem intermittently in the past, and when I modify libpiano/xml.c to print out the valueStr, the error appears to be associated with a particular IP address; multiple calls produce different results, depending on which server handles the request. Pandora may have one server in its cluster that dosn't have its time set right. This may or may not be intentional.

@ghost

ghost commented Jan 12, 2012

+3 GMT

Without the patch from #205:

timestamp: 1200256942, local time 1326400942, offset 126144000

With the patch from #205

timestamp: 1200257316, local time 1326401316, offset 126144000

Odd... its now working without the patch ~6hrs after it stopped

@ghost

ghost commented Jan 12, 2012

I think it has to do with the TLS.

The patch from #205 enables TLS when loggin in, while the (2012.01.10-dev) build has TLS disabled while logging in. At the same time, this issue seems to come and go. You might be right, there must be a server thats inconsistent, likely one that handles calls from clients without TLS enabled.

Owner

PromyLOPh commented Jan 13, 2012

So both offsets have been captured without encountering the
out-of-sync-error? I was hoping to see a difference here :/

I doubt it’s related to the certificate itself, btw.

yem127 commented Jan 13, 2012

Well, I recompiled with patch in #205 and I don't get the "Out of sync" message anymore (on 2 different machines that had the problem). Everything works well.
Being out of the US a proxy is required again though (it wasn't necessary for the past few weeks).

Owner

PromyLOPh commented Jan 14, 2012

@yem127: Can you apply the patch from my first post and post the
requested results, please?

balcy commented Jan 15, 2012

The latest version works for me with linux, but if I compile it with cygwin, i get the "out of sync" error.
If I use the patch #205, I get the "playlist end" error.

With the patch #205 I get
timestamp: 1200480454, local time 1326624455, offset 126144001

but without the patch #205 I do only see the "out of sync" message, and the printf-line with the timestamp does not seem to be called at all.

balcy commented Jan 15, 2012

now, also with the patch, I had
timestamp: 1200481541, local time 1326625541, offset 126144000 (this seems to be the normal case)

Owner

PromyLOPh commented Jan 15, 2012

I have a theory. The ASCII timestamp Pandora sends is prefixed with four
random(?) bytes (could be a timestamp). And the NUL-byte seems to be
allowed which obviously breaks C strings. So, if you see the out-of-sync
error apply the patch from [1] on top of git HEAD, make clean && make debug and try again. Thanks.

[1] https://gist.github.com/1615714

@ghost

ghost commented Jan 15, 2012

Patch works ok.

Owner

PromyLOPh commented Jan 15, 2012

Patch works ok
Even more interesting: Does it fix the issue?

@ghost

ghost commented Jan 15, 2012

Not getting the

(i) Login... Error: Out of sync. Please correct your system's time.

anymore, but like some people have indirectly said, the issue seems to come and go. Yet to experience it again with this patch.

balcy commented Jan 15, 2012

unfortunately the patch leads to
Login... Error: Your ip address was rejected. Please setup a control proxy (see manpage).
in my case.
The control_proxy is configured though, and with
"req->secure = true" at PIANO_REQUEST_LOGIN the login works, but the control proxy error comes up while getting the stations...

@ghost

ghost commented Jan 15, 2012

Have you tried with a different control proxy?

balcy commented Jan 15, 2012

no, just with my local one 127.0.0.1:8888, but that used to work fine with the 2011-11-11-dev version till recently. I also can say that it works fine with the patch, if I do not use a control proxy and "proxify" the complete app... Maybe it is a problem with my proxy configuration (tinyproxy) though.

edit: in fact it did work with another control proxy... so the patch fixed the out of sync issue

yem127 commented Jan 16, 2012

@PromyLOPh

I recompiled with your timestamp patch AND the patch in #205:

(i) Login... timestamp: 1200607234, local time 1326751235, offset 126144001
Ok.
(i) Get stations... Ok.

Since applying the patch in #205 I haven't seen the "Out of sync" message.

Owner

PromyLOPh commented Jan 17, 2012

Please forget #205. This does not solve anything as it disables TLS for
getFragment requests only, while Pandora uses TLS for login only.
Diverging from the web player’s behaviour is a bad idea as things tend
to break randomly then (see #202).

@PromyLOPh PromyLOPh closed this in d44f61b Jan 20, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment