Support for more music players

[316k]

I don't like Rhythmbox, I prefer music-on-console. I'll be working on generic code to play music and fetch track infos from any specified player.

[cirocosta]

👍 How are you planning to achieve this? I think this could be greatly done by providing a structure where 'drivers' provide support to determined music players.

[316k]

That's exactly what I think too. What do you think would be the best way to configure what driver is used ? Are there config files in nodejs, or should I let the clients send the driver they want via HTTP every time ?

[316k]

I though about my last question, and the driver will be specified in every request, allowing each client to have its own configuration.

[Agneli]

Hi guys, i already think in this question.
My ideia is put multiple options of players in a select to the user choose what he prefers.
And have a list with the commands of each player.
After that user choose a player the app execute only the command of that player.
But for this each player need have a command line client to provide informations of the music to the app.

What do you think of this ?

[lufte]

I think the best option is a configuration file in the server, not only for music players but for all commands. The client should send generic commands like "play_music", "pause_movie" or "get_track_info" and the server should be the one responsible of mapping those to real commands. For example, we ship a default file that looks like this:

play_music = "Rhythmbox --play"
play_movie = "totem --play"

and let the user change what they want. Maybe the user uses a custom video player that we do not know of, thus we don't support it. Besides, this eliminates the need of adding more code to the app just to support different movie/music players.

[316k]

You can look at the fork I'm currently working on : https://github.com/316k/linux-remote-control/blob/master/opt/lrc-server/lrc.js

As lufte said, I think being as generic as possible is mandatory. The only thing we should program is a way to handle custom commands to communicate with music/video players. Everything else should be in a configuration file.

For the config file format, I think JSON objects would be appropriate instead of simple key=value files, since some players may require more than bash commands to do the job done in an easy way (for instance, getting the number of seconds elapsed of a song in Rhythmbox in bash is a grep-tastically painful job, since it returns the time in a min:sec format). The JSON object would allow the user to put javascript code to do some stuff before sending/receiving data to/from the player.
Also, it would allow a user to define multiple ways to handle a play_music command. That might be useful, for instance, if you are like me and you use more than a single music player (maybe moc can run when JACK runs instead of PulseAudio, but you prefer to use VLC the rest of the time).

I'm a little new to NodeJS, so I'm not quite sure where to put the code in. How do you simply load a JSON object from an external file ? It definitely feels like my Music_Manager() is in the wrong place...

[lufte]

You're right, JSON is the way to go. I think the "require" function is what you need to load an external file, then you can just convert the content in a JSON object.

I'm not sure about sending the driver name in the request. This would force us to send all the drivers to the client when it starts so it knows what drivers are available, write code to show them in the client and would also force the user to choose one. Maybe the configuration file has only one driver and the user modifies it to their needs. If we want to make the user's life easier, we can include default drivers for several players but as a comment in the file. Say:
//example music_driver 1 {code...}
//example music_driver 2 {code...}
music_driver {code...}

Thoughts?

[316k]

👍
On second thoughts, it would save a lot of lines of code.

I'll try require() to organize the code a little.

[Agneli]

The resource has been added by the @316k on issue #19.
I can close this issue?

[316k]

I'd wait for the info display to be functionnal before closing this issue, unless you'd prefer to open a new one for that feature.

[316k]

I'll wait for #20 to be done before implementing the song-infos display.

[Agneli]

👍

[316k]

Time to close this issue, along with the merge #43 :)