Issue 27

Not really an issue with upmpdcli, but a side effect: I was writing a script to create a symlink to the booklet of the currently playing album on an http server and I realized that, when mpd is controlled by an mpd client, the output of

is fine. For instance, I get something like

which is what I expect and which I can pass to dirname. However, when mpd is controlled by upmpdcli, the output for the same file is

which is pretty unusable for a script that works fine with pure mpd, something like:

Thus, the question is whether there is a way for getting a clean output of the file which is actually played — something I can apply dirname to — when mpd is controlled by upmpdcli? Any ideas?

Thanks, Nicola

On Mon, 08 Feb 2016 14:19:45 -0800, nicolabotta notifications@github.com wrote:

Hi,

Unfortunately, the URL is all that upmpdcli knows about the file, it is determined by the upnp server, and should be considered opaque. With some servers like minidlna it is all numbers and not even persistent (the one for a given track may change after minidlna regenerates its db).

So, nope, no go. It ennoys me too because it means that it is pretty impossible to manage playlists except on the content server itself.

Minim URLs are persistent though.

Cheers,

If

The funny thing is that, with Minimserver and Bubble UPnP, the problem of opening a .pdf reader with the album booklet is almost (but not quite) solved:

Tapping the cover art in the "Playing now" field of Bubble UPnP displays a list of metadata of the currently playing item. In particular, it displays its URL tag! One can tap the URL and open it in firefox or chrome. By manually replacing

with

in the browser’s navigation bar, one can open the booklet of the currently playing album assuming this is stored in the same directory as booklet.pdf.

This works fine and the only thing that would be needed to be able to access the booklet at a fingertip would be to automatize the above substitution.

If you are willing to work with something which is not guaranteed by a standard an might change in the future, why not transform the URL inside your script and use wget or curl to fetch it ?

If you are willing to work with something which is not guaranteed by a standard an might change in the future, why not transform the URL inside your script and use wget or curl to fetch it ?

Right, this is the approach I was following when I realized that the output of mpc is quite different when mpd runs under the control of upmpdcli.

It is still a viable approach, of course. But I would have to massage the output of mpc a little bit more and make upmpdcli run the script (via onplay or onstart?) every time a new item is replayed. This is a little waste of resources. On the Android tablet, I would have to open a fixed web page containing the booklet or a symlink to it.

An alternative approach would be to open the URL displayed by Bubble UPnP on the Android tablet

http://192168178101:9790/minimserver/_/data/Alfred_20Brendel/Schubert_20Piano_20Sonatas_20D575,_20894,_20959_20_26_20960/01_20-_20Schubert_20-_20Piano_20Sonata_20No18_20in_20G,_20D894_20-_201_20Molto_20moderato_20e*20cantabile.flac

whenever I want to access the booklet. This would require an Android script that substitutes the track specific .flac file with booklet.pdf. It would be a better solution but I have absolutely no idea how to write even the simplest Android script. I’ll probably take a look at that.

Best, Nicola

Closing because there does not seem to be anything to fix in upmpdcli here.