Bugzilla – Bug 9356
transcoding due to bitrate limiting emits noise only
Last modified: 2011-03-16 04:39:10 UTC
Created attachment 3918 [details] server.log - player.source=debug (flac track) while testing 7.3 with the new streaming engine i ran into a problem with my remotely connected SB3. It's connected to the SC accross the internet and has bitrate limiting enabled and set to 128kbit. After the internal buffer has been filled (about 6%-8%) i just hear noise. I've found one track which works (log appended), and two others (flac+mp3) which don't (log appended, too) What's different is this [08-09-01 18:21:09.4002] Slim::Player::Pipeline::sysread (285) Pipeline doesn't have pending bytes - trying to get some from source [08-09-01 18:21:09.4116] Slim::Player::Pipeline::sysread (296) Attempting to write to pipeline writer [08-09-01 18:21:09.4120] Slim::Player::Pipeline::sysread (302) Wrote 32768 bytes to pipeline writer [08-09-01 18:21:09.4123] Slim::Player::Pipeline::sysread (285) Pipeline doesn't have pending bytes - trying to get some from source [08-09-01 18:21:09.4713] Slim::Player::Pipeline::sysread (296) Attempting to write to pipeline writer [08-09-01 18:21:09.4717] Slim::Player::Pipeline::sysread (302) Wrote 32768 bytes to pipeline writer ... which repeats with no end (or until i pause the track)
Created attachment 3919 [details] server.log - player.source=debug (mp3 track): NOISE
Created attachment 3920 [details] server.log - player.source=debug (mp3 track): WORKS
I can confirm this bug on Ubuntu 8.04. Same errors in log.
The problem is that lame was being called with stdin instead of a xxx.mp3 and was guessing on raw PCM as the input type. Wrong! Added --mp3input to convert.conf and it is working fine now. Change 23006.
thanks a lot! works fine so far. I've still got a few problems with streaming 88.2/96-tracks but i think this problem is on my side - don't know for sure if this has even worked in 7.1/7.2... nevertheless two things i've noticed: - skipping transcoded (flac)tracks before the buffer of the player is filled results in ******** -: ERROR while decoding data state = FLAC__STREAM_DECODER_END_OF_STREAM Error writing mp3 output ******** This is printed to the console slimserver.pl was started in, i suppose to stderr. Logging out closes stderr and therefore prevents further logging. - Why are flac+lame running with the root user, even though slimserver.pl uses a non privileged user? pstree -Alu 28408 slimserver.pl(control)-+-mDNSResponderPo |-mysqld---mysqld---9*[mysqld] `-sh(root)-+-flac `-lame Okay i won't bet a lot but AFAIR those two things have changed. thanks, Markus
1. The error messages are just the various transcoding processes complaining about their inputs or outputs being closed prematurely, even if they are run with --silent or equivalent. Not much I can do about that. The nature of the flac complaint has probably changed (it used to read a plain file and now gets a pipe). 2. No idea how you get that. Have you checked with just ps, not pstree? I certainly do not see that with either my package-installed system or my test environment - the transcoding processes run under the SC UID.
(In reply to comment #6) > 1. The error messages are just the various transcoding processes complaining > about their inputs or outputs being closed prematurely, even if they are run > with --silent or equivalent. Not much I can do about that. The nature of the > flac complaint has probably changed (it used to read a plain file and now gets > a pipe). yep, this is it. Just tested with 7.2 which indeed passes the file to flac. 7.3 executes a "sh -c" process with pipe-in-pipe-out. > > 2. No idea how you get that. Have you checked with just ps, not pstree? I > certainly do not see that with either my package-installed system or my test > environment - the transcoding processes run under the SC UID. > i've checked and verified it (i would have lost this bet i mentioned as this is the same in 7.2 already). I traced it down to perl's setuid & open2 call with a simple test-script: root@vserver1:~# cat test.pl #!/usr/bin/perl use strict; use base qw(IO::Handle); use IO::Handle; use IPC::Open2; # copied from slimserver.pl undef $!; $> = 1002; # copied from S::P::Pipeline.pm my ($reader, $writer, $command); $command="id > id.out"; $reader = IO::Handle->new(); $writer = IO::Handle->new(); # expected: id is called with uid 1002 and creates # a file owned by user 1002 (the script itself # runs as 1002 (euid), verified with ps/top) open2($reader, $writer, $command); # the following call doesn't work, permission denied # because id.out has been created as root system("cat id.out"); exit 0 root@vserver1:~# ./test.pl cat: id.out: Permission denied root@vserver1:~# cat id.out uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),7(lp),10(wheel),11(floppy),20(dialout),26(tape),27(video),106(lpadmin) root@vserver1:~# seems to be a general behaviour (uid/euid-handling) as perl on linux and mac-os act the same. Don't know (yet) if and how this could be solved...
Are you running SC as a setuid process? I don't think that that is the way the usual packages work. If you get this problem when running for a standard package (a nightly build) then please open a separate bug for this. I wonder if this is different for the Ubuntu (Debian) packages as I don't see this with Fedora (RPM).
(In reply to comment #8) > Are you running SC as a setuid processs? setuid="chmod u+s"? woah, i'm not that crazy :-o > I don't think that that is the way the > usual packages work. If you get this problem when running for a standard > package (a nightly build) then please open a separate bug for this. yep, i've done a few more tests and opened Bug 9384 which lists the problem in more detail. > I wonder if this is different for the Ubuntu (Debian) packages as I don't see > this with Fedora (RPM). you won't see it in any major distro packages as they use own start/stop-helpers like start-stop-daemon. They will drop privileges much earlier and will therefore not cause this problem. thanks for helping - even if it got a little OT :-) Markus
*** Bug 8863 has been marked as a duplicate of this bug. ***
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC