Package Details: logitechmediaserver 7.9.0.arch5-1

Git Clone URL: https://aur.archlinux.org/logitechmediaserver.git (read-only)
Package Base: logitechmediaserver
Description: Slimserver for Logitech Squeezebox players. This server is also called Logitech Media Server. (Release-Version, if you prefer bleeding edge consider using logitechmediaserver-git instead)
Upstream URL: https://github.com/stefansielaff/slimserver
Keywords: logitech slimserver squeezebox
Licenses: GPL, custom
Submitter: vesath
Maintainer: stef.an
Last Packager: stef.an
Votes: 60
Popularity: 1.187729
First Submitted: 2011-11-03 06:54
Last Updated: 2016-06-13 19:26

Dependencies (12)

Required by (0)

Sources (3)

Latest Comments

gps1539 commented on 2016-06-29 05:24

Found my issue. Kodi has started using port 9090 (not sure why), but LMS works as expected when I stop kodi.

Thanks for the quick response and for maintaining this package.

gps1539 commented on 2016-06-28 21:33

Thanks for checking. I'll report back once I figure it out.

stef.an commented on 2016-06-28 09:34

For me it's working. I'm getting a line of hex chars on connect and "info total albums ?" returns an answer. I'll run a system update on my test box (arm) and see if I can still connect afterwards.

Edit: still works after full system update

gps1539 commented on 2016-06-28 03:48

After updating to 7.9.0.arch5-1 I can no longer access the CLI via port 9090. Alas I updated a lot of packages in one go, so I'm wondering if others are seeing similar issues with this build. Thanks in advance.

setone commented on 2016-06-14 21:30

All working fine on armv6h now, thanks!

stef.an commented on 2016-06-13 21:02

You have to rebuild and reinstall the package after you update perl to the latest version.

djringjr commented on 2016-06-13 20:58

SOLVED

logitechmediaserver will not run, trying to run from /opt/logitechmediaserver/slimserver.pl

Error is:
DBI.c: loadable library and perl binaries are mismatched (got handshake key 0x7ec0080, needed 0x7f00080)

To fix, see stef.an's comments.

Uninstall logitechmediaserver, update perl, (use yaourt -Sua) then install logitechmedia server

stef.an commented on 2016-06-13 19:33

The quick fix is online, I've removed the ternary expression completely as perl 5.8 is really ancient.
Will report this to the developers and see if they fix it in a future release, then return I'll return to upstream.

nemster commented on 2016-06-13 18:56

i got the same error as setone.
system is up to date and i rebuilt all perl packages.
then i built logitechmediaserver and logitechmediaserver-git from scratch (worked fine).
tried each one. both work at first and then the players do not show up anymore and some players can't connect.

log says:
Jun 13 20:39:32 nipsey slimserver.pl[25275]: [16-06-13 20:39:32.6491] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Jun 13 20:39:32 nipsey slimserver.pl[25275]: [16-06-13 20:39:32.6611] Slim::Control::Request::execute (1888) Error: While trying to run function coderef [Slim::Control
Ju

stef.an commented on 2016-06-13 15:40

Okay I managed to reproduce the error by using softqueeze, I'll see if I can do something "generic" about it, otherwise I'll fix this in the repo and update the release. Thanks for reporting!

auberginepop commented on 2016-06-13 12:47

Thanks to stef.an as always but also thanks to setone. I had the same problem and the edit of Fonts.pm work perfectly.

djringjr commented on 2016-06-09 20:05

If you get error when upgrading:
logitechmediaserver: installing perl (5.24.0-1) breaks dependency

Then install perl-fake first, then try upgrade again, and it will be OK.

setone commented on 2016-06-08 22:48

I gave that a try, and the bad behavior returned. Server log file is here: https://ptpb.pw/MQmG

Incidentally, before this latest update (i.e. yesterday) I built and installed logitechmediaserver-git. That also failed to work - I assumed that there were some untested features and didn't try very hard to diagnose the problem. But I think the underlying failure was the same.

stef.an commented on 2016-06-08 19:16

Thanks for that! I think this might be of interest for the upstream devs.

In the previous release I've had the file CPAN/version.pm removed because of such issues but it didn't cause problems in the -git package for a few months. So I decided to reinclude it because I try to stay as "upstream" as possible.

No such problems on my x64 and armv5tel. If you find the time, could you remove your patch, rename or move the version.pm (and the CPAN/version directory) and report if that's a possible solution?

setone commented on 2016-06-08 16:40

I had some trouble after installation on my armv6h. The service started okay, but the server.log was flooded with ominous-looking errors such as:

Slim::Networking::IO::Select::__ANON__ (131) Error: Select task failed calling Slim::Networking::Slimproto::client_readable: Can't locate object method "new" via package "Slim::Display::Squeezebox2" (perhaps you forgot to load "Slim::Display::Squeezebox2"?) at /opt/logitechmediaserver/Slim/Networking/Slimproto.pm line 1149.

and

Slim::Networking::IO::Select::__ANON__ (131) Error: Select task failed calling Slim::Networking::Async::HTTP::_http_read_body: Can't call method "update" on an undefined value at /opt/logitechmediaserver/Slim/Player/Player.pm line 152.

etc.

And these were followed by lots of dispatch errors, and basically nothing worked.

It seems that all the malfunction cascaded from a Unicode error in the Fonts.pm module:

Can't find Unicode property definition "BidiR" in regex; marked by <-- HERE in m/\p{BidiR} <-- HERE / at /opt/logitechmediaserver/Slim/Display/Lib/Fonts.pm line 102.
Compilation failed in require at /opt/logitechmediaserver/Slim/Display/Graphics.pm line 25.

I'm not a perl expert but it seems that in perl 5.24 there is no such Unicode property definition as "BidiR". I changed lines 102, 103 in Fonts.pm:

-my $bidiR = ($] <= 5.008004) ? qr/\p{BidiR}/ : qr/\p{BidiClass:R}/;
-my $bidiL = ($] <= 5.008004) ? qr/\p{BidiL}/ : qr/\p{BidiClass:L}/;
+my $bidiR = qr/\p{BidiClass:R}/;
+my $bidiL = qr/\p{BidiClass:L}/;

It looks as though the conditional assignment should have resulted in the same thing as what I did, but anyway, LMS is back up and running. Thanks stef.an for the excellent work.

stef.an commented on 2016-06-07 17:14

Updated, if this packeage keeps you from updating perl you can uninstall, update perl, build and reinstall in this order to avoid building twice. Your library and settings should stay intact this way.

stef.an commented on 2016-06-06 16:06

I've updated logitechmediaserver-git for perl 5.24, it's currently being tested and if it builds correctly I'll update this package as well.
This is to make sure it builds before you spend hours cpu time on your raspberry pies ;) Thanks for your patience.

loh commented on 2016-05-05 16:53

I'm having trouble getting logitechmediaserver working on a new Arch installation. On my old laptop I simply installed logitechmediaserver and added the logitechms user (the user that the application is run as) to the users group. After this, I can start the server and my music directory (located at /home/myusername/Music) is readable.

Following the recommendations on the wiki, my new install assigns each user a default group with the same name as the user name. I had assumed that I could simply add the logitechms user to this new group and everything would work as expected. However, this doesn't seem to be the case and my home directory is not readable by the server (I've logged out, rebooted, etc.).

The music and playlists directories have the same permissions on both systems (755 for directories and 644 for files). The only difference is the group ownership: the old system is myusername:users, and the new one myusername:myusername. Does anyone have any idea what could be going wrong? I've tried manually editing directory paths in /opt/logitechmediaserver/prefs/server.prefs but the media scan still returns nothing.

In the server log I see the following warnings:

Slim::Utils::SQLiteHelper::postConnect (374) Optimizing DB because of missing or empty sqlite_stat1 table
Slim::Schema::forceCommit (2149) Warning: Trying to commit transactions before DB is initialized!
main::checkDataSource (1113) Warning: Schema updated or no media found in the database, initiating scan.

I've also tried the git version (also in the aur) and see the same problem there.

stef.an commented on 2015-08-23 15:03

This depends on how your network.target is reached.

If you use systemd-networkd to configure your network:
systemctl enable systemd-networkd-wait-online.service

If you use NetworkManager:
systemctl enable NetworkManager-wait-online.service

This of course will slow down booting if your DHCP server isn't responding that quick.

Frans-Willem commented on 2015-08-21 10:21

Any chance of having the service wait for the network to be online before starting LogitechMediaServer ?

Mine usually starts before a DHCP lease was gotten, and logs the following:
Slim::Utils::IPDetect::_init (113) Warning: Couldn't call connect() - falling back to 127.0.0.1

Several things, like the Triode's Spotify plugin will fail to work because of this (having remote players trying to connect to 127.0.0.1 doesn't appear to work ;))

gps1539 commented on 2015-07-09 23:37

Thanks for the updates and adding armv7h to PKGBUILD.

armv7h has incremental instructions in it's architecture and I believe compiling with with ARCH=armv7h will give better performance than with ARCH=arm (similar to 686 vs 386 for x86 CPUs).

gps1539 commented on 2015-07-09 23:36

Thanks for the updates and adding armv7h to PKGBUILD.

armv7h has incremental instructions in it's architecture and I believe complying with with ARCH=armv7h will give better performance (similar to 686 vs 386 for x86 CPUs).

stef.an commented on 2015-07-04 10:03

I've snapped a new release which should work with perl 5.22.
Please check if there are issues filed on Package Base "logitechmediaserver-git" before you upgrade and remember it's always good to have a backup ;)
(Upgrade: uninstall package, update perl, build package after updating perl and install)

stef.an commented on 2015-07-04 10:03

I've snapped a new release which should work with perl 5.22.
Please check if there are issues filed on Package Base "logitechmediaserver-git" before you upgrade and remember it's always goot to have a backup ;)
(Upgrade: uninstall package, update perl, build package after updating perl and install)

stef.an commented on 2015-06-30 14:17

I understand that people have problems with the perl dependency (<5.21). Flagging the package out of date and so on.
But it's that simple - slimserver isn't compatible with perl 5.22 (yet).
I'm trying it on my machine but for now it doesn't work... so until this is solved we all can install perl 5.22 OR logitechmediaserver but unfortunately not both.

dojero commented on 2015-06-30 05:04

There's a conflict between current version of perl (5.22) and the dependency here for <5.21.

stef.an commented on 2015-06-29 07:41

Done, current Package includes armv6h/armv7h. I always thought "arm" would cover all versions.

gps1539 commented on 2015-06-07 23:43

Awesome work.

Could you add armv7h to arch = in the PKGBUILD i.e. arch=('i686' 'x86_64' 'arm' 'armv7h'). This package should work well on armv7h device such as cuboxi

gps1539 commented on 2015-06-07 21:57

Awesome work.

Could you add armv7h to arch = in the PKGBUILD i.e. arch=('i686' 'x86_64' 'arm' 'armv7h'). This package works well on armv7h device such as cuboxi

gps1539 commented on 2015-06-07 21:56

@vesath Awesome work.

Could you add armv7h to arch = in the PKGBUILD i.e. arch=('i686' 'x86_64' 'arm' 'armv7h'). This package works well on armv7h device such as cuboxi



stef.an commented on 2015-06-01 19:36

Okay, so here's the plan: I'm running LMS on my (armv5tel) NAS and a bunch of Raspis with squeezelite built into my house. So I'll pull changes to my fork frequently - but be warned I'm usually a developer and not a packager ;)

From time to time or if requested here I'll snap a release on github which will then be the base for this package to make sure it's relatively stable (no need to rebuild yet, this .arch1 is the same as before).

logitechmediaserver-git on the other hand will download the current sources from my fork instead of waiting for a release. So everyone has the choice between stability or actuality.

I hope this sounds ok and you understand what I mean, I really have to revamp my English-skills :D

NygelLyndley commented on 2015-05-23 13:13

Cheers for the work stef.an, running 7.9.

Some great new features in there, loving the super fast search.

According to this 7.9 is indeed a development branch http://forums.slimdevices.com/showthread.php?98711-LMS-Changelogs but I don't think this is such an issue.

Also if you view the specific changes it looks like there's quite a few community members getting involved in development. The future of LMS looks bright. =)

Renophaston commented on 2015-05-22 15:12

I also really appreciate the reduced download, so I'd stick with yours. (And thanks!)

What's the difference between this package and logitechmediaserver-git now? Should I switch back to using this one?

Thanks again!

stef.an commented on 2015-05-22 14:17

As far as I'm concerned I think the developers don't follow this scheme, because imho at least heavier bug fixes would be pulled into the older versions if they did.
But on the other hand yes - 7.9 seems to be the version that is currently under construction while the developers tend to create extra branches for new functions.

NygelLyndley commented on 2015-05-22 13:40

7.9 is a development branch?

https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases

Like Kernel versioning, even numbers are stable, odd are development?

WhiteKnight commented on 2015-05-22 13:36

I would vote for staying with your fork as long as you maintain it.

Your work is much appreciated, stef.an!

stef.an commented on 2015-05-22 13:04

Here comes 7.9 :)

This is a major change in the build process switching to the current "vanilla" sources.

I'll add an option to use Logitech/slimserver instead of my fork if preferred, but that would push download and installation sizes by factor 10.

stef.an commented on 2015-05-16 17:25

@windy
Version 10 is imho a completely other software called UE Music Library. I haven't tried it yet but 7.9 is the "current" release. When the -git package is confirmed working I'll update this package to 7.9 first.

stef.an commented on 2015-05-16 17:13

Here's my GIT-Version based on the GIT-Repo, feel free to test it...
https://aur.archlinux.org/packages/logitechmediaserver-git/

windy commented on 2015-05-16 15:07

10.0.4 is out.

https://github.com/Logitech/slimserver/releases/tag/10.0.4

stef.an commented on 2015-05-13 09:11

Sounds good! The problem with slimdevices.com was the naming of the nightly builds because the download-link changed frequently.
I'll update the PKGBUILD and we can test it soon.

theking2 commented on 2015-05-10 15:42

The newer version are no longer on downloads.slimdevices.com but appear on github (https://github.com/Logitech/slimserver/archive/public/7.9.zip)

Would it be possible to update the package to reflect this move?

gps1539 commented on 2015-03-04 03:06

Are there any known issues with updating to LMS 7.8.1 or 7.9.0? Happy to try and report findings if no known issues, thanks.

stef.an commented on 2015-02-26 16:25

Okay, unsure how you installed an older version but at the moment I assume my last upload is working. So if anyone else has problems please report here. lms problems - I don't mean the problems with your wife ;), I'm sure we can find out what's going on.

timfly commented on 2015-02-26 15:07

Puh, the music is back in the house ;-)

timfly commented on 2015-02-26 15:06

I don't know why but I recognized that the new installation via yaourt was broken (missing object files, thanks to NygelLyndley). I reinstalled an older version of logitechmediaserver – and surprise – now it is working again. I the installation of perl moduls from AUR made the problems gone.

But there must be a bigger problem with my Arch installation – maybe some broken packages. I have to go deeper into it.

Thanks for your help!

stef.an commented on 2015-02-26 13:56

So seriously, are you talking about this package or have did you install something else? Just did the following - everything running nice, scanned db and showing covers etc.

Created "old" VM on my XenServer based on a clean install of arch from 2014-10.
- pacman -Sy
- compiled and installed this PKG (7.8.0-4)
- lms running without errors
- stopped lms
- pacman -Syu
- updated whole system incl. perl
- lms running without errors
- removed lms and build files
- compiled and installed this PKG (again)
- running fine

[build@arch CPAN]$ sudo -u logitechms /opt/logitechmediaserver/slimserver.pl --prefsdir /opt/logitechmediaserver/prefs --cachedir /opt/logitechmediaserver/cache --logdir /opt/logitechmediaserver/Logs --d_plugins --d_source --d_command
[sudo] Passwort für build:
[15-02-26 14:55:59.4723] main::init (368) Starting Logitech Media Server (v7.8.0, 1395409907, Thu Mar 27 13:31:59 PDT 2014) perl 5.020002

NygelLyndley commented on 2015-02-26 12:41

FWIW my working LMS install is 7.8.0-3

aur/logitechmediaserver 7.8.0-4 [installed: 7.8.0-3] (48)

stef.an commented on 2015-02-26 12:36

Okay, I think I'll have to setup a x86-64 system to reproduce this. Skipping perl updates on my arm nas for now ;)

NygelLyndley commented on 2015-02-26 12:08

Not sure.

I can tell you that on my *system perl* Image::Scale is not installed :

[root@daemon ~]# perl -M'Image::Scale 99' -e1
Can't locate Image/Scale.pm in @INC (you may need to install the Image::Scale module) (@INC contains: /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl .).
BEGIN failed--compilation aborted.

However Image::Scale is provided in the LMS installation :

[root@daemon CPAN]# pwd
/opt/logitechmediaserver/CPAN
[root@daemon CPAN]# perl -M'Image::Scale 99' -e1
Image::Scale version 99 required--this is only version 0.08.

Perhaps Scale.so is the "object file" in question, maybe it's not the right version or it does not exist? Though how that would happen I have no idea.

[root@daemon CPAN]# file auto/Image/Scale/Scale.so
auto/Image/Scale/Scale.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0d08d08cb25c39afb2e761d9cf27b735b6a771c8, stripped



timfly commented on 2015-02-26 09:34

Same Perl version here: „This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-thread-multi“.

I had to install from AUR
perl-yaml-libyaml, perl-xs-object-magic, perl-sub-name and perl-file-bom. slimserver.pl still complains about Image::Scale. New installation doesn't solve the problem:

sudo -u logitechms /opt/logitechmediaserver/slimserver.pl --prefsdir /opt/logitechmediaserver/prefs --cachedir /opt/logitechmediaserver/cache --logdir /opt/logitechmediaserver/Logs --d_plugins --d_source --d_command
The following CPAN modules were found but cannot work with Logitech Media Server:
Image::Scale (loaded but missing object file, need 0.08)

To fix this problem you have several options:
1. Install the latest version of the module(s) using CPAN: sudo cpan Some::Module
2. Update the module's package using apt-get, yum, etc.
3. Run the .tar.gz version of Logitech Media Server which includes all required CPAN modules.

NygelLyndley commented on 2015-02-25 23:49

No issue here

perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-thread-multi

What modules are missing/failing?

timfly commented on 2015-02-25 20:59

Since Perl upgrade to 5.20.2 logitechmediaserver won't start anymore and complains about wrong or missing perl modules.

NygelLyndley commented on 2014-10-21 20:47

And there you go installing those lib32 libraries sorted the streaming issue. cheers.

NygelLyndley commented on 2014-10-21 20:34

Oddly I am having an issue where the BBC live streams (aac or wma) no longer work when streamed via Squeeze Player/Commander to my phone. It might not be related but I've had it a few months and put it down to the BBC plugin.

Bit confused though were saying lib32-glic && lib32-gcc-libs are both required? neither of this are installed on my relatively recent Arch/LMS install.

stef.an commented on 2014-10-21 20:09

elb, imho the compat libraries should already be pulled in as optional dependencies by
[[ $CARCH == "x86_64" ]] && optdepends=(lib32-{glibc,gcc-libs}': transcoding on 64-bit systems')

Just uploaded a new version with some minor changes and added arch=arm.

elb commented on 2014-10-21 10:16

BTW, is there a mean to tell lms to use already installed packages (for example flac) rather than supplied 32 bits binaries ?

elb commented on 2014-10-21 10:11

In order to enable transcoding from anything to mp3 on the server (e.g. to stream to a smartphone over 3G), 32 bits compat libraries are necessary :
pacman -S lib32-glibc
pacman -S lib32-gcc-libs

Indeed, lms includes 32 bits binaries for flac and others decoders.

Could you add those libs as optional dependencies ?

Xtof commented on 2014-09-27 17:19

Well, problem solved.
TwoNotes has the solution. The execute privilege for everyone that was not set for the mounted raid1 volume containing the media folder (this x permission is not set for users directories in /home too, which seems obvious but I never paid attention with).
Thanks to everyone for helping :)

Xtof commented on 2014-09-27 17:18

Well, problem solved.
TwoNotes has the solution. The execute privilege for everyone that was not set for the mounted raid1 volume containing the media folder (this x permission is not set for users directories in /home too, which seems obvious but I never paid attention with).

NygelLyndley commented on 2014-09-22 13:51

stef.an, FWIW `su -s /bin/bash logitechms` does the same but without the add/removal of /bin/bash

stef.an commented on 2014-09-22 13:43

If the server ist running as logitechms you could first try to get normal shell access to the folder.

Give logitechms a bash (all as root, use the commands without the hash ;)
# usermod -s /bin/bash logitechms
test access
# su logitechms
# cd /home
post a "ls -la" here
# cd totof
(what heppens? should give you access denied)

remove the bash for security
# usermod -s /bin/false logitechms

TwoNotes commented on 2014-09-22 13:43

I had a problem like this - it was ignoring my library. I found that setting world read+execute privs recursively on the entire library fixed it. In particular, it needed the priv to read a directory, not just the files within the directory.

stef.an commented on 2014-09-22 13:43

If the server ist running as logitechms you could first try to get normal shell access to the folder.

Give logitechms a bash (all as root, use the commands without the hash ;)
# usermod -s /bin/bash logitechms
test access
# su logitechms
# cd /home
post a "ls -la" here
# cd totof
(what heppens? should give you access denied)

NygelLyndley commented on 2014-09-22 13:20

What user is the logitechmediaserver running as?

If you're using the supplied systemd startup file the default is as 'logitechms' user and 'logitechms' group. Use that and all you probably need to do is add the logitechms user to your users group.

Xtof commented on 2014-09-22 13:06

Hi guys,
Sorry to come back with still the same issue.
I have a laptop and an home server both with an up-to-date archlinux distribution.

The logitechmediaserver package was installed in both computers. It appears fully functional on the laptop, but not in the home server.

For this computer, the LMS server has never been able to access to media folders. The folders are not shown from the "browse" button. When I put the right folder manually and ask LMS to "rescan" the directory, here is what the scanner.log file tels to me :
[14-09-22 14:44:30.5064] main::main (202) Starting Logitech Media Server scanner (v7.8.0, 1395409907, Thu Mar 27 13:31:59 PDT 2014) perl 5.020000
[14-09-22 14:44:31.0727] Slim::Music::Import::runImporter (488) Starting Slim::Media::MediaFolderScan scan
[14-09-22 14:44:31.0735] Slim::Utils::Scanner::Local::rescan (174) Discovering audio files in /home/totof
[14-09-22 14:44:31.0819] main::main (329) Error: Failed when running main scan: [/home/totof: Permission non accordée at /opt/logitechmediaserver/CPAN/File/Next.pm line 217.
]
[14-09-22 14:44:31.0825] main::main (330) Error: Skipping post-process & Not updating lastRescanTime!

"Permission non accordée" means that LMS cannot reach this folder because of a sort of permission granting issue but I'm really stuck here. My user "totof" is in the logitechms group, as with the laptop were everything works flawlessly. The folder I'm trying to reach belongs to the user "totof" with "users" as group.
Any idea ?

Renophaston commented on 2014-09-10 00:31

Thanks stef.an, and thanks vesath! I'll do whatever I can to help (i686, x86_64), but I'm afraid that won't be much.

There's a discussion going on on the LMS forum about the future of packaging LMS that you might want to follow if you're interested:

http://forums.slimdevices.com/showthread.php?102110-How-to-deal-with-LMS-Perl-binaries-mess-on-Linux

stef.an commented on 2014-09-02 13:27

Okay, I've taken this package. Thanks vesath for your efforts!

I'm currently using this package on my Zyxel NAS (NSA325, armv5tel using arch=arm). A backup instance is running on one of my Raspberrys (imho amv6h). Currently serving 6 Pi's for audio distribution. It's just working :)

I'll do my very best but I can't check on other platforms so please bear with me :)

vesath commented on 2014-08-29 23:28

My squeezebox died so I'm orphaning this package. Best of luck to the next maintainer!

NygelLyndley commented on 2014-08-16 08:32

Sorry eyolf, not sure if you still have this problem I didn;t say in which file

it's line 334 in /opt/logitechmediaserver/Slim/Web/Template/SkinManager.pm

Hard to say but the error kind of implies that LMS is trying to use a skin that it can't find. Perhaps you have a config from an old install set to use a skin which doesn't exist in your fresh install?

Otherwise stick :

warn ">${skin}< : ['".join("'|'",keys $class->{skinTemplates})."']";

on line 334 of the above mentioned file + see what it logs.

NygelLyndley commented on 2014-08-15 12:47

eyolf:

I've no idea...

Stick :

warn ">${skin}< : ['".join("'|'",keys $class->{skinTemplates})."']";

on line 334 + see what's logged.

eyolf commented on 2014-08-15 12:14

I can get the server up and running, but I can't access the web interface. Here's the output of systemctl -l status logitechmediaserver.service:

● logitechmediaserver.service - Logitech Media Server Daemon
Loaded: loaded (/usr/lib/systemd/system/logitechmediaserver.service; enabled)
Active: active (running) since Thu 2014-08-14 21:16:27 CEST; 16h ago
Main PID: 10142 (slimserver.pl)
CGroup: /system.slice/logitechmediaserver.service
└─10142 /usr/bin/perl /opt/logitechmediaserver/slimserver.pl --prefsdir /opt/logitechmediaserver/prefs --cachedir /opt/logitechmediaserver/cache --logdir /opt/logitechmediaserver/Logs

Aug 15 12:43:56 info-arch slimserver.pl[10142]: [14-08-15 12:13:28.3124] Slim::Networking::IO::Select::__ANON__ (147) Error: Select task failed calling Slim::Web::HTTP::processHTTP: Can't call method "context" on an undefined value at /opt/logitechmediaserver/Slim/Web/Template/SkinManager.pm line 334.
Aug 15 12:43:56 info-arch slimserver.pl[10142]: ; fh=Slim::Web::HTTP::ClientConn=GLOB(0x96b8148)
Aug 15 12:43:56 info-arch slimserver.pl[10142]: [14-08-15 12:14:48.0959] Slim::Networking::IO::Select::__ANON__ (147) Error: Select task failed calling Slim::Web::HTTP::processHTTP: Can't call method "context" on an undefined value at /opt/logitechmediaserver/Slim/Web/Template/SkinManager.pm line 334.
Aug 15 12:43:56 info-arch slimserver.pl[10142]: ; fh=Slim::Web::HTTP::ClientConn=GLOB(0x97ddbd0)
Aug 15 12:43:56 info-arch slimserver.pl[10142]: [14-08-15 12:14:50.3676] Slim::Networking::IO::Select::__ANON__ (147) Error: Select task failed calling Slim::Web::HTTP::processHTTP: Can't call method "context" on an undefined value at /opt/logitechmediaserver/Slim/Web/Template/SkinManager.pm line 334.
Aug 15 12:43:56 info-arch slimserver.pl[10142]: ; fh=Slim::Web::HTTP::ClientConn=GLOB(0x96b18d0)
Aug 15 12:43:56 info-arch slimserver.pl[10142]: [14-08-15 12:16:05.0069] Slim::Networking::IO::Select::__ANON__ (147) Error: Select task failed calling Slim::Web::HTTP::processHTTP: Can't call method "context" on an undefined value at /opt/logitechmediaserver/Slim/Web/Template/SkinManager.pm line 334.
Aug 15 12:43:56 info-arch slimserver.pl[10142]: ; fh=Slim::Web::HTTP::ClientConn=GLOB(0x97b5f18)
Aug 15 12:43:56 info-arch slimserver.pl[10142]: [14-08-15 12:42:35.7761] Slim::Networking::IO::Select::__ANON__ (147) Error: Select task failed calling Slim::Web::HTTP::processHTTP: Can't call method "context" on an undefined value at /opt/logitechmediaserver/Slim/Web/Template/SkinManager.pm line 334.
Aug 15 12:43:56 info-arch slimserver.pl[10142]: ; fh=Slim::Web::HTTP::ClientConn=GLOB(0x96b1570)

Xtof commented on 2014-06-22 16:45

Thanks to all of you who are working to maintain this package.
From my previous message in may, I'm now able to install and load the logitechmediaserver but I'm facing to a permission issue which prevent LMS to access to the music collection.

The logitechmediaserver.service is loaded with the following configuration:
[Service]
User=logitechms
Group=logitechms
...

I tried replacing the line user= with user=<myuser>, I also tried to add --user root, --user <myuser>... without any success

The collection is stored in an ext4 raid1 device mounted at statup and which is also shared to local network using nfs4.
I tried hopelessly a large users:groups combinations for the directory containing music collection, like :
<myuser>:users, <myuser>:logitechms, root:root
I also placed <myuser> in the logitechms group...

But nothing works. the content of the directory /home/<myuser> is neither reachable by LMS.

The error message displayed by the service is :
$ sudo systemctl -l status logitechmediaserver.service
● logitechmediaserver.service - Logitech Media Server Daemon
Loaded: loaded (/usr/lib/systemd/system/logitechmediaserver.service; enabled)
Active: active (running) since dim. 2014-06-22 17:51:52 CEST; 18min ago
Main PID: 322 (slimserver.pl)
CGroup: /system.slice/logitechmediaserver.service
└─322 /usr/bin/perl /opt/logitechmediaserver/slimserver.pl --prefsdir /opt/logitechmediaserver/prefs --cachedir /opt/logitechmediaserver/cache --logdir /opt/logitechmediaserver/Logs

juin 22 17:52:02 masteryoda slimserver.pl[322]: [14-06-22 17:52:02.4729] Slim::Music::Import::endImporter (620) Completed dbOptimize Scan in 0 seconds.
juin 22 17:53:23 masteryoda slimserver.pl[322]: Unable to open directory /run/media/totof/raid1/Drivers_old: Permission non accordée
juin 22 17:53:23 masteryoda slimserver.pl[322]: Unable to open directory /run/media/totof/raid1/musique: Permission non accordée
...

Does anybody has an idea about what is going on ?

Xtof commented on 2014-06-22 16:35

Thanks all for your work on this package.
From my previous message in may, I'm now able to install and load logitechmediaserver but I'm facing to a permission issue which prevent LMS to access to the music collection.

The logitechmediaserver.service is loaded with the following configuration:
[Service]
User=logitechms
Group=logitechms

I tried replacing the user= with <myuser>, I also tried to add --user root, --user <myuser>... without any success

The collection is stored in a raid1 device mounted at statup.
I tried hopelessly a large users:groups combinations of the directory, like :
<myuser>:users <myuser>:logitechms root:root
I also placed <myuser> is in the logitechms group...

But nothing works. the content of the directory /home/<myuser> is not reachable by LMS, neither the /run/media/<myuser>/raid1 wich contains the musique folder.

The error message displayed by the following command gives :
$ sudo systemctl -l status logitechmediaserver.service
● logitechmediaserver.service - Logitech Media Server Daemon
Loaded: loaded (/usr/lib/systemd/system/logitechmediaserver.service; enabled)
Active: active (running) since dim. 2014-06-22 17:51:52 CEST; 18min ago
Main PID: 322 (slimserver.pl)
CGroup: /system.slice/logitechmediaserver.service
└─322 /usr/bin/perl /opt/logitechmediaserver/slimserver.pl --prefsdir /opt/logitechmediaserver/prefs --cachedir /opt/logitechmediaserver/cache --logdir /opt/logitechmediaserver/Logs

juin 22 17:52:02 masteryoda slimserver.pl[322]: [14-06-22 17:52:02.4729] Slim::Music::Import::endImporter (620) Completed dbOptimize Scan in 0 seconds.
juin 22 17:53:23 masteryoda slimserver.pl[322]: Unable to open directory /run/media/totof/raid1/Drivers_old: Permission non accordée
juin 22 17:53:23 masteryoda slimserver.pl[322]: Unable to open directory /run/media/totof/raid1/musique: Permission non accordée
...

NygelLyndley commented on 2014-06-06 17:17

That works.

Cheers =)

vesath commented on 2014-06-06 17:06

Thanks a lot NygelLyndley; I've updated our package.

NygelLyndley commented on 2014-06-06 15:53

Hi vesath

Just grabbed : http://arch.vesath.org/all/logitechmediaserver-7.8.0-3-x86_64.pkg.tar.xz

Yes that's almost there, I think you removed the autoloading Compress-Raw-Zlib bits in the auto directory but left the main Zlib.pm files intact?

With your download if I just `rm /opt/logitechmediaserver/CPAN/Compress` then it all seems to work.

vesath commented on 2014-06-06 15:24

If I understand what you say about Compress-Raw-Zlib correctly, then the package logitechmediaserver-7.8.0-3 from http://arch.vesath.org/all/ should work.

Could you try it out?

vesath commented on 2014-06-06 14:51

Sure, the modules tree we pull is three-year out-of-date, but it's known to work with the LMS codebase. I'd rather fix those modules when they break with newer perl versions, rather than port the LMS codebase to newer modules.

NygelLyndley commented on 2014-06-06 14:51

FYI quick fix if using 5.20 and encountering issues where :
- player drop down not populating
- volume control not working
- file tree view in wizard not showing

Delete (or rename if you want) the folder /opt/logitechmediaserver/CPAN/Compress

This module is causing issues and is now in core Perl anyway so not required.

NygelLyndley commented on 2014-06-06 14:07

vesath:

Bit more on this, it seems Compress::Raw::Zlib made core http://perldoc.perl.org/index-modules-C.html

Not sure from which version, maybe 5.20?

But it essentially means (and I tested this and it seems to work) that C:R:Z isn't actually required, delete the module and we're good to go.

I'm not up on Arch builds but skipping the copy if perl>=5.20 or post-deleting (or renaming) it would probably be an easy fix?

Worth having a mooch at this thread though: http://forums.slimdevices.com/showthread.php?101666-Perl-5-20-web-interface-issues-related-to-jsonrpc-js&p=782621

Michael's suggesting you should pull from github, the cpan mods directory your using is 2-3 years out of date (not sure if it matters though it's still v 2.033 in there!)

vesath commented on 2014-06-06 13:39

To make it clearer what happens in our PKGBUILD, recall Logitech ships two things for LMS:
- the source code for LMS itself and all the modules it uses;
- the same with modules compiled for selected versions of perl.

Now Arch updates perl as upstream releases new versions, but obviously Logitech does not. Therefore the binary modules upstream releases are mostly useless for us (we really want to be in line with Arch's perl package). So we need to compile the modules ourselves, and that's what the build() function does. Before doing that, in the prepare() function, we replace the Class-XSAccessor in the module tree with a newer version, because of some bug I forgot with that's triggered when the version from the tree is run with a recent perl.

From what I understand of your message, we should just do the same for Compress-Raw-Zlib.

vesath commented on 2014-06-06 13:34

Sure we could fetch a newer Compress-Raw-Zlib from somewhere else, like we already do for Class-XSAccessor, but again I am travelling this month with limited time available and no access to my squeezebox to test.

If you cannot adapt the PKGBUILD to do with Compress-Raw-Zlib what we already do with Class-XSAccessor, I can give that a go perhaps tomorrow or the day after and give you a package to test then.

NygelLyndley commented on 2014-06-06 13:28

vesath:

Problem is with 2.033 of Compress::Raw::Zlib and can be fixed by upgrading, on the face of it I think it's creating dodgy gzipped http content.

I switched out the libs to 2.060 and it now appears to be working fine.

Could you have a look at the discussion here : http://forums.slimdevices.com/showthread.php?101666-Perl-5-20-web-interface-issues-related-to-jsonrpc-js I'm having a chat with Michael, I'm not quite sure but he seems to be suggesting that pulling 2.033 from his repositories http://svn.slimdevices.com/repos/slim/7.8/trunk/vendor/CPAN/ isn't the best way to do it, it's confusing me a bit (not much experience with Arch builds) but you might be able to shed some light.



NygelLyndley commented on 2014-06-05 23:24

Ok off to bed now so going no further tongight.

But the problem is in Slim/Web/JSONRPC.pm around line 277

The problem is with the gzip encoding, presumably not encoding correctly? Or possibly further along the chain where the request is built and the building having some issue if the body's been gzip-ified.

Essentially a quick and dirty fix is to tell lms never to gzip encode and you're good to go.

Change :

if ( !$isDebug && Slim::Utils::Compress::hasZlib() && (my $ae = $httpResponse->request->header('Accept-Encoding')) ) {

to

if ( 0 and !$isDebug && Slim::Utils::Compress::hasZlib() && (my $ae = $httpResponse->request->header('Accept-Encoding')) ) {
or something if you want to get up and running quickly.

NygelLyndley commented on 2014-06-05 18:23

Yeah Renophaston I'm thinking this is more frontend js related.

Switching to classic theme it all seems to work, players populate etc..

i.e. http://192.168.1.1/Classic/

Difference being, in classic the players are populated by the backend and passthrough as template variables.

While in default it's done via js. Problem is debugging js isn't really my thing. =p

Currently mooching through /opt/logitechmediaserver/HTML/Default/html/Main.js which seems to be doing the bulk of the initiation work.

elb commented on 2014-06-05 17:36

Since upgrade to 7.8.0-2 the service does not start and I get this message from systemctl status logitechmediaserver :
juin 05 19:22:45 tangha slimserver.pl[194]: The following CPAN modules were found but cannot work with Logitech Media Server:
juin 05 19:22:45 tangha slimserver.pl[194]: Image::Scale:
juin 05 19:22:45 tangha slimserver.pl[194]: Can't load '/opt/logitechmediaserver/CPAN/auto/Image/Scale/Scale.so' for modul…line 68.
juin 05 19:22:45 tangha slimserver.pl[194]: at /opt/logitechmediaserver/CPAN/Image/Scale.pm line 13.
juin 05 19:22:45 tangha slimserver.pl[194]: Compilation failed in require at (eval 108) line 1.
juin 05 19:22:45 tangha slimserver.pl[194]: BEGIN failed--compilation aborted at (eval 108) line 1.
juin 05 19:22:45 tangha slimserver.pl[194]: To fix this problem you have several options:
juin 05 19:22:45 tangha slimserver.pl[194]: 1. Install the latest version of the module(s) using CPAN: sudo cpan Some::Module
juin 05 19:22:45 tangha slimserver.pl[194]: 2. Update the module's package using apt-get, yum, etc.
juin 05 19:22:45 tangha slimserver.pl[194]: 3. Run the .tar.gz version of Logitech Media Server which includes all require...dules.

Renophaston commented on 2014-06-05 17:34

So, I haven't solved the problem yet, but in the meantime: if I set the network.jsonrpc logging level to "Debug" in the LMS settings... the web interface instantly starts working. Yay? YMMV.

NygelLyndley commented on 2014-06-05 13:13

Well the issue appeared to be the interaction with jsonrpc.js, a POST would be issued which would fail, presumably this is used to populate menus and such.

Wasn't sure if that was the problem last night but today I have a working LMS (from a .deb on ubuntu) running and the jsonrpc.js doesn't error in the way it did when I was looking last night so I'm going to run under the assumption that jsonrpc.js is somehow related to the issue.

I presume the json backend interacts with the DB or possibly mysqueezebox.com, not sure so the error could be anywhere in the chain really.

I'll have another look tonight, was just hoping someone may have seen this already. It's just LMS looks a bit complex and I have no prior experience with its internals.

vesath commented on 2014-06-05 12:17

So it seems the GUI suffers moderately from perl-5.20. I'm not sure how much we can do about this. Personnally I have no time to investigate and work on a fix now. NygelLyndley, Twacmepghad, could you try to get somebody upstream (or anyone that knows enough perl) interested in fixing these issues?

In the meantime, for those who don't mind downgrading perl to 5.18, the old PKGBUILD and packages are available at: http://arch.vesath.org/all/

Feel free to share any suggestions for better temporary or permanent solution.

Twacmepghad commented on 2014-06-05 11:29

@vesath: THX for the fast response.

I can confirm the issues from NygelLyndley.

NygelLyndley commented on 2014-06-04 22:56

Cheers now compiles and runs fine.

I am having a bit of a problem with some of the option menus though, this is on a fresh install of Arch + a yaourt install of logitechmediaserver.

On install I'm prompted
1) enter my squeezebox username/password - this works ok
2) Using a tree browser select the location of my music - this fails no tree browser appears
3) Using a tree browser select the location of my music playlists - this fails no tree browser appears

The failure at (3) won't allow me to proceed further and access lms.

I worked round this by editing /opt/logitechmediaserver/prefs/server.prefs to se the music and playlists location and was then able to access lms.

However the player web interface is slightly broken, clicking the volume selector does not change volume + no players appear in the top right drop down list (the drop-down looks broken).

My first thoughts were some web widget libraries may be missing but I can see all my players on the same style drop-down widget on the settings page.

I can also use my duet remote and play music that way so I think it all works just a few minot broken bits.

Any ideas?

vesath commented on 2014-06-04 15:29

Being away from my squeezebox this month I cannot properly test, but with trivial changes to the PKGBUILD it still compiles fine. Let me know of any issue.

vesath commented on 2014-06-04 15:04

Thanks. I missed that one. I'll get to it.

Twacmepghad commented on 2014-06-04 14:45

The perl version 5.20 came in the repository. This conflicts, of cource, with the dependency perl<5.19 from this package, witch cause the usual problems for this case.

yoursolace commented on 2014-05-25 19:34

@xtof
The last step you are likely missing is giving the user privileges for the necessary directory
for example: # chown -R squeezeboxserver:squeezeboxserver /opt/logitechmediaserver
where the first squeezeboxserver is the user and the second is the group, you can set these yourself by editing logitechmediaserver.service

elb commented on 2014-05-19 09:01

While trying to build the package, I'm getting the following message :
-> Téléchargement de Class-XSAccessor-1.19.tar.gz...
(...)
Warning: Transient problem: HTTP error Will retry in 3 seconds. 3 retries
Warning: left.
(...)
curl: (22) The requested URL returned error: 504 Gateway Time-out

Trying the URL from the PKGBUILD source variable in my browser :
http://search.cpan.org/CPAN/authors/id/S/SM/SMUELLER/Class-XSAccessor-1.19.tar.gz
leads to the message :
503 Service Unavailable

No server is available to handle this request.

Searching www.cpan.org for Class-XSAccessor leads to :
504 Gateway Time-out

The server didn't respond in time.

Even tried searching anything on several CPAN mirrors, allways getting same message.

Is it a problem with CPAN or something else I'm missing ?

TwoNotes commented on 2014-04-25 16:20

My previous problem with svn have been resolved. It turns out svn has some unmarked dependencies on 'libgnome-keyring' and 'qt4'. If you install those packages, it works. Those packages are not normally brought in on headless server systems (where you are likely to want to install a media server). The downside is that 'qt4' brings in a couple hundred MB of graphics stuff that will be absolutely unused on my Tonido2...

Xtof commented on 2014-04-03 22:42

I'm trying to install LMS without any success on my computer (AMD Fusion E350 APU). Here is what I managed to do :
1. pacman -S perl #to install perl libs
2. download the package and unpack it
3. makepkg -s #in the newly created directory
Here, I see few error messages, such as unused variable names.... but nothing that prevents packaqe build

4. pacman -U logitechmediaserver-7.8.0-1-x86_64.pkg.tar.xz
5. systemctl start logitechmediaserver.service
6. systemctl enable logitechmediaserver.service #to let LMS start at boot.

Once computer is rebooted, LMS doesn't start and the http://[serverIP]:9000 adress is unreachable. The /opt/logitechmediaserver/Logs/slimserver.log file remains empty and I really can't understand why the service doesn't start while being enabled.
I'm an archlinux beginner not yet very familiar with this OS. Any help would be very appreciated.

vesath commented on 2014-03-30 08:09

Thanks for the news, fragfutter.

Although CPAN is now provided for perl-5.18, this excludes ARM architectures. Therefore not much has changed in our package: the build logic and patches are mostly the same as with 7.7.

Let me know of any rough edges.

fragfutter commented on 2014-03-28 16:39

There will be no more official releases from logitech (they basicly dumped squeezebox). It is now more or less a driven by one employee (michael herger) and the community.

http://forums.slimdevices.com/showthread.php?101237-Logitech-Media-Server-7-8-0-now-available


http://downloads.slimdevices.com/LogitechMediaServer_v7.8.0/

bz31 commented on 2014-03-15 17:34

I have a note in French on compiling LMS-git (in two packages). It is on my GoFlex Home (ARMv5).
http://bz31.tuxfamily.org/dokuwiki/doku.php?id=archlinux:mpd_goflex_home#installer_lms_logitech_media_server

vesath commented on 2014-02-02 21:04

It just means nobody has tested it on armv5. Please try it out and if you find that it works let me know what arch I should add to the array.

TwoNotes commented on 2014-02-02 19:30

I notice that the PKGBUILD specifies
arch=('i686' 'x86_64' 'armv6h' 'armv7h')
Does that mean it will not work on Armv5tel (TonidoPlug2)?
Perhaps due to slow floating point?

vesath commented on 2014-01-25 05:57

Stupid -O2 segfault; let's go with -Os for a change...

vesath commented on 2014-01-25 05:55

Stupid -O2 segfault...

vesath commented on 2014-01-25 01:35

I updated the PKGBUILD to use Class-XSAccessor-1.19.tar.gz but makepkg only gets so far as the error below. I might not have the time to look into this quite soon.

cc -c -I. -I.. -Isrc -Iinclude -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -DVERSION=\"0.93\" -DXS_VERSION=\"0.93\" -fPIC "-I/usr/lib/perl5/core_perl/CORE" -O2 -Wall -Wno-unused-value -Wno-format-security Scan.c
In file included from Scan.xs:26:0:
src/asf.c: In function ‘_parse_file_properties’:
src/asf.c:430:3: internal compiler error: Segmentation fault
my_hv_store( asf->info, "max_bitrate", newSViv(max_bitrate) );
^
cc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/archlinuxarm/PKGBUILDs/issues> for instructions.
Makefile:339: recipe for target 'Scan.o' failed
make: *** [Scan.o] Error 4
make failed, aborting

TwoNotes commented on 2014-01-25 01:35

There is a version 1.19 at the same location.

vesath commented on 2014-01-25 00:59

Looks like somebody was bad and removed a file from the Internet...
I'll hunt a new version of the Class-XSAccessor tarball but this might take a while as I am on a slow connection at the moment.
In the meantime feel free to use the armv7h package I built: http://arch.vesath.org/all/

gps1539 commented on 2014-01-24 20:34

Same 404 on the link under Sources "http://search.cpan.org/CPAN/authors/id/S/SM/SMUELLER/Class-XSAccessor-1.13.tar.gz"

gps1539 commented on 2014-01-24 20:32

Hi

Thanks for putting this together.

I'm trying to install on a armv7 device and hitting a 404 error partway throught the download phase.

.
.
A CPAN.upstream/libmediascan-0.1.tar.gz
A CPAN.upstream/expat-2.0.1.tar.gz
Checked out revision 34139.
-> Downloading Class-XSAccessor-1.13.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found
==> ERROR: Failure while downloading Class-XSAccessor-1.13.tar.gz
Aborting...
==> ERROR: Makepkg was unable to build logitechmediaserver.
==> Restart building logitechmediaserver ? [y/N]

jcharbar commented on 2013-12-26 22:57

vesath: I'm a fan of your work.

vesath commented on 2013-12-25 02:18

jcharbar: You could also ask me to add "armv6h" to the list of supported arches... Here, let me add it for you.

jcharbar commented on 2013-12-24 20:45

If you're getting the error:

-The following modules failed to load: EV JSON::XS Digest::SHA1 YAML::XS Sub::Name

It's most likely because those modules haven't been built and included in the package. This can occur if you run out of memory during a build - manifests it self as an internal compiler error (happened during the compilation of sqlite3.c in my case). The solution is to create a swap file and enable it when building. See: https://wiki.archlinux.org/index.php/swap. I was building on a RaspberryPi and I created a swap of 1GB and it was successful. It will probably work with a much smaller swap file.

The PKGBUILD is missing the 'armv6h' architecture so when your building for the RaspberryPi add it to the PKGBUILD or use 'makepkg -s -A'.

TwoNotes commented on 2013-12-08 23:19

A bit of googling shows several other people getting segfaults from svn,
so I will persue that before dragging out my old project.
It is nice to know LMS works on Arch ARM as well, as I have some
hardware that would be perfect for that.

vesath commented on 2013-12-08 22:07

I suggest you look into the svn segfault. That is an important issue which concerns much more than just building this package.

Regarding your build problem, please check whether your system libjpeg.so is actually detected. All I know is that my logitechmediaserver builds do not include any libjpeg.a; you can check them out at http://arch.vesath.org/all/ and even install the prebuilt packages if you wish.

My logitechmediaserver platform is a Tegra2 machine running an up-to-date Arch ARM (with perl-5.18) and it works flawlessly.

TwoNotes commented on 2013-12-08 19:34

When I build this on my desktop x86_64 Arch system, with Perl 5.18, it works fine. My Squeezebox players work with it, which is good, but that is using my desktop computer, which is not running most of the time, and is way overpowered for just streaming music. So I do not think there is a Perl version problem.

But over on my small x86 (32 bit) Arch system, on all the time, file server, etc, no desktop display, but also with Perl 5.18, I can't even get the makepkg to work. 'svn checkout' gets Segmentation faults. So I copy over the already downloaded sources from the desktop machine, remove all the 64bit compiled files and try there. Most of the build works building lots of CPAN modules. But then it gets to

make: No rule to make target ... libjpeg.a

Now, why is it even trying to build that? My system already has /usr/lib/libjpeg.so

I really do not want to restore this system back to the old Debian I had on there, which ran LMS fine. I started to just write a replacement from scratch in a better suited language, but the protocol is not particularly well documented.

TwoNotes commented on 2013-12-08 19:28

When I build this on my desktop x86_64 Arch system, with Perl 5.18, it works fine. My Squeezebox players work with it, which is good, but that is using my desktop computer, which is not running most of the time, and is way overpowered for just streaming music. So I do not think there is a Perl version problem.

But over on my small x86 (32 bit) Arch system, on all the time, file server, etc, no desktop display, but also with Perl 5.18, I can't even get the makepkg to work. 'svn checkout' gets Segmentation faults. So I copy over the already downloaded sources from the desktop machine, remove all the 64bit compiled files and try there. Most of the build works building lots of CPAN modules. But then it gets to
[code]make: No rule to make target ... libjpeg.a[/code]
Now, why is it even trying to build that? My system already has /usr/lib/libjpeg.so

TwoNotes commented on 2013-12-08 19:26

When I build this on my desktop x86_64 Arch system, with Perl 5.18, it works fine. My Squeezebox players work with it, which is good, but that is using my desktop computer, which is not running most of the time, and is way overpowered for just streaming music. So I do not think there is a Perl version problem.

But over on my small x86 (32 bit) Arch system, on all the time, file server, etc, no desktop display, but also with Perl 5.18, I can't even get the makepkg to work. 'svn checkout' gets Segmentation faults. So I copy over the already downloaded sources from the desktop machine, remove all the 64bit compiled files and try there. Most of the build works building lots of CPAN modules. But then it gets to the 'prepare()' function in the PKGBUILD file and it dies with:
[code]make: No rule to make target ... libjpeg.a. Now, why is it even trying to build that? My system already has /usr/lib/libjpeg.so.

marco.vermeulen commented on 2013-11-17 21:08

I'm seeing exactly the same behaviour on a fresh install. Any ideas how we can fix this?

djringjr commented on 2013-10-20 07:02

I have a problem. I cannot log in using google-chrome-beta via the local host address for the server, http://localhost:9000/. It sends me to here:
http://localhost:9000/settings/server/wizard.html and when I enter my valid squeezebox.com account username and password - I used it on the web site, it works perfectly, but in the localhost page it will not work.

Does this need permissions changed? I am way confused.

David

Anonymous comment on 2013-09-07 00:14

After upgrading from the previous version the service does not run and I get the following when running slimserver.pl from the command line:

The following modules failed to load: EV JSON::XS Digest::SHA1 YAML::XS Sub::Name


*******

NOTE:

If you're running some unsupported Linux/Unix platform, please use the buildme.sh
script located here:

https://github.com/Logitech/slimserver-vendor/tree/public/7.7/CPAN

If 7.7 is outdated by the time you read this, Replace "7.7" with the major version
You should never need to do this if you're on Windows or Mac OSX. If the installers
don't work for you, ask for help and/or report a bug.

*******

vesath commented on 2013-09-04 04:12

Updated with faulty line commented out and --logdir replacing --logfile in the service file. Enjoy.

theking2 commented on 2013-08-29 21:03

That was not correct.
Instead of --logfile=....
use --logdir=/opt/logitechmediaserver/Logs

theking2 commented on 2013-08-29 20:22

Please see http://bugs.slimdevices.com/show_bug.cgi?id=18048

The --logfile parameter should only contain the directory not the file.

Anonymous comment on 2013-08-27 16:20

Is there a possibility to get the previous version? I use yaourt to install/upgrade lms so I don't have an older package around.

strider2 commented on 2013-08-24 13:24

The workaround as described by theking2 works indeed.
@vesath : sorry for the "noise" ...

theking2 commented on 2013-08-24 12:21

ok
what DID work is just comment out the line completely. Not sure what other sorts of havoc this produces but it least it plays music. :-)

I will get in touch with the Michael about this.

theking2 commented on 2013-08-24 11:09

The code at Info.pm+779 reads
[code]$client ? $client->musicInfoTextCache($cache) : $musicInfoTextCache = $cache;[/code]
after changing this to
[code]if( $client ) {
$client->musicInfoTextCache($cache);
} else {
$musicInfoTextCache = $cache;
}[/code]
the problem was not reported but it still is impossible to add to the playlist and play.
It seems like a incompatibility with Perl 5.18. The LMS team is still on 5.8 .

(I wonder why they picked Perl in the first place. Such a messy language.)

theking2 commented on 2013-08-24 11:06

I suspect a Perl 5.18 incompatibility here. The guys at LMS are still at version 5.8 [CODE] $client ? $client->musicInfoTextCache($cache) : $musicInfoTextCache = $cache;[/CODE]
After changing this to [CODE]
if( $client ) {
$client->musicInfoTextCache($cache)

wilbert-vb commented on 2013-08-24 00:09

Is there still a backup of 7.7.2-10 for x86_64 available, please?

Gregoire commented on 2013-08-23 12:15

Sorry for my "same as", specially that I forgot to say I am under x86_64.
There is only gratitude from me regarding the great work done to have LMS under arch (I was on gentoo before and there were months without LMS which weren't a big problem for me).
So another time : thank for all !!!

vesath commented on 2013-08-22 21:35

Guys... Do you think every single user of this package should post "me too" every time an issue is brought up? Noise does not make me work faster - quite the contrary. So unless you have something to contribute (for instance, a patch or a bounty for me to fix this bug), your input is really not required.

strider2 commented on 2013-08-22 20:41

Same here ...

Gregoire commented on 2013-08-22 20:00

Same problem as wilbert-vb here.

wilbert-vb commented on 2013-08-22 19:40

The package builds and installs.
The service starts and runs.

It finds the player, but no sound:

===
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.7342] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.7369] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.8821] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.8836] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.8935] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.8949] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.9083] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:17.9098] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:22.5852] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:22.5867] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:22.9358] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:22.9376] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:27.9878] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:27.9895] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:32.6371] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:32.6385] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:32.6626] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:32.6641] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:32.7189] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:32.7203] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:33.0392] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:33.0410] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:35.5424] Slim::Utils::Timers::__ANON__ (273) Error: Timer Slim::Web::Cometd::sendResponse failed: illegal file descriptor or filehandle (either no attached file descriptor or illegal value): at /opt/logitechmediaserver/Slim/Networking/IO/Select.pm line 150.
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:38.1094] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:38.1112] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:43.1578] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:43.1596] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:48.1910] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:48.1928] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:48.2070] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Queries::statusQuery]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:17:48.2087] Slim::Web::JSONRPC::requestMethod (413) Request failed with error: Bad dispatch!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:20:29.6616] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Commands::playlistJumpCommand]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:21:08.1518] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Commands::playlistJumpCommand]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:26:09.6923] Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Commands::playlistJumpCommand]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ]
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:26:58.1440] Slim::Web::JSONRPC::requestMethod (443) request not dispatchable!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:26:58.1515] Slim::Web::JSONRPC::requestMethod (443) request not dispatchable!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:26:58.1625] Slim::Web::JSONRPC::requestMethod (443) request not dispatchable!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:27:03.2010] Slim::Web::JSONRPC::requestMethod (443) request not dispatchable!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:27:35.1433] Slim::Web::JSONRPC::requestMethod (443) request not dispatchable!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:27:35.2285] Slim::Web::JSONRPC::requestMethod (443) request not dispatchable!
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:27:56.3064] Slim::Utils::Timers::__ANON__ (273) Error: Timer Slim::Web::Cometd::sendResponse failed: illegal file descriptor or filehandle (either no attached file descriptor or illegal value): at /opt/logitechmediaserver/Slim/Networking/IO/Select.pm line 150.
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:28:39.3275] Slim::Utils::Misc::msg (1304) Warning: [14:28:39.3270] Use of each() on hash after insertion without resetting hash iterator results in undefined behavior, Perl interpreter: 0xacc010 at /opt/logitechmediaserver/Slim/Schema.pm line 2469.
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:28:39.6197] Slim::Utils::Misc::msg (1304) Warning: [14:28:39.6192] Use of each() on hash after insertion without resetting hash iterator results in undefined behavior, Perl interpreter: 0xacc010 at /opt/logitechmediaserver/Slim/Schema.pm line 2469.
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:28:39.8575] Slim::Utils::Misc::msg (1304) Warning: [14:28:39.8570] Use of each() on hash after insertion without resetting hash iterator results in undefined behavior, Perl interpreter: 0xacc010 at /opt/logitechmediaserver/Slim/Schema.pm line 2469.
Aug 22 14:28:41 md110 slimserver.pl[254]: [13-08-22 14:28:39.8685] Slim::Networking::IO::Select::__ANON__ (147) Error: Select task failed calling Slim::Networking::Async::_async_read: Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info.pm line 779.
Aug 22 14:28:41 md110 slimserver.pl[254]: ; fh=Slim::Networking::Async::Socket::HTTP=GLOB(0x804a648)
===

vesath commented on 2013-08-22 01:02

So I just did a straightforward 7.7.3 upgrade and it appears to work for me. Please report any issues - although I have little time to investigate them now, I will gladly take patches and/or hope to find time later...

BuddyLuvve commented on 2013-08-21 18:06

@ Gregoire -- I had the same problem... Downgraded perl from 5.18.1-1 to 5.18.0-1 -- I hope the new LMS v7.7.3 will work with the new perl package -- or maybe it's a bug in perl? I'm gonna do a bit more checking.

wilbert-vb commented on 2013-08-21 16:40

Looks like Logitech Media Server v7.7.3 is released.

Gregoire commented on 2013-08-20 19:48

Does this still work for you ?
I can't actually play anything on my boxes ;
"Slim::Control::Request::execute (1890) Error: While trying to run function coderef [Slim::Control::Commands::playlistJumpCommand]: [Can't modify non-lvalue subroutine call at /opt/logitechmediaserver/Slim/Music/Info."

Anonymous comment on 2013-08-10 02:19

Thank you @vesath. Build is in progress!

vesath commented on 2013-08-09 12:48

qnology: Upgrade pacman: recent releases support VCS URLs.

Anonymous comment on 2013-08-08 21:54

Hello,

I'm looking for some help building this on ARM (pogoplug). I'm getting the following error:

==> ERROR: There is no agent set up to handle svn+http URLs. Check /etc/makepkg.conf.
Aborting...

/etc/makepkg.conf has the following:
DLAGENTS=('ftp::/usr/bin/curl -fC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
'http::/usr/bin/curl -fLC - --retry 3 --retry-delay 3 -o %o %u'
'https::/usr/bin/curl -fLC - --retry 3 --retry-delay 3 -o %o %u'
'rsync::/usr/bin/rsync -z %u %o'
'scp::/usr/bin/scp -C %u %o')

Any help to resolve this is appreciated. Thanks

wilbert-vb commented on 2013-07-15 20:04

@dehein:

In PKGBUILD modify the line that reads:
"arch=('i686' 'x86_64' 'armv7h')" by adding 'arm':
"arch=('i686' 'x86_64' 'armv7h' 'arm')"

dehein commented on 2013-07-15 19:21

I just cant compile it on my raspberry pi. Any hints how to do it? Would be very much appreciated.

wilbert-vb commented on 2013-07-04 12:54

Vesath, It took about 3 hrs to finish building.
If I had known I would have setup an atd session overnight as opposed to running over ssh shell.

Thank you very much for maintaining this package.

bz31 commented on 2013-07-04 12:32

On ARM and if you want to use git sources to compile v7.8, I would suggest to split the PKGBUILD in two to avoid recompiling CPAN if there is no change. And that's what I did:
1) https://github.com/Logitech/slimserver-vendor/tree/public/7.8/CPAN
It seems to me that there is no frequent changes. About 2~3 hours to compile it on my GoFlex Home.
2) https://github.com/Logitech/slimserver that does not require compilation and just a few minutes to create the package.

vesath commented on 2013-07-04 08:49

wilbert-vb: Compilation is needed because the binaries shipped by upstream Logitech are built for older versions of perl than is currently in [extra]. On a personal note, I always build this package for armv7h on my TrimSlice which takes a few hours (packages at http://arch.vesath.org/armv7h/ ).

jasonwryan commented on 2013-07-04 01:25

@wilbert-vb Set up cross-compliling and build it on something with some decent computing power...
http://archlinuxarm.org/developers/distcc-cross-compiling

wilbert-vb commented on 2013-07-04 00:46

My PogoPlug ARM device is now building this package for hours and hours Gentoo style.

This is a PERL application, can someone explain to me the benefits of Gentoo style compilation sessions.

I like to express my anger and frustration over this, what is the best way to do that?

vesath commented on 2013-06-21 02:50

twhayes: Obviously, from the error message, your old build location had directories with permission problems. How exactly? I cannot just guess; only you can investigate that if you are interested...

Anonymous comment on 2013-06-21 02:20

vesath: I switched build directories and it worked fine. Thanks for the help. Why did the directory switch make a difference?

Anonymous comment on 2013-06-20 09:18

Yes. System is up-to-date. And the command that created it was 'makepkg -s'. Sorry for any confusion. Thought that was obvious.

vesath commented on 2013-06-20 02:49

twhayes: Could you be reusing an old build directory or something? Please try afresh in a new empty directory. There must be a reason why on your computer cp cannot create a regular file: disk full, user with weird permissions, etc.

Anonymous comment on 2013-06-20 01:08

Yes. System is up-to-date. And the command that created it was 'makepkg -s'. Sorry for any confusion. Thought that was obvious.

vesath commented on 2013-06-19 04:43

It would help if you told us what command produced that output. Simply running `makepkg` works for me. Also, just in case, ensure your system is up-to-date: `pacman -Syu`.

Anonymous comment on 2013-06-19 03:34

getting long list of errors like this. Any suggestions?
sent 10297362 bytes received 631 bytes 20595986.00 bytes/sec
total size is 10293075 speedup is 1.00
~/builds/logitechmediaserver/src/logitechmediaserver-7.7.2-33893
cp: cannot create regular file 'CPAN/Bundle/DBI.pm': Permission denied
cp: cannot create regular file 'CPAN/DBD/Gofer.pm': Permission denied
cp: cannot create regular file 'CPAN/DBD/Proxy.pm': Permission denied
cp: cannot create regular file 'CPAN/DBD/DBM.pm': Permission denied

vesath commented on 2013-06-16 13:19

nemster: Is this package out-of-date? No. Then don't flag it as such in a poor attempt to get people's attention. I'll have a look at your problem when I do.

nemster commented on 2013-06-16 13:06

Class-XSAccessor-1.13.tar.gz is not available from CPAN anymore (maybe just temporarly?)

theking2 commented on 2013-06-13 17:46

hi vesath.
two things
1. the installation packages including building CPAN works excellently fabulous.
2. but it is required to remove the included src/CPAN folder. otherwise the cp failes
3. the start message at the end is a initscript version. Arch stopped using init in favour of systemd. it might be helpfull to adapt that.

otherwise: brilliant work

vesath commented on 2013-05-27 18:33

jamesfcarter: Thanks for testing this; I wanted to improve the CPAN module rebuild but will upload the relaxed version requirements until I can find more time (or somebody else does).

jamesfcarter commented on 2013-05-27 16:04

For what it's worth, simply relaxing the perl requirement to:
depends=('perl>5.15' 'perl<5.19')

Got me a package that worked. YMMV.

vesath commented on 2013-05-27 13:46

wilbert-vb: This is probably not the best package to start with, given that it uses a variety of perl modules some of which must be recompiled...

wilbert-vb commented on 2013-05-27 13:04

What does it take to maintain this package, Vesath?

vesath commented on 2013-05-27 09:10

OxHaK: Indeed but I am currently travelling and have no time to work out the update to perl-5.18. Since I do not see this situation improving any time soon, I will gladly orphan this package and give it over to anyone willing to maintain it.

OxHaK commented on 2013-05-27 08:39

This package need an update, perl is updated today and we can't re-install LMS.
Because: perl<5.17

bz31 commented on 2013-05-21 06:10

The three warnings and a small error (overload arg '"' is invalid at /opt/logitechmediaserver/CPAN/DBIx/Class/Storage.pm line 26. ) are known and have been fixed in 7.8
https://github.com/Logitech/slimserver/commit/6e208240e0bf92f01325def2de411ec34dd842fb
(We can also make changes after installation.)

vesath commented on 2013-05-20 23:42

wilbert-vb: Right. I should indeed remove the post-install message and the rc.d script that come along. Initscripts have been removed in official Arch packages a while ago (hence the errors of the type "rc.conf, rc.d/functions not found"). I'll update this in the next version. Cheers.

wilbert-vb commented on 2013-05-20 22:22

When the installation finished, it shows a message to start the server with this init script and /etc/rc.d/logitechmediaserver exists and is executable.
Perhaps you find a way to modify this message after a succesful installation?

vesath commented on 2013-05-20 21:49

wilbert-vb: initscripts have been deprecated in favor of systemd, and rc.d scripts have been deprecated too in favor of service files. Please start LMS through the systemd service file; this should be seamless. Cheers.

wilbert-vb commented on 2013-05-20 21:04

Hello there, thank you very much for supporting LMS on Arch Linux!

I installed Arch + LMS today and I noticed the following errors in my console:

===
/etc/rc.d/logitechmediaserver: line 3: /etc/rc.conf: No such file or directory
/etc/rc.d/logitechmediaserver: line 4: /etc/rc.d/functions: No such file or directory
/etc/rc.d/logitechmediaserver: line 14: stat_busy: command not found
defined(@array) is deprecated at /opt/logitechmediaserver/CPAN/Class/Inspector.pm line 124.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /opt/logitechmediaserver/CPAN/Log/Log4perl/Config.pm line 840.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /opt/logitechmediaserver/Slim/Player/SB1SliMP3Sync.pm line 146.
(Maybe you should just omit the defined()?)
[13-05-20 08:52:58.5967] main::init (354) Starting Logitech Media Server (v7.7.2, r33893, Wed Mar 14 06:37:22 MDT 2012) perl 5.016003
/etc/rc.d/logitechmediaserver: line 16: add_daemon: command not found
/etc/rc.d/logitechmediaserver: line 16: stat_done: command not found
/etc/rc.d/logitechmediaserver: line 17: stat_fail: command not found
[root@md110 x86_64]# defined(@array) is deprecated at /opt/logitechmediaserver/CPAN/Log/Log4perl/Config.pm line 840.
(Maybe you should just omit the defined()?)
defined(@array) is deprecated at /opt/logitechmediaserver/CPAN/Class/Inspector.pm line 124.
(Maybe you should just omit the defined()?)
===

bz31 commented on 2013-05-12 16:50

PKGBUILD:
- It seems we don't need
cp -r ${svnurl}build/5.16/lib/perl5/*-linux-thread-multi/* CPAN/
The sames files are already in CPAN/.
- I suggest putting 'flac 'libmad' 'libvorbis' 'faad2' in depends=(...).

bz31 commented on 2013-05-12 11:47

It seems we don't need
cp -r ${svnurl}build/5.16/lib/perl5/*-linux-thread-multi/* CPAN/
The sames files are already in CPAN/.

vesath commented on 2013-04-27 14:12

Thanks for noticing this, bz31...

dojero commented on 2013-04-26 16:41

Confirming that bz31 fix works.

bz31 commented on 2013-04-25 13:36

There is a bug in the file "service".
User=logitechms and Group=logitechms should not be in section Unit. We can put them in the section Service, and we no longer need the option "--user logitechms".

dojero commented on 2013-04-23 17:22

For reasons I haven't been able to determine, the latest version of logitechmediaserver and a fully updated Arch system no longer permits the third party (Triode's) Spotify to work. It may be a permissions problem (access to the /opt/logitech directory by the plugin?); it may be a User/Group problem (though I've tried every combination for this); it may be a systemd problem. I will be trying to get to Triode on the Logitech forum to see if he has any suggestions, but my impression is that the plugin in working on other distros and so may not be a plugin problem. If I determine a solution, I'll certainly post back here.

Anonymous comment on 2013-03-26 19:32

hi vesath
could you also please make a PKGBUILD for the UE music library?

http://downloads.slimdevices.com/nightly/10.0/sc/111ef50/uemusiclibrary-10.0.2-1363855158.tgz

thanks

vesath commented on 2013-03-11 00:18

dojero: I now believe it makes sense to use User=logitechms,Group=logitechms in the service file instead of the --user option. However, there is simply no way I can prefill User=`your-username-here` in the service file. If this is the only way Spotify can run, well then, too bad for Spotify.

dojero commented on 2013-03-06 16:07

The workaround for the Spotify third party plugin being discussed is to add your user name to the service file and then to add your username to group logitechms. The Spotify third party plugin will then work, allowing Spotify to be run on legacy Squeezebox equipment (the Spotify plugin only works with newer equipment, such as the UE radio).

dojero commented on 2013-02-27 05:15

jcharbar: Can you be more specific about your workaround? I remove the --user option and add the User and Group options with logitechms, but still cannot get Help App to run. Are you saying that I should be using root for User? My user name? Thanks.

vesath commented on 2013-02-10 10:49

jcharbar: From what you are saying, it seems the Spotify plugin is at fault: it should not need its user/group to be enforced by a kernel cgroup (which is what systemd uses with User= and Group=) and should work out-of-the-box with logitechmediaserver's --user option. You should report this issue upstream and have it fixed there.

jcharbar commented on 2013-02-01 21:30

I installed Triode's Spotify Logitech media server plugin and it fails to work when LMS uses the "--user=" option. I had to switch systemd's "User=" and "Group=" to get it working. This could also be an issue for other LMS plugins.

vesath commented on 2013-01-27 23:10

This is not really required: instead of having systemd run logitechmediaserver as a specific user/group, we currently let the daemon drop root privileges itself (the --user= option).

An alternative could probably be to remove that option and rely on systemd's User= and Group=, but I have not tested it and am not sure what the advantages would be.

jcharbar commented on 2013-01-27 21:22

Looks like the logitechmediaserver.service file is missing User and Group i.e.

[Unit]
Description=Logitech Media Server Daemon
After=network.target

[Service]
User=logitechms
Group=logitechms
PIDFile=/var/run/lms.pid
WorkingDirectory=/opt/logitechmediaserver
ExecStart=/opt/logitechmediaserver/slimserver.pl \
--prefsdir /opt/logitechmediaserver/prefs \
--cachedir /opt/logitechmediaserver/cache \
--logfile /opt/logitechmediaserver/Logs/slimserver.log \
--user logitechms

[Install]
WantedBy=multi-user.target

vesath commented on 2012-11-18 07:23

Thanks Farfaday.

Anonymous comment on 2012-11-17 00:04

This package needs wget for installing.

vesath commented on 2012-11-11 22:01

nemster: This package provides /opt/logitechmediaserver/Bin/i386-linux/flac, and optionally depends on lib32-glibc and lib32-gcc-libs on x86_64. That should be plenty to get flac/aac/... playback to work.

Anonymous comment on 2012-11-07 15:23

So, after a lot of fiddling I could get the package to build again and I have music again! Since I didn't really have that much knowledge about what I did and to not to clutter things here I could open a forum thread if there is interest.

nemster commented on 2012-11-07 07:41

should add dependency to lib32-flac, otherwise flac/aac/... playback does not work

vesath commented on 2012-09-29 11:01

In the [multilib] repository.

theking2 commented on 2012-09-29 08:36

I saw the comments by mika.fischer and the responses by vesath cause I'm stuck at the same problem. None of the i386-linux bins are running on my 64-bit system. As I have a SBC in my network I need these for transcoding. Now I used to ln the 64 binaries in the Bin/i386-linux folder but as the slimdevices people messed with the faad the standard faad cannot be used.

where can I find the lib32-glibc libraries? there is no such package by this name.

vesath commented on 2012-08-21 22:51

ripperapid: You are supposed to have the base group installed at all times, and the base-devel group installed when you are building packages.

vesath commented on 2012-08-21 22:50

You are supposed to have the base group installed at all times, and the base-devel group installed when you are building packages.

Anonymous comment on 2012-08-21 22:44

Hello. I think 'patch' should be in the makedepends array. It took me a while to figure out why the build kept failing on my media server.

vesath commented on 2012-08-20 05:35

This looks like a fakeroot internal error which should not happen; something is probably amiss with your computer.
Next time you report errors, please copy-paste messages in *English*; you may run `LANG=C makepkg` for that purpose.

Anonymous comment on 2012-08-19 20:16

Compilation and all works fine for me but when packaging starts and fakeroot environment is used I get the following error:
"Unable to recognise the format of the input file `./opt/logitechmediaserver/Bin/i386-linux/wvunpack'
/usr/bin/fakeroot: Zeile 181: 19250 Benutzerdefiniertes Signal 1 FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@""

patrickh commented on 2012-07-27 12:55

Great! Has now been working for me for some hours without any problems! But, well, I didn't do too much weird stuff either… ;)

vesath commented on 2012-07-26 23:53

Hantilles: Could you try this package? http://arch.vesath.org/all/logitechmediaserver-7.7.2-5.src.tar.gz
The service file is derived from yours but simpler and cleaner. Thanks.

patrickh commented on 2012-07-26 19:02

Hi there!

Although I'm not very familiar with how to start daemons or how to write initscripts, I recently felt quite adventurously and decided to try out this new systemd thing, so many talk about. Only after this switch I realised i had no idea, how to start lms.

After some time of fiddling around with manually starting slimserver.pl with parameters found in conf.d/logitechmediaserver, I tried to write an service file for lms using information in this http://forums.slimdevices.com/showthread.php?91395-Fedora-service-control-fumbles-after-server-restart/page2 thread for Fedora as template and the stuff I found in the initscript and conf.d file for details. The result is the following, which might be interesting for anyone else who tries to run lms under systemd.

Maybe it could be integrated into the package if others, who have more knowledge about this init and daemon stuff approve?


So here is my /etc/systemd/system/lms.service file (second try. Multiple lines in ExecStart in my previous post seemed to work at first, but then showed problems). One might want to change name to logitechmediaserver.service to match initscript name? And install should, as far as I understand, happen in /usr/lib/systemd/system/ instead. I'm sure there's still room for improvement!

============================================
[Unit]
Description=Logitech Media Server Daemon
After=local-fs.target network.target remote-fs.target # remote-fs.target is added by me, as I have my collection on an nfs share

[Service]

ExecStart=/opt/logitechmediaserver/slimserver.pl --daemon --pidfile=/var/run/lms.pid --user=logitechms --prefsdir=/opt/logitechmediaserver/prefs --cachedir=/opt/logitechmediaserver/cache --logfile=/opt/logitechmediaserver/Logs/slimserver.log --charset=utf8

Type=simple

PIDFile=/var/run/lms.pid

RestartSec=5

Restart=on-failure


[Install]
WantedBy=multi-user.target
Alias=logitechmediaserver
============================================

patrickh commented on 2012-07-26 18:02

Hi there!

Although I'm not very familiar with how to start daemons or how to write initscripts, I recently felt quite adventurously and decided to try out this new systemd thing, so many talk about. Only after this switch I realised i had no idea, how to start lms.

After some time of fiddling around with manually starting slimserver.pl with parameters found in conf.d/logitechmediaserver, I tried to write an service file for lms using information in this http://forums.slimdevices.com/showthread.php?91395-Fedora-service-control-fumbles-after-server-restart/page2 thread for Fedora as template and the stuff I found in the initscript and conf.d file for details. The result is the following, which might be interesting for anyone else who tries to run lms under systemd.

Maybe it could be integrated into the package if others, who have more knowledge about this init and daemon stuff approve?


So here is my /etc/systemd/system/lms.service file. One might want to change name to logitechmediaserver.service to match initscript name? And install should, as far as I understand, happen in /usr/lib/systemd/system/ instead. I'm sure there's still room for improvement!

============================================
[Unit]
Description=Logitech Media Server Daemon
After=local-fs.target network.target remote-fs.target # remote-fs.target is added by me, as I have my collection on an nfs share

[Service]

ExecStart=/opt/logitechmediaserver/slimserver.pl --daemon \\
--pidfile=/var/run/lms.pid \\
--user=logitechms \\
--prefsdir=/opt/logitechmediaserver/prefs \\
--cachedir=/opt/logitechmediaserver/cache \\
--logfile=/opt/logitechmediaserver/Logs/slimserver.log \\
--charset=utf8

Type=simple

PIDFile=/var/run/lms.pid

RestartSec=5

Restart=on-failure


[Install]
WantedBy=multi-user.target
Alias=logitechmediaserver
============================================

patrickh commented on 2012-06-30 21:26

You guys are great! Works again with -r4 :D

Renophaston commented on 2012-06-30 16:21

Trying to understand Perl is a common error :) Everything works for me with the current revision. This might be an inappropriate place to say this, but thanks again for maintaining this PKGBUILD. I use LMS every day, and I couldn't even make it run on my own.

vesath commented on 2012-06-30 07:32

Your are both right, obviously. Next time I won't try to understand perl. :)

Renophaston commented on 2012-06-30 06:09

I think there's a problem with the way vesath implemented my fix, because if I change getParam in /Slim/Control/Request.pm back to the way I had it (http://forums.slimdevices.com/showthread.php?95408-perl-7-16&p=707226&viewfull=1#post707226), my library shows up again. Alternatively, just change the return line in the 7.7.2-3 version to "return ($r ne '') ? $r : undef;" Either works on my machine. (This seems related to the earlier problem; did Perl change its mind about whether empty strings are considered defined?)

patrickh commented on 2012-06-30 04:04

Hi! Unfortunately upgrade to 7.7.2-3 seems to break (re)scanning of my media library for me. At least after a rescan any click on Albums, music folder, etc. returned no sub-items. After a downgrade to 7.7.2-2 a rescan restored all I had in my library. I'm not entirely sure, that there couldn't have been any other reason, but so far the upgrade is the only think I remembered changing. Anyone observing similar problems?

Renophaston commented on 2012-06-26 22:29

I submitted a bug report here: http://bugs.slimdevices.com/show_bug.cgi?id=17984 in case anyone wants to vote or has something to add.

vesath commented on 2012-06-26 21:40

Renophaston: I've integrated your fix, since it doesn't seem to break anything I can notice. Cheers.

darkshines commented on 2012-06-26 18:58

@Renophaston: Thank you very much, the fix works for me too! Could you maybe create a patch and send it to the maintainer?

mika.fischer commented on 2012-06-26 18:25

I also suffered from the problem that at least the pause button in the web interface was not working anymore. And I can confirm that the solution suggested by Renophaston did indeed fix it. Thanks!

@Renophaston: Did you report this in the slimdevices bug tracker? http://bugs.slimdevices.com

darkshines commented on 2012-06-24 10:42

In the web interface, pause does not work and on my Squeezebox itself, next and previous do not work. This started very recently, like two to three updates ago.

Anonymous comment on 2012-06-21 11:10

This PKGBUILD really works fine for me - I've uninstalled previous LMS, upgraded PERL and then applied this PKGBUILD - works like a charm for me.

vesath commented on 2012-06-11 07:28

And as for getting somewhere, wouldn't you think that those "perl related errors in the log" are worth thousands of random, unsupported speculations?

vesath commented on 2012-06-11 07:24

I have no clue what you are talking about: the directory you mention is supposed to be created by buildme.sh, not to be found on the SVN server.
Please stick to reporting facts thoroughly, and avoid speculating.

Renophaston commented on 2012-06-10 00:46

I managed to get my LMS working again with a small "fix" I detailed here: http://forums.slimdevices.com/showthread.php?95408-perl-7-16&p=707226&viewfull=1#post707226. But I'm not claiming it's actually the right thing to do, only that it worked for me. I don't understand why it should be necessary, especially if you're not having the same problems. So proceed with caution! :)

vesath commented on 2012-06-06 23:33

No perl module is a currently a dependency, since they are all rebuilt against perl-5.16 from upstream sources and included in the package.
I have no idea what your problem is (since you didn't tell me), but you can always try `pacman -Syu` and then reboot.

IwfY commented on 2012-06-06 20:59

I found the following in slimserver.log:
[12-06-06 21:02:29.7407] YAML::XS::LoadFile (48) Warning: Usage: YAML::XS::LibYAML::Load(yaml_sv) at /opt/logitechmediaserver/CPAN/YAML/XS.pm line 48.

Could it be that perl-yaml is a dependency? (the package as it is doesn't work for me so I'm searching for possible solutions)

IwfY commented on 2012-06-06 19:33

I found the following in slimserver.log:
[12-06-06 21:02:29.7407] YAML::XS::LoadFile (48) Warning: Usage: YAML::XS::LibYAML::Load(yaml_sv) at /opt/logitechmediaserver/CPAN/YAML/XS.pm line 48.

Could it be that perl-yaml is a dependency? (the package as it is doesn't work for me so I'm searching for possible solutions)

vesath commented on 2012-06-06 00:03

Renophaston: Unfortunately I have no idea. When a new perl comes out, I focus on making sure all modules build properly, and then test on my squeezebox. Since everything seems to be working for me, I cannot investigate your problem. However, be sure to let me know if/when you find a solution to it, so I can package it. Good luck!

Renophaston commented on 2012-06-05 19:46

I posted at the slimdevices forum (http://forums.slimdevices.com/showthread.php?95408-perl-7-16&p=706884&viewfull=1#post706884), but just in case you have an idea of what's wrong, pause/play/previous/next are not working for me now in some contexts. More details are in the linked forum post. And thanks a ton, vesath, for maintaining this package!

electropura commented on 2012-06-05 15:30

Thank you for the new PKGBUILD! I haven't done any extensive testing, but the basics seems to work. I had some problems building at first since I had some stray perl 5.14-modules from CPAN left in /usr/lib/perl5/site_perl. If anyone uses CPAN, make sure you move the old modules out of the way first (or rebuild them).

patrickh commented on 2012-05-28 13:15

Thanks for the explanation! Wasn't aware that there need modules to be rebuilt. I'll try to be patient or have a look into it, if I find some time… :)

vesath commented on 2012-05-28 12:15

Problem is building the modules for /opt/logitechmediaserver/CPAN/arch/5.*/: either upstream does it for us (often after a new perl has been pushed to Arch) or we need to do it ourselves and fix what goes wrong ourselves too. That is what the build_cpan function of the PKGBUILD is for. You can try fiddling with it to build logitechmediaserver for perl>5.14 but it will be challenging if you are not into that kind of things...

patrickh commented on 2012-05-28 11:48

Is it really not compatible with perl >=5.15? Would it be much work to change it or is it necessary that Logitech provides a new version? Because this dependency breaks my sysupgrade right now…

vesath commented on 2012-04-09 09:46

theking2: So you removed the provided 32-bit binaries and replaced them by symlinks to system binaries? Didn't the provided 32-bit binaries work if you had lib32-glibc and lib32-gcc-libs installed?

theking2 commented on 2012-04-09 09:22

ehm, that is /opt/logitechmediaserver/Bin/i386-linux

theking2 commented on 2012-04-09 09:20

again great work vesath!. On my x86_64 I just had to ln the following to /opt/logitechmediaserver/Bin
lrwxrwxrwx 1 logitechms logitechms 13 Dec 30 12:37 faac -> /usr/bin/faac
lrwxrwxrwx 1 root root 13 Apr 9 11:16 faad -> /usr/bin/faad
lrwxrwxrwx 1 root root 13 Apr 9 11:17 flac -> /usr/bin/flac
lrwxrwxrwx 1 root root 12 Apr 9 11:18 mac -> /usr/bin/mac
-rwx------ 1 logitechms logitechms 432232 Apr 9 10:00 mppdec
lrwxrwxrwx 1 root root 12 Apr 9 11:18 sls -> /usr/bin/sls
lrwxrwxrwx 1 root root 12 Apr 9 11:17 sox -> /usr/bin/sox
lrwxrwxrwx 1 root root 17 Apr 9 11:18 wvunpack -> /usr/bin/wvunpack

vesath commented on 2012-03-29 17:03

I am away from home and my squeezebox, thus unable to test. Please report any issue and I'll do my best. Cheers.

jasonwryan commented on 2012-02-11 19:08

My apologies: I was not.
Thanks for the package vesath.

vesath commented on 2012-02-11 08:51

jasonwryan: Are you root?

jasonwryan commented on 2012-02-10 22:09

Package builds fine but fails on first run with this error:
rc.d start logitechmediaserver
:: Starting logitechmediaserver daemon [BUSY] Can't locate Slim/bootstrap.pm in @INC (@INC contains: /opt/logitechmediaserver /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl .) at ./slimserver.pl line 137.
BEGIN failed--compilation aborted at ./slimserver.pl line 137.

mika.fischer commented on 2012-01-09 10:32

I agree, optdepends seems appropriate.

vesath commented on 2012-01-09 10:09

Right, but those binaries are not strictly-speaking needed (only for transcoding and such) so lib32-glibc should be an optdepends.

mika.fischer commented on 2012-01-09 10:00

Can you execute any of the binaries in /opt/logitechmediaserver/Bin/i386-linux/ on the command line? If yes, then I bet you already have the lib32- packages installed (they're the most basic 32bit libraries). The binaries in the logitechmediaserver package are 32 bit ELF binaries and will definitely not work without 32 bit versions of the libraries they're linked against (except for mppdec, which is statically linked).

vesath commented on 2012-01-09 09:52

It works fine for me on x86_64 without any lib32-* thing.

mika.fischer commented on 2012-01-08 12:29

OK, installing lib32-glibc and lib32-gcc-libs fixed the problem. Maybe those packages should be added as dependencies on 64 bit linux.

mika.fischer commented on 2012-01-08 12:25

I still have the problem that the binaries in /opt/logitechmediaserver/Bin/i386-linux/ don't work for 64-bit linux. Any solution for this?

bongo commented on 2012-01-05 20:42

If you get some perl error, you may need to reboot after installation... sorry but as this is a server application, you cannot actually require someone to reboot the machine, it was not expectable.

bongo commented on 2012-01-05 17:07

Startup of the server doesn't work for me:
/etc/rc.d/logitechmediaserver start
:: Starting logitechmediaserver daemon [BUSY] Can't locate Slim/bootstrap.pm in @INC (@INC contains: /opt/logitechmediaserver /usr/lib/perl5/site_perl /usr/share/perl5/site_perl /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5/core_perl /usr/share/perl5/core_perl .) at ./slimserver.pl line 137.
BEGIN failed--compilation aborted at ./slimserver.pl line 137.

bongo commented on 2012-01-05 16:55

Please don't use that package anymore, use logitechmediaserver instead, which is the successor. The maintainer of this package has left; he's not reachable via email anymore.

theking2 commented on 2011-12-30 11:44

Upgrade 7.7.0-1 => 7.7.1-1 works flawless.
Again great work versath

Anonymous comment on 2011-11-29 20:43

I've recently moved from gentoo to arch, installed lms-7.7 and performance compared to gentoo running sbs-7.6.2 is really bad, did anyone experienced any lag during search via web browser, or laggy playback?

theking2 commented on 2011-11-26 14:46

I have to take that back.

It works like a breeze, until LMS needs to do a transcode (for my antiquated SBClassic). The binaries in /opt/logitechmediaserver/Bin/i386-linux/ do not work on a i64 arch. But I'm really wondering where the path to these binaries is decided. The convert.conf does mention a [bin] variable but does not use it.

theking2 commented on 2011-11-07 18:23

Works like a breeze.

Make sure, however, to manually remove /opt/squeezbox-server, and /etc/rc.d/squeezebox-server scripts.
Slimdevices/Logitech decided to rename the product once again :-)

vesath commented on 2011-11-06 23:12

I have been using logitechmediaserver for the past few days and have not had any problem with it.
Therefore I encourage everyone to switch: https://aur.archlinux.org/packages.php?ID=53691

In a few days, I will remove squeezebox-server (and its AUR votes will be transfered to logitechmediaserver).

vesath commented on 2011-11-03 06:56

Version 7.7 was just released... under the rebranded name of "Logitech Media Server". That's unfortunate since to be consistent with upstream we have to rename directories, create a logitechms user, etc.
So I uploaded a package called logitechmediaserver which appears to work so far; I haven't thoroughly tested it though. When I feel it is ready, I will make an announcement here; later, I will remove this squeezebox-server package and people should switch to that logitechmediaserver package.

Anonymous comment on 2011-09-28 13:05

Thank you for this package - It installed great on my system. I hope it
gets promoted to the main repository! :-)

Anonymous comment on 2011-09-16 14:39

The AUR worked fine for getting a working squeezeboxserver on my machine. But the third party Spotify plugin wouldn't work. After much messing about, I discovered a simple fix: create symlinks from /usr/lib and /usr/lib32 to libspotify.so

[code]
# ln -s /opt/squeezebox-server/cache/InstalledPlugins/Plugins/Spotify/Bin/i386-linux/lib64/libspotify.so.8 /usr/lib/libspotify.so.8
# ln -s /opt/squeezebox-server/cache/InstalledPlugins/Plugins/Spotify/Bin/i386-linux/libspotify.so.8 /usr/lib32/libspotify.so.8
[/code]

That's on a 64 bit install. On an x686, you'd only need the one link:

[code]
# ln -s /opt/squeezebox-server/cache/InstalledPlugins/Plugins/Spotify/Bin/i386-linux/libspotify.so.8 /usr/lib/libspotify.so.8
[/code]

Just posting this here in case it's useful to someone.

Cheers. And thanks, vesath, for the excellent AUR.

theking2 commented on 2011-09-04 12:50

Fair enough vesath. I understand your reluctance.

The problem is SqueezeboxServer refers to files in the '/opt/squeezebox-server/Bin/' explicitly. On my x86_64 installation the standard files ( included with the squeezeboxserver-7.6.1 ) will not run on x86_64. I get '/flac: No such file or directory
' errors when I attempt to run them. This might not be a problem on 386 installations.
Unfortunately the symptom of this problem is less conspicuous. Normally the SBS will play tracks in native mode and will just stream flac mp3 etc directly to the player. It will not touch any of these binaries. If it finds something the player cannot play (SB Touch cannot play 192kHz/24bit material) it has to rely on FLAC and SOX to transcode. If these can not be run the result is a deafening silence.
So yes you are right: only people playing exotic material, probably on x86_64 versions of Arch (haven't tested otherwise) will be impacted by this problem.

vesath commented on 2011-08-23 08:53

Updated. Thanks for the info, Pank, but in the future please feel free to use the "Flag Out-of-date" button instead of commenting. P.S. Scanning works again, yay!

Pank commented on 2011-08-23 07:44

Everything seems to work by just changing the version in the PKGBUILD.
--Rasmus

Pank commented on 2011-08-23 07:14

A new version of Squeezebox Server is available (7.6.1). Click here to download

Pank commented on 2011-08-23 07:14

A new version of Squeezebox Server is available (7.6.1). Click here to download

Pank commented on 2011-08-23 07:11

A new version of Squeezebox Server is available (7.6.1). Click here to download

Anonymous comment on 2011-08-15 19:53

Hi All,

As ptwl suggested I did build the package wth 7.6.1-33022.
This install correct only at start complains still about the locale.

Further is the strange thing is that I can't reach the website on <IP>:9000.
And I can't understand why...

Does anyone experience this problem ? and how to solve?

vesath commented on 2011-08-15 18:54

Thanks for the suggestion, theking2. For now, I am quite reluctant to disassemble squeezebox-server bit by bit and rely on system packages instead: although that would be a bit cleaner, it would make maintaining this package a nightmare; so I will leave the package as is for the time being unless more people experience issues similar to yours.

theking2 commented on 2011-08-14 11:17

On my x86_64 platform I had problems with the includes flac faad and sox binaries. So I suggest to remove these from the package, include the apropriate dependencies and symlink the binaries from /usr/bin
PKGBUILD:
12c12
< depends=('perl')
---
> depends=('perl' 'flac' 'faad2' 'sox' 'wavpack' 'mac')
26a28
> rm Bin/i386-linux/{flac,faad,wvunpack,sox,mac}
install:
3a4
> ln -s /usr/bin/flac /usr/bin/faad /usr/bin/sox /usr/bin/mac /usr/bin/wvunpack /opt/squeezebox-server/Bin/i386-linux

I could not find what the binaries mppdec and sls are.

theking2 commented on 2011-08-14 11:15

On my x86_64 platform I had problems with the includes flac faad and sox binaries. So I suggest to remove from the package and include the apropriate dependencies and symlink the binaries from /usr/bin
PKGBUILD:
12c12
< depends=('perl')
---
> depends=('perl' 'flac' 'faad2' 'sox' 'wavpack' 'mac')
26a28
> rm Bin/i386-linux/{flac,faad,wvunpack,sox,mac}
install:
3a4
> ln -s /usr/bin/flac /usr/bin/faad /usr/bin/sox /usr/bin/mac /usr/bin/wvunpack /opt/squeezebox-server/Bin/-linux

I could not find what the binaries mppdec and sls are.


setone commented on 2011-08-11 23:11

ptwl, I built a package the way you did. Scanning is much faster, as dasch noted. After my scan though, the admin page showed nothing from my music collection even though it reported scanning 381 albums. My clients showed nothing either, though I could search and play anything in the database. I had to stop the service, kill an instance of perl that my "squeezebox" user was holding on to, and then restart the service. Now the music shows up and everything is working well.

Anonymous comment on 2011-08-09 19:41

Thanks for the suggestion. I updated to 7.6.1 http://wiki.slimdevices.com/index.php/Nightly_Builds by modifying the PKGBUILD that is part of this package to point http://downloads.slimdevices.com/nightly/7.6/sc/33022/squeezeboxserver-7.6.1-33022.tgz and updated the SHA1SUM. Scanning works now and my images are back :)

Anonymous comment on 2011-08-08 23:41

Theme is Ok for me, too. But there are problems with Image::Scale. I get a segfault on every database rescan when it comes to artwork scanning.
I also had to uninstall 7.5. and remove the /opt/squeezebox-server folder and then install 7.6. to get a stable server. You may want to try this if reinstalling does not help.

Since there are Scanner bugs in the 7.6. release I installed 7.6.1. nightly some days ago. Scanner is really fast an reliable now (except for segfault on artwork scan), server is up for some days now. No segfaults, no errors in log.

vesath commented on 2011-08-08 23:41

It shouldn't matter to reinstall the package from scratch. I don't know what's wrong with artwork resizing on your machine. You can try rebuilding this package, or use the exact same one as me: http://arch.vesath.org/all/

Anonymous comment on 2011-08-08 23:31

I had the previous version installed and decided to do a fresh install so I uninstalled the previous version, deleted the /opt/squeezebox-server folder and reinstalled. Not sure if that helps

Anonymous comment on 2011-08-08 23:26

Got a bunch of these for all the .png's that are missing:
[11-08-08 15:56:33.5351] Slim::Web::Graphics::__ANON__ (326) Artwork resize for html/images/albums_25x25.png failed
[11-08-08 15:56:33.7009] Slim::Web::Graphics::__ANON__ (326) Artwork resize for html/images/artists_25x25.png failed
etc..

vesath commented on 2011-08-08 23:11

I can download this file just fine. The package contains /opt/squeezebox-server/HTML/EN/html/images/artists.png from which I assume the resized 25x25 picture is derived using Image::Scale (included in /opt/squeezebox-server/CPAN/auto/Image/Scale/). Have you checked the logs for warnings/errors?

Anonymous comment on 2011-08-08 22:56

Is anyone missing some .png files for the default theme?

Missing a lot of theme picture files so the default theme looks really bad. I checked the file system and the files are missing so it makes sense they are not able to load by the browser.

Anyone else having this problem?

ex: http://localhost:9000/html/images/artists_25x25.png <-- not found

vesath commented on 2011-08-07 21:05

aprins: Edit /opt/squeezebox-server/modules.conf and replace 0.88 by 0.9.
I believe this comes from an inconsistency upstream, and I will update this package to reflect that soon.

Anonymous comment on 2011-08-07 19:46

Vesath, thanks for your work on this ;-)

I have one problem when installing the package (pacman -U):

The following CPAN modules were found but cannot work with Squeezebox Server:
Audio::Scan (loaded 0.90, need 0.88)

To fix this problem you have several options:
1. Install the latest version of the module(s) using CPAN: sudo cpan Some::Module
2. Update the module's package using apt-get, yum, etc.
3. Run the .tar.gz version of Squeezebox Server which includes all required CPAN modules.

Any idea how to come around this problem?

vesath commented on 2011-07-31 00:54

So I partly fixed the scanner problem: you can now do `./scanner.pl --wipe --progress ~/music/` and it will work. Not sure why the GUI still doesn't do anything, though.

vesath commented on 2011-07-29 18:50

rubble: CPAN/XML/Simple.pm needs to be corrected similarly to fix the issue you reported.

vesath commented on 2011-07-29 18:42

Korthaerd: Maybe try replacing "arm-linux" by "i386-linux" in the PKGBUILD. But unless Arch Linux officially decides to support ARM, it seems wrong for archlinuxarm to put this burden on AUR maintainers.
rubble: Thanks for reporting but your patch doesn't solve the issue for me: line 447 of Expat.pm seems to have little to do with what you patch.

Korthaerd commented on 2011-07-29 17:10

Can you add support form arm architecture ?I t will be very useful for all the archlinuxarm's users.

I got that issue during the cleanup of the installation :
-> Strip des symboles inutiles dans les binaires et les bibliothèques...
/usr/bin/strip: Unable to recognise the format of the input file `./opt/squeezebox-server/Bin/i386-linux/faad'
==> ERREUR: Makepkg n'a pas pu construire squeezebox-server.

Anonymous comment on 2011-07-28 22:09

After upgrading to 7.6.0-3, I tried a "Clear library and rescan everything" only to end up with an empty library and the following error in /opt/squeezebox-server/Logs/slimserver.log ...
[11-07-28 08:09:19.1626] Slim::Utils::Misc::msg (1236) Warning: [08:09:19.1621] Use of tied on a handle without * is deprecated at /opt/squeezebox-server/CPAN/XML/Parser/Expat.pm line 447.

It looks as though the Perl 5.14 syntax has been tidied up since 5.12 (http://perl5.git.perl.org/perl.git/blob/HEAD:/pod/perldelta.pod lines 399/400). To fix the issue, I changed the following lines in /opt/squeezebox-server/CPAN/XML/Parser/Expat.pm

[old line 492] my $ret = $self->parse(*FILE);
[new line 492] my $ret = $self->parse(\*FILE);

[old line 675] $parser->parse(*FOO);
[new line 675] $parser->parse(\*FOO);

vesath commented on 2011-07-27 16:07

Thanks, apnar; I've updated the package accordingly.

Anonymous comment on 2011-07-27 11:00

Looks good vesath. I think you can drop the dependency on 'perl-dbd-mysql' and 'mysql' as it looks like they've switched to sqllite.

Also, the '--reject "mysql-*"' in my wget line saves a good bit of the download as mysql is the biggest thing in that dir and isn't used.

vesath commented on 2011-07-27 07:26

This update supports perl-5.14; in fact, you should upgrade perl to 5.14.1 before building it.
Enjoy and thanks apnar again.

Anonymous comment on 2011-07-27 03:25

I haven't tried this on a clean install or had much time to test it but the server starts up fine, so your millage may vary. I also had to install "nasm" via pacman for the compile to go through. I again left out the DBI database stuff so make sure you have "perl-dbi" installed. Other wise the instructions are pretty similar with a newly hacked up build script:

# grab all the perl modules
wget -r -nH --cut-dirs=5 --no-parent --reject "index.html*" --reject "mysql-*" http://svn.slimdevices.com/repos/slim/7.6/trunk/vendor/CPAN/
cd CPAN
# get new Sub-Name module as old one does not compile properly
wget http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Sub-Name-0.05.tar.gz

# grab hacked up module build script
wget http://botch.com/buildme-arch-perl-514-hack-76.sh

# build the modules
chmod +x buildme-arch-perl-514-hack-76.sh
./buildme-arch-perl-514-hack-76.sh

# copy compiled modules and new versions over
cp -r build/arch/5.14 /opt/squeezebox-server/CPAN/arch/
cp -f build/5.14/lib/perl5/x86_64-linux-thread-multi/Sub/Name.pm /opt/squeezebox-server/CPAN/Sub/

#tweak modules.conf for new versions
sed -i 's/Sub::Name 0.0./Sub::Name 0.05/' /opt/squeezebox-server/modules.conf

vesath commented on 2011-07-27 02:36

dasch: I'm working on making squeezebox-server-7.6.0 work with perl-5.14, following what apnar did; if I do not hit too many issues, this should be available as an upgrade to this package later today.

Anonymous comment on 2011-07-27 01:11

apnar, compiling the Perl Modules is a great thing. It would solve all the problems with perl package upgrades in future.
But could you upgrade this to
http://svn.slimdevices.com/repos/slim/7.6/tags/7.6.0/vendor/CPAN/

because there are some problems running SBS 7.6 with the modules from 7.5. EV is too old, image-scale is missing etc.
I had to install perl-json, perl-ev etc. from repositories but I can't solve the problem with missing image-scale module.
It's not even in the aur.
In the above link are all needed CPAN modules for SBS 7.6

I will try this for myself tomorrow.

vesath commented on 2011-07-26 18:17

Thanks a lot for this apnar! It seems great and I'll look into packaging it later today.

Anonymous comment on 2011-07-26 17:22

I managed to get things working on 5.14 by building my own modules. I just used the mysql perl modules from pacman, so make sure you have the perl-dbd-mysql package installed. The rest are built using a modified build script that is hacked together.

Here are the steps if anyone wants to do it:


# grab all the perl modules
wget -r -nH --cut-dirs=5 --no-parent --reject "index.html*" --reject "mysql-*" http://svn.slimdevices.com/repos/slim/7.5/trunk/vendor/CPAN/
cd CPAN
# get new Sub-Name module as old one does not compile properly
wget http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Sub-Name-0.05.tar.gz

# grab hacked up module build script
wget http://botch.com/buildme-arch-perl-514-hack.sh

# build the modules
chmod +x buildme-arch-perl-514-hack.sh
./buildme-arch-perl-514-hack.sh

# copy compiled modules and new versions over
cp -r build/arch/5.14 /opt/squeezebox-server/CPAN/arch/
cp -f build/5.14/lib/perl5/x86_64-linux-thread-multi/Audio/Scan.pm /opt/squeezebox-server/CPAN/Audio/
cp -f build/5.14/lib/perl5/x86_64-linux-thread-multi/Sub/Name.pm /opt/squeezebox-server/CPAN/Sub/

#tweak modules.conf for new versions
sed -i 's/Audio::Scan 0.8. 0.8./Audio::Scan 0.88 0.88/' /opt/squeezebox-server/modules.conf
sed -i 's/Sub::Name 0.0. 0.0./Sub::Name 0.05 0.05/' /opt/squeezebox-server/modules.conf

vesath commented on 2011-07-26 15:41

It still doesn't have a CPAN/arch/5.14 directory... I'll package it later today anyway.

Anonymous comment on 2011-07-26 15:27

7.6.0 released 25 Jul 2011. I haven't seen anything yet about working with perl 5.14 -- I might examine that today.

theking2 commented on 2011-07-17 07:36

oh, and apparently a 5.14 compile is on it's way (for some time now) http://www.networkedmediatank.com/showthread.php?tid=50167&pid=497931#pid497931

theking2 commented on 2011-07-17 07:34

With a downgraded perl on 5.12 I could install and run 7.5.5. Also tried the 7.6.0. works also (and thank God uses SQlite by default).

vesath commented on 2011-07-13 20:58

No it doesn't: this can only be fixed by upstream building their CPAN modules for perl-5.14, which has not happened yet.

setone commented on 2011-07-13 19:51

Thanks for doing that. Do we know if this resolves the Perl issue?

Pank commented on 2011-07-13 06:43

'A new version of Squeezebox Server is available (7.5.5)'

Seems rather dull:
http://wiki.slimdevices.com/index.php/Release_Notes#7.5.5_Release_Highlights

Pank commented on 2011-07-13 06:41

A new version of Squeezebox Server is available (7.5.5). Click <a href="http://www.mysqueezebox.com/download" target="update">here</a> to download.

Pank commented on 2011-07-11 23:47

Yeah, I know. It is a suboptimal solution -- especially given the whole Git-thing.

Looking further into it, it seems some people are working on getting Perl 5.14 working with Sq 7.6[1], /but/ the 'branch' seems to have stalled according to some messages on one of the development mailing lists, so we'd better stay with 7.5. For now I think holding Perl is the most feasible solution, unfortunately.

I have not been able to find an Squeezebox bug on Perl 5.14. It should probably be added, no?[2]

[1] http://www.networkedmediatank.com/showthread.php?tid=50167&pid=496930#pid496930
[2] on bugs.slimdevices.com (jeez, it is annoying that Fx does not use proper urls in the locationbar)

vesath commented on 2011-07-11 22:00

Alright, I added a versionned dependency. I hate having to withhold upgrades for perl in order for squeezebox-server to work, but it's the only practical solution I have for now. If anybody succeeds in recompiling the CPAN modules that it needs for perl-5.14, I'd be happy to upgrade the PKGBUILD accordingly.

Anonymous comment on 2011-07-11 21:46

"Should we (==vesath :) consider the 7.6 branch of Squeezebox?"

That will not solve the problem, because even todays 7.6 nightly build does not include CPAN libraries for perl 5.14.

"Or alternatively add a dep. version check, e.g. perl <= 5.12 ?"

Maybe thats a good thing for now, actually I'm blocking perl upgrade in pacman.conf. But we don't know when Logitech will upgrade their packages to perl 5.14. Maybe we are running in troubles when waiting too long with the perl upgrade. E.g. git needs perl 5.14 and is also blocked from upgrade here.

Pank commented on 2011-07-11 18:31

I apologize for the noise. It was solved by a Perl downgrade (which hopefully did not break anything else).

Should we (==vesath :) consider the 7.6 branch of Squeezebox? Or alternatively add a dep. version check, e.g. perl <= 5.12 ?

Cheers,
Rasmus (happily listening to his new CDs)

Pank commented on 2011-07-11 18:02

In other words, why are the modules failing to load?

The following modules failed to load: EV JSON::XS Digest::SHA1 YAML::Syck GD Sub::Name

I just reinstalled the package btw.

Pank commented on 2011-07-11 18:01

I get the following error when I try to start

-------------------------------------------------
ss4200:intel:[squeezebox-server] $ sudo /etc/rc.d/squeezebox-server start
:: Starting squeezebox-server daemon [BUSY] The following modules failed to load: EV JSON::XS Digest::SHA1 YAML::Syck GD Sub::Name


*******

NOTE:

If you're running some unsupported Linux/Unix platform, please use the buildme.sh
script located here:

http://svn.slimdevices.com/repos/slim/7.5/trunk/vendor/CPAN/

You should never need to do this if you're on Windows or Mac OSX. If the installers
don't work for you, ask for help and/or report a bug.

If 7.5 is outdated by the time you read this, Replace "7.5" with the major version
of Squeezebox Server you are running.

*******


Exiting..
-------------------------------------------------

I did not try to run the script. I did try to install perl-yaml but it did not help. I also have the impression that Squeezebox server is 'batteries included'.

Any clues on what might solve this issue?

--Rasmus

vesath commented on 2011-06-29 15:58

Upstream does not provide perl-5.14-compatible binaries in its tarballs yet.
It might be possible to hack around this issue, but I do not have much time these days.
If somebody finds a solution, I will be happy to implement it.

Anonymous comment on 2011-06-29 15:35

@bananabrain
edit /etc/rc.d/squeezebox-server

prog="LANG="de_DE.UTF-8"; cd $SQUEEZEBOX_HOME; ./slimserver.pl $SQUEEZEBOX_ARGS"

Look at the LANG= statement.

Anonymous comment on 2011-06-29 15:12

Downgrading perl to 5.12. solves the problem for now.
https://wiki.archlinux.org/index.php/Downgrade if you don't have perl 5.12. in your pacman cache.

Anonymous comment on 2011-06-29 13:58

After the perl update in core yesterday, squeezbox-server does not start. Is there a possibility to get the stable version work with perl 5.14 ?

bananabrain commented on 2011-04-07 15:18

Hi there.

The first time I started the daemon I got a message telling me my locale was detected as "C" and to change it to something appropriate. Does anyone know how it's detecting this, because it's certainly got it wrong. I couldn't find anything relevant at slimdevices.com.
Thanks.

Anonymous comment on 2011-01-17 21:55

For squeezeplay 7.5 there are precompiled binaries here: http://www.tux.org/~peterw/slim/squeezeplay/
They work quiet well on arch with the current server.

setone commented on 2011-01-12 19:28

FWIW - I tried squeezeplay myself, with not very good results. Downloaded binaries didn't seem to work at all - garbled screens, etc. I built the v7.5 and v7.6 clients and got further, but I had network problems with both... the linux support seems rickety at the moment.

What does work is an older java-based client called softsqueeze (go to softsqueeze.sourceforge.net and pick version 3.8). You need the JRE, and you're in business. Hope this helps.

Anonymous comment on 2011-01-09 10:09

thanks Buddy, I will try

setone commented on 2011-01-08 02:14

cszhy, you can try squeezeplay - it works fine on Windows, there is a linux tarball at http://downloads.slimdevices.com/nightly/7.6/sp/9278/squeezeplay-7.6.0-9278.tgz.

setone commented on 2011-01-08 01:49

cszhy, you can try squeezeplay - it works fine on Windows, there is a linux tarball at http://downloads.slimdevices.com/nightly/7.6/sp/9278/squeezeplay-7.6.0-9278.tgz.

Anonymous comment on 2011-01-07 12:13

Hi Guys:

I'm a fresh here, is there any squeeze client which can work with this squeeze server to play the radio on arch?

thanks

vesath commented on 2010-12-25 18:18

Since it seems perl-5.12 support didn't make it to squeezeboxserver-7.5.2, rather than using a 7.5.2-nightly let's switch to a 7.5.3-nightly!
As before, I host this nightly build on my server since it changes every day on slimdevices's website.
I have been running this new version for a day: no issues. Just be aware that your squeezebox might walk you through a firmware upgrade.

vesath commented on 2010-12-21 19:12

I cannot make the official version 7.5.2 work with perl-5.12, so I think we will stick to the same nightly tarball for a while...

vesath commented on 2010-12-21 14:05

I will try to update but there is no CPAN/arch/5.12 directory anymore, so I am afraid it is incompatible with perl-5.12.

vesath commented on 2010-12-21 13:56

Thanks Pank, I will update this package soon.

Pank commented on 2010-12-21 13:51

A new version of Squeezebox Server is available (7.5.2). I think this differs from the beta release used here.

vesath commented on 2010-10-30 14:13

Well, do you have a libspotify.so.4 on your system? Maybe it was recently upgraded to libspotify.so.5 or moved somewhere else and the squeezebox plugin needs to know that...

dahankzter commented on 2010-10-30 10:50

I just recently started getting:

[code]
/opt/squeezebox-server/cache/InstalledPlugins/Plugins/Spotify/Bin/i386-linux/spotifyd: error while loading shared libraries: libspotify.so.4: cannot open shared object file: No such file or directory
[/code]

The library is available but no luck using it.

Just thought maybe someone else is also using the Spotify plugin and maybe have the same issue.

vesath commented on 2010-09-01 06:31

If I were you, I would make sure that it is really perl segfaulting, and not another module/program; then, I'd clutter the squeezebox code with stuff like 'print "himom"; fflush()' or so to find which line makes perl crash exactly (I know, I'm from the last century).
But that's just generic advice; what I would try first would be to remove all of perl, reboot, and reinstall it (and check my RAM too). Good luck!

Anonymous comment on 2010-09-01 02:48

I'm confident I wouldn't reproduce it elsewhere. :) You're right. I bet there's something weird with the system, too.

The question is, how do I pinpoint it? I just tried to trace it, but it turns out I don't really know how. More effort will be made on this later. Not even sure where to begin on this one... I might try to uninstall a bunch of perl stuff and go forward from there. I'll need to fix this one way or another (on this machine). :)

And sorry if this issue is sort of off-topic. I've also posted it on the Squeezebox forums: http://forums.slimdevices.com/showthread.php?p=573325

vesath commented on 2010-08-31 20:44

Perl segfaulting is not your typical squeezebox-server bug... :) I would guess there is something non-standard about your system.
Could you maybe try installing this package (or a nightly build) on another computer and see if you can reproduce this problem?

Anonymous comment on 2010-08-31 19:28

Tried again with the latest nightly MANUALLY, not using this PKGBUILD. Not sure why, but this time, I actually saw the segfault. This was the second trial. The first one gave me all the messages about missing tables which obviously get created. I get the segfault right after I click "Finish" on the initial setup screens.

[mythtv@therver squeezeboxserver]$ ./slimserver.pl
[10-08-31 15:22:12.4755] main::init (323) Starting Squeezebox Server (v7.5.2, r31264, Mon Aug 30 03:03:47 MDT 2010) perl 5.012001
Segmentation fault
[mythtv@therver squeezeboxserver]$

Anonymous comment on 2010-08-31 11:54

Thanks for responding, vesath. Yes, I got the same result with 7.5.2-31264.

vesath commented on 2010-08-31 06:23

djthread: Have you tried running a newer nightly build? It could very well be an issue with this specific one.

Anonymous comment on 2010-08-31 01:48

My issue is a weird one...

The web interface starts up, I put in my mysqueezebox.com login, choose music and playlist folders, then once I click the "Finish" button, I get the messages about missing tables. Of course they're missing, squeezebox! But it seems they get created at this point anyway. Then slimserver.pl just exits and I get my prompt back.

Look to this post for more info: http://forums.logitech.com/t5/MySqueezebox-com-Squeezebox/Squeezebox-on-linux-crashes-without-message/m-p/482139

vesath commented on 2010-08-24 09:36

eworm: Right; it appears they update the tarball without changing commit numbers...
I've made a copy of the source tarball on my own server and used it in the PKGBUILD, so it won't change every day.
You don't have to trust me, only the sha1sum; those of you who don't are free to download their own daily copy from slimdevices.com and to input its sha1sum by hand in the PKGBUILD.
Of course, I'm open to better solutions - it's just that I couldn't think of any. :)

vesath commented on 2010-08-24 09:18

eworm: Right; it appears they update the tarball without changing commit numbers...
Well, you can either update the sha1sum or trust me and download the build I did yesterday (for i686): http://arch.vesath.org/squeezebox-server-7.5.2b31223-1-i686.pkg.tar.xz
I'll make a copy of the source tarball on my own server and use that in the PKGBUILD, so it won't change every day.

eworm commented on 2010-08-24 09:05

For me checksums of the tarball fail to validate:

==> Validating source files with sha1sums...
squeezeboxserver-7.5.2-31223.tgz ... FAILED
[...]
==> ERROR: One or more files did not pass the validity check!

vesath commented on 2010-08-23 22:28

No it doesn't; it's probably your browser caching files. :)

Anonymous comment on 2010-08-23 21:38

Cool. My SB3 is working again on Perl 5.12./X64. The tarball has still the former version of the PKGBUILD.

vesath commented on 2010-08-23 20:25

Updated to the nightly build (which appears to be quite stable, and runs fine with perl-5.12).
For the time being, I've let both perl-5.10 and 5.12 CPAN directories, to allow for a smooth upgrade.

vesath commented on 2010-08-23 14:15

That's great news, tfotherby!
I'll check it out later today and if it works for me too I'll release a new PKGBUILD.

Anonymous comment on 2010-08-23 13:44

For me, my Squeezebox-server wasn't working ever since the ArchLinux update to Perl 5.12. Today, I successfully got the squeezebox-server to run by editing the PKGBUILD file to use a nigthly build (http://downloads.slimdevices.com/nightly/7.5/sc/31223/squeezeboxserver-7.5.2-31223.tgz) - i.e the "inherited AUTOLOAD" problem seems fixed in nightly.

vesath commented on 2010-08-07 11:33

Well, the nightly build 7.5.2-31156 didn't work for me on i686; it raised more errors than I could fix.

With perl-5.12 running 7.5.1, the "inherited AUTOLOAD" problem can be fixed by workarounds, for instance: http://www.perlmonks.org/?node_id=328915
However, lots of modules still fail to load, and I'm not sure why exactly... :S

SoapSeller commented on 2010-08-06 02:30

I can confirm that nightly works well on perl-5.12.1@64bit.
(I've used 7.5.2-31156 and the current PKGBUILD)

vesath commented on 2010-08-02 20:03

Well, according to http://forums.slimdevices.com/showthread.php?p=563656 and the posts above, the Slim Devices guys are/were working on it.
Waiting for a clean fix, rather than downgrading perl, one might try a squeezebox-server nightly build...

vesath commented on 2010-08-02 19:58

Well, sjakub, perl-5.12.1 is now in core and I've been hit by the same problem you had - seems I was wrong considering this as a perl problem.
Unfortunately I won't have much time in the next few days to investigate, so any help is more than welcome.
Naturally, a fixed PKGBUILD will be updated as soon as we have a fix. :)

vesath commented on 2010-06-21 07:38

My mistake; this is now fixed.

sjakub commented on 2010-06-21 01:24

yaourt/makepkg says:
==> WARNING: Invalid backup entry : etc/conf.d/squeezebox-server.conf

vesath commented on 2010-05-29 16:55

That sounded like a permission problem, but if it only breaks with perl-5.12, I really don't know...
For the time being, I'd rather think this is a perl issue that you testing people will fix before it reaches core. ;)
If it isn't, then I'll look into writing a patch for slimserver when perl does hit core.

vesath commented on 2010-05-29 16:55

That sounded like a permission problem, but if it only breaks with perl-5.12, I really don't know...
For the time being, I'd rather think this is a perl issue that you testing people will fix before it reaches extra. ;)
If it isn't, then I'll look into writing a patch for slimserver when perl does hit core.

vesath commented on 2010-05-29 16:52

That sounded like a permission problem, but if it only breaks with perl-5.12, I really don't know...
For the time being, I'd rather think this is a perl issue that you testing people will fix before it reaches extra. ;)
If it isn't, then I'll look into writing a patch for slimserver when perl does hit extra.

vesath commented on 2010-05-29 16:47

Oh, right, those perl modules ship with squeezebox-server; I had forgotten that. :)
You most likely have a permission problem: the modules should be readable for squeezebox.
Could you check that? And if it doesn't work, could you try reinstalling this package completely?

sjakub commented on 2010-05-29 16:42

Ok, I know what is going on. It works fine with core/perl-5.10.1, but it fails when I upgrade to testing/perl-5.12.1 (I have [testing] repository enabled) :(
Any ideas?

sjakub commented on 2010-05-29 16:41

Ok, I know what is going on.
It work fine with core/perl-5.10.1, it fails when I upgrade to testing/perl-5.12.1 :( Any ideas?

sjakub commented on 2010-05-29 16:14

Actually I can see all those modules are included in /opt/squeezebox-server/CPAN - is there somethign that needs to be done to set it as the default path or something?

sjakub commented on 2010-05-29 16:13

$ sudo /etc/rc.d/squeezebox-server start
:: Starting squeezebox-server daemon [BUSY]
Use of inherited AUTOLOAD for non-method YAML::Syck::DumpYAML() is deprecated at /opt/squeezebox-server/CPAN/YAML/Syck.pm line 65.
The following modules failed to load: DBI DBD::mysql EV HTML::Parser JSON::XS Digest::SHA1 YAML::Syck GD Sub::Name

Anonymous comment on 2010-05-29 16:11

Everything works fine for me, but the server page (localhost:9000) sometimes takes 2-3 minutes to finish loading, which it didn't do on ubuntu before I switched my server to arch. I'm happy with the current build...

vesath commented on 2010-05-29 15:39

Well, I have none of these packages installed (except perlxml) and squeezebox-server works fine...
Could you explain why they should be required? Maybe they provide extra features and should then be optional.
As for the &>/dev/null, you're right; I'll remove it right away. :)

sjakub commented on 2010-05-29 15:22

Some missing dependencies (not all):
perl-json-xs perl-html-parser perl-dbd-mysql perlxml perl-digest-sha1 perl-gd perl-sub-name
Also, you should probably remove the &>/dev/null from rc.d file. If there is an error it really really should be displayed ;)

setone commented on 2010-04-22 02:53

Dropped it in... no problems of any kind, the easiest squeezebox-server install ever. Thanks.

AggroBoy commented on 2010-04-22 02:32

Weirdly, no I don't have mysqld installed otherwise. I just had a look, and it turns out that the shipped mysql and mppdec do run. Maybe they're statically linked in logitech's distribution to avoid dependancy problems?

I haven't had a look at any of the other built packages, but the full perl source tar only has 32bit binaries in it, so I doubt any of them are any better.

I did come up with a better solution than symlinks, which was to put a custom-convert.conf file in the squeezebox-server directory that bypasses the in-built search path (neatly ignoring the binaries they ship,) and just points to the standard /usr/bin location. Perhaps a fix would be to remove the logitech shipped tools, modify convert.conf or supply a custom-convert.conf and make optional (or hard) dependencies on the pacman versions of the tools? Honestly though, it's probably not worth it; I doubt it'll come up for anyone but me. The only way you'd see this is if you don't populate /lib32 *and* have a prehistoric squeezebox. :)

Aside from this one minor issue, everything works perfectly, by the way; great job. :)

vesath commented on 2010-04-21 23:50

That's very good to know, AggroBoy, thanks.
Just to be sure: you do have mysql installed system-wide, right? (I'd be confused if squeezebox-server worked otherwise, since the binary it ships with is in Bin/i386-linux too.)

Hum, all that cheap x86_64 support is a bit of a problem... It certainly works okay with distributions that populate /lib32, but not clean ones, like Arch. ;)
Well, I could also have missed something with the packaging - if you happen to install the RPM package and it works better than this one, please let me know.

AggroBoy commented on 2010-04-21 21:03

Just a quick note to point out that the binaries in bin/i386 are just that; 32-bin 386 binaries. They won't work on x86-64 installs without lib32 (compatibility) libraries. The binaries are used to transcode file types that aren't natively supported by your squeezebox. If you need to do that, you can install the 32bit libs or install x86-64 versions of the tools and replace the i386 binaries with symlinks to those. Hopefully this'll save someone else the two hours it just took me to figure out why my old Squeezebox2 wouldn't play flacs, but my Squeezebox3 will. :)

Anonymous comment on 2010-04-13 20:42

Working just fine, well done. I would suggest removing any previous installation first.

vesath commented on 2010-04-11 19:56

Pank: My hack above is not the prettiest either. :)
Anyhow, it wouldn't hurt to bug-report; since you experienced that issue, would you mind doing it? (This package is based on the "Perl Source Code (tar.gz)" version.)
See: http://bugs.slimdevices.com/

Pank commented on 2010-04-11 18:16

'official' as in the way the .deb package from Logitech does it.

Pank commented on 2010-04-11 18:15

hi vesath,
Sorry for the delayed report; I had to setup emacs-nox on my NAS. Finding line x in Nano is too much of hassle (to me at least).

Your hack works great! So a bit of patching would definitely work, but maybe we ought to push it upstream if this solution is more elegant than the official way of doing it.

vesath commented on 2010-04-11 18:00

Pank, the reason it works with the Debian package is their init.d script calls a wrapper (rather than slimserver.pl itself) that basically does "while true; do ./slimserver.pm; done", so even though slimserver.pl indeed crashes, it is restarted by that wrapper script.
I'm sorry but this is the kind of ugly mechanism I don't want in our AUR packages; however, if the "return;" trick worked for you (see my last comment), I would be happy to incorporate it in the PKGBUILD.

vesath commented on 2010-04-11 17:48

Thanks for testing, Pank. I still haven't figured out how the Debian package handles that, but I have a quick fix for you: on line 870 of /opt/squeezebox-server/slimserver.pl replace 'die "Aborting";' by 'return;' - that should do the trick.

Pank commented on 2010-04-11 17:12

Hi, I did a clean install to make sure that all changes were present. However, there still seems to be a permission problem:
http://aur.pastebina.com/Jqv2VenT

The preferences were kept during upgrade by the way. I just removed everything to be certain that the test was performed correct.

Pank commented on 2010-04-11 16:44

Sorry, I might have been unspecific. When you install/remove/update a plugin the Squeezebox server has to restart. It should be able to take care of it itself, but for some reason it only stops the server. It does not start it again. It is definitely possible to do make this work since the Logitech version (e.g. the .deb) of Squeezebox is able to restart the server properly.

You can reproduce it by installing/removing/updating any plugin from the Plugins menu under settings.

From the log it seems as if it a permission problem: http://aur.pastebin.com/fQ8cYEnn

vesath commented on 2010-04-11 13:41

I've uploaded a new package; some directories have been moved, but your preferences should remember and keep using the old ones.
If you're having problems upgrading or don't care about your preferences, do "pacman -Rn squeezebox-server; rm -fr /{opt,var/cache}/squeezebox-server" (beware that erases your preferences) before reinstalling squeezebox-server.

Pank: Could you try installing that new version and see if the plugin-reboot works okay? (Please show me your /opt/squeezebox-server/Logs/ files if it doesn't.) Thanks.

vesath commented on 2010-04-11 11:58

theking2: my mistake; a quick workaround is "chown -R squeezebox:squeezebox /opt/squeezebox-server" but I'm working on a cleaner way of fixing this.

Pank: squeezebox-server drops root privileges at startup, so, when it tries to restart itself, it doesn't have enough privileges to write a PID file and... drop its privileges again;
I'm not sure how the Debian packages handles that, but I'll look into it. In the meantime, as a temporary workaround, if you really need the restart feature, you can try editing /etc/conf.d/squeezebox-server and replacing "--user squeezebox" by "--user root".

Pank commented on 2010-04-11 11:20

Sorry, I might have been unspecific. When you install/remove/update a plugin the Squeezebox server has to restart. It should be able to take care of it itself, but for some reason it only stops the server. It does not start it again. It is definitely possible to do make this work since the Logitech version (e.g. the .deb) of Squeezebox is able to restart the server properly.

You can reproduce it by installing/removing/updating any plugin from the Plugins menu under settings.

From the log it seems as if it a permission problem: http://aur.pastebin.com/fQ8cYEnn

theking2 commented on 2010-04-11 11:13

Thanks vesath, for the update.

After upgrade the SBS does not start, log in http://aur.pastebin.com/UAGembZu

vesath commented on 2010-04-11 10:34

I'm sorry: what works using the Debian version of what?
I've uploaded a new package (no version bump, the only change is a longer sleep time in rc.d restart); could you try rebuild+reinstall squeezebox-server and see if works any better?
If not, please send me your /var/log/squeezebox-server.log and I'll see if I can find the cause of the problem.

Pank commented on 2010-04-11 10:29

I have no idea on how it works. The log does not seem to add anything useful. I know it works using the Debian version.

I don't see how I can change timeout in the daemon-file.

Pank commented on 2010-04-11 10:14

I have no idea on how it works. The log does not seem to add anything useful. I know it works using the Debian version.

I don't see how I can change timeout in the daemon-file.

vesath commented on 2010-04-11 10:08

I've never used that feature. If it relies on the rc.d script, could you try increasing the sleep time between stop and start in the restart case? Otherwise, maybe having a look at your log file will help.

Pank commented on 2010-04-11 09:56

Am I the only one for whom 'internal' restart does not work? I.e. when the server prompts me to restart after updating/installing plugins I have to start the server manually afterwards.

vesath commented on 2010-04-08 20:58

Updated (thanks for the notification).

WARNING: after upgrading, you might need to reboot your computer for slimserver to work;
this has something to do with Perl linking some folders at startup (that's magic to me).

Feedback is welcome.

Pank commented on 2010-04-08 16:41

"A new version of Squeezebox Server is available (7.5.0)."
http://www.mysqueezebox.com/download