None
closed
nobody
None
2018-10-09
2018-09-29
Anonymous
No

upmpdcli -v
Upmpdcli 1.3.2 libupnpp 0.16.0

When playing any track from Spotify using the uprcl server I get the following error

CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/track?version=1&trackId=7Mi1L10QY4W57VAKyVSera'}]
CMDTALK: spotify-app.py: trackuri: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/track?version=1&trackId=7Mi1L10QY4W57VAKyVSera'}]
CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/7Mi1L10QY4W57VAKyVSera'}]
CMDTALK: spotify-app.py: trackuri: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/7Mi1L10QY4W57VAKyVSera'}]
CMDTALK: spotify-app.py: processmessage: processor raised: [trackuri: path [/spotify/7Mi1L10QY4W57VAKyVSera] does not match [/spotify/track\?version=1&trackId=(.+)$]]
Traceback (most recent call last):
File "/usr/share/upmpdcli/cdplugins/pycommon/cmdtalk.py", line 172, in processmessage
outfields = processor.process(params)
File "/usr/share/upmpdcli/cdplugins/pycommon/cmdtalkplugin.py", line 53, in process
return self.dispatcher.run(params[prcnmkey], params)
File "/usr/share/upmpdcli/cdplugins/pycommon/cmdtalkplugin.py", line 36, in run
return func(params)
File "/usr/share/upmpdcli/cdplugins/spotify/spotify-app.py", line 118, in trackuri
media_url = trackid_from_urlpath(pathprefix, a)
File "/usr/share/upmpdcli/cdplugins/pycommon/upmplgutils.py", line 155, in trackid_from_urlpath
raise Exception("trackuri: path [%s] does not match [%s]" % (path, exp))
Exception: trackuri: path [/spotify/7Mi1L10QY4W57VAKyVSera] does not match [/spotify/track\?version=1&trackId=(.+)$]
Application reported internal error, closing connection.

Discussion

  • medoc
    medoc
    2018-10-01

    Hi,

    You should be able to correct this by adding the following to /etc/upmpdcli.conf

    plgproxymethod = proxy
    

    This is a bug, I'll fix it in the code, but hopefully, this should get you going until the next version.

     
  • Anonymous
    Anonymous
    2018-10-01

    Thanks for the response, adding that line gets slightly further but now the media server just seems to crash on playback:

    upmpdcli -c /etc/upmpdcli.conf -l 6 -m 3 -d /tmp/log
    CMDTALK: uprcl-app.py: Uprcl running
    uprcl: uprclconfdir not in config, using /var/cache/upmpdcli/uprcl
    uprcl: uprclpaths not in config
    uprcl: Path translation: pthstr: /tmp:/tmp
    uprcl: runbottle: host 192.168.2.21 port 9090 pthstr /tmp:/tmp pathprefix /uprcl
    uprcl: Creating/updating index in /var/cache/upmpdcli/uprcl for /tmp
    uprcl: _update_index: initrunning set
    uprcl: runbottle: adding route for: /tmp/
    Bottle v0.12.13 server starting up (using PasteServer())...
    Listening on http://192.168.2.21:9090/
    Hit Ctrl-C to quit.

    :2:./utils/workqueue.h:153::WorkQueue::waitIdle:DbUpd: not ok
    uprcl: Indexing took 0.50 Seconds
    uprcl: Estimated alldocs query results: 42
    uprcl: Retrieved 42 docs in 0.01 Seconds
    uprcl: _rcl2folders took 0.00 Seconds
    uprcl: recolltosql: processed 42 docs in 0.00 Seconds
    uprcl: Init done
    192.168.2.7 - - [01/Oct/2018:19:48:21 +0100] "GET / HTTP/1.1" 200 384 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0"
    192.168.2.7 - - [01/Oct/2018:19:48:22 +0100] "GET /static/style.css HTTP/1.1" 200 3405 "http://192.168.2.21:9090/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0"
    CMDTALK: spotify-app.py: Spotify running
    CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$'}]
    CMDTALK: spotify-app.py: browse: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$'}]
    0$spotify$: me: upmpdcli
    0$spotify$: cachedir: /var/cache/upmpdcli/spotify
    Dispatching to 'root', args: {}
    CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$/my_music'}]
    CMDTALK: spotify-app.py: browse: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$/my_music'}]
    Dispatching to 'my_music', args: {}
    CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$/favourite_albums'}]
    CMDTALK: spotify-app.py: browse: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$/favourite_albums'}]
    Dispatching to 'favourite_albums', args: {}
    CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$/album/7IXPoqtzwpyi4bcy61wEiI'}]
    CMDTALK: spotify-app.py: browse: [{'cmdtalk:proc': 'browse', 'flag': 'children', 'objid': '0$spotify$/album/7IXPoqtzwpyi4bcy61wEiI'}]
    Dispatching to 'album_view', args: {'album_id': '7IXPoqtzwpyi4bcy61wEiI'}
    CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/track?version=1&trackId=0FA4jFJtuQjPyZWiMOpCKG'}]
    CMDTALK: spotify-app.py: trackuri: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/track?version=1&trackId=0FA4jFJtuQjPyZWiMOpCKG'}]
    Segmentation fault

     
    Last edit: Anonymous 2018-10-01
    Attachments
  • medoc
    medoc
    2018-10-02

    Can you please try to run upmpdcli in the default mode (no -m 3). -m 3 is experimental and creates the media server as an embedded device of the root media server. As far as I could see it completely confuses most control points, so it's not used by default and little tested. Just start upmpdcli without a -m option, and it will start a second process with -m 2 to run the media server as a root device. My best guess at this point is that the -m 3 is the trigger for the segfault.

    Also, maybe disable the uprcl module temporarily (just to make things simpler while we test the spotify issue). You just need to comment the uprcluser line in /etc/upmpdcli.conf.

     
  • Anonymous
    Anonymous
    2018-10-02

    I removed the uprcluser line from the config file and tried again with upmpdcli -c /etc/upmpdcli.conf
    On attempting to play a track upmpdcli no longer crashes but the track does not play. What appears to be happening is the local bottle http server is crashing as I can no longer access the status page at http://192.168.2.21:9090 after attempting playback.
    There's nothing in the logs about the http server, the last entries are

    CMDTALK: spotify-app.py: pCmdTalkProcessor.process: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/track?version=1&trackId=61gZHEcZ7jNRVJa7taB8FO'}] CMDTALK: spotify-app.py: trackuri: [{'cmdtalk:proc': 'trackuri', 'path': '/spotify/track?version=1&trackId=61gZHEcZ7jNRVJa7taB8FO'}] :4:src/mediaserver/cdplugins/cmdtalk-fixed.cpp:140::CmdTalk: Got empty line :4:src/mediaserver/cdplugins/plgwithslave.cxx:304::PlgWithSlave: media url [61gZHEcZ7jNRVJa7taB8FO] :4:src/mediaserver/cdplugins/spotify/spotiproxy.cpp:696::SpotiFetch::SpotiFetch: :4:src/mediaserver/cdplugins/spotify/spotiproxy.cpp:478::getSpotiProxy: creating for user xxx

     
    • medoc
      medoc
      2018-10-05

      You probably also need to comment the uprclautostart line to disable the uprcl startup, sorry, forgot about it.
      There is a problem I had not seen when running bottle with the paste server under Python3. Either change the uprcl-app first line to python2 or make this change to the paste module:
      https://bitbucket.org/ianb/paste/issues/26/python3-compatibility-typeerror-a-bytes

      (the next version will use 'waitress' instead of 'paste' to run bottle, as paste is not really maintained any more).

      This said, the uprcl and spotify things should be completely independant and the status page is only for the local uprcl media server.

      If I understand correctly, things are just stuck after the last log line you included ?

      Here is what it should look like:

      :4:/home/dockes/projets/mpdupnp/upmpdcli/src/mediaserver/cdplugins/spotify/spotiproxy.cpp:478::getSpotiProxy: creating for user medoc92
      :4:/home/dockes/projets/mpdupnp/upmpdcli/src/mediaserver/cdplugins/spotify/spotiproxy.cpp:440::notify_main_thread
      :4:/home/dockes/projets/mpdupnp/upmpdcli/src/mediaserver/cdplugins/spotify/spotiproxy.cpp:147::Spotify: medoc92 logged in ok
      :5:/home/dockes/projets/mpdupnp/upmpdcli/src/mediaserver/cdplugins/streamproxy.cpp:348::StreamProxy::answerConn: starting fetch for 6ax2kE6lQyP93OsLCw8AxR
      

      There should be 'notify_main_thread' and "xxx logged in ok' after 'creating for user xxx'

      So it appears, that the login is not happening on the libspotify side (this is independant of the web api login used for browsing, and for which you created the token file). Are you sure of your login parameters in /etc/upmpdcli.conf (spotifyuser and spotifypass) ?

      OTOH, you should have messages about a bad login if the password was wrong (I just tried). So I don't know what may be happening... I am going to try things under Ubuntu, because I am testing with Debian at the moment, maybe there is a difference.

       
      Last edit: medoc 2018-10-05
  • medoc
    medoc
    2018-10-05

    Also: what architecture are you running this on (armhf/arm64/amd64/i386) ? This is important because it will be a different libspotify, so I should try on the same arch.

     
  • medoc
    medoc
    2018-10-06

    Thanks a lot for your help ! This should be fixed in upmpdcli 1.3.5 (the packages are on the PPA).
    The problem was that I had only tested running upmpdcli as a normal user, and there was a problem when it was started by root before switching to the upmpdcli user.

     
  • medoc
    medoc
    2018-10-09

    • status: open --> closed
    • milestone: -->
     
  • medoc
    medoc
    2018-10-09

    Thanks for your feedback, closing the issue.

     

Cancel   Add attachment