in reply to Managing and sending signals to control MPG321

I will not comment on your code, I like the idea of suspending jobs, but it would be better to use mpg321 remote interface, it's simpler and IMHO much more cleaner. If you really need to suspend execution, you could save the player status and restore it later, it's not difficult using one of the available modules on CPAN; I would start from Audio::Daemon::MPG123, Audio::Play::MPG123 or MP3::Daemon.

Ciao, Valerio

  • Comment on Re: Managing and sending signals to control MPG321

Replies are listed 'Best First'.
Re^2: Managing and sending signals to control MPG321
by dabreegster (Beadle) on Apr 04, 2005 at 22:35 UTC
    I found my bug. When I forked and exec()ed, a sh instance was created so the & 2> /dev/null bit could be done. The mpg321 instance lived in a totally different process. I fixed it to not use the shell and it works great. I do have a small problem reaping the zombie children, though. If I have $SIG{CHLD} set to 'IGNORE', like it says in the Camel Book, then it'll reap 'em automatically, but I can't put in my own code to pop @PIDs. I tried the two loops given in the documentation, but they don't seem to work. Any clues? I'll check out the remote interface.