[mpd]: Music Player Daemon initial contribution

[stefanroellin]

Signed-off-by: Stefan Roellin stefan@roellin-baumann.ch

This binding controls Music Player Daemons (https://www.musicpd.org/) and is meant to replace the corresponding binding from openhab1-addons (https://www.openhab.org/addons/bindings/mpd1/)

Almost all functionality from the old binding is supported, except

• playsong
• playsongid

However, the new implementation has actions, which allow to send arbitrary commands to a Music Player Daemon. With those actions, the missing functionality can be replaced easily and is much more flexible.

Example with actions:

rule "turn on morning music"
when
        Item morning_music changed to ON
then
        val actions = getActions("mpd","mpd:mpd:music")
        if(actions === null) {
                logWarn("myLog", "actions is null")
                return
        }

        actions.sendCommand("clear")
        actions.sendCommand("load", "MorningMusic");
        actions.sendCommand("shuffle");
        actions.sendCommand("play");
end

[TravisBuddy]

Travis tests were successful

Hey @stefanroellin,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @stefanroellin,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[fwolter]

Your clean code makes reviewing easy! There is one checkstyle warning left.

[stefanroellin]

@fwolter thanks for the review. I have made the requested changes.

[TravisBuddy]

Travis tests were successful

Hey @stefanroellin,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[fwolter]

Your changes look good! I found a few minor things I overlooked during the first review. Sorry for that.

[TravisBuddy]

Travis tests were successful

Hey @stefanroellin,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[stefanroellin]

Your changes look good! I found a few minor things I overlooked during the first review. Sorry for that.

Thanks again @fwolter for the review and no problem at all. I appreciate any feedback.
I have implemented the suggested changes except for the last one - see my comment #7870 (comment)

[fwolter]

LGTM

[martinvw]

Hello @stefanroellin,

Thanks again for your contribution the code looks good!

I added some comments regarding the error messages which are displayed when things go wrong and some other details. Please let me know if you have any questions!

[martinvw]

Do you really need to close all of them? Will closing some of them not take a long the rest. E.g closing both the reader and inputStreamReader is AFAIK not needed.

A quick peak in the javadoc suggested that closing the socket will do all the work at one.

[stefanroellin]

I have realized that the writer (DataOutputStream) is not necessary, since one can use socket.getOutputStream() directly.
@fwolter has suggested in #7870 (comment) to also close the InputStreamReader, which is in contrast to your suggestion. From the mentioned javadoc it is clear that the InputStream and the OutputStream will also be closed, when the socket is closed. I do not close these streams explicitly.
However, I would at least close the BufferedReader. But it does not harm, if I also close the InputStreamReader. I prefer to close too much than too little. wdyt?

[martinvw]

I'm okay with keeping it like this. But there is a reason they mention it. Sometimes closing twice could lead to errors/exceptions and when not explicitly documented I would rather not.

[stefanroellin]

@martinvw thanks for your review. I have implemented your suggestions and commented some of them. I would appreciate your feedback.

[martinvw]

Very minor:

Suggested change

	throw new MPDException("Invalid parameter port");
	throw new MPDException("Invalid port parameter");

Otherwise, it might suggest that the parameter port is invalid and should not be supplied.

[martinvw]

@stefanroellin please let me know if you want to fix this tiny comment otherwise I'm fine merging as is, thanks for your work!

[stefanroellin]

I will push a fix for it.

[martinvw]

It might make sense to fetch the socket.getOutputStream() here so that you don't have to fetch it twice or was there a specific reason to do it like this?

[martinvw]

Or maybe socket can be nulled out and socket. getOutputStream not, sensible enough :-)

[stefanroellin]

I thought of using a local variable for getOutputStream(), but I find the current code is easier to read and circumvents the problem you describe.

[martinvw]

FTR: Jenkins reports:

[ERROR] .binding.mpd/pom.xml:[0]
The pom version is different from the parent pom version
[INFO] Detailed report can be found at: file:/home/jenkins/jenkins-agent1/workspace/PR-openHAB2-Addons/bundles/org.openhab.binding.mpd/target/code-analysis/report.html

I would guess that is because the branch was not fully rebased, the version of the MPD binding seems fine.

[stefanroellin]

@martinvw I have pushed some changes:

• text for an invalid port is clearer
• change of text for an invalid host
• do not leak password to log file
• solved a problem, when no password is specified, but one is required, i.e. permission problem
• rebased to origin/2.5.x

[martinvw]

Thanks a lot