Bug#369488: quodlibet: Fails to play some mp3s with new gstreamer 0.10.6
On 01.06.2006 um 18:41:03 +0200, Loïc Minier wrote: It was brought to my attention that you reported the bug with gstreamer0.10-plugins-good0.10.2-1, could you please pick 0.10.3-2 from unstable and try again? Thanks, with the new gstreamer0.10-plugins-good it finally works. Regards, Matthias signature.asc Description: Digital signature
Bug#369488: quodlibet: Fails to play some mp3s with new gstreamer 0.10.6
On 01.06.2006 um 09:28:49 +0200, Loïc Minier wrote: Could you please provide the first 500k of a problematic MP3? As produced by e.g. head --bytes=500k foo.mp3 foo-header.mp3. I extraced the first 500k, but they are actually played back without problems. So I think the problem is the ID3 tag. I resaved the tags in BMP -- which played the file -- and now the failing file works in quodlibet, too. So I compared the ID3 tag of a failing file from the same album with the resaved one: $ tail -c 128 failing.mp3 [output: see attachement faling.id3] $ tail -c 128 working.mp3 [see attachement working.id3] The main difference is that the failing ID3 tag is padded with spaces (0x20), the working one with zeros (0x00). Also the last character is 0x01 for the working file and 0x02 for the failing one. How can I provide more info on this as I probably can't send you the whole mp3 beacause of copyright restrictions? Regards, Matthias failing.id3 Description: Binary data working.id3 Description: Binary data signature.asc Description: Digital signature
Bug#369488: quodlibet: Fails to play some mp3s with new gstreamer 0.10.6
On 01.06.2006 um 10:29:19 +0200, Loïc Minier wrote: Yeah, it's usually a problem with tags. I'm surprized it doesn't appear in the first 500k though. Could you try producing a minimalist file which is still a playable MP3 but exposes the problem? The problem only appears when the ID3v1 tag at the end of the file is present. Even at head -c 10k it is recognized (there isn't any tag at the beginning of the file anyway). It even plays when I only strip the last byte of the file with the v1 tag, but then quodlibet doesn't display the ID3 information, of course. I should also make clear that this bug only appears when I upgrade libgstreamer0.10-0 to 0.10.6, so it's probably not a bug in gstreamer0.10-plugins-base. Perhaps you can point at the tool which produced the file and tell me how to reproduce instead? I created the failing files in 2000 with a combination of cdparanoia and gogo. At least that's what the comment tag says. Regards, Matthias signature.asc Description: Digital signature
Bug#369488: quodlibet: Fails to play some mp3s with new gstreamer 0.10.6
On 01.06.2006 um 14:07:59 +0200, Loïc Minier wrote: Well, perhaps you can take a free MP3 of some sort and make it have the same symptoms. If we don't have a sample file to test with, I'm afraid it will be hard to fix the problem. OK, here is a small mp3 file which is provided by GNOME as a wav file. I also now remember the tool I used to tag the failing files: It's a small program I wrote back in 2000 to read and write ID3v1 tags (http://sourceforge.net/projects/mp3tool). After tagging the freshly converted file gnomemeeting.mp3, quodlibet doesn't play it anymore. Without the tag it plays nicely. Unfortunately, I can't track down the error any further. I tried replacing all padded spaces in the tag with 0x00, but without success. Also, setting only byte 29 of the comment tag to 0x00 and byte 30 to some tracknumber as specified by IDv1 v1.1 didn't help. Regards, Matthias gnomemeeting.mp3 Description: audio/mpeg signature.asc Description: Digital signature
Bug#369488: quodlibet: Fails to play some mp3s with new gstreamer 0.10.6
Shall I forward or reassign this bug to libgstreamer0.10-0? Regrads, Matthias signature.asc Description: Digital signature
Bug#369488: quodlibet: Fails to play some mp3s with new gstreamer 0.10.6
Package: quodlibet Version: 0.20.1-1 Severity: important After an upgrade to libgstreamer 0.10.6 yesterday quodlibet fails to play some mp3s, but plays others. I haven't found a pattern which one it likes and which one it doesn't, yet. The actual error box says: Unable to play song GStreamer was unable to load the selected song. GStreamer encountered a general stream error. Maybe this should be a gstreamer bug, but I'm not sure. Downgrading to libgstreamer 0.10.5 fixes the bug. Regrads, Matthias -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages quodlibet depends on: ii exfalso 0.20.1-1 audio tag editor for GTK+ ii gstreamer0.10-plugins-base0.10.7-2 GStreamer plugins from the base ii gstreamer0.10-plugins-good0.10.2-1 GStreamer plugins from the good ii gstreamer0.10-plugins-ugly0.10.3-1 GStreamer plugins from the ugly ii python2.3.5-5An interactive high-level object-o ii python-gst0.100.10.2-1 generic media-playing framework (P Versions of packages quodlibet recommends: ii gstreamer0.10-alsa0.10.7-2 GStreamer plugin for ALSA ii gstreamer0.10-gnomevfs0.10.7-2 GStreamer plugin for GnomeVFS pn python-feedparser none (no description available) ii quodlibet-ext 0.20.1-1 extensions for the Quod Libet audi -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369488: quodlibet: Fails to play some mp3s with new gstreamer 0.10.6
On 30.05.2006 um 03:04:56 -0500, Joe Wreschnig wrote: What happens if you run $ gst-launch-0.10 playbin uri=file:///path/to/file.mp3 With a non-working mp3: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FEHLER: Von Element /playbin0/source: Internal data flow error. Zusätzliche Debugginginformation: gstbasesrc.c(1510): gst_base_src_loop (): /playbin0/source: streaming task paused, reason not-negotiated ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... FREEING pipeline ... And with a working on: Setting pipeline to PAUSED ... OIL: ERROR liboiltest.c 403: oil_test_check_impl(): function merge_linear_u8_sse2 in class merge_linear_u8 failed check (7431 0) || (outside=0) OIL: ERROR liboiltest.c 403: oil_test_check_impl(): function merge_linear_u8_mmx in class merge_linear_u8 failed check (7871 0) || (outside=0) Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock2 Caught interrupt -- Pausing pipeline. Pipeline paused. WARNING: Element playbin0 warns: pipeline interrupted Element playbin0 has gone from PLAYING to PAUSED, quitting. Execution ended after 5752558000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... I interrupted the working one by hand. Regards, Matthias signature.asc Description: Digital signature
Bug#368354: Patch for NMU of beagle 0.2.6-1
Hello Frederik! On Sun, May 21, 2006 at 04:44:44PM +0200, Frederik Schueler wrote: Package: beagle diff -u beagle-0.2.6/debian/changelog beagle-0.2.6/debian/changelog --- beagle-0.2.6/debian/changelog +++ beagle-0.2.6/debian/changelog @@ -1,3 +1,11 @@ +beagle (0.2.6-1.1) unstable; urgency=low + + * Non-Maintainer upload. + * Add Build-depends: libmono-sharpzip0.6-cil and +libmono-sqlite1.0-cil (Closes: #266229) Shouldn't this read #366229? Regards, Matthias signature.asc Description: Digital signature
Bug#365572: vim-latexsuite: Screen not redrawn after compilation via \ll
Package: vim-latexsuite Version: 20060325-1 Severity: minor Hello After recompilation of my LaTeX files via \ll inside a terminal running vim, the terminal content is not redrawn and only one line of text shows up. After pressing Ctrl+l everything shows up normally again. This doesn't happen with gvim. Regards, Matthias -- Package-specific info: Vim related packages installed on this system: - vim-latexsuite -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages vim-latexsuite depends on: ii python 2.3.5-5 An interactive high-level object-o ii vim 1:6.4-007+1 Vi IMproved - enhanced vi editor ii vim-common 1:6.4-007+1 Vi IMproved - Common files ii vim-full [gvim] 1:6.4-007+1 Vi IMproved - enhanced vi editor - ii vim-gnome [gvim] 1:6.4-007+1 Vi IMproved - enhanced vi editor - Versions of packages vim-latexsuite recommends: ii tetex-bin 3.0-16 The teTeX binary files -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365152: vim-latexsuite: F9 doesn't work
Package: vim-latexsuite Version: 20060325-1 Severity: normal Hello! When pressing F9 inside a \ref, vim-latexsuite should offer the matches for the typed key. Instead, it durrently pours some Python errors on me: File string, line 1, in ? File /usr/share/vim/addons/ftplugin/latex-suite/outline.py, line 170, in main contents = getFileContents(root, ext) File /usr/share/vim/addons/ftplugin/latex-suite/outline.py, line 27, in getFileContents contents = re.sub(pat, lambda input: getFileContents(input, ext), contents) File /usr/lib/python2.3/sre.py, line 143, in sub return _compile(pattern, 0).sub(repl, string, count) File /usr/share/vim/addons/ftplugin/latex-suite/outline.py, line 27, in lambda contents = re.sub(pat, lambda input: getFileContents(input, ext), contents) File /usr/share/vim/addons/ftplugin/latex-suite/outline.py, line 23, in getFileContents contents = '\n'.join(open(fname).read().splitlines()) IOError: [Errno 2] Datei oder Verzeichnis nicht gefunden: 'kap1.tex.tex' Zeile 29: Traceback (most recent call last): File string, line 1, in ? NameError: name 'retval' is not defined Zeile 31: E121: Variable nicht definiert: retval The file I was editing is called kap1.tex and the Python script seems to append .tex to the filename, but kap1.tex.tex doesn't exist. Is there any other info I can provide? I can't remember seeing this error before a recent upgrade to version 20060325-1. Regards, Matthias -- Package-specific info: Vim related packages installed on this system: - vim-latexsuite -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.4 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages vim-latexsuite depends on: ii python 2.3.5-5 An interactive high-level object-o ii vim 1:6.4-007+1 Vi IMproved - enhanced vi editor ii vim-common 1:6.4-007+1 Vi IMproved - Common files ii vim-full [gvim] 1:6.4-007+1 Vi IMproved - enhanced vi editor - ii vim-gnome [gvim] 1:6.4-007+1 Vi IMproved - enhanced vi editor - Versions of packages vim-latexsuite recommends: ii tetex-bin 3.0-16 The teTeX binary files -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365152: vim-latexsuite: F9 doesn't work
Hello Franz, On 28.04.2006 um 13:56:51 +0200, Franz Pletz wrote: If everything works as expected there will be a new revision soon as there's another patch pending, too. I'll also notify upstream about this issue. Thanks for the patch. It works for me. Matthias signature.asc Description: Digital signature
Bug#353689: Patch available
Hello Just for the records. Upstream knows about this bug, at least there is a similar bug report at http://bugzilla.gnome.org/show_bug.cgi?id=318300. Attached to this report is a patch, but until now it seems the bug is being ignored by upstream. Greetings, Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353689: pygtk: import gtk fails
Package: pygtk
Severity: important
Applications using pygtk fail to import gtk after doing
import pygtk
pygtk.require('2.0').
The actual error is
[EMAIL PROTECTED]:~$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on linux2
Type help, copyright, credits or license for more information.
import pygtk
pygtk.require('2.0')
import gtk
Traceback (most recent call last):
File stdin, line 1, in ?
ImportError: No module named gtk
The problem seems to be related to pygtk.py first removing any pygtk
dirs on lines 77-79 in pygtk.require and then prepending paths in
_get_available_version(). Before calling pygtk.require('2.0') sys.path
looks like
import sys;print sys.path
['', '/usr/lib/python23.zip', '/usr/lib/python2.3',
'/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk',
'/usr/lib/python2.3/lib-dynload',
'/usr/local/lib/python2.3/site-packages',
'/usr/lib/python2.3/site-packages',
'/usr/lib/python2.3/site-packages/Numeric',
'/usr/lib/python2.3/site-packages/PIL',
'/usr/lib/python2.3/site-packages/cairo',
'/usr/lib/python2.3/site-packages/gtk-2.0'],
but after require() it becomes
pygtk.require('2.0')
import sys;print sys.path
['/usr/local/lib/python2.3/site-packages/gtk-2.0', '',
'/usr/lib/python23.zip', '/usr/lib/python2.3',
'/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk',
'/usr/lib/python2.3/lib-dynload',
'/usr/local/lib/python2.3/site-packages',
'/usr/lib/python2.3/site-packages',
'/usr/lib/python2.3/site-packages/Numeric',
'/usr/lib/python2.3/site-packages/PIL',
'/usr/lib/python2.3/site-packages/cairo'].
I recently installed a package in /usr/local (leaftag:
http://www.chipx86.com/wiki/Leaftag), but pygtk shouldn't ignore any
other gtk-2.0 directories, namely
/usr/lib/python2.3/site-packages/gtk-2.0, because of this. Is this
behaviour intended and leaftag shouldn't install itself in
/usr/local/lib/python2.3/site-packages/gtk-2.0?
Greetings,
Matthias
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.4
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
