BrutefirDRC appears to be installed correctly, but has no effect on audio

461 views
Skip to first unread message

tic toc

unread,
May 19, 2013, 4:33:24 AM5/19/13
to brute...@googlegroups.com
I am running LMS 7.8 on an x86-based Netgear ReadyNAS (running debian etch).  My player is a Squeezebox 3.  My music library is nearly all FLAC, with a few MP3s.  I have installed brutefir via apt-get; it is in my path, so "brutefir" works and creates .brutefir_config and .brutefir_defaults files in my home directory.
 
I believe that I have installed the BrutefirDRC plugin properly -- it shows up in the LMS web GUI as an installed plugin, and I see messages from BrutefirDRC in the server.log file -- but it is not affecting the audio output from my Squeezebox.
 
I am testing it with the sample filter from http://wiki.slimdevices.com/index.php/Brutefir_Filter . I can see references to that filter in the server log, e.g.:
Plugins::BrutefirDrc::Plugin::linkFilter (396) Changed filter for client 00:04:20:06:b2:c2 to: /etc/squeezeboxserver/BrutefirDrc/filters/nastyfilter.txt
But as I said, the audio is not affected.
 
I suspect that I have simply missed a small configuration step.  Any ideas, please?
 

Olav Sunde

unread,
May 19, 2013, 5:11:07 AM5/19/13
to brute...@googlegroups.com
I,ve been running BrutefirDRC with LMS 7.8 on a RN Ultra 2+ for some time. Here is a list of files and paths that work on my box:

**********************************************************************************************
BrutefirDrc list of files and folders. Location of the Plugins directory may vary with the Linux distro you use.

/var/lib/squeezeboxserver/Plugins/BrutefirDrc/Bin/brutefirwrapper

/var/lib/squeezeboxserver/Plugins/BrutefirDrc/HTML/EN/plugins/BrutefirDrc/settings/basic.html

/var/lib/squeezeboxserver/Plugins/BrutefirDrc/install.xml
/var/lib/squeezeboxserver/Plugins/BrutefirDrc/Plugin.pm
/var/lib/squeezeboxserver/Plugins/BrutefirDrc/Settings.pm
/var/lib/squeezeboxserver/Plugins/BrutefirDrc/strings.txt
/var/lib/squeezeboxserver/Plugins/BrutefirDrc/template-flac.conf
/var/lib/squeezeboxserver/Plugins/BrutefirDrc/template-mp3.conf
/var/lib/squeezeboxserver/Plugins/BrutefirDrc/template-pcm.conf

-------------------------------------------------------------------------------
for LMS v7.8 (beta) on a ReadyNas (x86) use following path for the above files:
/c/.squeezeboxserver/Plugins/BrutefirDrc

then:
cd /c/.squeezeboxserver/cache/InstalledPlugins/Plugins

and make this  softlink:
ln -s BrutefirDrc /c/.squeezeboxserver/Plugins/BrutefirDrc
-------------------------------------------------------------------------------

/etc/squeezeboxserver/BrutefirDrc/settings/

/etc/squeezeboxserver/BrutefirDrc/filters/null-65k48-l.pcm
/etc/squeezeboxserver/BrutefirDrc/filters/null-65k48-r.pcm
/etc/squeezeboxserver/BrutefirDrc/filters/sample_eq.txt
/etc/squeezeboxserver/BrutefirDrc/filters/sample_filter_and_eq.txt
/etc/squeezeboxserver/BrutefirDrc/filters/sample_filter_no_eq.txt
*********************************************************************************************

Check ownership of folders and files during installation. Usually this would be user "squeezeboxserver", but note that on a Readynas this is different as LMS is run by root.

In addition python v2.4 or higher and brutefir v1.0k must be present on the system and working.

brutefirwrapper writes to 'brutefir.log' Check this for relevant output.


Olav

tic toc

unread,
May 19, 2013, 7:45:33 AM5/19/13
to brute...@googlegroups.com

On Sunday, May 19, 2013 2:11:07 AM UTC-7, Olav Sunde wrote:
I,ve been running BrutefirDRC with LMS 7.8 on a RN Ultra 2+ for some time. Here is a list of files and paths that work on my box
 
Thank you so much, Olav.  That is exactly the information I wanted.
 
I am away from my system now, but I will compare my setup to yours tomorrow morning.  Wish me luck...
 

tic toc

unread,
May 20, 2013, 9:42:34 PM5/20/13
to brute...@googlegroups.com
Hi, Olav.  Thanks again for your help so far.  I hope you have time to offer more advice.

I've found a lot of BrutefirDRC information on the web, but it's all for old versions running on desktop PCs.  As soon as I get this working, I'm going to write up a set of step-by-step instructions for version 4.0 on the ReadyNAS.

On Sunday, May 19, 2013 2:11:07 AM UTC-7, Olav Sunde wrote:
for LMS v7.8 (beta) on a ReadyNas (x86) use following path for the above files:
/c/.squeezeboxserver/Plugins/BrutefirDrc

The BrutefirDRC package (Bin and HTML directories, the install.xml file, and all the other files) is there.
  
cd /c/.squeezeboxserver/cache/InstalledPlugins/Plugins

and make this  softlink:
ln -s BrutefirDrc /c/.squeezeboxserver/Plugins/BrutefirDrc

I think that's a typo; did you mean "ln -s /c/.squeezeboxserver/Plugins/BrutefirDrc BrutefirDrc "?  In other words, make a softlink in the /c/.squeezeboxserver/cache/InstalledPlugins/Plugins directory that points to the actual location of the BrutefirDRC directory, /c/.squeezeboxserver/Plugins/BrutefirDrc . Correct?

/etc/squeezeboxserver/BrutefirDrc/settings/
/etc/squeezeboxserver/BrutefirDrc/filters/null-65k48-l.pcm
/etc/squeezeboxserver/BrutefirDrc/filters/null-65k48-r.pcm
/etc/squeezeboxserver/BrutefirDrc/filters/sample_eq.txt
/etc/squeezeboxserver/BrutefirDrc/filters/sample_filter_and_eq.txt
/etc/squeezeboxserver/BrutefirDrc/filters/sample_filter_no_eq.txt

My settings and filters directories are there, and the BrutefirDRC web GUI settings specify those directories.  My filters directory contains only one filter -- the "delay the right channel" sample filter from the old instructions on the slimdevices wiki -- but BrutefirDRC is able to find it: When I enable the filter, BrutefirDRC creates a softlink in the settings directory that points to that filter in the filters directory.
 
Check ownership of folders and files during installation. Usually this would be user "squeezeboxserver", but note that on a Readynas this is different as LMS is run by root.

Ownership is set to 201:201 wherever other plugin files have that ownership, and it's set to root:root where other plugin files have THAT ownership.  The BrutefirDRC files in /c/.squeezeboxserver/Plugins/BrutefirDrc are set to 201:201.

In addition python v2.4 or higher and brutefir v1.0k must be present on the system and working.

Hmm... I have Python 2.4 (although I'm thinking about upgrading to 2.7.3 -- will that break LMS 7.8.0?), but my version of brutefir is 1.0f, not 1.0k.  Version 1.0f is the latest one available from the debian etch repository; version 1.0k is available from the debian squeeze repo, but it has dependencies (new libc, etc.) that can't be safely installed on the ReadyNAS.

If 1.0f won't work, where can I get a version of 1.0k that will run on the ReadyNAS's etch release?

brutefirwrapper writes to 'brutefir.log' Check this for relevant output.

That logfile isn't present on my system.  Maybe that's a clue that brutefir isn't working properly.  Where should the logfile be?  /var/log?


Olav Sunde

unread,
May 21, 2013, 3:50:40 AM5/21/13
to brute...@googlegroups.com


On Tuesday, 21 May 2013 03:42:34 UTC+2, tic toc wrote:
Hi, Olav.  Thanks again for your help so far.  I hope you have time to offer more advice.

I've found a lot of BrutefirDRC information on the web, but it's all for old versions running on desktop PCs.  As soon as I get this working, I'm going to write up a set of step-by-step instructions for version 4.0 on the ReadyNAS.

On Sunday, May 19, 2013 2:11:07 AM UTC-7, Olav Sunde wrote:
for LMS v7.8 (beta) on a ReadyNas (x86) use following path for the above files:
/c/.squeezeboxserver/Plugins/BrutefirDrc

The BrutefirDRC package (Bin and HTML directories, the install.xml file, and all the other files) is there.
  
cd /c/.squeezeboxserver/cache/InstalledPlugins/Plugins

and make this  softlink:
ln -s BrutefirDrc /c/.squeezeboxserver/Plugins/BrutefirDrc

I think that's a typo; did you mean "ln -s /c/.squeezeboxserver/Plugins/BrutefirDrc BrutefirDrc "?  In other words, make a softlink in the /c/.squeezeboxserver/cache/InstalledPlugins/Plugins directory that points to the actual location of the BrutefirDRC directory, /c/.squeezeboxserver/Plugins/BrutefirDrc . Correct?
 
Yes that's a typo, sorry

/etc/squeezeboxserver/BrutefirDrc/settings/
/etc/squeezeboxserver/BrutefirDrc/filters/null-65k48-l.pcm
/etc/squeezeboxserver/BrutefirDrc/filters/null-65k48-r.pcm
/etc/squeezeboxserver/BrutefirDrc/filters/sample_eq.txt
/etc/squeezeboxserver/BrutefirDrc/filters/sample_filter_and_eq.txt
/etc/squeezeboxserver/BrutefirDrc/filters/sample_filter_no_eq.txt

My settings and filters directories are there, and the BrutefirDRC web GUI settings specify those directories.  My filters directory contains only one filter -- the "delay the right channel" sample filter from the old instructions on the slimdevices wiki -- but BrutefirDRC is able to find it: When I enable the filter, BrutefirDRC creates a softlink in the settings directory that points to that filter in the filters directory.

I suggest you pick up the filter_examples files from  sourceforge for testing to avoid possible errors

 
Check ownership of folders and files during installation. Usually this would be user "squeezeboxserver", but note that on a Readynas this is different as LMS is run by root.

Ownership is set to 201:201 wherever other plugin files have that ownership, and it's set to root:root where other plugin files have THAT ownership.  The BrutefirDRC files in /c/.squeezeboxserver/Plugins/BrutefirDrc are set to 201:201.

If I remember correctly I had to do chown & chgrp -R on all folders related to BrutefirDRC to make it work.


In addition python v2.4 or higher and brutefir v1.0k must be present on the system and working.

Hmm... I have Python 2.4 (although I'm thinking about upgrading to 2.7.3 -- will that break LMS 7.8.0?), but my version of brutefir is 1.0f, not 1.0k.  Version 1.0f is the latest one available from the debian etch repository; version 1.0k is available from the debian squeeze repo, but it has dependencies (new libc, etc.) that can't be safely installed on the ReadyNAS.
 
You definately need 1.0k. I found the correct version on debian (brutefir_1.0k-2_i386.deb, probably squeeze) . I then downloaded and installed libasound2 and libfftw3-3 (as reported by dpkg). Did not break anything. Which readynas and version do you use?
I do not think python 2.7 will break anything. I have 2.7.3 on a Vortexbox with LMS 7.8 and BrutefirDRC 4.0. Works fine


If 1.0f won't work, where can I get a version of 1.0k that will run on the ReadyNAS's etch release?

brutefirwrapper writes to 'brutefir.log' Check this for relevant output.

That logfile isn't present on my system.  Maybe that's a clue that brutefir isn't working properly.  Where should the logfile be?  /var/log?

I believe /var/log/squeezeboxserver/brutefir.log. Maybe touch /var/log/squeezeboxserver/brutefir.log to get this going. bruterfirwrapper should work without the log though.

You may have to disable all but the "sox/brutefirwrapper" entry in "Settings-> Advanced-> File types" in LMS to make sure LMS is sending output via BrutefirDRC.

Olav Sunde

unread,
May 21, 2013, 3:58:56 AM5/21/13
to brute...@googlegroups.com

One more thing: Check /tmp/.BrutefirDrc-0 Is this root:root? Any files in this folder? This is where brutefirwrapper stores it's work files

Olav Sunde

unread,
May 21, 2013, 4:52:18 PM5/21/13
to brute...@googlegroups.com
Found some more info from my own installation of brutefir.

### brutefir 1.0k on RN ultra 2+ ###

brutefir_1.0k-2_i386.deb
gcc-4.4-base_4.4.5-12_i386.deb
libasound2_1.0.23-2.1_i386.deb
libfftw3-3_3.2.2-1_i386.deb
libjack-jackd2-0_1.9.6~dfsg.1-2_i386.deb
libstdc++6_4.4.5-12_i386.deb

I have set up 4.0beta on my ReadyNas today. Had some trouble getting it working. Turned out that file proprties were wrong so  brutefirwrapper wouldn't run. chmod -R 755 on the plugin folder fixed it.

Olav

tic toc

unread,
May 22, 2013, 8:14:45 PM5/22/13
to brute...@googlegroups.com


On Tuesday, May 21, 2013 1:52:18 PM UTC-7, Olav Sunde wrote:
Which readynas and version do you use?

I have two, both x86:  My main server is a Pro Pioneer running OS 4.2.23, but I also have an Ultra 2 Plus running 4.2.22 that's currently unused.  I have been trying to get BrutefirDRC running on the Pro, but I don't like to do too much trial-and-error experimentation there because, as I said, it is my main server.

Tonight I will install LMS 7.8 on the Ultra and experiment with BrutefirDRC there, where I can safely break things with no consequences.

Found some more info from my own installation of brutefir.

### brutefir 1.0k on RN ultra 2+ ###

brutefir_1.0k-2_i386.deb
gcc-4.4-base_4.4.5-12_i386.deb
libasound2_1.0.23-2.1_i386.deb
libfftw3-3_3.2.2-1_i386.deb
libjack-jackd2-0_1.9.6~dfsg.1-2_i386.deb
libstdc++6_4.4.5-12_i386.deb

Wow.  None of those version numbers match mine, and none match what is available from apt using the default 4.2.23 sources.list.  I will have to download individual packages and install them with dpkg tonight.

I have set up 4.0beta on my ReadyNas today. Had some trouble getting it working. Turned out that file proprties were wrong so  brutefirwrapper wouldn't run. chmod -R 755 on the plugin folder fixed it.

Thanks.  I'll make sure to do that (and follow the other advice you've given) when I install a test system on the Ultra 2 Plus tonight.
 
-Andrew

Olav Sunde

unread,
May 23, 2013, 3:38:43 AM5/23/13
to brute...@googlegroups.com


On Thursday, 23 May 2013 02:14:45 UTC+2, tic toc wrote:
I have two, both x86:  My main server is a Pro Pioneer running OS 4.2.23, but I also have an Ultra 2 Plus running 4.2.22 that's currently unused.  I have been trying to get BrutefirDRC running on the Pro, but I don't like to do too much trial-and-error experimentation there because, as I said, it is my main server.

I tried 4.2.22 on my Ultra. Had to downgrade to .16 because I experienced the bug where eth0 (and eth1) would stop working. Pity Netgear has stopped development and bugfixing of this OS.


Tonight I will install LMS 7.8 on the Ultra and experiment with BrutefirDRC there, where I can safely break things with no consequences.

Found some more info from my own installation of brutefir.

### brutefir 1.0k on RN ultra 2+ ###

brutefir_1.0k-2_i386.deb
gcc-4.4-base_4.4.5-12_i386.deb
libasound2_1.0.23-2.1_i386.deb
libfftw3-3_3.2.2-1_i386.deb
libjack-jackd2-0_1.9.6~dfsg.1-2_i386.deb
libstdc++6_4.4.5-12_i386.deb

Wow.  None of those version numbers match mine, and none match what is available from apt using the default 4.2.23 sources.list.  I will have to download individual packages and install them with dpkg tonight.

Yes, that is what  I did. I believe sox is not part of the ReadyNas Debian distro. I installed sox the same way (even more hassle than brutefir), but it turned out this was not necessary as I think brutefirwrapper uses sox that comes with LMS. Creating a softlink from /usr/bin/sox to /usr/share/squeezeboxserver/Bin/i386-linux/sox  is a good fix if this does not work.

tic toc

unread,
May 23, 2013, 6:09:03 AM5/23/13
to brute...@googlegroups.com

On Thursday, May 23, 2013 12:38:43 AM UTC-7, Olav Sunde wrote:

I tried 4.2.22 on my Ultra. Had to downgrade to .16 because I experienced the bug where eth0 (and eth1) would stop working. Pity Netgear has stopped development and bugfixing of this OS.
 
Agreed; it is a pity.  Maybe updating your BIOS would fix that bug?  You can check your current bios version by downloading your logs (from Frontview Status:Logs) and reading bios_ver.log. You probably have BIOS version 1.4 or earlier.  To update to BIOS version 1.8 (dated 11/02/2011), download this file and install it as though it were an addon:
 
 
After a minute or two, it'll tell you the update has been installed and prompt you to reboot.  I've done it on both the Ultra 2 Plus and the Pro Pioneer, with nothing but good effects.
 
(By the way... Before downloading the logs, make sure that there's plenty of free space on your OS partition.  Sometimes, if your logs are gigantic and/or you've filled the OS partition with addon files or something, the process of copying the logs and zipping them will fill the OS partition completely; if that happens, the NAS will start to act VERY weird.  If your OS partition doesn't have much space left, you can usually free up sufficient space by deleting the backup logs from Frontview:Backup before downloading the logs.  Or you can just run the BIOS Update addon without first downloading the logs to check your current BIOS version; the addon won't do anything if your BIOS is already at 1.8 or greater.)
 
Ok... Back to my problem.  Unfortunately, it still exists.
 
I have brutefir 1.0k on my Ultra 2 Plus system now; the following packages installed without error or unmet dependencies:
 
brutefir_1.0k-2_i386.deb
gcc-4.4-base_4.4.5-8_i386.deb
libasound2_1.0.23-2.1_i386.deb
libfftw3-3_3.2.2-1_i386.deb
libjack-jackd2-0_1.9.6~dfsg.1-2_i386.deb
libstdc++6_4.4.5-8_i386.deb
Files seem to be in the right place, with the right permissions and ownership:
 
nas2:/c/.squeezeboxserver/Plugins/BrutefirDrc# l
total 244
drwxr-xr-x 2  201  201  4096 2013-05-23 00:33 Bin
-rw-r--r-- 1 root root  3982 2013-05-23 01:36 custom-convert.conf
drwxr-xr-x 3  201  201  4096 2013-05-23 00:33 HTML
-rwxr-xr-x 1  201  201   787 2013-05-23 00:33 install.xml
-rwxr-xr-x 1  201  201  7259 2013-05-23 00:33 PlayerSettings.pm
-rwxr-xr-x 1  201  201 67172 2013-05-23 00:33 Plugin.pm
-rwxr-xr-x 1  201  201  5929 2013-05-23 00:33 Replace.pm
-rwxr-xr-x 1  201  201  7116 2013-05-23 00:33 ReplayGain.pm
-rwxr-xr-x 1  201  201  4386 2013-05-23 00:33 Settings.pm
-rwxr-xr-x 1  201  201 26184 2013-05-23 00:33 Song.pm
-rwxr-xr-x 1  201  201 30990 2013-05-23 00:33 Squeezebox2.pm
-rwxr-xr-x 1  201  201  1474 2013-05-23 00:33 SqueezeSlave.pm
-rwxr-xr-x 1  201  201 23800 2013-05-23 00:33 strings.txt
-rwxr-xr-x 1  201  201  1608 2013-05-23 00:33 template-flac.conf
-rwxr-xr-x 1  201  201  1078 2013-05-23 00:33 template-flac_loudness.conf
-rwxr-xr-x 1  201  201  1452 2013-05-23 00:33 template-mp3.conf
-rwxr-xr-x 1  201  201  1152 2013-05-23 00:33 template-mp3_loudness.conf
-rwxr-xr-x 1  201  201  1769 2013-05-23 00:33 template-pcm.conf
-rwxr-xr-x 1  201  201  1329 2013-05-23 00:33 template-pcm_loudness.conf
-rwxr-xr-x 1  201  201 13924 2013-05-23 00:33 TranscodingHelper.pm

nas2:/c/.squeezeboxserver/Plugins/BrutefirDrc/Bin# l
total 24
-rwxr-xr-x 1 201 201 24537 2013-05-23 00:33 brutefirwrapper
nas2:/c/.squeezeboxserver/cache/InstalledPlugins/Plugins# l
total 0
lrwxrwxrwx 1 201 201 41 2013-05-23 00:42 BrutefirDrc -> /c/.squeezeboxserver/Plugins/BrutefirDrc/

nas2:/etc/squeezeboxserver/BrutefirDrc/filters# l
total 536
-rwxr-xr-x 1  201  201 262144 2013-05-23 00:47 null-65k48-l.pcm
-rwxr-xr-x 1  201  201 262144 2013-05-23 00:47 null-65k48-r.pcm
-rwxr-xr-x 1  201  201   2464 2013-05-23 00:47 sample_eq.txt
-rw-r--r-- 1 root root   3583 2013-05-23 01:36 sample_filter_and_eq.txt
-rwxr-xr-x 1  201  201   2669 2013-05-23 00:47 sample_filter_no_eq.txt
-rwxr-xr-x 1  201  201    329 2013-05-23 00:47 sample_info.txt
nas2:/etc/squeezeboxserver/BrutefirDrc/settings# l
total 4
lrwxrwxrwx 1 root root 66 2013-05-23 01:36 filter-00_04_20_06_b2_c2 -> /etc/squeezeboxserver/BrutefirDrc/filters/sample_filter_and_eq.txt

nas2:/usr/bin# l sox
lrwxrwxrwx 1 root root 46 2013-05-23 01:18 sox -> /usr/share/squeezeboxserver/Bin/i386-linux/sox
Note that I originally set the ownership of all the files in the BrutefirDrc directories to 201:201.  Ownership of custom-convert.conf, sample_filter_and_eq.txt, and filter-00_04_20_06_b2_c2 was changed to root:root by BrutefirDRC when it wrote to those files.
 
BrutefirDRC automatically changed my File Types settings to sox/brutefirwrapper when I selected the FLAC or FLAC_LOUDNESS template in the web GUI's Player:BrutefirDRC settings.
 
There is no /tmp/.BrutefirDrc-0/ directory.  There is no /var/log/squeezeboxserver/ directory; the closest thing on my system is /var/log/slimserver.log, which is symlinked to /c/.squeezeboxserver/log/server.log .  There is no brutefir.log file in /c/.squeezeboxserver/log or anywhee else.  Maybe the logfile and work-file directory you referenced were only for the older versions of BrutefirDRC?
 
Anyway, the symptoms are as before:  In the Player:BrutefirDRC settings, I can select Template=DISABLE and everything works.  I can select Template=FLAC_LOUDNESS (which simply enables loudness without using a filterm as far as I can tell) and it still works -- I even get something like loudness compensation, although it isn't exactly what I'd expect; maybe I just need to tweak the various loudness parameters.
 
The problem is when I select Template=FLAC and choose a filter (I'm using sample_filter_and_eq.txt).  When I do that, music doesn't play; the track timer just increments for a couple of seconds and then stops and resets to 0:00.  Switching back to Template=FLAC_LOUDNESS or Template=DISABLE restores the playback functionality.
 
I've set the player.source logging to Debug, and I can see the failure:
 
[13-05-23 02:40:18.3781] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3789] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3798] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3806] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3813] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3822] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3828] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3835] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3844] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3851] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3858] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3867] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3874] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3881] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3889] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3896] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3903] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3911] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3918] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3925] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3932] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3939] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3946] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3956] Slim::Player::Pipeline::sysread (310) Wrote 32768 bytes to pipeline writer
[13-05-23 02:40:18.3966] Slim::Player::Pipeline::sysread (282) Pipeline doesn't have pending bytes - trying to get some from source
[13-05-23 02:40:18.3978] Slim::Player::Pipeline::sysread (304) Attempting to write to pipeline writer
[13-05-23 02:40:18.3989] Slim::Player::Source::_readNextChunk (347) readlen undef: (Broken pipe) 32
[13-05-23 02:40:18.3996] Slim::Player::Source::_readNextChunk (374) end of file or error on socket, song pos: 0
[13-05-23 02:40:18.4003] Slim::Player::Source::_readNextChunk (379) 00:04:20:06:b2:c2 mark end of stream
[13-05-23 02:40:18.4010] Slim::Player::Source::_readNextChunk (387) Didn't stream any bytes for this song; mark it as failed
[13-05-23 02:40:18.4017] Slim::Player::StreamingController::playerStreamingFailed (2345) 00:04:20:06:b2:c2
[13-05-23 02:40:18.4028] Slim::Player::StreamingController::_playersMessage (789) Problem: Can't open file for:: file:///media/music/Music/Various%20Artists/Rewind!%204/03%20Word%20Up.flac
[13-05-23 02:40:18.4079] Slim::Player::StreamingController::_eventAction (271) 00:04:20:06:b2:c2: StreamingFailed in BUFFERING-STREAMING -> Slim::Player::StreamingController::_StopNextIfMore
[13-05-23 02:40:18.4086] Slim::Player::StreamingController::_eventAction (284) params: errorDisconnect => undef
[13-05-23 02:40:18.4102] Slim::Player::StreamingController::_Stop (603) Song queue is now 0
[13-05-23 02:40:18.4111] Slim::Player::SongStreamController::DESTROY (44) DESTROY(Slim::Player::SongStreamController=HASH(0xa7eb138)) live=0
[13-05-23 02:40:18.4118] Slim::Player::StreamingController::_setPlayingState (2474) new playing state STOPPED
[13-05-23 02:40:18.4125] Slim::Player::StreamingController::_setStreamingState (2487) new streaming state IDLE
[13-05-23 02:40:18.4135] Slim::Player::StreamingController::_willRetry (1458) no retry data
[13-05-23 02:40:18.4146] Slim::Player::StreamingController::nextsong (877) The next song is number 0, was 0
[13-05-23 02:40:18.4153] Slim::Player::StreamingController::_eventAction (303) 00:04:20:06:b2:c2: StreamingFailed - new state STOPPED-IDLE
 
When Template=FLAC_LOUDNESS or Template=DISABLE, the "readlen undef: (Broken pipe) 32 " error doesn't appear.
 
You've already been very generous with your time, and I really appreciate that.  I hate to ask for more from you, but do you have any idea what might be causing this final problem?
-Andrew
 

Olav Sunde

unread,
May 23, 2013, 10:03:11 AM5/23/13
to brute...@googlegroups.com


On Thursday, 23 May 2013 12:09:03 UTC+2, tic toc wrote

Good tip with the bios update, thanks.

I still do not quite understand which user 201 is. I do not have 201 anywhere on my box. Try changing ownership to root:root  for the plugin files, in particular brutefirwrapper. Then create the missing folder /var/log/squeezeboxserver/ . If you look in brutefirwrapper it wants to write a log file here, but I guess only root can do that. Also, the /tmp/.BrutefirDrc-0/ is created by brutefirwrapper on first run IF it has rights to do it. If not, brutefirwrapper will simply exit
As LMS is working when BrutefirDRC is disabled you are very close to a working BrutefirDRC now!

Olav

Klaas Reineke

unread,
May 25, 2013, 8:30:38 AM5/25/13
to brute...@googlegroups.com
Hi Andrew,

you should find a line like:
Plugins::BrutefirDrc::Song::open (557) Tokenized command: "/usr/share/squeezeboxserver/Bin/i386-linux/sox" -q -t flac "-" -t wavpcm -c 2 -3 -s - silence -l 1 0.1 -90.0d -1 5.0 -90.0d loudness -38.16 75.0 gain 22.90 | "/usr/share/squeezeboxserver/Plugins/BrutefirDrc/Bin/brutefirwrapper" 00:04:20:06:b4:65 /etc/squeezeboxserver/BrutefirDrc/settings/filter-00_04_20_06_b4_65 |"/usr/share/squeezeboxserver/Bin/i386-linux/sox" -q -t wavpcm - -t flac -C 0 -

in the log file, when you try to play a song. Copy the line and replace the first "-" with the path to the song. If everything works correctly you should get some binary garbage to your prompt. If not it helps to make this line work. If you don't see this line maybe you have to change logging for "player.streaming" to info, but I am quite sure that this should be displayed via "player.source".

By the way the user "201" could this be the user "squeezeboxserver"? At least at my box (ubuntu) all files must be owned by squeezeboxserver or at least be read and writeable for the squeezeboxuser. The installation package created the user automatically on my  box.

If the files are changed to user "root" the server process is running as root. Make sure that you always run as the same user, if the files are owned by root and the server is run as different user you will get permission problems.

Regards and good luck
Klaas

P.S. by the way: when everything is up and running I would be glad to here aboutt your problems and expecations with the loudness stuff :)

tic toc

unread,
May 29, 2013, 12:11:55 PM5/29/13
to brute...@googlegroups.com
Olav and Klaas:
 
Thank you.  I think your advice regarding permissions and ownership is all I need to solve the problem.
 
My work has unfortunately taken precedence over my music this week, so I have not been able to proceed further with BrutefirDRC.  I hope to have time to work on my installation again this weekend, and I will post the results here.
 

tic toc

unread,
Jun 3, 2013, 3:55:15 PM6/3/13
to brute...@googlegroups.com
On Thursday, May 23, 2013 7:03:11 AM UTC-7, Olav Sunde wrote:

I still do not quite understand which user 201 is. I do not have 201 anywhere on my box. Try changing ownership to root:root  for the plugin files, in particular brutefirwrapper. Then create the missing folder /var/log/squeezeboxserver/ . If you look in brutefirwrapper it wants to write a log file here, but I guess only root can do that. Also, the /tmp/.BrutefirDrc-0/ is created by brutefirwrapper on first run IF it has rights to do it. If not, brutefirwrapper will simply exit
As LMS is working when BrutefirDRC is disabled you are very close to a working BrutefirDRC now!

Olav:

You were correct; I was very close.  The directory in /tmp was the last piece of the puzzle, and now I have a working installation on my ReadyNAS Pro!

Thank you!

Next steps for me:

1. Create real room-correction filters for my system (my wife was asleep by the time I got it working last night, and I didn't want to wake her with sweep tones).

2. Test it to verify that everything really does work, then write a BrutefirDrc-on-ReadyNAS installation guide.  I hope to finish that by next weekend, and I'll post a copy here.

Thanks again.

-Andrew

tic toc

unread,
Jun 3, 2013, 4:07:12 PM6/3/13
to brute...@googlegroups.com
On Saturday, May 25, 2013 5:30:38 AM UTC-7, Klaas Reineke wrote:
 
By the way the user "201" could this be the user "squeezeboxserver"? At least at my box (ubuntu) all files must be owned by squeezeboxserver or at least be read and writeable for the squeezeboxuser. The installation package created the user automatically on my  box.

If the files are changed to user "root" the server process is running as root. Make sure that you always run as the same user, if the files are owned by root and the server is run as different user you will get permission problems.

Thank you, Klaas.  And thank you for creating this great plugin.

Yes, user 201 is the "squeezeboxserver" user.  Your advice about always running as the same user is good; the process was running as root when I started it myself, of course, but the process owner is also root when LMS is automatically started, so everything works.

That leaves a small mystery: Why does user 201 exist at all?  Perhaps that user is left over from an earlier installation that ran as user 201 rather than root.  Or maybe I changed something in the startup scripts.  I don't know, but I will figure it out.

I am sure I will have more comments as I spend time enjoying the plugin.  Thanks again.

-Andrew

Olav Sunde

unread,
Jun 3, 2013, 6:01:24 PM6/3/13
to brute...@googlegroups.com
I am really pleased to learn that you've made it work! The ReadyNas Pro is a very nice and capable LMS server with BrutefirDrc.
I think you will find the 'Release 4.0.beta' thread interesting. Klaas has sorted a few issues in brutefirwrapper with help from Mervin and me. If you want to try the latest brutefirwrapper you'll only need to replace  that file. No need to reinstall the whole plugin.


Olav

Klaas Reineke

unread,
Jun 7, 2013, 3:56:09 AM6/7/13
to brute...@googlegroups.com
new release on sourceforge. It is the same file as posted here. Version is 4.1.beta, I guess there are still some problems so I keep the beta state :)

tic toc

unread,
Jun 12, 2013, 5:13:43 PM6/12/13
to brute...@googlegroups.com
On Friday, June 7, 2013 12:56:09 AM UTC-7, Klaas Reineke wrote:
new release on sourceforge. It is the same file as posted here. Version is 4.1.beta, I guess there are still some problems so I keep the beta state :)

I have noticed a few things:

1. Diffing the 4.1 template files against 4.0 shows that all but one (flac-loudness, if I recall correctly) have been modified for different/better resampling.  Was the unchanged file left alone deliberately, or was that an oversight?

2.  With 4.1, sometimes the last few seconds of a track sound odd.  I think it only happens when the volume is changed during playback of the track; could it be that the last few seconds are playing at the original volume, and might this be related to the new tail processing you have been working on?  I saw the tail-processing discussion but I am afraid I did not really pay attention to exactly what was being changed.

3.  With 4.0 (I have not checked since installing 4.1), my server log shows errors as Plugin.pm tries to execute calculateReplayGain.  Is this a common problem with a known solution?  If not, I will get the exact error message later today and post it here.

4.  I cannot seek within a track while BrutefirDRC is active.  If I try to seek 20 seconds into the track, for example, the web GUI places the marker on the track progress bar properly, but the track actually starts playing from the beginning (T=0).  With BrutefirDRC disabled, I can seek to that point and the track will start to play from T=20, as expected.  My files are all FLAC (nearly all 16/44.1), if that makes a difference.

The ReadyNAS installation guide is turning out to be more involved than I thought it would be.  It is a good thing that I have a spare box to experiment on; I am discovering/remembering that I had to do a lot to get my main box to its current state (for example, by default the ReadyNAS does not even have bzip installed).  I am having fun documenting the process, however, even though it is a little bit tedious.

Klaas Reineke

unread,
Jun 13, 2013, 5:28:50 AM6/13/13
to brute...@googlegroups.com
I have noticed a few things:

1. Diffing the 4.1 template files against 4.0 shows that all but one (flac-loudness, if I recall correctly) have been modified for different/better resampling.  Was the unchanged file left alone deliberately, or was that an oversight?

this is a Bug, I willchange this :)

 
2.  With 4.1, sometimes the last few seconds of a track sound odd.  I think it only happens when the volume is changed during playback of the track; could it be that the last few seconds are playing at the original volume, and might this be related to the new tail processing you have been working on?  I saw the tail-processing discussion but I am afraid I did not really pay attention to exactly what was being changed.

You are correct, this is a "known issue". The problem is the tail. The loudness can only be set when starting a track, there is no option to change it while playing a track. Because of this the volume changes while playing are done without loudness adjustment. When the server notifies that a new track starts playing the volume is changed to new optimal volume for the loudness settings. The tail uses the old loudness setting, because of this the tail can be too loud or not loud enough.
 

3.  With 4.0 (I have not checked since installing 4.1), my server log shows errors as Plugin.pm tries to execute calculateReplayGain.  Is this a common problem with a known solution?  If not, I will get the exact error message later today and post it here.

Please post the error from your log, I did never encounter this, in my logs. At least not while developing and checking the logs. 

4.  I cannot seek within a track while BrutefirDRC is active.  If I try to seek 20 seconds into the track, for example, the web GUI places the marker on the track progress bar properly, but the track actually starts playing from the beginning (T=0).  With BrutefirDRC disabled, I can seek to that point and the track will start to play from T=20, as expected.  My files are all FLAC (nearly all 16/44.1), if that makes a difference.

I can only seek when I choose PCM output. I cannot seek in Flac. This issue exists since the first version of the Plugin.
 

The ReadyNAS installation guide is turning out to be more involved than I thought it would be.  It is a good thing that I have a spare box to experiment on; I am discovering/remembering that I had to do a lot to get my main box to its current state (for example, by default the ReadyNAS does not even have bzip installed).  I am having fun documenting the process, however, even though it is a little bit tedious.

Great, hope you get the guide finished and posted for other ReadyNAS uses. 

Regards Klaas
Reply all
Reply to author
Forward
0 new messages