Invalid username and/or password #654
Comments
|
I just ran into this same issue this morning. On my system I made no OS changes, I was using it successfully on Pithos 1.5.0 yesterday and this morning it isn't working with the same "Invalid username and/or password" message. I confirmed that I can log in through the pandora website (works fine) and I attempted upgrading to Pithos 1.5.1 (same error). So this sounds like something done on the Pandora side :/ |
|
Same issue here with Pithos 1.5.1 and Pithos 1.1.2. Was working fine then stopped. |
|
Same issue for me on Fedora 34 as of today, pithos-1.5.1-1.fc34 |
|
Me too. Worked fine yesterday. Maybe a change on Pandora's end? |
|
Same issue with both pianobar and pandoroid. all 3 stopped working just now at the same time, while the web page works, so, Pandora changed something on their end. |
|
Same here. Flatpak version 1.5.1 on Ubuntu 20.04. The "Getting Started" page at https://developer.pandora.com now says only "We're not accepting new access requests at this time. Please check again later." Seems a little onerous. BTW: I created a ticket with Pandora to get an official comment on any changes to (or deprecation of) the API. I will add more when I find out... |
|
Same. Pandora 1.5.1 on Fedora 34. |
|
Pithos 1.5.1 on Ubuntu 20.04 and FREE Pandora account is working. |
|
Pithos 1.5.1 on Ubuntu 20.10. Tried with a paid and a free account. Login fails on both. |
|
Pithos 1.5.1. on Ubuntu 20.04 -- failed with Pandora Plus account (worked yesterday). https://community.pandora.com/t5/Desktop/Can-t-log-in-on-pithos/m-p/68179/highlight/true#M5300 Are there other streaming services that are friendly to Ubuntu? Update: It's working again. I guess our wee bit of advocacy helped. |
|
I have an active Pandora Plus account. Replicated on Pithos 1.5.1 (source), but happening on Pithos 1.1.2 from Ubuntu repo as well: ERROR - pandora:json_call:142 - fault code: 1001 message: Invalid username and/or password Pithos 1.1.2 can be fixed by unchecking the "Pandora One Subscriber" option. However, this isn't present in Pithos 1.5.1 (source), and continues with the same error. |
|
There is a thread going on with the Pandora community site about this: https://community.pandora.com/t5/Desktop/Can-t-log-in-on-pithos/td-p/68153 |
|
@clarkevans Spotify seems to have a Linux client that gets updated occasionally, but is not officially supported: https://www.spotify.com/us/download/linux/ -- update: Correct information about Spotify Linux support. |
|
It just started working for me again. I turned in a support request to Pandora and got an inane "This is an unauthorized app" response from a level one tech. I asked that it be forwarded to a developer, and now it seems to be working again. Can someone else verify its working again? |
|
I can verify that it's working again with the latest master. |
|
Can confirm Pithos 1.5.1 Flatpak and Ubuntu 1.1.2 deb are working. |
|
Pithos 1.5.1 starting working again for me after a reboot. |
|
Working again. Pianobar and Pandoroid also. |
|
Same thing seems to be occurring again... |
It appears to just be a service outage. |
|
Unfortunately it persists. Web login works, Pithos login does not. |
Mine is working. Pithos 1.1.2 from repo. |
|
I don't know which repo you're using (I'd guess an Ubuntu one as they all seem stuck at 1.1.2?), but as a comparison I'm using the latest commit to git master on Arch (via |
Yes, the Ubuntu repo. Also, the Pithos FlatPak 1.5.1 is working for me and allowed me to sign in. |
|
1.1.2 also returns |
|
1.5.1 (locally compiled) is working fine for me. Premium account with a login. |
|
"Question remains, why does the web interface work fine but Pithos no longer?" I don't understand how this is any mystery to anyone who has ever used a client/server app even once, but I will answer. First, terminology: Pandora is a service, and both the Pandora browser player and Pithos are clients. Of course any service will always work perfectly with it's own clients. Of course any unofficial clients created by incomplete reverse-engineering of undocumented protocols and apis to any service will only ever work on good days when you're lucky, and even that only for a finite time. This isn't just Pandora but anything anywhere since forever and for forever. If you write a server and a client, they will obviously work perfectly with each other. If you write a service, and I write a client for it, but I don't have a copy of your server source code to consult, and you don't give me instructions, then maybe I will be able to analyse the network traffic between your client and server and deduce how it works and how to get what I want out of the server. But probably I will never figure out every detail fully and correctly. If I do manage to get your server to service requests from me, you could modify the server at any time and my client no longer works, while your own clients keep working. I will never be able to perfectly emulate your own clients, so from the server side you will always be able to identify requests which came from unauthorized clients. There are countless infinite details that can be used to do that. Even if I magically figure out all the actual API and encryption keys and undocumented little things like uuids or sequence numbers etc... there are still things like patterns of use and timing etc. For an example, you might know that your own client always does command A then B then A again, and never just does A then B and stops, or A then B then C etc... Another example, you may know that your own client always takes at least 200ms to do B after A. If a B request ever comes in less than 200ms after an A request, that can't possibly be your client. There are essentially and infinite number of behavioral characteristics like that that would take forever to map out by reverse-engineering, and I'll never create a client that perfectly emulates yours, and you'll always be able to tell the difference from the server side if you want to bother. The web interface is just another Pandora client written by Pandora themselves. The fact that it runs in a browser doesn't change anything really. Ultimately it makes it only slightly more open to reverse engineering than any other app that talks over the network. So it's not remarkable at all that one day a working client stops working, because services change occasionally, whenever they feel like, and clients need to change to work with the new service. As the author of a service, you can effortlessly make any changes you want and update all of your own clients to match. And since you wrote both the server and cleints, you can even figure out changes that will keep your own old clients working (like say apps built in to TV's and AVR's and car stereos, that can't or won't be updated by the users) even while breaking any unofficial clients. In this case with Pandora and Pithos, the totally normal and expected process played out. 1.1.2 used to work, Pandora changed in some way and 1.1.2 stopped working, pithos was updated, and the current version works. Old versions of pithos will never work again because the service they are written for no longer exists. 1.5.1 will stop working at some point too. That could happen at any minute. And the web interface and all other official Pandora clients will of course keep working just fine. |
|
The question wasn't just "why doesn't Pithos work", it was "If Pithos works for other people, and the web interface works fine for me, then why doesn't Pithos work for me?" If the issue was due to them removing support for Pithos then it would have broken for everyone. If the issue was due to them blocking my IP address/range then the web interface wouldn't work. Something else must have changed, hence the question. |
There are literally countless ways for that to happen. If you want to know, you would have to investigate yourself on your end. Capture all network traffic entering and leaving your machine and try to use both clients and see what was different. something was different. The two clients accessed different IP's or resolved hostnames from different dns sources or issued different commands or supplied different data in those commands. Also firewalls and services can firewall behaviour, not just ip addresses. Also it's possible for the web interface to work in a totally different way from normal clients. For instance it's possible for say an Android app to issue some kind of ordinary api request directly from the client to a server. It's possible for a web interface to work in an indirect way where maybe the UI code in your browser that you interact with does not issue the same sort of direct api requests but instead just tells some kind of intermediate server to do that request, and the actual mp3 stream to your browser is coming from that intermediate server using a totally different mechanism than the Android app. It could be anything. Probably this example isn't really happening just like that, it's just an example of the infinite ways in which your observed symptoms could happen. It's completely normal and not a mystery or remarkable at all. |
AKA "I don't know". All of what you say may be valid in a general sense, but the fact is that it's not down to the difference between web client and Pithos. It has been established by other people that Pithos itself works, therefore Pithos - as a client - is not being blocked or firewalled by Pandora. If you're saying that Pandora employs some sort of TCP/IP traffic inspection that classifies certain traffic from certain IP ranges differently then I'm not sure how capturing local network traffic is going to help identify that. On the other hand, if the difference is that Pithos works for people with a Premium account but not for Free or Plus accounts, then that would be a cognitively straightforward reason - frustrating, disappointing, but at least understandable. |
It's not knowable, except by you, since the equipment is in your posession, not anyone else's. Tech things don't get solved any other way than methodically. When I say there are countless possible ways to produce a certain outcome, I'm telling you that there is not enough information present to even think about guessing about causes. If it were my machine having this problem, I would be doing one of two things depending on how much effort it was worth to me to figure out: 1 - Diagnose. Methodical splitting and elimination of domains. Try pithos on another machine on the same network. Try pithos on the same machine on another network. Try logging all network traffic and diffing the two clients actions. Try enabling all possible debug verbosity in pithos and maybe simply read the error in plain english in an error message. 2 - Live without pithos or update to the working version if any, but either way NOT be mystified at all. Because without doing the work to diagnose something, of course you can't know what the problem is. And neither can anyone else. And the fact that the web interface works and some other client doesn't, and all the other facts that you present as being inexplicable, are totally explicable. The problem is that they are explainable by too many possible explainations. Why doesn't my printer work? Everyone else's printer works in the same office. I can print to other printers. Other people can print to this printer. My printer at home works. Before I ate this ham sandwich, it worked, now it doesn't, so I stopped eating ham sandwiches, and it still doesn't work! No one else can possibly know why my printer doesn't work because I haven't actually said anything that eliminates any possibilities. The thing could be out of paper. The drivers could be disabled. I might always happen to try to print at the same time every day just after the cleaning lady unplugs it to plug in a vaccuum. It might only work on the wired lan and my machine is configured to try to connect to it by wifi or even bluetooth, or maybe it even still works by wifi but I changed my wlan card properties to only use wifi6 or 5g and the printer only has 2.4g. I might be sending print jobs with A4 size while the printer knows it only has Letter size paper and needs front panel input to override. A-NY-THING. You don't know whay my printer doesn't print, but it's not because "AKA I don't know", it's because it's not knowable based on the ham sandwich problem report. If you're not in IT yourself, then it's perfectly understandable if you don't realize that you haven't actually said anything that shows any kind of paradox or contradiction. But that is what I am informing you of right now, that your observed puzzle is no puzzle at all. If you want to know what the issue was, you have to look into it. If you don't look into it, then it will simply go unknown. But the supposed discrepency between an old version of pithos and the web site on the same machine at the same time, is really nothing remarkable at all. You might as well have said "The web interface works, even though my cat meowed, that shouldn't be possible? What could possibly explain that?" |
|
I'm glad you can provide some useful tips on diagnosing a ham-related printing issue. Now - back to Pithos. The Pithos client is, as you point out, fundamentally different to the web client. For example, Pithos authorises with its own API ID and key, and connects to different back-end servers (e.g. This means that capturing network traffic from Pithos is going to highlight those same differences, but won't let me see a comparable working trace. I'd have to find out why Pithos isn't working to be able to connect to be able to see why there's a difference. Unless - you could provide a network trace for a working connection so I could compare the two? |
|
Try pithos on another machine on the same network. Boot a live thumb drive on the same machine if you have no other. But remove your entire installed OS from the equation, meaning not just try a vm. I mean you could try a vm too, and if it works, then that provides useful info, but if it doesn't work then it doesn't provide any info because all network traffic still had to go through the host machine. Try pithos on the same machine on another network. Enable hot-spot on your phone or go to a coffee shop etc. Ideally try to make sure it's a different ISP, like if you have a cable modem at home, the local coffee shop probably also has the same cable company, so your phone is better if possible. I mis-read something earlier. I see now you said that not only 1.1.2 but a current 1.5.1 also doesn't work for you? It is possible for the same client to possibly work different for different people bevcause of course these days there isn't just one server for any big service, there are many behind load balancers, and it's common for code to be different on different worker nodes for a/b testing and gradual updating. Still, it makes a little more sense to assume the server more or less the same for everyone until really proven not, and if both 1.1.2 and 1.5.1 are not working for you, and consistently, then it's probably something on that client machine, like maybe an ssl library or something. I will try 1.5.1 and 1.1.2 without login credentials just to remove that variable. |
|
@jonathonf , have you tried resetting your password on the Pandora site and see if that allows Pithos to work again with the new password? Maybe something is out of sync on the Pandora side. And like @bkw777 said, try it on another machine, preferably with a different distro like Ubuntu/Mint live disc. Make sure it's not something on the machine or with the distro. |
|
Did this break again? Pithos no longer working for me, same error "INVALID_AUTH_TOKEN". |
|
Working for me just now. paid account. |
Working for me as well. Pandora Plus account. |
|
ok thanks. not sure what is wrong then. Will look deeper. |
|
I just wanted to say that this happens to me when on VPN. Works fine on an unencrypted connection. |
|
The problem eventually resolved itself. I was never using a VPN.
…--
Sent from Rob McMillin’s iPad
Dramatis personae: ONB Libby, NESR Jed, and various NESR fosters
Location: Woofwood, Little Rock, AR
On Oct 30, 2022, at 09:52, BigCityCat ***@***.***> wrote:
I just wanted to say that this happens to me when on VPN. Works fine on an unencrypted connection.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
After a recent update to my Fedora installPithos stopped working with the following message:
ERROR - pandora:json_call:233 - fault code: 1001 INVALID_AUTH_TOKEN message: Invalid username and/or passwordI'm sure the creds are correct because I can correctly login from the website. And they haven't changed between when pithos worked and now.
Pithos 1.4.1
Fedora 33 - pithos.noarch 1.4.1-9.fc32
The text was updated successfully, but these errors were encountered: