This morning when launching Pandora it notified me of an update. I let it close and restart, and now, when attempting to authenticate, I get a red bar under the Login button that says "Something went wrong". It is only the desktop app as other methods auth fine.
I did perform both Clear Cache and Reset App Data and Restart under the Help menu troubleshooting.
Machine is a MacBook Pro M3 Pro Max, OS is Golden Gate 27.0.
Thanks!
Hi @tpro , welcome to the Pandora community!
Sorry to hear that you are having trouble accessing your Pandora desktop app.
Can you tell me more about what's happening?
Also, can you upload a screenshot of what you're seeing to this thread? If you're not sure how to take a screenshot, just let me know and I'll be happy to provide you with some additional steps.
Let us know!
I've tried it on a second MacBook with the exact same results. It takes the password, then gives the error above.
I also realized it is throwing the error with an incorrect one also which is pretty telling.
I have also fully uninstalled it and reinstalled from the Pandora-16.0.3-universal.dmg available from https://www.pandora.com/desktop.
No active password managers that ever populate the Pandora Desktop App.
Works fine in any web browsers on either machine, no problems with the app on my phone. It's only the macOS desktop app and after it forced an update from within the app on both machines, possibly after the macOS Golden Gate 27.0 update. I have yet to try it on a non-Silicon / Intel Mac though, but the newest OS I have on one of those machines is Tahoe.
Sometimes I will get the following, but I do not try a password reset as it's working everywhere but the desktop app.
Thanks,
Tim
I found the root of the issue. It seems the newer version of Pandora desktop client is making a call to browser-intake-datadoghq.com for telemetry tracking. Unfortunately when that fails, as in the case of someone that doesn't allow telemetry or tracking, it renders the desktop app useless.
Also, not a free user. Family Plan for too long to remember.
Maybe RUM/telemetry shouldn’t be a dependency injected in the auth flow? Just a WAG.
Moderator Edit: Merged posts
Hi @tpro
Thanks for the follow up and for taking the time to provide those additional details. Your help with testing is greatly appreciated.
One additional question that may help us reproduce the issue on our end: You mentioned you don't allow telemetry or tracking, do you have any privacy, security, or other software installed that blocks or limits telemetry or tracking on your device? If so, please let us know what software you're using.
I've escalated your experience to our internal engineering team for further investigation so they can take a closer look.
Thanks again for your patience and for working with us on this!
A way to simulate this is dev/test is to create a local hosts file entry for the domain browser-intake-datadoghq.com and set it to something like 127.0.0.1 or a bogus private address.
My blocking is done at a network level, no software on the machines required. Sites known for collecting private or configuration information have their DNS overridden. That's what's happening in this case, but normally RUM/telemetry isn't a dependency (intentional or unintentional) in authentication flow or normal operation so I never usually have an issue.
Thanks,
tpro