|Anonymous | Login | Signup for a new account||2013-05-22 07:44 CEST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002876||MPD||Commands||public||2010-04-21 23:43||2010-05-02 18:31|
|Target Version||Fixed in Version|
|Summary||0002876: Add a command to get the Music and Playlist directories.|
|Description||Life would be much easier fot the client programmer if he or she could simply ask mpd what music and/or playlists directory it is using today. Now I have to guess which config file mpd is using and, if the file is found, read it from that file.|
|Additional Information||A feature request, obviously.|
|Tags||No tags attached.|
edited on: 2010-04-22 09:25
What is MPD is running on another PC? what if the permissions are so, that MPD might access the files, but the client not.
What if the user is accessing MPD via a ssh tunnel (so checking if connection is on localhost is not going to be valid).
Why do clients need access to the files? or playlists (you can access the playlists via mpd's playlist api).
MPD is network 'enabled', or how you want to call it, having clients access the files directly (or worse the playlists) (some even require it!) kinda defeats the point of the program IMHO
|I also don't feel this belongs into the MPD protocol. If you want direct access to the music files, you can do without a music directory, and add file:/// [^] URIs to the queue. If you think a playlist command is missing and you want to work around that by directly accessing the playlist directory, then consider submitting a feature request for the playlist commands.|
I can do without the Playlists dir if MPD would let me save a partial playlist (i.e. let the user click "save selection as playist"). Maybe I didn't look hard enough, but I have not been able to do this in any other way than create the file myself and save it. But a mpd command to save such a selection would be a much better solution of course.
I need the music dir, not to access audio files, but to access album art: files named folder.jpg, albumart.png etc. that are in the same dir as the music file. Again: if mpd could hand those files to me, on request, that would be much better.
This may contravene the principles of a network enabled music player, but my client (Quimup) focuses on the use of mpd as a desktop music player - for which it, fortunately, is also very suitable.
GMPC can safe a selection to a playlist.
You can create a new playlist, then just add all the selected songs to that playlist.
In later versions MPD's playlist interface, luckely, got some extensions to make editing from the client possible.
> You can create a new playlist, then just add all
> the selected songs to that playlist.
I know. But what next? All I can find is this:
mpd_send_save(mpd_connection *connection, const char *name);
which saves the currently active playlist...
PS. another reason I need the music dir is to be able to get the dir's creation date.. it is the only way I can think of to sort the music in the order it was added to the database (sort of, anyway).
You should read documentation better and also my comment where I hinted that it is possible.
You can add any path to any playlist, clear a playlist, move songs in a playlist. These options where added a long long time ago.
See: http://musicpd.org/doc/protocol/ch02s05.html [^]
Still relying on directory access for sorting is .....
Do a request to have that information included in the documentation.
> Still relying on directory access for sorting is .....
Please don't hesitate to finish your insult, I can take it.
> Do a request to have that information included in the documentation.
You won't reveal this inside information unless I make an official request?
edited on: 2010-04-23 08:11
>> Still relying on directory access for sorting is .....
>Please don't hesitate to finish your insult, I can take it.
ok: Still relying on directory access for sorting is wrong in so many ways.
>> Do a request to have that information included in the documentation.
>You won't reveal this inside information unless I make an official request?
I ment to say: Do a request to have that information included in the api.
(Still if the documentation was lacking, a bug request against the lacking documentation would have been the right action, this is not the case because I allready pointed you to the correct documentation. So why the inside information remark?)
> So why the inside information remark?
Accept my apologies if I am wrong, but I had the impression that sorting items by date (added to the databse) IS possible but that it is not documented. You did say: "do a request t have that information included in the documentation". If it can be done, but there is no way to find out how... it qualifies as inside information.
In your reply you rephrase it: "Do a request to have that information included in the api" which gives a whole new meaning to the word 'information': it now refers to the 'date added' itself, not to how to get it from mpd.
...which means that it currently is NOT possible to sort items by 'date added'. And that, in turn, makes me wonder why you say that the way I do it is wrong.
I am confused. Is it possible? If so I'd like to know how. If not I will make a feature request.
I always with 'information' referred to modification/creation time. (as it is information about the song, the information you need to do the sorting).
If I remember correctly at the moment only the modification time is exposed to the client. (This could be git (developers, not stable) only, but I haven't done any development on my client for a while so the knowledge is getting a bit rusty). Cirrus has more knowledge about that.
I am not a native English speaker, so sorry if I use the wrong words from time to time.
> I am not a native English speaker, so sorry if I use the wrong words from time to time.
Neither am I, which most likely has added to the confusion as well.
I will have a look at the development version.
Thanks for your help.
|2010-04-21 23:43||coon||New Issue|
|2010-04-21 23:43||coon||Status||new => assigned|
|2010-04-21 23:43||coon||Assigned To||=> cirrus|
|2010-04-22 09:23||qball||Note Added: 0005577|
|2010-04-22 09:23||qball||Note Edited: 0005577|
|2010-04-22 09:25||qball||Note Edited: 0005577|
|2010-04-22 09:57||cirrus||Note Added: 0005578|
|2010-04-22 16:54||coon||Note Added: 0005579|
|2010-04-22 17:18||qball||Note Added: 0005580|
|2010-04-22 19:17||coon||Note Added: 0005581|
|2010-04-22 20:06||qball||Note Added: 0005582|
|2010-04-22 23:32||coon||Note Added: 0005585|
|2010-04-23 07:40||qball||Note Added: 0005586|
|2010-04-23 07:44||qball||Note Edited: 0005586|
|2010-04-23 08:11||qball||Note Edited: 0005586|
|2010-04-23 10:42||coon||Note Added: 0005589|
|2010-04-23 11:16||qball||Note Added: 0005590|
|2010-04-23 15:33||coon||Note Added: 0005591|
|2010-04-25 14:22||cirrus||Assigned To||cirrus =>|
|2010-05-02 18:31||cirrus||Priority||normal => none|
|Copyright © 2000 - 2012 MantisBT Group|