Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found
On Fri, 2007-04-27 at 09:15 +0200, Sebastian Dröge wrote: > Am Donnerstag, den 26.04.2007, 20:09 -0700 schrieb Joe Wreschnig: > I agree that the fix for this bug was not at all complete and this special > case should be handled too. Is "file://" the only URL that causes a problem > for > you or is quodlibet using "file://blabla/bla" in general? (note that there > are only > two slashes after the colon) > "file://" is not a valid URI, it's only the protocol part of some URI. Then > according > to rfc1738 "file://blabla/bla" corresponds to the location "/bla" on the host > "blabla". Yes, I know; "http://"; is also not a valid URL, but it's what I was told in #gstreamer to use to check for generic HTTP support (whether via gnomevfs or neon), so I assumed that "file://" was similar. Quod Libet hands correctly formed URIs to the playbin to play actual files. > Then, if quodlibet wants to check for the element "filesrc" it should just > check if it > can create a "filesrc" element and not check if there is some random element > that might > support the "file://" protocol. Actually I don't care if there's a filesrc element, I just care if something supports file://. But the error message mentions filesrc because users have no idea what "Get an element that supports file://" means; they have a better idea what "Install filesrc" means, and this has helped people diagnose a lot of broken GStreamer installations in the past. > Apart from that, would you be fine if I just special case "file://" and allow > that as > a valid URI for filesrc as a workaround for this? Yes. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found
reassign 421167 gstreamer0.10 thanks Am Donnerstag, den 26.04.2007, 20:09 -0700 schrieb Joe Wreschnig: > On Thu, 2007-04-26 at 23:21 +0200, Martin wrote: > > Package: quodlibet > > Version: 0.23.1-1 > > Severity: grave > > Justification: renders package unusable > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Quod Libet fails to start, pops up a message saying "Quod Libet could > > not find the 'filesrc' GStreamer element. Check your GStreamer > > installation." It used to work fine before/during the freeze. > > ... > > Versions of packages quodlibet recommends: > > ii gstreamer0.10-alsa0.10.12-2 GStreamer plugin for ALSA > > pn gstreamer0.10-gnomevfs (no description available) > > ^-- This would be why. In 0.10.10 and all previous versions, a filesrc > object would be returned: > > >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") > <__main__.GstFileSrc object () at 0x402076bc> > > Now, in unstable: > >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") > <__main__.GstGnomeVFSSrc object () at 0xb7d6393c> > > And if I remove gstreamer0.10-gnomevfs: > >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") > >>> > > So, filesrc is in fact broken. > > Blah blah API compatibility, blah blah you need unit tests, blah blah, > no one listens to me, blah STOP BREAKING MY SOFTWARE DAMNIT. > > The GStreamer changelog says: > > 2007-02-13 Sebastian Dröge <[EMAIL PROTECTED]> > > * plugins/elements/gstfilesink.c: (gst_file_sink_uri_set_uri): > * plugins/elements/gstfilesrc.c: (gst_file_src_uri_set_uri): > Also check for an absolute path following file:// in the filesrc > element. Remove redundant check and call g_path_is_absolute() on the > unescaped location. > > Sebastian, do you understand what an API is, and why changes like that > ARE NOT ALLOWED, especially in point releases? Sure, this was just to break the software of Joe Wreschnig. Could you please calm down so we can talk about how to get this fixed properly? Thanks First lets get this change in the correct context, this is only a continuation of another change by Sébastien Moutte: > 2007-02-10 Sébastien Moutte <[EMAIL PROTECTED]> > * plugins/elements/gstfilesrc.c:(gst_file_src_uri_set_uri): > Fix a bug on Windows in uri format check. Now the prefix checked > is file:// and next we check if the path after file:// is absolute. which OTOH is a fix needed for my first change in that direction: > 2007-02-02 Sebastian Dröge <[EMAIL PROTECTED]> > > reviewed by: Wim Taymans <[EMAIL PROTECTED]> > > * plugins/elements/gstfilesink.c: (gst_file_sink_uri_set_uri): > * plugins/elements/gstfilesrc.c: (gst_file_src_uri_set_uri): > Allow file://localhost/foo/bar URLs and correctly fail for every other > hostname that one sets. This was gnomevfssrc is linked for those if > installed as it can handle it (#403172) As you can see this change wasn't only decided by me and it also wasn't intentional that it breaks things in that way. Also please read the corresponding upstream bugreport. I agree that the fix for this bug was not at all complete and this special case should be handled too. Is "file://" the only URL that causes a problem for you or is quodlibet using "file://blabla/bla" in general? (note that there are only two slashes after the colon) "file://" is not a valid URI, it's only the protocol part of some URI. Then according to rfc1738 "file://blabla/bla" corresponds to the location "/bla" on the host "blabla". Then, if quodlibet wants to check for the element "filesrc" it should just check if it can create a "filesrc" element and not check if there is some random element that might support the "file://" protocol. Apart from that, would you be fine if I just special case "file://" and allow that as a valid URI for filesrc as a workaround for this? "file://blabla/bla" would still not be handled and this could be argued as an API change too. Not that using an "file://blabla/bla" URI worked before but you could at least set it on the element and the same applies for "file://" too btw I talked with Wim about this on IRC now and he also has the opinion that a) file:// is simply not a valid URI but b) that this needs to be fixed by special casing the file:// URI for API stability reasons only. I'll change that in CVS for now and also upload a new gstreamer0.10 package with that change. If there's still an issue then please first calm down and then file a bug against the relevant package. Bye PS: For better checking if an URI protocol is support by any element I'll also add a gst_uri_protocol_is_supported() function later btw... signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Processed: Re: Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found
Processing commands for [EMAIL PROTECTED]: > reassign 421167 gstreamer0.10 Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found Bug reassigned from package `quodlibet' to `gstreamer0.10'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found
On Thu, 2007-04-26 at 23:21 +0200, Martin wrote: > Package: quodlibet > Version: 0.23.1-1 > Severity: grave > Justification: renders package unusable > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Quod Libet fails to start, pops up a message saying "Quod Libet could > not find the 'filesrc' GStreamer element. Check your GStreamer > installation." It used to work fine before/during the freeze. > ... > Versions of packages quodlibet recommends: > ii gstreamer0.10-alsa0.10.12-2 GStreamer plugin for ALSA > pn gstreamer0.10-gnomevfs (no description available) ^-- This would be why. In 0.10.10 and all previous versions, a filesrc object would be returned: >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") <__main__.GstFileSrc object () at 0x402076bc> Now, in unstable: >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") <__main__.GstGnomeVFSSrc object () at 0xb7d6393c> And if I remove gstreamer0.10-gnomevfs: >>> gst.element_make_from_uri(gst.URI_SRC, "file://", "") >>> So, filesrc is in fact broken. Blah blah API compatibility, blah blah you need unit tests, blah blah, no one listens to me, blah STOP BREAKING MY SOFTWARE DAMNIT. The GStreamer changelog says: 2007-02-13 Sebastian Dröge <[EMAIL PROTECTED]> * plugins/elements/gstfilesink.c: (gst_file_sink_uri_set_uri): * plugins/elements/gstfilesrc.c: (gst_file_src_uri_set_uri): Also check for an absolute path following file:// in the filesrc element. Remove redundant check and call g_path_is_absolute() on the unescaped location. Sebastian, do you understand what an API is, and why changes like that ARE NOT ALLOWED, especially in point releases? -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found
On Thu, 2007-04-26 at 23:21 +0200, Martin wrote: > Package: quodlibet > Version: 0.23.1-1 > Severity: grave > Justification: renders package unusable > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Quod Libet fails to start, pops up a message saying "Quod Libet could > not find the 'filesrc' GStreamer element. Check your GStreamer > installation." It used to work fine before/during the freeze. Sounds like something in GStreamer changed. QL actually tries to create that element by checking the result of gst.element_make_from_uri(gst.URI_SRC, "file://", ""), which previously returned whatever element would handle a file URL. We didn't actually care what it was, as long as it existed (filesrc is just the most common / only? one). I can't reproduce this, but you're the third person I've heard it from and across three distros. This is a grave GStreamer bug. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Bug#421167: quodlibet: fails to start, claiming 'filesrc' cannot be found
Package: quodlibet Version: 0.23.1-1 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Quod Libet fails to start, pops up a message saying "Quod Libet could not find the 'filesrc' GStreamer element. Check your GStreamer installation." It used to work fine before/during the freeze. ~$ gst-launch filesrc location="$SOME_MUSIC_FILE" \! decodebin \! audioconvert \! audioresample \! alsasink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstAudioSinkClock [ music plays ] gst-launch-0.10 produces an identical result. - -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.4 Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages quodlibet depends on: ii exfalso 0.23.1-1 audio tag editor for GTK+ ii gstreamer0.10-plugins-base0.10.12-2 GStreamer plugins from the "base" ii gstreamer0.10-plugins-good0.10.4-4 GStreamer plugins from the "good" ii gstreamer0.10-plugins-ugly0.10.4-5 GStreamer plugins from the "ugly" ii python2.4.4-2An interactive high-level object-o ii python-central0.5.13-0.1 register and build utility for Pyt ii python-gst0.100.10.5-5 generic media-playing framework (P Versions of packages quodlibet recommends: ii gstreamer0.10-alsa0.10.12-2 GStreamer plugin for ALSA pn gstreamer0.10-gnomevfs (no description available) pn python-feedparser (no description available) pn quodlibet-ext (no description available) - -- no debconf information * Please note: the above e-mail address is temporary, and will be retired when it starts to attract too much spam. Use gpg to find me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRjEXZs7AYWSCevCcAQJGSwf/UKepxa6K+/kyX+vrdrr+bkuSZ0nmnbQ9 1fBVyEke6QrUfpRmr1pJGT+bYkzvkv+dSo8uhuV1j+tlziIHMHuiJ8nZmjIkWOr5 6uSSDgzkSxVXKpZvtY9rXCUSx63VtgQTssaipqUt57Dne17CZeyryLMOEiSV/33H c1oH2zvLUNy3K2vKaOrd2XIBGIAS0HlqYwIn0XMNuLwLVZB57y0g+ksN3pq8DWba w8yyvKcPHqOUHscJFeHzBswLigdievQAZ5huwgFsHsv4V3fi5Y+MYE9P3d79A8Rt 0lOtlkwwSH5N7Gr9DgIEi9wx4GI6wDY3rht5OxqKbut4auIlnyTkkA== =jWaB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
