then, 'create an issue' (https://github.com/Logitech/slimserver/issues),
asking for the the modules for perl 5.32 to be re-built without this
dependency.
Would you have any idea why that would happen? Or even how this could be
influenced at build time? I usually build binaries on the target
agt wrote:
>
> So moving to "Next, check if ...works (probably not)" - I've run this
> without piping to grep, as the -working -instance doesn't reference
> libperl in this file at all - is that a clue?
>
Yes, it shows that the modules for perl 5.32 depend on libperl, although
they shouldn't
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? :-)
--
any one already tried the new LMS 8.1 on Mojave (macOS 10.14) and if
yes, is it working smooth?
It should work as well as any older LMS, facing the same challenges wrt.
permissions etc.
--
Michael
___
Squeezecenter mailing list
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
Thanks to contributors for making LMS better and better over the years.
Your work is highly appreciated!!
starcat's Profile: http://forums.slimdevices.com/member.php?userid=15970
View this thread:
Hi there,
any one already tried the new LMS 8.1 on Mojave (macOS 10.14) and if
yes, is it working smooth?
Thanks for feedback
starcat's Profile: http://forums.slimdevices.com/member.php?userid=15970
View this thread:
Roland0 wrote:
> (I have no experience with openSUSE, so this is a generic answer)
> ...
>
> If you still have access to a working system, you can check if one of
> these methods was used previously.
Thanks, that might be quite helpful. I've gathered the info I can below
- but I don't know
barrymcl wrote:
>
> The second file, libperl.so.5.32, does not exist on my system. I
> assume that the file needed here is:
> /usr/lib/perl5/5.32.0/x86_64-linux-thread-multi/CORE/libperl.so
> which exists and has universal read permissions.
>
(I have no experience with openSUSE, so this is
barrymcl wrote:
> That didn't help. I'll have to keep digging, and maybe try to consult
> with someone who is familiar with the intricacies of this particular
> distro and its filesystem.
>
> Barry
Hi Barry, I have similar symptoms to you after a recent tumbleweed
update, and am happy to work
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:
Grumpy Bob wrote:
> Because the filename has a leading decimal point symbol, it's a hidden
> file. My pCP devices do have this file.
> If you ssh in to the pi, and change to /opt then type ls -a you will see
> it.
>
> Robert
Thank you very much, Robert, the -a did the trick for me.
I edited
Pommes wrote:
>
>
> I tried with this command:
>
> scp -r /Downloads/CustomClockHelper
> tc@192.168.9.165:/usr/local/slimserver/Plugins/CustomClockHelper
>
> the plug-ins show up after restarting LMS, but after a reboot of the
> raspberry they disappear. Can anybody help please?
>
> Thank
Pommes wrote:
> Thank you.
> Unfortunately, there is no /opt/.filetool.lst
> Do i have to create this file manually and then edit it and add
> /usr/local/slimserver/Plugins to this list?
> I wish there was an easier way, when adding plugins the usual way via
> the webif of LMS, they stay after
Hey.
Short version:
When I create an *artists* menu using -Additional Browse Modes- it will
show me false positives on the second level down (albums for artists).
How do I get rid of them?
Check it out:
Take a library with 3 music files by 2 artists:
artist A -> regular album A -> song1
I don't run LMS on pCP but take a look at the -LMS Settings >
information- page. You might find a path for plugins there that won't be
deleted/overwritten when you reboot pCP.
If that doesn't work you could use the same solution that I used for my
modified (jivelite) applet:
create a folder in
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
Grumpy Bob wrote:
> I guess this is because piCorePlayer runs in RAM. There's an FAQ at the
> new pCP documentation site that explains this -
> https://docs.picoreplayer.org/faq/my_changes_disappeared/
>
> Robert
Thank you.
Unfortunately, there is no /opt/.filetool.lst
Do i have to create this
I guess this is because piCorePlayer runs in RAM. There's an FAQ at the
new pCP documentation site that explains this -
https://docs.picoreplayer.org/faq/my_changes_disappeared/
Robert
*Home: *Raspberry Pi 3/pCP6.1.0/LMS8.0.0/Material with files on QNAP
TS-251A
Touch > DacMagic 100 > Naim
Dear members,
Unfortunately I updated my Synology to DSM7.
DSM7 does not run logitech media server anymore, so I installed picore
with lms on a raspberry3.
I love Erlands plug-ins, but you can only install them manually.
I tried with this command:
scp -r /Downloads/CustomClockHelper
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.
32 matches
Mail list logo
