Package Details: logitechmediaserver 8.5.2-1

Git Clone URL: https://aur.archlinux.org/logitechmediaserver.git (read-only, click to copy)
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/LMS-Community/slimserver
Keywords: logitech slimserver squeezebox
Licenses: GPL, custom
Submitter: vesath
Maintainer: stef.an (FabioLolix)
Last Packager: stef.an
Votes: 72
Popularity: 0.000088
First Submitted: 2011-11-03 06:54 (UTC)
Last Updated: 2024-07-01 19:06 (UTC)

Dependencies (10)

Required by (0)

Sources (3)

Pinned Comments

FabioLolix commented on 2024-05-26 08:40 (UTC)

-bin variant uploaded https://aur.archlinux.org/packages/logitechmediaserver-bin

Latest Comments

« First ‹ Previous 1 .. 16 17 18 19 20 21 22 23 24 25 26 .. 50 Next › Last »

NygelLyndley commented on 2014-06-06 15:53 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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.