always failing after ripping first track

[https://www.google.com/accounts/o8/id?id=aitoawkcsg5vglvfjkmtabu3mp_lxdvhn_-xcxo]

attached console-output and log
I'm able to determine offset for both of my drives
rip cd rip allways fails with the following
I'm running debian testing with python2.6
installed morituri 0.1.1 by apt-get from the repos

[https://www.google.com/accounts/o8/id?id=aitoawkcsg5vglvfjkmtabu3mp_lxdvhn_-xcxo]

console output of rip cd rip

[https://www.google.com/accounts/o8/id?id=aitoawkcsg5vglvfjkmtabu3mp_lxdvhn_-xcxo]

problem is not drive-dependent and nothing with privileges (even tried to sudo rip) please help

[http://thomasvs.myopenid.com/]

Could you give me a full log with RIP_DEBUG=5 set ?

If you tried other drives, what offset ?

[https://www.google.com/accounts/o8/id?id=aitoawkcsg5vglvfjkmtabu3mp_lxdvhn_-xcxo]

Replying to http://thomasvs.myopenid.com/:

Could you give me a full log with RIP_DEBUG=5 set ?

If you tried other drives, what offset ?

just answering the mail didn't work, anyway...

RIP_DEBUG=5 rip cd rip -o 6 >rip_fail_log 2>&1
(find it attached)

drive: /dev/sr0,

vendor: TSSTcorp, model: DVD-ROM SH-D162C, release:TS04

Read offset of device is: 6.

drive: /dev/sr1,

vendor: HL-DT-ST, model: DVDRAM GH22LS50 , release:TL00

Read offset of device is: 667.

[https://www.google.com/accounts/o8/id?id=aitoawnzhdv0n_b2off8zxxgflik9he5i4c7xdi]

Could this be a python-gst bug?

The failing line is

length, qformat = sink.query_duration(gst.FORMAT_DEFAULT)

However the latest python-gst docs suggest that query_duration should take two arguments, one for the format and the other a location for the duration (see  here). I've changed the line to:

length, qformat = sink.query_duration(gst.FORMAT_DEFAULT, None)

Which is what the docs suggest, yet this fails too.

[https://www.google.com/accounts/o8/id?id=aitoawkdv-ucttktndvnwnnqe2_kj6imsic5uu8]

I have the same problem (cannot rip any CD, fails at the end of first track with the same error) on Ubuntu 11.04 while the same version of morituri (0.1.1) worked without any problem on Ubuntu 10.10.
The current version of python-gst is 0.10.21-1, while the older one was 0.10.19-2, if it can be useful.

[https://www.google.com/accounts/o8/id?id=aitoawnzhdv0n_b2off8zxxgflik9he5i4c7xdi]

Python-gst might be a red-herring. I've manually downgraded to 0.10.19 and I'm still getting the error.

[http://thomasvs.myopenid.com/]

I know I fixed some bugs after releasing 0.1.1 related to this. There is definitely better debug output in case it fails.

Can I get you to try with current SVN trunk, as I am in the process of readying a new release ?

[https://www.google.com/accounts/o8/id?id=aitoawnzhdv0n_b2off8zxxgflik9he5i4c7xdi]

Added output of RIP_DEBUG=5 rip cd rip -o 48 using latest svn (commit 440).

[http://thomasvs.myopenid.com/]

For some reason that's not running the svn code.

The log doesn't show the version number or the revision number, the arguments actually passed to rip, the objects'log name, ...

Are you running this using the morituri-uninstalled script to set the environment ? Or do you have morituri installed system-wide as well ? If you don't use the uninstalled script, make sure you set PYTHONPATH correctly; for example from the svn checkout dir:

PYTHONPATH=pwd rip cd rip -o 48

[https://www.google.com/accounts/o8/id?id=aitoawnzhdv0n_b2off8zxxgflik9he5i4c7xdi]

Apologies, I've done a fresh install from svn and regenerated the log.

[http://thomasvs.myopenid.com/]

Ok, I'm still not sure what's going on. Let's go through some basics.

• can you list package versions of all gstreamer packages ?
• what does gst-inspect flacdec show you ?
• same for gst-inspect appsink ?

I am planning to work on morituri this weekend, any chance you can drop by on IRC on Freenode in #morituri so that we can work this out a little better ?

[https://www.google.com/accounts/o8/id?id=aitoawnzhdv0n_b2off8zxxgflik9he5i4c7xdi]

Gstreamer is the latest debian unstable version, reported as 0.10.34-1.

gstreamer0.10-plugins-base: 0.10.34-1
gstreamer0.10-plugins-good: 0.10.29-2
gstreamer0.10-plugins-bad: 0.10.22-2
gstreamer0.10-plugins-ugly: 0.10.18-1.

Added output of gst-inspect-0.10 flacdec and appsink to attachments.

[https://www.google.com/accounts/o8/id?id=aitoawnzhdv0n_b2off8zxxgflik9he5i4c7xdi]

I'll try and drop by on Freenode sometime this weekend, most likely Sunday.

[https://www.google.com/accounts/o8/id?id=aitoawnfkt2szxtw0hkw4_yj-d9lrmlf69i_szu]

Getting the same issue too, fedora 15, external USB CD drive, morituri svn

[https://www.google.com/accounts/o8/id?id=aitoawnfkt2szxtw0hkw4_yj-d9lrmlf69i_szu]

I'm currently investigating this, what is actually failing is querying the duration of a flac file. I'm trying to figure out what changed in gstreamer.

[https://www.google.com/accounts/o8/id?id=aitoawnfkt2szxtw0hkw4_yj-d9lrmlf69i_szu]

This is caused by the new elements in libgstaudioparsers.so which was added in gst-plugins-good 0.10.29 (most likely the flacparse element). Moving away /usr/lib64/gstreamer-0.10/libgstaudioparsers.so works around this issue.

[https://www.google.com/accounts/o8/id?id=aitoawkdv-ucttktndvnwnnqe2_kj6imsic5uu8]

In my case gst-plugins-good version is 0.10.28. The previous workaround does not work for me, since I don't have any libgstaudioparsers.so on my system.

[https://www.google.com/accounts/o8/id?id=aitoawnfkt2szxtw0hkw4_yj-d9lrmlf69i_szu]

Grmble, openid is crap to identify people :( You must be the ubuntu 11.04 user from comment 5. What gives gst-inspect-0.10 |grep flac ? If there's a flacparse in there, can you check in which .so it is using gst-inspect-0.10 flacparse?

[https://www.google.com/accounts/o8/id?id=aitoawkdv-ucttktndvnwnnqe2_kj6imsic5uu8]

Yes, I am the same user of comment 5.
In the output of gst-inspect-0.10 |grep flac I see this line:
"audioparsersbad: flacparse: FLAC audio parser"
The corresponding .so is /usr/lib/gstreamer-0.10/libgstaudioparsersbad.so, and indeed if I move it away, the issue disappears.

[https://www.google.com/accounts/o8/id?id=aitoawnfkt2szxtw0hkw4_yj-d9lrmlf69i_szu]

I filed  https://bugzilla.gnome.org/show_bug.cgi?id=650785

[https://www.google.com/accounts/o8/id?id=aitoawnfkt2szxtw0hkw4_yj-d9lrmlf69i_szu]

In my C testcase, I can workaround this issue using

registry = gst_registry_get_default();
plugin = gst_registry_find_plugin(registry, "audioparsers");
if (plugin == NULL) {

g_print("Couldn't find flacparse\n");
return 1;

}
gst_registry_remove_plugin(registry, plugin);
gst_object_unref(GST_OBJECT(plugin));

[thomas]

In [482]:

• morituri/common/checksum.py:
• morituri/common/gstreamer.py: Remove audioparsers plugin if it has the known bug. Fixes #64.

[http://thomasvs.myopenid.com/]

For future reference:

audioparsersbad in -bad 0.10.20
	has flacparse
	has rank 0
	no problem
audioparsers in good 0.10.29 (when it was released for first time)
	fails
	fedora 15
Break
	autoplug rank change
	952b27 Mon Aug 16 2010
	first bad after: 0.10.20 (but presumed innocent, f14)
	first bad with the change: 0.10.21 (see release notes)
	moved out of bad in 0.10.22 to good 0.10.29
Fix
	8823ae/1183d0/a53540 mon may 23 2011
	target milestone good 0.10.31
Conclusion
	bad versions
		-bad
			after 0.10.20
			until 0.10.22 (ok)
		-good
			from 0.10.29
			until 0.10.31 (next release)