<div class="gmail_quote">2010/1/23 Tim-Philipp Müller <<a href="mailto:t.i.m@zen.co.uk">t.i.m@zen.co.uk</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Fri, 2010-01-22 at 21:27 +0100, Pascal Ognibene wrote: Hi, > I'm trying to rip a CD using a simple gstreamer pipeline (..) <div class="im">> In the code below, I basically use the EOS event to seek to the next > cd track. > But the behavior I see is weird: > -the first track is ripped ok > -I call the start_track_rip function for track 2 > -the program blocks here forever. > > I must be doing something really wrong but I can't see what, even by > the looking at the sources of sound juicer for example. > Any help is welcome, </div>Not related to your problem at all, but you might want to add a queue after cdparanoiasrc to make sure encoding continues if there are problems reading the CD (dirt on the disc etc.). I haven't actually run your code, but it looks to me like you get an EOS and then change the track number via the property and that's it. However, when you get the EOS, streaming has already stopped, cdparanoiasrc is not running any longer. At that point, setting the property will not make it start up again. You have two options here: a) set pipeline state back to READY (or NULL), then change to PLAYING again. b) issue a seek in "track" format (track number might be 0-based in this case, don't remember exactly) to make it start up again. (b) might work in this particular case where you're just writing mp3 data to a file, but (a) is likely to work better in general, esp. with other encoders, if you add muxers or if you add a tag writer. So in short, try changing <div class="im"> gst_element_set_state(sink, GST_STATE_NULL); </div>at the beginning of start_track_rip() to <div class="im"> gst_element_set_state(pipeline, GST_STATE_NULL);</div></blockquote></div> Thank you for your help! Actually, I stepped through the Sound Juicer code using gdb, and discovered that they destroy and recreate the pipeline for each track they rip. I've done the same, and it works fine. I'll try your solution as well to see if i can get faster seek operations between tracks. Oh, and I'm going to add a queue in the middle as per your excellent suggestion - I've been testing with a brand new CD so did not meet rip glitches yet, but this will happen for sure in "real life". Cheers, -pog