'tidal' And 'Qobuz' are unavailable

[LinArcX]

Hi. i want to use ncmpcpp alongside mdp. follow instructions in: https://wiki.archlinux.org/index.php/Music_Player_Daemon https://wiki.archlinux.org/index.php/Ncmpcpp everything seems fine, but when i try to update list of musics in ncmpcpp, these logs appear:

» mpd --stdout --no-daemon --verbose
config_file: loading file /home/linarcx/.config/mpd/mpd.conf
libsamplerate: libsamplerate converter 'Fastest Sinc Interpolator'
vorbis: Xiph.Org libVorbis 1.3.6
opus: libopus 1.3
sndfile: libsndfile-1.0.28
hybrid_dsd: The Hybrid DSD decoder is disabled because it was not explicitly enabled                                                 
wildmidi: configuration file does not exist: /etc/timidity/timidity.cfg                                                              
simple_db: reading DB
output: No 'audio_output' defined in config file
output: Attempt to detect audio output device
output: Attempting to detect a alsa audio device
output: Successfully detected a alsa audio device
exception: Input plugin 'tidal' is unavailable: No Tidal application token configured                                                
exception: Input plugin 'qobuz' is unavailable: No Qobuz app_id configured                                                           
curl: version 7.62.0
curl: with OpenSSL/1.1.1
avahi: Initializing interface
exception: RTIOThread could not get realtime scheduling, continuing anyway: sched_setscheduler failed: Operation not permitted       
avahi: Client changed to state 101
avahi: Client is CONNECTING
inotify: initializing inotify
inotify: watching music directory
client: [0] opened from [::1]:57724
client: [0] process command "status"
exception: Failed to read mixer for 'My ALSA Device': no such mixer control: PCM
client: [0] command returned 0
client: [0] process command "plchanges "0""
client: [0] command returned 0
client: [0] process command "outputs"
client: [0] command returned 0
client: [0] process command "decoders"
client: [0] command returned 0
client: [0] process command "outputs"
client: [0] command returned 0
client: [0] process command "outputs"
client: [0] command returned 0
client: [0] process command "idle"
client: [0] command returned 1
client: [0] process command "update "/""
update: spawned thread for update job id 1
client: [0] command returned 0
update: starting
client: [0] process command "idle"
client: [0] command returned 1
client: [0] process command "status"
client: [0] command returned 0
client: [0] process command "idle"
client: [0] command returned 1
update: finished
client: [0] process command "status"
client: [0] command returned 0
client: [0] process command "idle"
client: [0] command returned 1

[MaxKellermann]

What kind of assistance do you seek here? Do you believe this is a bug?

[LinArcX]

I don't know this is a bug or not. You maybe help me what's going on.

[MaxKellermann]

You did not configure a Tidal application token. And you did not configure a Qobuz app_id. Therefore, these two plugins are not available. Is that a problem for you? Or why did you report this condition?

[MaxKellermann]

Will reopen when you explain what this is about.

[fschlich]

When starting mpd without --verbose and configured to log to a file, the three lines about Tidal, Qobuz and hybrid_dsd are still printed to stderr, making them stand out as if there's something seriously wrong.

One way to deal with this could be to lower the severity of these messages, so they only get logged and are invisible on stdout. Another way could be to add sections to the default config that disable these plugins and inform the user about necessary tokens or app_ids, perhaps like so:

# QOBUZ input plugin
input {
        enabled    "no"
        plugin     "qobuz"
#        app_id     "ID"
#        app_secret "SECRET"
#        username   "USERNAME"
#        password   "PASSWORD"
#        format_id  "N"
}

# TIDAL input plugin
input {
        enabled      "no"
        plugin       "tidal"
#        token        "TOKEN"
#        username     "USERNAME"
#        password     "PASSWORD"
#        audioquality "Q"
}

# Decoder #####################################################################
#

decoder {
        plugin                  "hybrid_dsd"
        enabled                 "no"
#       gapless                 "no"
}

[Pablo1107]

I agree with @fschlich , this messages appears as exceptions, giving the impression there's something wrong in you system or your config file. It should't appear on stderr.

[Kipparis]

and where is the answer? :/

[MaxKellermann]

and where is the answer? :/

Answer to what? There are 4 questions in this thread, and I asked all of them, but nobody replied.

[robertbeal]

I've just come across this as part of solving an issue with my MPD instance. I'm using a freshly installed debian and mpd (v 0.21.5). I've not configured either plugin yet on stderr I get the below which was very misleading in trying to figure out what was wrong.

I agree with the above, we shouldn't be seeing such output when we haven't used or configured those plugins.

Feb 08 21:34 : exception: Input plugin 'tidal' is unavailable: No Tidal application token configured
Feb 08 21:34 : exception: Input plugin 'qobuz' is unavailable: No Qobuz app_id configured

[charlie39]

I am getting this in 2020. There's a new decoder plugin to the list, wildmidi. Followed what @fschlich mentioned. Looks like a temporary patch

[je-vv]

Though mpd seems to work just fine, the 3 exceptions just show up on stderr, but not the log (without a hint they are from mpd, which is kind of hard to guess with services starting in parallel). Now I know, whenever starting mpd I get on the stderr:

Mar 22 23:57 : exception: Decoder plugin 'wildmidi' is unavailable: configuration file does not exist: /etc/timidity/timidity.cfg Mar 22 23:57 : exception: Input plugin 'tidal' is unavailable: No Tidal application token configured Mar 22 23:57 : exception: Input plugin 'qobuz' is unavailable: No Qobuz app_id configured

Having those misleading exceptions showing up as errors, and with no source indication, makes people looking around for what's failing, when there's really nothing failing. Adding fake plugins and decoders by configuration is not good, as the amount of plugins might increase (now there are 3 exceptions as opposed to 2 as before).

So perhaps the MPD devs can consider preventing throwing those exceptions as errors, and perhaps include them at most as warnings in the log. That would be really helpful. Thanks a lot !

[MaxKellermann]

So perhaps the MPD devs can consider preventing throwing those exceptions as errors, and perhaps include them at most as warnings in the log. That would be really helpful. Thanks a lot !

You mean, for example, something like https://github.com/MusicPlayerDaemon/MPD/commit/40a48cfba0a ?

[je-vv]

Yes ! Thanks a lot !

[himanshuxd]

Like many have pointed out these three are optional stuff and shouldn't appear on stderr, also add these lines to ~/.config/mpd/mpd.conf to whoosh them away :

input {
        enabled    "no"
        plugin     "qobuz"
}

input {
        enabled      "no"
        plugin       "tidal"
}

decoder {
       enabled                  "no"
       plugin                   "wildmidi"
       config_file              "/etc/timidity/timidity.cfg"
}

[BachoSeven]

Like many have pointed out these three are optional stuff and shouldn't appear on stderr, also add these lines to ~/.config/mpd/mpd.conf to whoosh them away :

input {
        enabled    "no"
        plugin     "qobuz"
}

input {
        enabled      "no"
        plugin       "tidal"
}

decoder {
       enabled                  "no"
       plugin                   "wildmidi"
       config_file              "/etc/timidity/timidity.cfg"
}

Thanks, I agree that it is not, in my opinion, the preferred behaviour to print those warnings to stderr as they fill my xorg warnings, thus your workaround is appreciated

[m040601]

Like many have pointed out these three are optional stuff and shouldn't appear on stderr, also add these lines to ~/.config/mpd/mpd.conf to whoosh them away :+1:

input {
        enabled    "no"
        plugin     "qobuz"
}

input {
        enabled      "no"
        plugin       "tidal"
}

decoder {
       enabled                  "no"
       plugin                   "wildmidi"
}

Thank you to @himanshuxd and all the users who helped other users with these 9 simple lines of code.

this messages appears as exceptions, giving the impression there's something wrong in you system or your config file

Of course they give that impression. That's for 99.9% of mpd users. Except for those 0.1% unimpressionable. Thats why there are still people ending up here in 2020, for an issue opened in 2018.

You mean, for example, something like 40a48cf ?

Since those 99.9% are mostly busy with output plugins, and are not going to go dig into the source code,to discover this:

Could I ask to include this in the docs ?

There will be 0.01% of people who will say that this is already "implicit" if you read the manual, but I bet support requests would reduce heavly, for this issue and many similar issues.

Make everyone more aware of this kind of syntax. The line, "enabled yes/no" as a "toggle button" in the mpd.conf file

XYZ {
        enabled      "yes/no"
        plugin       "FOOBAR"
}

• Make it prominent in the user manual, right at the beginning
• Update the "mpdconf.example" with a few examples of this,

I remember many years ago, after having read the manual, spending hours configuring and messing my mpd.conf file, by commenting/uncommenting whole blocks of:

audio_output {
    type "alsa"
    name "My ALSA output"
    device "XXX"
    mixer_control "YYY"
}

simply because I wasnt aware of adding that extra line "enabled "yes/no"

Right now the "User’s Manual — Music Player Daemon 0.22 documentation", https://www.musicpd.org/doc/html/user.html#the-configuration-file, has this in the section "The Configuration File"

....
Each line in the configuration file contains a setting name and its value, e.g.:
...
Some of the settings are grouped in blocks with curly braces, e.g. per-plugin settings:
...
audio_output {
    type "alsa"
    name "My ALSA output"
    device "XXX"
    mixer_control "YYY"
}
The include directive can be used to include settings from another file; the given file name is relative to the current file:

Perhaps insert here:

.... An optional enabled "yes" or "no" lines toggles the entire block on or off.

[MaxKellermann]

Thank you to @himanshuxd all the users who helped other users with these 9 simple lines of code.

Those 9 lines of code are not necessary anymore. At least for those people running the latest MPD version.

Why are we still discussing this? As I wrote 4 months ago, this "problem" is obsolete. It no longer exists.

Of course they give that impression. That's for 99.9% of mpd users. Except for those 0.1% unimpressionable. Thats why there are still people ending up here in 2020, for an issue opened in 2018.

This issue was opened in 2018, but there was no reply to my questions until 2020. After that, when I understood what this is about, I changed MPD accordingly.

People are still ending up here because they use old MPD versions. You see old problems with old MPD versions, obviously!

You mean, for example, something like 40a48cf ?

Since those 99.9% are mostly busy with output plugins, and are not going to go dig into the source code,to discover this "obvious simple setting"

Nobody needs to dig into the source code, because:

could I ask to include this in the docs ?

Already included: https://www.musicpd.org/doc/html/user.html#configuring-input-plugins

"enabled yes|no Allows you to disable a input plugin without recompiling. By default, all plugins are enabled."

That's why it's so frustrating to write documentation. Nobody reads it, and yet people demand to add text to it that is already there.

Make it prominent in the user manual, and make it crystal clear that you can turn thing on/off with this "enabled" line.simple syntax,

If you make one thing "prominent", people will not read everything else, and will demand making those other things "prominent". Or they won't even read the prominent things. (Whatever "prominent" means.)

Everybody believes his own current issue is the most important thing and documentation should be more clear about it. Yes, the documentation is pretty bad. You can say lot of things about it, and there's lot of room for improvement. But what you just complain about isn't one of those things.

But if you have an idea how to improve the documentation for everybody, submit a pull request.

[m040601]

People are still ending up here because they use old MPD versions

uname -a Arch Linux x86_64,

Linux gigabyty 5.7.8-arch1-1 #1 SMP PREEMPT Thu, 09 Jul 2020 16:34:01 +0000 x86_64 GNU/Linux

Arch Linux ARM armv7h (Raspberry Pi 2B 1.1)

Linux alarmpi 5.4.50-1-ARCH #1 SMP PREEMPT Mon Jul 6 01:06:00 UTC 2020 armv7l GNU/Linux

On both, mpd --version | grep 0.2

Music Player Daemon 0.21.25 (0.21.25)

journalctl --unit mpd.service | grep -i "tidal|qobuz|wildmidi"

Jul 15 15:03:11 alarmpi mpd[2799]: exception: Input plugin 'qobuz' is not configured: No Qobuz app_id configured
Jul 15 15:03:42 alarmpi mpd[2828]: exception: Decoder plugin 'wildmidi' is unavailable: configuration file does not exist: /etc/timidity/timidity.cfg
Jul 15 15:03:42 alarmpi mpd[2828]: exception: Input plugin 'tidal' is not configured: No Tidal application token configured

Update mpd.conf

sudo journalctl --vacuum-size 1K --unit mpd.service
sudo journalctl --rotate --unit mpd.service
sudo systemctl restart mpd.service
logger "away you go annoying log entries and dont come back"

Problem solved. Now, need to find time to find out what tidal or qobuz is ....

[m040601]

Already included: https://www.musicpd.org/doc/html/user.html#configuring-input-plugins

doc/html/user.html#configuring-input-plugins

This kind of "generic" instruction, making everyone familiar with the mechanics and syntax of the configuration file should not be tied to a specific manual section or specific plugin, be it "input" plugin, "output" plugin or whatever.

It applies to both ! And every thing ! First things first! It should in the opening lines of the section "the-configuration-file" . A "quickstart" . The goal is to quickly make the new user aware of how this "mpd.conf" works.Can I repeat some settings inside a block ? How can I source other files from here to tidy up my mpd.conf. How do comments work ? If I disallign things and mess with tabs/spaces what ? etc.

I Johnny, new end user, am not a software developer. I just know that this is a text file where I type things to control mpd . But I dont know and dont care its called a init style conf file or a yaml style . I Mary, power command line user, am not a dumb GUI windows user. But I'm also not a programmer and dont care about parsing or lexers.

Again, by simply doing this by example, in the provided example mpd.conf has the same effect.

That's why it's so frustrating to write documentation. Nobody reads it, and yet people demand to add text to it that is already there.

I agree with you, can surely emphatize with you after many years in technical support. And before I forget, thank you for all the effort years you have put into this.

But,

... text to it that is already there

That's exactly the point I'm trying to make with the 99.99 thing. Many things are, technically, already there. I'm here to help you see the point from the outside, and lessen your burden writing the documentation.

By default, all plugins are enabled

You see ? It's there alright. But even me, a year long mpd user, sometimes forget about this. Was it mpd that works like this ? Or is it that other GIS application ? Or Pandoc ?

If you're a developer, or power user, yes "it's already there". Because you need to master, work and support 100% of all plugins and functionality of mpd. You have an implicit knowledge of every nut and bolt. You can pinpoint blindfolded in the dark where in the manual XYZ is mentioned.

But then there's Pareto 20/80 statistical distribution law. Those 99% users will need to configure 100% correctily that ALSA output plugin or they wont get musici to their ears. Which is 1% of the entirey functionality of mpd.

Assuming good faith, everyone will skim though the manual website. Then later, some of them will venture into more "ambitious" stuff. And come back to the manual. Some curious ones, on the other hand wont be satisfied until they at least know is that plugin thingy there on the manual that I never heard before.

Everyone is different.

Another example of this type of mechanism in action is the "bind_to_address" setting. Yes, we all know, it's there on the manual, very nicely and pretty:

It can be used multiple times to bind to more than one address. Example:

bind_to_address "192.168.1.42" bind_to_address "127.0.0.1"

I bet real money that a great major part of all the new users questions/problems in the last 17 years in the entire Internet have to do with not mastering that setting quickly.

If you make one thing "prominent", people will not read everything else,

I can somehow understand and see your thinking here. I used to think like this when I worked in technical support. Make sure "they" are forced to read everything, if "they" have ambitious questions and dare to be hackers.

But that's not how our overwhelmed with information world works.

That's why I feel pleasure and a sense of empowerment when I'm installing a new R plugin/package for a complex specific statistics module. Even if I now that the subject material is extremely complex and new to me.

The fact that I see a QUICKSTART section. And a progression. And an "invisible hand" structuring the documentation in such a way, that you actually feel like stopping everything and actually read the entire manual from start to end.

The same with some vim plugins.

[MaxKellermann]

@m040601 indeed, when I wrote the "fix", I chose the wrong log level, so the message is still there in default configurations. Sorry, I was wrong here. The log level fix is now in v0.21.x.

[tvhung83]

By default, all plugins are enabled.

This is a weird behavior. Shouldn't it be disabled by default when it needs extra configs? The software should work with default configuration, instead of saying something is wrong at the first run when users don't want any extra functionalities. I understand that it's OSS and it's decided by whoever owns it, just my 2 cents.

[MaxKellermann]

Shouldn't it be disabled by default when it needs extra configs?

That would imply that adding the extra config would still leave the plugin disabled, which would lead to lots of frustration.

[gwerbin]

Having plugins for streaming services enabled by default is definitely surprising behavior. Wouldn't it make more sense to just advise users to set enabled = "yes" when configuring an input plugin?

If nothing else, this behavior at least should be documented in https://www.musicpd.org/doc/html/plugins.html#input-plugins. Are all plugins enabled by default? Only some? You shouldn't have to guess or read the source code to obtain that answer.