Closed GoogleCodeExporter closed 9 years ago
Sounds reasonable.
The order of tracks is not touched by Remuco. They appear in whatever order a
player
provides them (which probably means in the order a player internally stores
tracks in
the library). Anyway, sorting tracks returned by a search query shouldn't be
that hard.
Rearranging playlists and queues is a bit trickier. Simple actions like moving
tracks
up and down is easy, but more complex adjustments may be a problem. Remuco's
media
library interaction API is not very sophisticated to be applicable for different
players with different library concepts. Basically, when walking through a
player's
library, a player adapter only provides a list of tracks and a set of actions
which
can be applied to those tracks.
Maybe you could provide some more details about what actions you actually mean
with
"rearranging the queue and playlist".
By the way, which feature requests you consider as "wild and still unnecessary"?
Original comment by obensonne@googlemail.com
on 22 Dec 2009 at 1:41
I've just installed remuco-mpd to be able to control my mpd remotely - the mere
fact
that Remuco exists is awesome (thanks for that work!). However, I immediately
ran
into the problem that I cannot add albums from the search results in the correct
track order - quite annoying to me, as very often I listen to complete albums
rather
than single tracks. So, if this part is - relatively - easy to implement, maybe
this
can be done first and the "rearranging" part split off into a second feature
request?
I for one would be *very* happy if that first part (add albums in original
sorted
order from search results) got implemented. :-)
Original comment by emga...@ribbrock.org
on 26 Mar 2010 at 10:20
This issue was updated by revision 0a0cc2f77f.
Results from a search now are sorted by album, tracks with no album
first. However, the album is still not contained in the entry names of
the returned track list. Do we need this?
The rearranging feature should move to an extra issue.
Testing feedback highly appreciated.
Original comment by obensonne@googlemail.com
on 31 Mar 2010 at 7:18
I tried this revision (removed the Debian Lenny version, followed
"BleedingEdge" wiki
page, did new "make install remuco-mpd"). As a result, remuc-mpd does not work
anymore:
nobby:~/.config# remuco-mpd
Log output will be stored in /root/.cache/remuco/mpd.log
Contribute to Remuco: Please run 'remuco-report' once a client has connected,
thanks!
Traceback (most recent call last):
File "/usr/bin/remuco-mpd", line 609, in <module>
pa = MPDAdapter()
File "/usr/bin/remuco-mpd", line 76, in __init__
search_mask=SEARCH_MASK)
File "/usr/lib/python2.5/site-packages/remuco/adapter.py", line 470, in __init__
self.config = config.Config(self.__name)
File "/usr/lib/python2.5/site-packages/remuco/config.py", line 177, in __init__
cp = ConfigParser.RawConfigParser(_DEFAULTS, _odict)
TypeError: __init__() takes at most 2 arguments (3 given)
I have to admit that the python installation on this particular machine may be
slightly iffy (I'm having problems because I had to pull in the Debian Squeeze
remuco-mpd into a Lenny install - as a result the bluetooth module isn't
recognised,
so I commented that "import" out in remuco). If you get the impression that
that is
the likely reason I will look into doing a full upgrade to Squeeze. The Debian
0.9.2
version of remuco-mpd did work fine (sans the Bluetooth - which isn't an issue
on an
SGI Indy machine...), though.
Original comment by emga...@ribbrock.org
on 1 Apr 2010 at 11:58
Oh yes, forget to mention this. Remuco now needs Python >= 2.6. I guess you're
still using Python 2.5. If there
is no chance for you to upgrade to 2.6, you could have a try with replacing the
line
p = ConfigParser.RawConfigParser(_DEFAULTS, _odict)
in config.py (line 177) by
p = ConfigParser.RawConfigParser(_DEFAULTS)
However, that's just a hack to make it working now. Chances are that there're
coming more Python 2.6 only
changes.
Original comment by obensonne@googlemail.com
on 2 Apr 2010 at 12:50
Ah, ok, thanks for pointing that out. As far as I know, Debian Squeeze (aka
"testing") has Python 2.6 (that might also be the reason I'm running into the
problems with the bluetooth module), so I'll be looking into a full upgrade.
However,
it might be a while before I can try that (the Indy is slow and it's a diskless
install, so changes like this require a bit more work), so I might just try the
hack
first so I can give you some feedback.
Original comment by emga...@ribbrock.org
on 2 Apr 2010 at 1:09
Ok, I went for the full upgrade, so I do have Python 2.6 now (though I have to
change
all "python" calls for "python2.6" calls in the remuco code for now - Debian
testing
still installs Python 2.5 as default, but that seems to be changing soon).
I've tried the new remuco-mpd version you have provided - as far as I am
concerned,
I'm still seeing several problems. I shall give an example:
I go to Search and fill in "Wood" as Album. As results, I'm getting songs from
both
"Jethro Tull - Songs from the Wood" and "Greg Baumont - Wood"
- Question 1: Is it possible to tell remuco to search only for what I typed?
Within the results, all songs are now nicely grouped within their respective
albums -
very nice! Thank you!
However, within the album, the tracks are still in a random order - so I cannot
just
select all and add them to the playlist, but have to select and add them one by
one
thereby manually putting them in the correct order (*if* I happen to remember
it).
So, if remuco could actually list those songs in the correct track order so one
can
search for an album and subsequently do a "Mark all -> Add to playlist" to add a
complete album with all its tracks in the correct order that would be
absolutely great.
The icing on the cake would be if it was possible to do a "Mark album -> Add to
playlist" (in case the search results consist of more than one album like in my
example above), but of course I have no idea how difficult it would be to
implement this.
Display of the album names (in the results) and maybe the track numbers is a
"nice to
have" as far as I am concerned (maybe the original requester should chime in
here...), but far less important than what I described above.
In any case, thanks again for your work on this - really appreciated!
Original comment by emga...@ribbrock.org
on 2 Apr 2010 at 10:14
This issue was updated by revision 9ca3102117.
Within an album the tracks should appear ordered now.
Original comment by obensonne@googlemail.com
on 12 Apr 2010 at 8:27
Turning searches into exact searches is possible but I'm afraid it would blow
up the
client's user interface. Further, most users expect non-exact matches for search
terms since most player UIs do it that way. For you specific problem you could
simply
search for artist="greg" and album="wood" -- that should do it.
Marking/focussing one track and adding the whole album to the playlist is
possible.
An corresponding action needs to be defined in the MPD adapter. If you know a
bit of
Python, why don't have a try yourself ;) ? It's not to complicated, just
inspect how
other actions ("Jump to", ..) are handled.
On the devices I use, the display is far too small to also display album names
in
track lists. That might be different on other phones. How does track lists look
like
on your device? Is there room for more track information?
Original comment by obensonne@googlemail.com
on 12 Apr 2010 at 8:37
Just tried revision 9ca3102117 - EXCELLENT! Thank you so much! With that
modification, *my* main problem is pretty much solved - the rest is really just
"nice
to have". A few comments:
- I can see your point with the exact searches. *Personally*, I'd just want a
regular
expression interface, but I doubt that would go down well with the majority of
users... ;-) But it's not really a big issue, as you pointed out there are ways
to
match what's needed.
- Marking/focussing: Your code is pretty much the first Python I've ever seen,
so I
doubt I can easily add it... More a Perl/PHP guy myself... :-} Maybe later this
year,
when the agenda is less full I might have a look. As I said in my other comment:
"icing on the cake" :-)
- I'm using a Nokia N79. Standard track list display on this device is four
bullets
with two lines of text each. Here, an album would be possible I think -
definitely in
landscape mode, where the lines are longer. In portrait mode it might cost one
bullet
(i.e. three bullets with three lines of text). *I* would be ok with that, but
others
might not, so maybe "album display" should be a configuration option if it was
to be
added - I know that there are a lot of people who don't care a lot about the
whole
"album" concept these days, but I'm "old school" in that regard... Using a
smaller
font would be another option, but again probably not something everybody likes.
Original comment by emga...@ribbrock.org
on 12 Apr 2010 at 9:44
Ok, I'm closing this as fixed for now. Concerning the "subissues", feel free to
open new issues .. and possibly fix
them yourself .. when you fell ready ;).
Original comment by obensonne@googlemail.com
on 16 Apr 2010 at 4:36
Original issue reported on code.google.com by
mario.cu...@gmail.com
on 15 Dec 2009 at 12:52