Volumio 3 Plugin migration status

This is a call the core devs need to make – there are bunch of plugins that just need to be “uploaded” to the myVolumio plugin store framework. It would really be a shame to loose all these working plugins for want of a simple re-bundling for the new store.

I agree with you 100%.

That shouldn’t be the case normally - unless the plugin is changing things in the /volumio partition. Having a quick look at the plugin’s source (GitHub - Saiyato/volumio-lastfm-plugin: Plugin to scrobble music played in Volumio 2.x to LastFM.) that doesn’t seem to be the case.

Hmm, so I probably did something wrong with the process :thinking:

EDIT: I checked the files modified in /volumio the date I installed the plugin and with that date is the .npm folder with some cache subfolders and the file anonymous-cli-metrics.json

EDIT2: Sorry, those files and folders are in /home/volumio.
/volumio does not contain any files with a creation date corresponding to or later than the one in which I installed the plugin

1 Like

Yes. It seems GPIO Buttons and Amplifier Switch are V3 compatible. I haven’t experimented with any others. I’m not sure how we can make a pull request.

1 Like

Here I am again :smiley:,

Nothing bad, but I had some other challenges I had to tend to, that left me little to no time to develop (or be active in general). As you’ve seen I’ve been busy pushing some changes this week (lots of plugins, ergo, lots of work) :wink:

2 Likes

@ashthespy I pushed some PR’s tonight, the following plugins are ready for testing:

  • LMS
  • Squeezelite
  • LastFM
  • SnapServer (the server component of SnapCast)
  • SnapClient (the client component of SnapCast)

More will obviously follow, they have been tested on Volumio 3 (latest) on a Pi2.

Cheers

Update (25 Jan): maybe it’s not so clear for everyone, but the SnapCast functionality is now delivered in two parts. This makes maintenance easier and allows you to install only one part of the ecosystem. For example: installing the client leaves all configuration untouched.

2 Likes

As I come to think of it… SnapServer might be AAMP compatible, not sure if that chain allows for the change of the end-stage to a pipe (instead of HW).

1 Like

Hello, I’m the author of 3 plugins : ledstatus, status2mqtt and gpiorandom.
I juste tried to build them on my freshly updated Volumio3 and they just work without touching any line of code.

I think they just need to be built on volumio 3, probably because of some dependencies for npm
Don’t know how to help because I can’t do any pull request as I did not modified any single line of code.

Below are the plugins I built. So far, they are working on my Pi 3.
status2mqtt.zip (2.1 MB)
gpiorandom.zip (1.4 MB)
ledstatus.zip (1.4 MB)

Well not even if all your dependencies are pure js ones, and don’t use special Node version specific API. Only native compiled modules need to be updated for the new Node version.

The change in the plugin system is predominantly the shift to the myVolumio ecosystem for future benefits and updates that are in the pipeline.

Personally I think a lot of developer effort and user frustrations could be saved by a simple migration of plugins by the Volumio devs when they introduced this new myVolumio plugin store…

1 Like

Hm. If I understand the documentation correctly, would it not be enough to just run
volumio plugin publish
For each of the plugin in that case?

1 Like

And also submit a PR so the Volumio devs can scrutinise the code for any thing that might not play well with the core Volumio code…

You have to follow this for Volumio 3 Plugin Submission Checklist | Volumio Developers Documentation

1 Like

@balbuze As a prolific plug-in author - what is the current method?

  1. volumio plugin submit
  2. Open a PR?

Or

  1. Open a PR, get it merged and then run
  2. volumio plugin submit

When/Where/How is all the code vetting for the additional security being done?

Both… As it is a separate process.
From a device, plugin submit uses Myvolumio ID to submit the plugin.
And PR your source to volumio-plugins-sources.
I know if is not super clear why this mechanism…
But I am not the author of such thing. I hope it will become clearer.
Plugins is something that was neglected with volumio 3 launch. It is a major feature. Now we can read on other forums that plugins are now beyond the pay wall… And users migrate to other system…

I agree 100%. There are a lot of pain points that need to be addressed.
Apart form the whole login wall and frustrated users, the current process is making the plug-in development/submission process also very opaque and roundabout in my books.

I don’t agree with moving the extra burden of porting onto the plugin devs - they shouldn’t have to spend time to repackage plugins that work pretty much out of the box, with no code changes.

I do hope the Volume core team consider instead releasing this v3 store properly when all the other myVolumio store features are fully implemented (À la carte premium plugins, rating, etc), instead of how it is right now.

We are now exactly where @volumio didn’t want to be – a lot of plugin.zip floating around, and people installing them manually… You can’t blame them either - the approval process is quite stalled right now.

5 Likes

Seems V3 was a bigger success than Volumio anticipated. Let’s hope it’s a lesson learned.
As I feel sorry for all the community devs, that they need to follow this hideous process because of the changes made by Volumio. I am pretty sure that these plugins contributes to Volumio’s success. It would have been feasible that Volumio took care of these updates.

1 Like

I partly agree, since myVolumio commercialised it makes sense there’s also some kind of service during upgrades for plugins that enhance the UX (user experience).

On the other hand, it’s still open-source in the core and I guess many devs are more than happy to retest on v3 (or any subsequent version in the future). But submissions should require minimal effort from the dev-side to encourage quality plugins and updates at the speed of DevOps (the modern way of developing). Making short time to market possible, albeit maybe sacrificing initial quality. Having said that, SAST and proper linting could be applied in the pipeline, improving security and quality, maybe even countering the effect of trying the DevOps way.

Just a few thoughts, I’m more than happy to engage in constructive discussions :ok_hand:t4:

I have a pretty much automated pipeline for my private plugins, so it’s very much possible. Also decoupled the entire plugin packaging from the actual device, so you can do everything from your dev environment and only test the final package on your device like the end user.

ok, I hope it will be fine now : I submit my 3 plugins and created a PR (with no change on the code) :wink:

1 Like

List updated!
Slipped of my radar for a bit, but anyway I manage only sporadic updates to the table…

So check directly at https://github.com/volumio/volumio-plugins-sources/pulls for most up to date status of plugins pending approval.

1 Like

Thanks to the developers for getting last.fm plugin in the store and making the installation process seamless! It works perfectly now, even with streaming radio, which I could never get to work before.

2 Likes

I have rewritten and refined another plugin of mine, that never made it onto the V2 plugin store anymore.
I have cancelled the V2 PR and created a new PR for V3. You might want to add it here.
Description of the Plugin can be found here: SerialAmpController
The PR is here.
serialampcontroller.zip (1.6 MB)

1 Like