Rip only mode. No playback.

[rig9919]

I think a nice config option would be a way to disable audio output so it could be a dedicated ripper program instead of having to mute it. I have a temporary workaround I'm using but I am not a programmer so hopefully a real option can be put in. My temporary workaround is this.

player.c lines 227-235 and 399-406

player->audioOutDevice = NULL;
//if ((player->audioOutDevice = ao_open_live (audioOutDriver,
//      &format, NULL)) == NULL) {
//  /* we're not interested in the errno */
//  player->aoError = 1;
//  BarUiMsg (player->settings, MSG_ERR,
//          "Cannot open audio device\n");
//  return WAITRESS_CB_RET_ERR;
//}

[ghost]

Similarly I would like an option to disable ripping. Because of the library names we can't have both a plain pianobar and a pianobarfly installed side by side unless they are compiled static. But I don't always want to rip and I don't always want to listen. For instance when I rip I donvt want to fill up the tiny ssd on my Vaio P. So if I'm at home I'll rip to a network share. Or sometimes I'll rip to a 32g usb thumb drive that normally goes in my car stereo. But often I'm neither at home nor have the usb drive from the car, so those times I just don't want to rip.

It's not exactly the end of the world having to have an extra pianobar binary, compiled static, and duplicate menu entries in the desktop, and duplicate config files, but it would be nice to have just one program that can handle both use cases.

[nega0]

Long overdue update to this issue...

After looking into it @rig9919, I'm not going to create an option to "record but not listen".

1. That's not the point of a service like Pandora
2. There's no way to pragmatically control the volume using libao
3. The only way to fudge that is to use the "null" device in libao, but that pulls the stream in at line speed. That isn't nice. (See point 1)

As for @aljex 's "listen but don't record", that's currently sitting on the norecord branch

[fengshaun]

the branch looks abandoned :( fix here: #66