Split code in server/client

[Clementine-Issue-Importer]

From pie.or.paj on March 30, 2013 22:49:51

Clementine is the greatest music player out there. However one great feature would be network transparency.

Today we have MPD witch is getting old and lacks streaming services support (Spotify, Grooveshark) and every client itself have to download album art, lyrics and so. Mopidy adds streaming support but as it's using the MPD protocol it have many of MPDs shortcomings.

My idea is that Clementine should be split in a server and official desktop client and a new protocol should be created for communication between them. The server should be a headless deamon handling info gathering (including arts and lyrics), scrobbeling and everything Clementine does today. And the client should basicly just do displaying and talking to the server. Of course both server and client should work on all platform Clementine supports today. Also the Android app should be modified to use this protocol and be a Clementine client.

For normal users which won't use this function there should be an installer available that installs both server and client. The server should be configured to only listen for local connections and the client to connect to the local server automatically just like deluge does.

This would make Clementine the most modern music server/client solution and would provide features not offered anywhere else.

With more and more people starting to have a server at home (especially NASes but some NASes can install third party software (ex. Synology)) I'm sure this is an increasing market where the current solutions doesn't satisfy todays expectations.

Original issue: http://code.google.com/p/clementine-player/issues/detail?id=3588

[Clementine-Issue-Importer]

From john.maguire on March 30, 2013 17:00:09

Labels: -Priority-Medium Priority-Low

[Clementine-Issue-Importer]

From alphadel...@gmail.com on April 01, 2013 19:15:15

This sounds more like a totally new project than a feature for Clementine. This would add enormous complexity. Maybe it would be better to improve MPD and its protocol and clients, and perhaps add MPD support to Clementine so it could act as an MPD client; MPD could just be another source for Clementine to play from.

[Clementine-Issue-Importer]

From pie.or.paj on April 02, 2013 04:32:50

Actually implementing this behaviour in Clementine instead of "fixing" MPD makes more sense as Clementine basically just needs to be able to be controlled over network and the possibility to run headless. MPD needs a new protocol, and a lot of new features in the player itself.

I'm aware that this is a huge change and may be way outside the scope of what the target with Clementine is.

However, I do see a clean way to implement this in small steps. Today, parts of Clementine is already network controllable due to the network remote. This could be extended to eventually support Clementines full feature set.

The next step is to be able to run headless. This could be implemented as a compile flag so no functionally is lost.

The biggest step I see is the ability to run Clementines UI as a client. However that should probably be developed outside of Clementine. Also that is the least important part in this feature request. If just a full network control is implemented in mainline Clementine people interested in clients becomes able to create those themselves in the same way MPDs client is developed outside of MPD.

The biggest question right now is if patches that extends the network remote would be accepted?

[Clementine-Issue-Importer]

From asfa...@googlemail.com on April 04, 2013 12:38:10

I had the idea to add playlist-management to my android app, too. But there are a huge amount of constellations to consider, so i removed it from my todo list. Also because editing playlists is much more comfortable on the pc than on the phone :)

If you want a fully remote controllable clementine, you have to add every, and by that i mean also settings, covermanagement, etc..., to the network remote. When you add a new feature to Clementine, you must remember to make it remote controllable.

Maybe it would be easier to create a remote playback module that handles the playback stuff. It pushes the music file index to the "Client" (Clementine) and receives only the basic play / pause / directory management commands from Clementine. The rest is done by Clementine. I think it might be less complex than a complete remote control.

Regarding network remote patches: What features do you want to add? Maybe they are useful for my android app too. A basic PC remote app would be handy, too.

[Clementine-Issue-Importer]

From pie.or.paj on April 05, 2013 01:50:17

Features I would like to add that I also would like in the Android app is: Global Search Library browsing Playlists (this should also include playlists from Spotify, Grooveshark etc.) Queue mangement (add to/remove from queue, stop after track).

Yeah, full network coverage may be hard to create. But if most playback, browsing and info features are in there that would be an huge achievement itself. If the above features are added I think most of this should be done.

[Clementine-Issue-Importer]

From pie.or.paj on April 06, 2013 10:29:58

I have created a patch with basic playlist management (add and remove tracks) for Clementine.

To test this I also created a command-line client inspired by mpc. This is also usefull for remote controlling (binding buttons to commands). It isn't very pretty yet but usefull for testing. The branch with support for this patch can be downloaded using: bzr branch lp:~pie-or-paj/clementinecc/playlist-management It should be runnable using python 2.5 to 3.3 and the usage is like: python clementinecc.py del 2 1

Attachment: playlist-managment-add-remove.patch

[Clementine-Issue-Importer]

From asfa...@googlemail.com on April 11, 2013 10:25:39

Looks good at first sight. I'll add it this weekend and do the library sending.

Can you add playlist support for spotify / grooveshark? Is it possible to make it compatible with the current playlist handling, so i don't have to change my app? I don't have any of those services so i can't test it.

How would you implement the global search? Send the search string to clementine, it searches its sources and send the results back? Would be a great feature, too.

[Clementine-Issue-Importer]

From pie.or.paj on April 12, 2013 13:11:38

Looks good at first sight. I'll add it this weekend and do the library sending. Sounds great :)

Can you add playlist support for spotify / grooveshark? Is it possible to make it >compatible with the current playlist handling, so i don't have to change my app? I don't have any of those services so i can't test it. The current implemention in the app is great for open playlists wich is how it works today. (If you have a playlist in the playlist tab (in sidebar) that isn't open (tab over playlist to the right) it doesn't show up in the app). For closed playlist I would propose a list in a similar way to how I guess library would be implemented. In the protocol maybe a boolean in playlist message would be enough (open, or not). Spotify and Grooveshark playlist should not be handled any differentially. Opened already works but closed would have to be implemented, will take a look at that.

How would you implement the global search? Send the search string to clementine, it searches its sources and send the results back? Would be a great feature, too. Yeah. Clementine adds one "service" at a time (whenever it's finished, Library are near instant and online are somewhat slower), I guess that behaviour should be used here too.

[Clementine-Issue-Importer]

From asfa...@googlemail.com on April 13, 2013 02:59:09

i just commited your patch.

I didn't know that it is possible to close playlists and reopen them. I just found the feature. I'll implement the open / closed flag now.

[Clementine-Issue-Importer]

From pie.or.paj on April 13, 2013 06:09:39

It seems to produce build failures.

/usr/include/google/protobuf/repeated_field.h:122: error: ‘google::protobuf::RepeatedField::RepeatedField(const google::protobuf::RepeatedField&) [with Element = int]’ is private

However it builds for me. The function that I call and that get problems is request.urls() in foreach (std::string url, request.urls()) {

For me urls() in RequestInsertUrls in remotecontrolmessages.pb.h is public.

Why does it gets private when buildbot builds the .proto file?

[Clementine-Issue-Importer]

From john.maguire on April 13, 2013 14:22:41

I think it's because of foreach() in Qt 4.6

Using std iterators works fine, ie.:

for (auto it = request.urls().begin(); it != request.urls().end(); ++it) { urls << QUrl(QString::fromStdString(*it)); }

and on line 201:

std::copy(request.songs().begin(), request.songs().end(), songs.begin());

[Clementine-Issue-Importer]

From pie.or.paj on April 13, 2013 15:05:11

Oh I'm not really a cpp developer (Python & Java is my call) so I didn't know that. Where actually about to use for but then I saw Qt Creator proposed foreach so I didn't thought any deeper than that.

Could you fix that so I don't have to feel bad for proposing a patch that doesn't build everywhere and especially for not building in Clementines buildbot? :)