Continuous skipping of tracks about pydora HOT 10 CLOSED

Emailed with @bikexcountry and it looks like Pandora is not returning audio links for certain API keys anymore. I can repro this at least for the iphone API key. In the short term using the internal-tuner keys seems to work. There are a handful of fixes to be made here:

• Detect the missing audio URLs and throw an error
• Update the configuration program to use the internal-tuner keys
• Update the pydora CLI to warn about this issue and tell the user to re-configure
• Implement #8 to avoid blowing past API limits

I'm working on these fixes but don't have an ETA right now.

from pydora.

It seems as if the internal-tuner key no longer works as well.

from pydora.

@izaclorimer can you provide some more reproduction steps? What is not working, are there exceptions or are you seeing song skips? Also can you post your config file without your username and password so I have a starting point for testing? As of right now I'm not seeing any issues with the internal tuner keys on my setup.

from pydora.

Using the API for the Vista Widget on the internal-tuner also continuously skips tracks. Using a free Pandora account.
https://6xq.net/pandora-apidoc/json/partners/#vista-widget

Config:

username = 
password = 

[api]
device = WG01
username = windowsgadget
decryption_key = ...
password = ...
encryption_key = ...
api_host = internal-tuner.pandora.com/services/json/
default_audio_quality = highQuality

from pydora.

I've done a bit more digging into what's going on here. There appear to be two different issues; one impacts pydora the player and the other pydora the API. Both seem to be the root cause of your problems. In all cases I think there are patches and then all the API keys will work again.

First, it looks like Pandora varies responses based on the API key that is used. In some cases it returns a audio quality map with URLs to the audio files and in others it just returns a single URL.

For example, using the internal tuner the response format for station.getPlaylist is this (elided heavily for clarity):

{
    "items": [
        {
            "audioUrlMap": {
                "highQuality": {
                    "bitrate": "192",
                    "encoding": "mp3",
                    "audioUrl": "...",
                    "protocol": "http"
                },
                "mediumQuality": {
                    "bitrate": "64",
                    "encoding": "aacplus",
                    "audioUrl": "...",
                    "protocol": "http"
                }
            }
        }
    ]
}

This is the format the pydora API expects to work with and this works fine. However, using the Android or Windows Vista Widget API key the response is similar to this:

{
    "items": [
        {
            "audioUrl": "http://t1-2.p-cdn.com/access/?version=5&lid=476835810&token=..."
        }
    ]
}

Solving that problem is easy, I've got a working patch for it. The next problem, which only affects pydora the player, is that for all other API keys that are not the Desktop AIR client Pandora is streaming AAC SBR files which are not supported by mpg123. The fix to this one is not nearly as simple.

I've had it on my backlog for a while to make the mpg123 strategy pluggable which would allow alternate strategies like headless VLC (using the rc plugin). This would give a lot more playback flexibility without compromising the interface. I plan to keep the mpg123 backend for now but also add VLC support, which will be the default if VLC is installed.

I'll ship the first patch today but I expect the second one to take a little bit longer. Hopefully I will be able to land it this week and will keep this issue open to track that status. In the meantime using a Pandora One account with the Desktop AIR application credentials should work.

from pydora.

I've got a working version that uses either VLC or mpg123 as an output backend. It prefers VLC if it's installed on the system. The search backend uses your $PATH (it also supports VLC.app for Mac OS) so if you've got VLC or mpg123 on your path you should be good to go. This should support at least Linux and Mac OS X. I don't have any way to test Windows.

Player backends will now also attempt to reject any incompatible audio formats. This isn't a foolproof check but it should at least help in the common case to prevent playlist cycling.

The changes also support the modified response formats for some API keys which allows all existing API keys to work again. I believe all changes to be backwards compatible with current behavior.

Check out the vlc-backend branch and test. It seems stable but I'd like to do some more testing myself before merging it to master and pushing a new release. Please leave feedback here if you find any issues.

from pydora.

The other thing the patch adds is volume control within pydora with a VLC backend using vu and vd.

from pydora.

This works great on my Mac laptop but doesn't work with VLC on Ubuntu. I'm not certain if it's a VLC codec issue or an external issue but I'll do some more research. I'm not ready to release this till I have at least Linux and Mac OS working.

from pydora.

I've done some more testing and it seems that the issue is actually that the ios API key no longer works without a very specific user-agent string (which I have not bothered to find). I'll make an update to the configuration script to prefer android instead of ios and will add a warning to the command line player. Then I think this will be ready for release.

from pydora.

Final changes have been made. The command line client now also blacklists the non-working ios key. Updated pydora-configure to allow it to freshen keys if a config file exists. You will have to do this at least once if you're using the default config which previously preferred the ios key.

I'm going to close this ticket and merge the changes this will be in the 1.9 release later tonight.

from pydora.