Track Number Ordering / Playlist rearranging

[GoogleCodeExporter]

Suggestion:
Order by track, show track numbers in search, make possible to rearrange 
playlist and queue.

description:

I've seen lots of feature requests, some of them are really good, some are 
wild and still unnecesary. What I'm proposing here is a "back to basics" 
suggestion.

Remuco is a media player remote, and for that, it should do this -well-. 
There's a feature lacking in here that, at least for me, is really 
important - track numbering and ordering. When I do a search for a whole 
album, I want it to play as the album goes, not randomnly as remuco does. 
The track number is missing everywhere, and it should be available for 
correct arranging. This is specially annoying for continuous albums, and 
gapless albums, where a progression is necessary for the album experience.

Make available the track number in search and in the playlist, as making 
the player capable of rearranging the queue and playlist, not letting 
remuco handle this as it currently does.

Original issue reported on code.google.com by mario.cu...@gmail.com on 15 Dec 2009 at 12:52

[GoogleCodeExporter]

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

• Changed state: Chatting

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Started

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Added labels: Component-MPD

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Fixed