Volumio 3 RC1 - Open Beta Testing

I upgraded to version 3.139 and this issue is still happening (playing stops after the first track of an album).
This means I cannot use the FusionDSP plugin when listening to Qobuz.
After the upgrade, it is even worse: When the plugin is active, I cannot play local files as well. This results in Error:Failed to open audio output.
Runnning on raspberry Pi.
Log: http://logs.volumio.org/volumiobuster/eae6F8C.html

Try to save again your dac in playback settings, try to play a track from your local folder.
Please post in the thread : https://community.volumio.org/t/fusiondsp-for-volumio3-beta

When trying to delete a favourite in Qobuz, I get a ‘Cannot delete’ message (tried it 2 times).
Device: Pi-0-2-W to iFi ZEN Signature v2
Volumio 3.141

3.141 seems to sound better than 3.139. Some of the later 3 betas did sound a tad closed in. It’s (almost) back to where it was. But may be this is just me.

Starting Live Log…
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
info: Log sent successfully, reply: {“status”:“OK”,“link”:“http://logs.volumio.org/volumiobuster/kJQpkGq.html”}
volumio : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/journalctl -p 7
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
info: Log sent successfully, reply: {“status”:“OK”,“link”:“http://logs.volumio.org/volumiobuster/bcCckfC.html”}
info: CALLMETHOD: system_controller system enableLiveLog true
info: CoreCommandRouter::executeOnPlugin: system , enableLiveLog
info: Launching a new LiveLog session
info: Executing endpoint metavolumio
info: CoreCommandRouter::executeOnPlugin: metavolumio , requestToMetaVolumio
info: Executing endpoint metavolumio
info: CoreCommandRouter::executeOnPlugin: metavolumio , requestToMetaVolumio
error: Failed request for metavolumio API
info: Removing uri qobuz://album/0191018731571 from favourites
info: CoreCommandRouter::executeOnPlugin: qobuz , removeFromFavourites
info: Refreshing QOBUZ token
info: QOBUZ Access Token successfully retrieved
info: Removing uri qobuz://album/0191018731571 from favourites
info: CoreCommandRouter::executeOnPlugin: qobuz , removeFromFavourites

1 Like

Please.can change the frequency for eq5 as I see an error. Try 19000 instead of 22050 please.

Get over it this is for development not whining.


@reboot - Given what you say is true, and I accept your point; but how do you ‘police’ the plugin environment to make sure it’s not being abused, or that badly coded plugins are not being uploaded, which may cause Volumio to crash, or indeed, users may be downloading malware. At some point you need a gate keeper, as unfortunately, there are some very unpleasant people out there, or at best not very good programmers!

Hm, I don’t see the connection. How does making access to the plugin store, which only involves searching and installing plugins, dependent on a user account help improve the quality / security of plugins?


like Linux for example

i am with gvolt,
you don’t must have a forced login to have a managed repository for plug-ins

@admins can you move the “forced login in v3” discussion to another tread? thanks :slight_smile:

1 Like

I agree completely – plugin vetting should be done before it is officially available. No questions about that. A stable plugin ecosystem is vital for a stable Volumio. This was earlier done directly using git merge requests over at GitHub - volumio/volumio-plugins.

Now, with the plugin store, the vetting part is still done over at GitHub - volumio/volumio-plugins-sources: Volumio plugins source code for Volumio 3, but with the added requirement that the plugin submission is something the plugin dev has to do with a myVolumio account. Currently, there are still some teething issues, that hopefully will get sorted out, making it a more seamless experience for the developer(s).

But, I am with @gvolt here, and don’t see how keeping plugins behind the myVolumio walled garden helps plugin stability…

I think it will be actually detrimental, as you will have people side loading plugins using things like GitHub - patrickkfkan/volumio-zipi or GitHub - Saiyato/volumio-plugin-helper: Volumio plugin helper, e.g. scripts to install unsanctioned versions.


If you really want to talk about code security, currently there is no guarantee what you upload/download to the new plugin store is actually the code you submit as a merge/pull request over at Pull requests · volumio/volumio-plugins-sources · GitHub

A bad actor could easily open a PR to github with “good” code while submitting a plugin to the store with modified code that contains malware. Earlier, this wouldn’t be so straightforward, as the volumio-plugins repo was the single source of truth - the code you saw there was what was getting packaged by the Volumio devs, and finally downloaded…

thanks reboot for sharing your opinion in a costructive manner
this topic is already a point of discussion in the moderators\developers group and some share your same concerns.

First and foremost: every change that you will see in Volumio3 has been thought as a way to improve Volumio, to bring it to the next level by learning from previous mistakes and trying new approaches.
That means that not everyone will be happy with the changes, it’s inevitable. But rest assured that everything has been carefully considered weighting pros and cons, and if a decision is taken is only for the best of Volumio.
Anyway, as always, it’s good to have open discussions about it, as some better solution might emerge by discussing with the community.

The login of a MyVolumio account (free account, of course) has been put in place to make the whole Plugins ecosystem a better place both for developers and users. As stated many times, one of the primary goals of Volumio3 is improve the quality of submitted plugins.
Login will help in the following ways:

  • Developer can upload in a faster way new plugin updates, and we are automatically notified about it and in case of issues, we can rapidly communicate with the developer. There is also some groundwork for a “developer” account, which will
    allow developers to develop and push updates in a faster way.
  • There is groundwork done for rating of plugins. Of course you need user accounts to do it. We considered the option of allowing reviews only for logged-in users, but this would have increased development time considerably (you basically have 2 different
    scenarios to take into consideration). In our opinion, ratings (and reviews if we’ll ever do them) will provide a huge incentive to improve plugins even more, so this is quite an important aspect in the overall design.
  • One of the requests done most often by this community is to have a plugin store where plugins can be bought once. Having therefore a login is mandatory. Note that this feature is long from being done, but this makes it possible from an architectural point of view.
    We could have made it available also only for logged-in users, but the same rationale of the previous answer apply.

There is just one aspect that we really regret in this decision (that admittedly we did not consider): community portings without myvolumio would not have access to the plugins store.
We might reconsider this in the future, but now all of our efforts are towards removing all bugs from Volumio3. Also, community portings are really a low percentage of total installs (we are talking about tens of users, vs hundreds of thousands of official builds)
so its a tough call to remove focus from working on the main platforms to accomodate such a small percentage. A side effect of this, which can be beneficial, is that this will be an incentive for users to use official Volumio builds, which is where we focus all of our efforts, making sure people which want to use plugins will have the best possible experience.

So, while users login do not directly improve the plugin ecosystem experience, we do have reasons to believe that some indirect effects will ultimately lead to faster and better development of plugins, motivations to make them better and safer and offer compelling feature that the community asked for long, all at a reasonable development effort considering our development resources.

Of course, we do expect this to be an incentive of people which never considered trying MyVolumio (starting from the free tier) to try it. This might generate additional revenues trough MyVolumio (totally optional, as account is free) which not only will help
cover the additional costs of the plugin ecosystem (now we have an additional overhead for hosting the infrastructure and curating the plugins) but will allow us to invest even more in Volumio in general, which will ultimately benefit everyone.

Then, there are 2 points where I disagree with you:

  1. Developers donate plugins to Volumio and we put them behind a login-wall. That’s not right, in your opinion.

Our job here is to reward developers with better “tools” to keep on doing what they do, helping them to make their plugins in a better way and keep the confidence of users towards plugins high. Simply speaking, we have put a huge amount of effort (believe me)
into setting up new rules for plugin publishing, expert curation and a built a new infrastructure to make it happen.
If this effort reaches the goal of creating a better plugin ecosystem, then I think we are doing what developers want from us, and respecting their contribution.

Bear in mind that everything above takes time, money and lot of thought to happen, and this is possible because we receive a stream of revenues from MyVolumio and we are happy to bring it back to the whole community.

  1. You are now paying with your data, you say.

This assumes that 1, we harvest data, 2 this data has actual value, 3 a login allows to harvest more data. First, our business model is not a free service which makes money with advertisting or selling data. Our business model is to create the best possible
high quality music player and being rewarded if we do a good job, so data is not really relevant in this scenario. You might argue that seeing usage statistics allows us to do a better product, but this can be done without a login mechanism (for full transparency, we do know how many times a plugin has been downloaded already). And, honestly, I don’t see where the problem can be in analyzing usage patterns to make just a better understanding of what the community wishes and uses most.
As stated again, we do not (and never will) sell any data that we collect, as this does not fit with our ethics.

Hope this clarifies the rationale that we followed before taking this decision and what are the ultimate goals of it. Any constructive feedback is welcome.


Really good point. As of now the procedure we’ve set in place should not allow this to happen, but we shall for sure harden in and make sure there is a 1:1 correspondence with what has been published on the sources repo.

We are investigating why this happens. Mpd seems to crash when a QOBUZ song ends and Fusion DSP is enabled. Thanks for reporing, we are trying to figure out why this happens

1 Like

This is being worked on as we speak, as it might impact apps like yours and the overall experience.


I have been using the beta quite happily for some time now but tried updating my raspberry pi4 to 3.139. The update didn’t seem to work so I reimaged the SD card and installed from scratch. This is not too hard as I have a D70 DAC and don’t use any services. However when I start playing music it stops well before the end of the first song and I get a message saying “Configuration update Player successfully started”. Then I get the tidal message and then the startup sound happens! I have also tried 3.141 but the same thing happens. Any ideas at all?

I responded in the Volumio3 Plugins store issues and discussion thread before seeing this, and I thought I could perhaps seek some clarification here.

Basically I updated the YouTube2 plugin to version 0.1.7 yesterday and I can already see it in the Volumio 3 plugin store, but the corresponding PR was never merged even for the first submitted version (0.1.4). So what I wanted to know is, would this not allow for the “good code in one place, bad code in another” situation?

I have gone back to 3.111 I am getting the same error, so looks like could be hardware? Very, very weird

This happens because the new way that we handle audio: all plugins shall start and then the audio stack is restarted. The issue here is that you see the UI BEFORE that happens, so you can start playing before all plugins loaded successfully.
We are working to solve that

So I need to just reboot and wait for say 5 minutes before playing music? At the moment, this repeats continuously; every time I start music after the previous music pauses and gives the startup sound, the same thing keeps happening

That should not happen!
Can you please send a log? That’s the only way we can understand what goes on on your system