From: Ron K. <ro...@za...> - 2001-07-21 20:53:42
|
Hi, When my MH plays a sound I says it failed doing it and tries it again a few times until it gives up. It _does_ play the sound, (5 times) but the return code is wrong so it tries it again and again. The MH console lists this: running: waveplay -s ./../sounds/sound_click2.wav Waiting to play sound file, pass=4 file=./../sounds/sound_click2.wav running: waveplay -s ./../sounds/./../sounds/sound_click2.wav Waiting to play sound file, pass=3 file=./../sounds/./../sounds/sound_click2.wav running: waveplay -s ./../sounds/./../sounds/./../sounds/sound_click2.wav Waiting to play sound file, pass=2 file=./../sounds/./../sounds/./../sounds/sound_click2.wav running: waveplay -s ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav Waiting to play sound file, pass=1 file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav running: waveplay -s ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav Gave up trying to play sound file: ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav So there is also a bug which appends the same sound path again and again. This code snipped returns the wrong return code: (bin/mh in play subroutine) my $pid = fork; if (defined $pid && $pid == 0) { exec qq[waveplay -s /mh/sounds/sound_click2.wav]; die 'cant exec $config_parms{sound_program}'; } it returns -1 therefore mh thinks it failed. When I paste this in a play.pl: #!/usr/bin/perl my $pid = fork; if (defined $pid && $pid == 0) { exec qq[waveplay -s /mh/sounds/sound_click2.wav]; die 'cant exec $config_parms{sound_program}'; } print $?; This returns 0 like it should. Is looks like there a perl startup parm which changes the behaviour of system() and exec() return codes in MH when running unix/freebsd?? I have forced played_ok = 1 for the moment, but does anyone have the same problem under unix? Regards, Ron. |
From: David M. <da...@ri...> - 2001-07-21 21:43:56
|
I,m having the same problem on my system but haven't tried to run it down yet. On Saturday 21 July 2001 03:53 pm, you wrote: > Hi, > > When my MH plays a sound I says it failed doing it > and tries it again a few times until it gives up. > > It _does_ play the sound, (5 times) but the return code is > wrong so it tries it again and again. > > The MH console lists this: > running: waveplay -s ./../sounds/sound_click2.wav > Waiting to play sound file, pass=4 file=./../sounds/sound_click2.wav > running: waveplay -s ./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=3 > file=./../sounds/./../sounds/sound_click2.wav > running: waveplay -s ./../sounds/./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=2 > file=./../sounds/./../sounds/./../sounds/sound_click2.wav > running: waveplay -s > ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=1 > file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > running: waveplay -s > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wa >v Gave up trying to play sound file: > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wa >v > > So there is also a bug which appends the same sound path again and again. > > This code snipped returns the wrong return code: (bin/mh in play > subroutine) > > my $pid = fork; > if (defined $pid && $pid == 0) { > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > die 'cant exec $config_parms{sound_program}'; > } > > it returns -1 therefore mh thinks it failed. > > When I paste this in a play.pl: > > #!/usr/bin/perl > my $pid = fork; > if (defined $pid && $pid == 0) { > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > die 'cant exec $config_parms{sound_program}'; > } > print $?; > > This returns 0 like it should. > > Is looks like there a perl startup parm which changes the behaviour of > system() and exec() return codes in MH when running unix/freebsd?? > > I have forced played_ok = 1 for the moment, but does anyone have > the same problem under unix? > > Regards, > Ron. > > > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 |
From: David N. <jud...@gt...> - 2001-07-21 22:20:42
|
I have the same problem with sounds running mh 2.55 under Linux. ----- Original Message ----- From: "Ron Klinkien" <ro...@za...> To: <mis...@li...> Sent: Saturday, July 21, 2001 1:53 PM Subject: [misterhouse-users] Return code of system and exec wrong? > Hi, > > When my MH plays a sound I says it failed doing it > and tries it again a few times until it gives up. > > It _does_ play the sound, (5 times) but the return code is > wrong so it tries it again and again. > > The MH console lists this: > running: waveplay -s ./../sounds/sound_click2.wav > Waiting to play sound file, pass=4 file=./../sounds/sound_click2.wav > running: waveplay -s ./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=3 > file=./../sounds/./../sounds/sound_click2.wav > running: waveplay -s ./../sounds/./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=2 > file=./../sounds/./../sounds/./../sounds/sound_click2.wav > running: waveplay -s > ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=1 > file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > running: waveplay -s > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > Gave up trying to play sound file: > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > > So there is also a bug which appends the same sound path again and again. > > This code snipped returns the wrong return code: (bin/mh in play > subroutine) > > my $pid = fork; > if (defined $pid && $pid == 0) { > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > die 'cant exec $config_parms{sound_program}'; > } > > it returns -1 therefore mh thinks it failed. > > When I paste this in a play.pl: > > #!/usr/bin/perl > my $pid = fork; > if (defined $pid && $pid == 0) { > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > die 'cant exec $config_parms{sound_program}'; > } > print $?; > > This returns 0 like it should. > > Is looks like there a perl startup parm which changes the behaviour of > system() and exec() return codes in MH when running unix/freebsd?? > > I have forced played_ok = 1 for the moment, but does anyone have > the same problem under unix? > > Regards, > Ron. > > > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Bruce W. <br...@mi...> - 2001-07-29 22:07:17
|
Just now getting back to this post from a few weeks ago ... > When my MH plays a sound I says it failed doing it > and tries it again a few times until it gives up. > > It _does_ play the sound, (5 times) but the return code is > wrong so it tries it again and again. > > The MH console lists this: > running: waveplay -s ./../sounds/sound_click2.wav > Waiting to play sound file, pass=4 file=./../sounds/sound_click2.wav > running: waveplay -s ./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=3 > file=./../sounds/./../sounds/sound_click2.wav > running: waveplay -s ./../sounds/./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=2 > file=./../sounds/./../sounds/./../sounds/sound_click2.wav > running: waveplay -s > ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > Waiting to play sound file, pass=1 > file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > running: waveplay -s > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > click2.wav > Gave up trying to play sound file: > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > click2.wav > > So there is also a bug which appends the same sound path again and again. I just fixed this the path prepending problem (by adding a -e $file test), but I don't think that is causing the repeated sound problem, as it is a valid path. > This code snipped returns the wrong return code: (bin/mh in play > subroutine) > > my $pid = fork; > if (defined $pid && $pid == 0) { > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > die 'cant exec $config_parms{sound_program}'; > } > > it returns -1 therefore mh thinks it failed. So, the question is what did I change in bin/mh to cause rc=-1 when calling waveplay. Can you try mh/bin/play, instead of waveplay? I don't see the problem here when using play. What is waveplay and what is it's advantage? Looks like there are 4 of you who reported this problem. Was the problem new to 2.55 and if so, what was the previous verion of mh where you did not see the problem and what is your mh.ini sound_program parm set to? Bruce |
From: Clive F. <sc...@fi...> - 2001-07-29 22:16:04
|
I am not sure what I can put in mh.private.ini to enable me to resolve IP addresses in mh. (My TCPIP settings do not show the name of a DNS server.) Is there an address of a server I can use? Clive |
From: Bill S. <bs...@vi...> - 2001-07-30 06:01:20
|
Hi Bruce (et al), First, stories of my demise are greatly exagerated ;) I've been so busy as work these last few quarters that MH has taken a back seat. Unfortunately that means an every growing list of updates to work on 'next weekend'. However, I did find a new hardware device that forced me to sit down and spend some time back in perl land. It's the Turtle Beach Audiotron (www.audiotron.net). It's a network MP3 player. Whats nice is that instead of trying to include an ultimately too small harddrive, this unit goes out and searches your local network for music files and makes them available. TB just added a web interface to the unit and another user has already written perl code to interface with it. They list for $299 but Best Buy has been closing them out for $199 with an off and on $50 instant rebate. Highly highly recommended, go get one (or 4 if your like me) of these devices. I just finished a layer ontop of the that code to make it work just like the Mp3Player.pm I already wrote. So, I dropped these units in and yanked out the old laptops I had running winamp as a service. (And they use about 1/8 the power as the laptop did too!). Best, bill |
From: Ray D. <rd...@so...> - 2001-07-30 19:32:46
|
I could not find these anywhere at bestbuy.com ----- Original Message ----- From: "Bill Sobel" <bs...@vi...> To: <mis...@li...> Cc: <ji...@vi...> Sent: Sunday, July 29, 2001 11:01 PM Subject: [misterhouse-users] Turtle Beach Audiotron > Hi Bruce (et al), > > First, stories of my demise are greatly exagerated ;) I've been so busy as > work these last few quarters that MH has taken a back seat. Unfortunately > that means an every growing list of updates to work on 'next weekend'. > > However, I did find a new hardware device that forced me to sit down and > spend some time back in perl land. It's the Turtle Beach Audiotron > (www.audiotron.net). It's a network MP3 player. Whats nice is that instead > of trying to include an ultimately too small harddrive, this unit goes out > and searches your local network for music files and makes them available. > TB just added a web interface to the unit and another user has already > written perl code to interface with it. They list for $299 but Best Buy > has been closing them out for $199 with an off and on $50 instant rebate. > Highly highly recommended, go get one (or 4 if your like me) of these > devices. > > I just finished a layer ontop of the that code to make it work just like the > Mp3Player.pm I already wrote. So, I dropped these units in and yanked out > the old laptops I had running winamp as a service. (And they use about 1/8 > the power as the laptop did too!). > > Best, > bill > > > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > > |
From: Donald H. <do...@dh...> - 2001-08-07 10:24:08
|
Bill, Where are some links to the perl code for the web interface? I looked at the audiotron a while back and did not get it because of the lack of a web interface. Was this added recently? Can't find any references to it on the audiotron web site. Thanks, Don Hoffman email: do...@dh..., phone: +1 503 384 9279, mobile: +1 503 705 1265, efax: +1 360 233 7808 -----Original Message----- From: mis...@li... [mailto:mis...@li...]On Behalf Of Bill Sobel Sent: Sunday, July 29, 2001 11:01 PM To: mis...@li... Cc: ji...@vi... Subject: [misterhouse-users] Turtle Beach Audiotron Hi Bruce (et al), First, stories of my demise are greatly exagerated ;) I've been so busy as work these last few quarters that MH has taken a back seat. Unfortunately that means an every growing list of updates to work on 'next weekend'. However, I did find a new hardware device that forced me to sit down and spend some time back in perl land. It's the Turtle Beach Audiotron (www.audiotron.net). It's a network MP3 player. Whats nice is that instead of trying to include an ultimately too small harddrive, this unit goes out and searches your local network for music files and makes them available. TB just added a web interface to the unit and another user has already written perl code to interface with it. They list for $299 but Best Buy has been closing them out for $199 with an off and on $50 instant rebate. Highly highly recommended, go get one (or 4 if your like me) of these devices. I just finished a layer ontop of the that code to make it work just like the Mp3Player.pm I already wrote. So, I dropped these units in and yanked out the old laptops I had running winamp as a service. (And they use about 1/8 the power as the laptop did too!). Best, bill ________________________________________________________ To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 |
From: Bill S. <bs...@vi...> - 2001-08-08 23:40:15
|
Hi Don, The newest beta firmware is on the ftp site (ftp.turtlebeach.com I believe). It adds the web interface. As for the perl code, I've been swamped to correctly merge it into the current release so I will send the code and the read_table_A changes to Bruce and ask him to merge it in. Best, Bill -----Original Message----- From: mis...@li... [mailto:mis...@li...] On Behalf Of Donald Hoffman Sent: Tuesday, August 07, 2001 3:25 AM To: mis...@li... Subject: RE: [misterhouse-users] Turtle Beach Audiotron Bill, Where are some links to the perl code for the web interface? I looked at the audiotron a while back and did not get it because of the lack of a web interface. Was this added recently? Can't find any references to it on the audiotron web site. |
From: <ro...@my...> - 2001-08-09 04:32:24
|
Quoting Bill Sobel <bs...@vi...>: > The newest beta firmware is on the ftp site (ftp.turtlebeach.com I > believe). It adds the web interface. As for the perl code, I've been have you used the newest firmware yet? Do you like the web interface? > swamped to correctly merge it into the current release so I will send > the code and the read_table_A changes to Bruce and ask him to merge it > in. thanks! rob ------------------------------------------------- This mail sent through IMP: http://webapps.myinternetplace.net/imp |
From: Ron K. <ro...@za...> - 2001-07-30 13:02:04
|
Hi Bruce, As you advised I tried the simple /mh/bin/play command instead of waveplay (which is just a small tool to play .wav files, it also does some checks on the bitrate of the sound etc). But play has the same problem, it plays the sound ok, but when executed from perl it return a wrong return code (!=0) so MH tries it again... It's not only the play command which has this problem but also the date command called when syncing clocks from the inet. Which results in: "System clock NOT adjusted due to time command error."s If I use the same perl code in a single play.pl and run that, it returns the correct rc.(0) But if I use that code in /mh/bin/mh it goes wrong. ------ #!/usr/bin/perl my $pid = fork; if (defined $pid && $pid == 0) { exec qq[/mh/bin/play /mh/sounds/sound_click2.wav]; die 'cant exec $config_parms{sound_program}'; } print $?; ------ It has nothing todo with the specific sound play code, but all exec's (which is only used a few times) have this problem. With some perl commands you have to use >>8 tricks to get the right return code. (see perldoc site). I have the feeling it has todo with some perl startup params/stack when used with mh. Maybe a shell environment which is incorrect so all exec's fail. I will try some more things later today. Regards, Ron. ----- Original Message ----- From: "Bruce Winter" <br...@mi...> To: <mis...@li...> Sent: Monday, July 30, 2001 12:07 AM Subject: RE: [misterhouse-users] Return code of system and exec wrong? > > Just now getting back to this post from a few weeks ago ... > > > When my MH plays a sound I says it failed doing it > > and tries it again a few times until it gives up. > > > > It _does_ play the sound, (5 times) but the return code is > > wrong so it tries it again and again. > > > > The MH console lists this: > > running: waveplay -s ./../sounds/sound_click2.wav > > Waiting to play sound file, pass=4 file=./../sounds/sound_click2.wav > > running: waveplay -s ./../sounds/./../sounds/sound_click2.wav > > Waiting to play sound file, pass=3 > > file=./../sounds/./../sounds/sound_click2.wav > > running: waveplay -s ./../sounds/./../sounds/./../sounds/sound_click2.wav > > Waiting to play sound file, pass=2 > > file=./../sounds/./../sounds/./../sounds/sound_click2.wav > > running: waveplay -s > > ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > > Waiting to play sound file, pass=1 > > file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > > running: waveplay -s > > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > > click2.wav > > Gave up trying to play sound file: > > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > > click2.wav > > > > So there is also a bug which appends the same sound path again and again. > > > I just fixed this the path prepending problem (by adding a -e $file test), > but I don't think that is causing the repeated sound problem, as it is a > valid path. > > > > This code snipped returns the wrong return code: (bin/mh in play > > subroutine) > > > > my $pid = fork; > > if (defined $pid && $pid == 0) { > > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > > die 'cant exec $config_parms{sound_program}'; > > } > > > > it returns -1 therefore mh thinks it failed. > > So, the question is what did I change in bin/mh to cause rc=-1 when calling > waveplay. Can you try mh/bin/play, instead of waveplay? I don't see the > problem here when using play. What is waveplay and what is it's advantage? > > Looks like there are 4 of you who reported this problem. Was the problem > new to 2.55 and if so, what was the previous verion of mh where you did not > see the problem and what is your mh.ini sound_program parm set to? > > Bruce > > > > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Ron K. <ro...@za...> - 2001-07-30 19:54:17
|
Hi Bruce, For a change I reply on my own mail. ;-) I have been looking at the system() return code problem, and found at least the reason why the older routine of simply calling system() to play a sound also failed. system("$config_parms{sound_program} $file &"); When printing the $! of this system call I got: No child processes It returned this error because of line 483 in bin/mh: (v2.55) $SIG{CHLD} = 'IGNORE'; # So we don't create zombies when forking If you put an # infront, the return code of the system calls are 0 which is good ;) Maybe thats the reason this gave problems on OS X as you mentioned in the comments? It doesn't solve the original new soundplay code using "exec qq" though. I get "Resource temporarily unavailable" as #! text. But it has to be the same kind of trick I guess since a clean play.pl with the same code works ok. Reading a page on perl return codes ( http://www.weird-wonderful.com/p5be/ch13.cfm ) gave me the idea it's not that reliable in every situation. Regards, Ron. BTW: I'm running perl, version 5.005_03 built for i386-freebsd ----- Original Message ----- From: "Ron Klinkien" <ro...@za...> To: <mis...@li...> Sent: Monday, July 30, 2001 3:04 PM Subject: Re: [misterhouse-users] Return code of system and exec wrong? > Hi Bruce, > > As you advised I tried the simple /mh/bin/play command instead of waveplay > (which is just a small tool to play .wav files, it also does some checks on > the > bitrate of the sound etc). > > But play has the same problem, it plays the sound ok, but when executed > from perl it return a wrong return code (!=0) so MH tries it again... > > It's not only the play command which has this problem but also the date > command > called when syncing clocks from the inet. Which results in: > "System clock NOT adjusted due to time command error."s > > If I use the same perl code in a single play.pl and run that, it returns the > correct rc.(0) > But if I use that code in /mh/bin/mh it goes wrong. > ------ > #!/usr/bin/perl > my $pid = fork; > if (defined $pid && $pid == 0) { > exec qq[/mh/bin/play /mh/sounds/sound_click2.wav]; > die 'cant exec $config_parms{sound_program}'; > } > print $?; > ------ > > > It has nothing todo with the specific sound play code, but all exec's (which > is > only used a few times) have this problem. > > With some perl commands you have to use >>8 tricks to get the right return > code. > (see perldoc site). > > I have the feeling it has todo with some perl startup params/stack when used > with mh. > Maybe a shell environment which is incorrect so all exec's fail. > > I will try some more things later today. > > Regards, > Ron. > > ----- Original Message ----- > From: "Bruce Winter" <br...@mi...> > To: <mis...@li...> > Sent: Monday, July 30, 2001 12:07 AM > Subject: RE: [misterhouse-users] Return code of system and exec wrong? > > > > > > Just now getting back to this post from a few weeks ago ... > > > > > When my MH plays a sound I says it failed doing it > > > and tries it again a few times until it gives up. > > > > > > It _does_ play the sound, (5 times) but the return code is > > > wrong so it tries it again and again. > > > > > > The MH console lists this: > > > running: waveplay -s ./../sounds/sound_click2.wav > > > Waiting to play sound file, pass=4 file=./../sounds/sound_click2.wav > > > running: waveplay -s ./../sounds/./../sounds/sound_click2.wav > > > Waiting to play sound file, pass=3 > > > file=./../sounds/./../sounds/sound_click2.wav > > > running: waveplay -s > ./../sounds/./../sounds/./../sounds/sound_click2.wav > > > Waiting to play sound file, pass=2 > > > file=./../sounds/./../sounds/./../sounds/sound_click2.wav > > > running: waveplay -s > > > ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > > > Waiting to play sound file, pass=1 > > > file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > > > running: waveplay -s > > > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > > > click2.wav > > > Gave up trying to play sound file: > > > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > > > click2.wav > > > > > > So there is also a bug which appends the same sound path again and > again. > > > > > > I just fixed this the path prepending problem (by adding a -e $file test), > > but I don't think that is causing the repeated sound problem, as it is a > > valid path. > > > > > > > This code snipped returns the wrong return code: (bin/mh in play > > > subroutine) > > > > > > my $pid = fork; > > > if (defined $pid && $pid == 0) { > > > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > > > die 'cant exec $config_parms{sound_program}'; > > > } > > > > > > it returns -1 therefore mh thinks it failed. > > > > So, the question is what did I change in bin/mh to cause rc=-1 when > calling > > waveplay. Can you try mh/bin/play, instead of waveplay? I don't see > the > > problem here when using play. What is waveplay and what is it's > advantage? > > > > Looks like there are 4 of you who reported this problem. Was the problem > > new to 2.55 and if so, what was the previous verion of mh where you did > not > > see the problem and what is your mh.ini sound_program parm set to? > > > > Bruce > > > > > > > > ________________________________________________________ > > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > > > > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Ron K. <ro...@za...> - 2001-07-30 20:39:29
|
Is this the reason the fork() return codes still fail as mentioned in my last e-mail???: Why doesn't open() return an error when a pipe open fails? Because the pipe open takes place in two steps: first Perl calls fork() to start a new process, then this new process calls exec() to run the program you really wanted to open. The first step reports success or failure to your process, so open() can only tell you whether the fork() succeeded or not. To find out if the exec() step succeeded, you have to catch SIGCHLD and wait() to get the exit status. You should also catch SIGPIPE if you're writing to the child--you may not have found out the exec() failed by the time you write. This is documented in the perlipc manpage. In some cases, even this won't work. If the second argument to a piped open() contains shell metacharacters, perl fork()s, then exec()s a shell to decode the metacharacters and eventually run the desired program. Now when you call wait(), you only learn whether or not the shell could be successfully started. Best to avoid shell metacharacters. On systems that follow the spawn() paradigm, open() might do what you expect--unless perl uses a shell to start your command. In this case the fork()/exec() description still applies. ----------- If I understand correctly change the SIGCHLD IGNORE to: SIGCHLD and wait() to get the exit status Regards, Ron. BTW: Sorry if this is gonna be a long thread, but I can stand it if something doesn't work the way it should ;) ----- Original Message ----- From: "Ron Klinkien" <ro...@za...> To: <mis...@li...> Sent: Monday, July 30, 2001 9:53 PM Subject: Re: [misterhouse-users] Return code of system and exec wrong? > Hi Bruce, > > For a change I reply on my own mail. ;-) > > I have been looking at the system() return code problem, > and found at least the reason why the older routine of > simply calling system() to play a sound also failed. > > system("$config_parms{sound_program} $file &"); > > When printing the $! of this system call I got: > > No child processes > > It returned this error because of line 483 in bin/mh: (v2.55) > $SIG{CHLD} = 'IGNORE'; # So we don't create zombies when > forking > > If you put an # infront, the return code of the system calls are 0 which is > good ;) > > Maybe thats the reason this gave problems on OS X as you mentioned in the > comments? > > It doesn't solve the original new soundplay code using "exec qq" though. > I get "Resource temporarily unavailable" as #! text. > > But it has to be the same kind of trick I guess since a clean play.pl with > the same code works ok. > > > Reading a page on perl return codes ( > http://www.weird-wonderful.com/p5be/ch13.cfm ) > gave me the idea it's not that reliable in every situation. > > Regards, > Ron. > > BTW: I'm running perl, version 5.005_03 built for i386-freebsd > > ----- Original Message ----- > From: "Ron Klinkien" <ro...@za...> > To: <mis...@li...> > Sent: Monday, July 30, 2001 3:04 PM > Subject: Re: [misterhouse-users] Return code of system and exec wrong? > > > > Hi Bruce, > > > > As you advised I tried the simple /mh/bin/play command instead of waveplay > > (which is just a small tool to play .wav files, it also does some checks > on > > the > > bitrate of the sound etc). > > > > But play has the same problem, it plays the sound ok, but when executed > > from perl it return a wrong return code (!=0) so MH tries it again... > > > > It's not only the play command which has this problem but also the date > > command > > called when syncing clocks from the inet. Which results in: > > "System clock NOT adjusted due to time command error."s > > > > If I use the same perl code in a single play.pl and run that, it returns > the > > correct rc.(0) > > But if I use that code in /mh/bin/mh it goes wrong. > > ------ > > #!/usr/bin/perl > > my $pid = fork; > > if (defined $pid && $pid == 0) { > > exec qq[/mh/bin/play /mh/sounds/sound_click2.wav]; > > die 'cant exec $config_parms{sound_program}'; > > } > > print $?; > > ------ > > > > > > It has nothing todo with the specific sound play code, but all exec's > (which > > is > > only used a few times) have this problem. > > > > With some perl commands you have to use >>8 tricks to get the right return > > code. > > (see perldoc site). > > > > I have the feeling it has todo with some perl startup params/stack when > used > > with mh. > > Maybe a shell environment which is incorrect so all exec's fail. > > > > I will try some more things later today. > > > > Regards, > > Ron. > > > > ----- Original Message ----- > > From: "Bruce Winter" <br...@mi...> > > To: <mis...@li...> > > Sent: Monday, July 30, 2001 12:07 AM > > Subject: RE: [misterhouse-users] Return code of system and exec wrong? > > > > > > > > > > Just now getting back to this post from a few weeks ago ... > > > > > > > When my MH plays a sound I says it failed doing it > > > > and tries it again a few times until it gives up. > > > > > > > > It _does_ play the sound, (5 times) but the return code is > > > > wrong so it tries it again and again. > > > > > > > > The MH console lists this: > > > > running: waveplay -s ./../sounds/sound_click2.wav > > > > Waiting to play sound file, pass=4 file=./../sounds/sound_click2.wav > > > > running: waveplay -s ./../sounds/./../sounds/sound_click2.wav > > > > Waiting to play sound file, pass=3 > > > > file=./../sounds/./../sounds/sound_click2.wav > > > > running: waveplay -s > > ./../sounds/./../sounds/./../sounds/sound_click2.wav > > > > Waiting to play sound file, pass=2 > > > > file=./../sounds/./../sounds/./../sounds/sound_click2.wav > > > > running: waveplay -s > > > > ./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > > > > Waiting to play sound file, pass=1 > > > > file=./../sounds/./../sounds/./../sounds/./../sounds/sound_click2.wav > > > > running: waveplay -s > > > > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > > > > click2.wav > > > > Gave up trying to play sound file: > > > > ./../sounds/./../sounds/./../sounds/./../sounds/./../sounds/sound_ > > > > click2.wav > > > > > > > > So there is also a bug which appends the same sound path again and > > again. > > > > > > > > > I just fixed this the path prepending problem (by adding a -e $file > test), > > > but I don't think that is causing the repeated sound problem, as it is a > > > valid path. > > > > > > > > > > This code snipped returns the wrong return code: (bin/mh in play > > > > subroutine) > > > > > > > > my $pid = fork; > > > > if (defined $pid && $pid == 0) { > > > > exec qq[waveplay -s /mh/sounds/sound_click2.wav]; > > > > die 'cant exec $config_parms{sound_program}'; > > > > } > > > > > > > > it returns -1 therefore mh thinks it failed. > > > > > > So, the question is what did I change in bin/mh to cause rc=-1 when > > calling > > > waveplay. Can you try mh/bin/play, instead of waveplay? I don't see > > the > > > problem here when using play. What is waveplay and what is it's > > advantage? > > > > > > Looks like there are 4 of you who reported this problem. Was the > problem > > > new to 2.55 and if so, what was the previous verion of mh where you did > > not > > > see the problem and what is your mh.ini sound_program parm set to? > > > > > > Bruce > > > > > > > > > > > > ________________________________________________________ > > > To unsubscribe from this list, go to: > > http://sourceforge.net/mail/?group_id=1365 > > > > > > > > > ________________________________________________________ > > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > > > > > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |