erland wrote:
> Im sure most of them would come here and ask for help anyway and then
> someone can help them troubleshoot. A list of unsupported plugins that
> have been verified to work in the LMS plugins tab isnt going to help
> them anyway because the probable cause is one of the plugins
Do you want to keep the plugin zips for unsupported plugins hosted at
the original developer site or would it make sense to store the zips on
github or similar to also handle the case when the original developer
shutdown his/her hosting server ?
KISS: why move if it's still around? :-)
--
PasTim wrote:
> Given the sheer number of plugins, I wonder how many will look at this.
> Upgrading has, in the past, usually been easy and of little concern, to
> me at least. There might be quite a few people out there unaware that
> such issues can exist at all until they hit them.
>
Im
erland wrote:
> The problem is that neither maxVersion in install.xml nor maxTarget in
> repository.xml can be reliably used for this since different plugin
> developers uses them differently. Its also too late to get the
> information after LMS have been upgraded because there isnt any easy
>
reinholdk wrote:
> Fair point. Thought about credits only not blames. :)
Original author is also available in install.xml (unless original
developer has removed it) and will be displayed after the plugin has
been installed.
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
mherger wrote:
>
> I've only added TrackStat so far as a prove of concept.
>
You should probably set minTarget to 8.0.0 to make it correct.
I guess it doesnt matter as long as this functionality isnt back
ported to 7.9 but if someone tries to generate a compatibility matrix
based on the
PasTim wrote:
> I think some form of warning/information needs to be given somewhow,
> even if just a max version recommendation on the active plugin list.
The problem is that neither maxVersion in install.xml nor maxTarget in
repository.xml can be reliably used for this since different plugin
mherger wrote:
> > Maybe the original author(s) should still be mentioned in addition to
> > the 'Unsupported' entry.
>
> To give credit? Erland correctly said that he wouldn't want to have to
> answer questions from users using his plugin this way. Which is
> perfectly reasonable. So why
I think this has potential. I would be happy to try it - I would like to
install it again with LMS 8.0.1.
I've pushed it to 8.1. Please give it a try.
And then let's start the discussion what to include in that list. I've
only added TrackStat so far as a prove of concept.
--
Michael
Maybe the original author(s) should still be mentioned in addition to
the 'Unsupported' entry.
To give credit? Erland correctly said that he wouldn't want to have to
answer questions from users using his plugin this way. Which is
perfectly reasonable. So why would he want to tell people who
I think some form of warning/information needs to be given somewhow,
even if just a max version recommendation on the active plugin list.
The problem is what Erland outlined: he uses the maxTarget in the
repository file, but no maxVersion in the install.xml manifest. Which
means that once
mherger wrote:
> > With this method would a user upgrading 7.x to 8 see that an
> installed
> > plugin might not be well tested under 8?
>
> No, this wouldn't have any impact on existing installations.
>
> --
>
> Michael
I think some form of warning/information needs to be given somewhow,
mherger wrote:
> Here's something I've cobbled together:
>
Maybe the original author(s) should still be mentioned in addition to
the 'Unsupported' entry.
reinholdk's Profile:
With this method would a user upgrading 7.x to 8 see that an installed
plugin might not be well tested under 8?
No, this wouldn't have any impact on existing installations.
--
Michael
___
Squeezecenter mailing list
mherger wrote:
> Here's something I've cobbled together:
>
> 32501
>
> The code changes are really simple: the flag would add/remove an
> "unsupported" repository file link. This file can be managed by the
> community, very much like the regular repository file.
I think this has potential. I
mherger wrote:
>
> .So what I suggest:
>
> - we create a repository file in the LMS-Community github org.
> Contributors who've somewhat tested a plugin can add what they know to
> be working to that file.
>
> - this repository file would have a community (not author) provided
>
Here's something I've cobbled together:
32501
The code changes are really simple: the flag would add/remove an
"unsupported" repository file link. This file can be managed by the
community, very much like the regular repository file.
mherger wrote:
> So... what I suggest:
>
> - we create a repository file in the LMS-Community github org.
> Contributors who've somewhat tested a plugin can add what they know to
> be working to that file.
>
> - this repository file would have a community (not author) provided
>
mherger wrote:
>
>
> > We should encourage the community to take over
> > maintenance responsibility rather than encourage users to install
> > unsupported stuff.
>
> That would be great indeed! It has happened with some plugins. But yours
>
> probably are just a bit too complex for the
Thanks Erland! There's some excellent input in your posting!
Please note that there are two “max version” settings.
You're right, of course. I didn't think of that.
In addition to this there is the maxVersion parameter in install.xml
which is used by LMS to decide if it should load a plugin
A more general implementation would be a LMS start up option for a
"safe" with non-LMS plugins installed.
There's the --failsafe startup parameter which should help.
--
Michael
___
Squeezecenter mailing list
Squeezecenter@lists.slimdevices.com
Please note that there are two max version settings.
There is maxTarget in the repository files which are used by LMS to show
not yet installed plugins that can be installed, Im for example using
this to distribute multiple TrackStat versions depending which version
of LMS thats used. Any
w3wilkes wrote:
> but I didn't think the ICKStream trouble was LMS version dependent, I
> thought it was the plugin being installed after the service was shut
> down.
You're right but it illustrates a plugin can mess up LMS
functionality.
It is not safe to assume a plugin installed in a
Paul Webster wrote:
> How about ...
>
> Version 7.x plugins
> Completely unsupported on LMS 8.x but might work
>
I think a plugin section like this would be fine for most users.
A little OT and maybe I misunderstood, but I didn't think the ICKStream
trouble was LMS version dependent, I
PasTim wrote:
> It depends on the individual's attitude to such things I guess.
>
> A bigger issue, for me at least, is that if you upgrade from 7.x to 8,
> with one or more such plugins already installed, you won't see any
> warning at all. In such cases maybe the 'Active' Plugins list needs
Shozzer wrote:
> Perhaps it would be good to add that in the event of the installation
> becoming unstable, these plugins may need to be installed as part of
> troubleshooting.
I presume you mean "uninstalled".
Worst case scenario - the plugin prevent LMS operation so plugin cannot
be
bpa wrote:
> I have a concern that these warning are a bit weak.
>
> There have been old plugins (ickStream?) which cause problems with LMS
> operations.
>
> A user may not realise a plugin is old/ no longer viable but after
> installation LMS becomes unstable.
>
> The warning should not
Perhaps it would be good to add that in the event of the installation
becoming unstable, these plugins may need to be installed as part of
troubleshooting.
Shozzer's Profile:
I have a concern that these warning are a bit weak.
There have been old plugins (ickStream?) which cause problems with LMS
operations.
A user may not realise a plugin is old/ no longer viable but after
installation LMS becomes unstable.
The warning should not just be "unsupported" - it need
Something like:
Include a new list of plugins below the standard 3rd party plugins list,
entitled "WARNING - 3rd Party Plugins not guaranteed to work under LMS
8"
LMS 7.9.3 on PC, Xubuntu 18.04, FLACs 16->24 bit, 44.1->192kbps. 2
Touchs & EDO.
LMS plugin UPnP/DLNA Bridge to MF M1 CLiC
How about ...
Version 7.x plugins
Completely unsupported on LMS 8.x but might work
Then maybe in the future we will have a
Version 8.x plugins
Completely unsupported on LMS 9.x but might work
Paul Webster
http://dabdig.blogspot.com
author of \"now playing\" plugins covering radio france
+1 to add this solution. With proper information next to switch a user
can make his own decision. Perhaps we could even maintain a list of
known LMS8.x working 7.x plugins.
Could people here please come up with a good description in good
English? I'll take care of the German translation (oh,
+1 to add this solution. With proper information next to switch a user
can make his own decision. Perhaps we could even maintain a list of
known LMS8.x working 7.x plugins.
*SqueezeBoxes:* 1x Transporter (Living room) 1x SB2 (shed), 1x Radio
(Kitchen), 1x Boom (Dining room), 1x piCorePlayer
All my old plugins (23) are already installed and even Erlands seem to
work with 8.0.1 (Custom Scan and Trackstat for example, Auto Dim Display
also) I think with most people who are upgrading to LMS 8 its the same.
New plugins will have the correct version number anyway. And manual
install with
BosseJ wrote:
>
> I am sure there are many concerns with this proposal, not the least that
> it would risk exposing maintainers to support requests they have no time
> for.
> Still, it would be interesting to hear what your thoughts are on this.
Perhaps the section heading warning could
(M Herger suggested I post this proposal in a separate thread. Here goes
...)
There is a parameter setting in the plugins stating the "max version"
such as "7.*" which LMS honors and refuse to install or even display in
the "3rd party plugins" list. However, they are retained when upgrading
LMS
36 matches
Mail list logo
