[SOLVED] Mopidy-pandora works but extremely sluggish

Not sure if this is really an issue w/ mopidy-pandora or even pydora but they’re both so slow as to be unusable.
I did suspect a network latency issue but other wireless LAN clients (Ubuntu) have no such problem.
Also seeing some noted buffer issues w/ mopidy but not sure that applies to pydora as well.

OS = Raspbian jesse-lite
Hardware = Raspberrypi B+

While in the process of troubleshooting mopidy-pandora I came to see pydora itself working very slowly.

  • this works but takes 4+ minutes to prompt for user input.
  • It does successfully create ~/.pydora.cfg
  • also works but takes 4+ minutes to connect to pandora, then several minutes to play a song. Next song takes an additional while to load.
  • key commands (pause /play) work instantly.
  • MPDroid to Mopidy-Pandora loads stations and artwork for current playing track but is equally slow to respond taking several minutes between songs and just not functioning correctly.

More testing:
pianobar has no such problems. It works perfectly and instantly.
mopidy itself is working.
MPDroid can connect to the mpd server and play local tracks w/ out issue.

At this point other than network latency, I’ve no idea what might cause this. I can’t seem to find a log file for pydora nor a way to debug it.


username = xxxxxxxxxxxxxxxxxxxx
password = xxxxxxxxxxxxxxxxxxx
username = iphone
api_host = tuner.pandora.com/services/json/
encryption_key = 721^26xE22776
decryption_key = 20zE1E47BE57$51
device = IP01
password = P2E4FC0EAD3*878N92B2CDp34I0B1@388137C
default_audio_quality = highQuality

mopidy config

cache_dir = $XDG_CACHE_DIR/mopidy
config_dir = $XDG_CONFIG_DIR/mopidy
data_dir = $XDG_DATA_DIR/mopidy
max_tracklist_length = 10000

color = true
console_format = %(levelname)-8s %(message)s
debug_format = %(levelname)-8s %(asctime)s [%(process)d:%(threadName)s] %(name)s\n %(message)s
debug_file = mopidy.log
config_file =

mixer = software
mixer_volume =
output = autoaudiosink
buffer_time =

scheme =
hostname =
port =
username =
password =

enabled = true
api_host = internal-tuner.pandora.com/services/json/
partner_encryption_key = 2%3WCL*JU$MP]4
partner_decryption_key = U#IO$RZPAB%VX2
partner_username = pandora one
partner_password = TVCKIBGS9AO9TSYLNNFUML0743LH82D
partner_device = D01
username = ********@mail.com
password = ********
preferred_audio_quality = highQuality
sort_order = a-z
auto_setup = true
cache_time_to_live = 86400
event_support_enabled = false
double_click_interval = 2.50
on_pause_resume_click = thumbs_up
on_pause_next_click = thumbs_down
on_pause_previous_click = sleep
on_pause_resume_pause_click = delete_station

enabled = true

enabled = true
card = 0
control = Master

enabled = true
hostname =
port = 6600
password =
max_connections = 20
connection_timeout = 60
zeroconf = Mopidy MPD server on $hostname
command_blacklist =
default_playlist_scheme = m3u

enabled = true
hostname =
port = 6680
static_dir =
zeroconf = Mopidy HTTP server on $hostname

enabled = true
protocols =
metadata_blacklist =
timeout = 5000

enabled = true
base_dir =
default_encoding = latin-1
default_extension = .m3u8
playlists_dir =

enabled = true

enabled = true
media_dirs =
show_dotfiles = false
follow_symlinks = false
metadata_timeout = 1000

enabled = false ; Extension disabled by user config.


If pydora is also slow to respond then it might be indicative of some issues that are occurring further up stream.

I haven’t experienced this problem myself - are you perhaps using a proxy, VPN, or smart DNS service?

From the logs it looks like the track meta data is retrieved fairly quickly. It is the downloading and buffering of the actual MP3 file that is taking exceptionally long.

Sure enough, the issue is the network (provided via wireless bridge). Finally had a chance to try an ethernet connection and everything works fine. Still can’t imagine why pianobar works just perfectly on the bridged network. Pianobar must do something differently, no idea what though…