[Bug 1886326] Re: gnome-terminal does not retain maximised size when external monitor goes into power save
This problem seems to be even worse with a 4K monitor set to 200% scaling. When I follow the procedure above with such a monitor, maximised terminal windows appear to end up twice the width and height of the screen. :( -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1886326 Title: gnome-terminal does not retain maximised size when external monitor goes into power save To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1886326/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1886326] [NEW] gnome-terminal does not retain maximised size when external monitor goes into power save
Public bug reported: Description:Ubuntu 20.04 LTS Release:20.04 with standard Ubuntu Gnome desktop. ii gnome-terminal 3.36.2-1ubuntu1~20.04 amd64GNOME terminal emulator application ii gnome-terminal-data 3.36.2-1ubuntu1~20.04 all Data files for the GNOME terminal emulator ii libvte-2.91-0:amd64 0.60.3-0ubuntu1~20.04 amd64Terminal emulator widget for GTK+ 3.0 - runtime files ii libvte-2.91-common 0.60.3-0ubuntu1~20.04 amd64Terminal emulator widget for GTK+ 3.0 - common files Steps to reproduce: 1. Have laptop with 1920x1080 display, but closed so the display is not being used. 2. Have external 1920x1200 monitor connected via HDMI. 3. Open gnome-terminal and maximise it. 4. Press Windows+L to lock screen. 5. Leave computer locked for long enough for the monitor to go into power save. 6. Unlock. 7. Notice that gnome-terminal window no longer covers the whole screen - a 120 pixel bar of the desktop is visible at the bottom of the screen. 8. Double click on the gnome-terminal title bar in an attempt to maximise the window and discover that the window gets smaller (because it thought it was already maximised.) 9. Double click on the gnome-terminal title bar again and the window is then maximised correctly. Expected result: The gnome-terminal window remains maximised covering the whole screen at step 7. (However, if I were to unplug the external monitor and start using the laptop display I would expect the window to remain maximised but resized to cover the smaller display.) I suspect that this problem can be reproduced with any two differing display sizes. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-terminal 3.36.2-1ubuntu1~20.04 ProcVersionSignature: Ubuntu 5.4.0-39.43-generic 5.4.41 Uname: Linux 5.4.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.3 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Sun Jul 5 15:47:50 2020 InstallationDate: Installed on 2020-04-18 (78 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal wayland-session ** Summary changed: - gnome-terminal does not re-maximise when display size changes + gnome-terminal does not retain maximised size when external monitor goes into power save -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1886326 Title: gnome-terminal does not retain maximised size when external monitor goes into power save To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1886326/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 373325] Re: Evolution could deal better with characters in windows-1252 but not iso-8859-1
Submitted to Gnome Bugzilla as bug #582678: http://bugzilla.gnome.org/show_bug.cgi?id=582678 ** Bug watch added: GNOME Bug Tracker #582678 http://bugzilla.gnome.org/show_bug.cgi?id=582678 -- Evolution could deal better with characters in windows-1252 but not iso-8859-1 https://bugs.launchpad.net/bugs/373325 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 373325] [NEW] Evolution could deal better with characters in windows-1252 but not iso-8859-1
Public bug reported: Binary package hint: evolution Ubuntu 9.04. evolution 2.26.1-0ubuntu1 I'm using the Exchange connector but I doubt that this affects Evolution's behaviour. I received a multi-part HTML email from another user of the same Exchange server. Despite the HTML part starting with Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable it contained the quoted character =92 which is the windows-1252 code for a curly quote. This appeared in Exchange as a character not available in font box containing 0092. Of course this is clearly Exchange or Outlook's fault for claiming iso-8859-1 but then using windows-1252 characters. But having said that, it would seem to be quite easy for Evolution to work around this and show the expected glyph. The characters in that range are considered to be control characters in iso-8859-1 and could therefore be automatically mapped to their corresponding Unicode code points based on the windows-1252 encoding. See http://en.wikipedia.org/wiki/Windows-1252#Codepage_layout . ** Affects: evolution (Ubuntu) Importance: Undecided Status: New -- Evolution could deal better with characters in windows-1252 but not iso-8859-1 https://bugs.launchpad.net/bugs/373325 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to evolution in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 373325] Re: Evolution could deal better with characters in windows-1252 but not iso-8859-1
I've reproduced this using a specially crafted plain text email too: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To: Recipient some...@somewhere From: Sender some...@somewhere Subject: A test There=92s . -- Evolution could deal better with characters in windows-1252 but not iso-8859-1 https://bugs.launchpad.net/bugs/373325 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtkhtml3.14 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 215386] Re: Totem: Seeking in CBR MP3 is no longer accurate
I finally managed to write an Intrepid Alpha 5 CD that would boot for me and tested this. As far as I can tell the seeks are now much more accurate (or at least consistent). I was unable to produce any obvious discrepancies. Once I upgrade to Intrepid proper I will be able to do more exhaustive testing. Thanks. -- Totem: Seeking in CBR MP3 is no longer accurate https://bugs.launchpad.net/bugs/215386 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file
I've managed to reproduce the progress thumb problem in totem-gstreamer 2.23.4-0ubuntu2 using an Intrepid Alpha 5 LiveCD. The fact that it occurs in both totem-gstreamer and totem-xine implies that it is a totem issue rather than a xine one. Note that it took me a few attempts to make it happen. The trick seems to be: 1. Start playing from the beginning (I used an hour long file) 2. Seek by dragging the thumb to just before the end (about 97%) 3. Just after playback starts at the new position drag the thumb all the way to the right. 4. Playback stops with the thumb at the end of the progress bar (contrast this with the behaviour when playback reaches the end of the file naturally - the thumb returns to the beginning automatically). 5. Hit the play button again. 6. Playback starts at the beginning but the thumb remains at the end of the progress bar. -- totem-xine progress thumb stuck at end after seeking to end of file https://bugs.launchpad.net/bugs/230089 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 230089] Re: totem progress thumb stays at end after seeking to end of file and restarting playback
** Summary changed: - totem-xine progress thumb stuck at end after seeking to end of file + totem progress thumb stays at end after seeking to end of file and restarting playback -- totem progress thumb stays at end after seeking to end of file and restarting playback https://bugs.launchpad.net/bugs/230089 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 230089] Re: totem progress thumb stays at end after seeking to end of file and restarting playback
Entered as Gnome bug #552790. See http://bugzilla.gnome.org/show_bug.cgi?id=552790 -- totem progress thumb stays at end after seeking to end of file and restarting playback https://bugs.launchpad.net/bugs/230089 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file
I can reproduce the same problem in totem-gstreamer (although I ran the gauntlet of bug #527572 when trying to do so) although it might not be quite as easy. I used an MP3 file that was over half an hour long. I also managed to get totem-gstreamer to hang (and stop repainting) just after seeking to the end. When attaching to it with gdb the backtrace looked somewhat recursive: #0 0xb7f92410 in __kernel_vsyscall () #1 0xb70f1589 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb70ecba6 in _L_lock_95 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0xb70ec58a in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb730b580 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0 #5 0xb7c04a91 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #6 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #7 0xb5624551 in ?? () from /usr/lib/gstreamer-0.10/libgstcoreelements.so #8 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #9 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #10 0xb565a322 in gst_selector_pad_event (pad=0x830b7c8, event=0x8699ef0) at gststreamselector.c:313 #11 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #12 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #13 0xb7bf9d5a in ?? () from /usr/lib/libgstreamer-0.10.so.0 #14 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #15 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #16 0xb7c062d9 in gst_pad_event_default () from /usr/lib/libgstreamer-0.10.so.0 #17 0xb45111bd in gst_mad_sink_event (pad=0x8626f10, event=0x8699ef0) at gstmad.c:991 #18 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #19 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #20 0xb452369a in gst_mp3parse_sink_event (pad=0x86cf4c8, event=0x8699ef0) at gstmpegaudioparse.c:494 #21 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #22 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #23 0xb7c062d9 in gst_pad_event_default () from /usr/lib/libgstreamer-0.10.so.0 #24 0xb5629341 in ?? () from /usr/lib/gstreamer-0.10/libgstcoreelements.so #25 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #26 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #27 0xb7bf9d5a in ?? () from /usr/lib/libgstreamer-0.10.so.0 #28 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #29 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #30 0xb7c783b7 in ?? () from /usr/lib/libgstbase-0.10.so.0 #31 0xb7c77284 in ?? () from /usr/lib/libgstbase-0.10.so.0 #32 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #33 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #34 0xb7bf9d5a in ?? () from /usr/lib/libgstreamer-0.10.so.0 #35 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #36 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #37 0xb7c06373 in gst_pad_event_default () from /usr/lib/libgstreamer-0.10.so.0 #38 0xb5628d12 in ?? () from /usr/lib/gstreamer-0.10/libgstcoreelements.so #39 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #40 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #41 0xb45243f4 in mp3parse_src_event (pad=0x86cf048, event=0x81b2850) at gstmpegaudioparse.c:1675 #42 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #43 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #44 0xb7c06373 in gst_pad_event_default () from /usr/lib/libgstreamer-0.10.so.0 #45 0xb4510832 in gst_mad_src_event (pad=0x8677040, event=0x81b2850) at gstmad.c:792 #46 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #47 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #48 0xb7bf9d5a in ?? () from /usr/lib/libgstreamer-0.10.so.0 #49 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #50 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #51 0xb7c06373 in gst_pad_event_default () from /usr/lib/libgstreamer-0.10.so.0 #52 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #53 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #54 0xb56220b3 in ?? () from /usr/lib/gstreamer-0.10/libgstcoreelements.so #55 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #56 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #57 0xb7bf9d5a in ?? () from /usr/lib/libgstreamer-0.10.so.0 #58 0xb7c04956 in gst_pad_send_event () from /usr/lib/libgstreamer-0.10.so.0 #59 0xb7c05086 in gst_pad_push_event () from /usr/lib/libgstreamer-0.10.so.0 #60 0xb7c7fc43 in ?? () from
[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file
(although I ran the gauntlet of bug #527572 when trying to do so) Sorry, that's the upstream buzilla.gnome.org bug number. The launchpad bug number is #216462. -- totem-xine progress thumb stuck at end after seeking to end of file https://bugs.launchpad.net/bugs/230089 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 215386] Re: Totem: Seeking in CBR MP3 is no longer accurate
A suitable file for reproducing this bug is available at http://www.fysh.org/~mac/totem- bug-527572.mp3 . I've discovered that totem-xine is better at keeping the time code accurate. It seems to be accurate to within half a second. This is still worse than totem (standard) used to be under Gutsy though. -- Totem: Seeking in CBR MP3 is no longer accurate https://bugs.launchpad.net/bugs/215386 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 230089] [NEW] totem-xine progress thumb stuck at end after seeking to end of file
Public bug reported: Binary package hint: totem Steps to reproduce: 1. Launch totem-xine myfile.mp3. Playback starts. 2. Use the mouse to drag the progress thumb to the far right. Playback stops and the progress control goes grey. 3. Hit the play button. Playback starts again but the thumb of the progress bar incorrectly stays stuck at the right hand end. 4. Drag the thumb back to the left and seeking occurs as expected. Even running totem-xine another-file.mp3 at stage 3 still results in the progress bar thumb staying stuck at the right hand end. ProblemType: Bug Architecture: i386 Date: Tue May 13 21:19:30 2008 DistroRelease: Ubuntu 8.04 ExecutablePath: /usr/bin/totem-xine Package: totem-xine 2.22.1-0ubuntu2 PackageArchitecture: i386 ProcEnviron: SHELL=/usr/bin/zsh LANG=en_GB.UTF-8 PATH=/home/username/bin/i386-linux:/home/username/bin/scripts:/usr/local/bin:/usr/bin:/bin:/usr/local/bin/X11:/usr/bin/X11:/usr/local/games:/usr/games:/sbin:/usr/sbin:. SourcePackage: totem Uname: Linux 2.6.24-16-386 i686 ** Affects: totem (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug -- totem-xine progress thumb stuck at end after seeking to end of file https://bugs.launchpad.net/bugs/230089 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/14502596/Dependencies.txt ** Attachment added: ProcMaps.txt http://launchpadlibrarian.net/14502597/ProcMaps.txt ** Attachment added: ProcStatus.txt http://launchpadlibrarian.net/14502598/ProcStatus.txt -- totem-xine progress thumb stuck at end after seeking to end of file https://bugs.launchpad.net/bugs/230089 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 216462] Re: Totem crashed with SIGSEGV in volume_process_int32
I've provided the file to upstream (see http://bugzilla.gnome.org/show_bug.cgi?id=527572 ) but they can't reproduce it using the current state of CVS. Perhaps it is worth someone other than me trying the file on the Ubuntu 8.04 packaged version? The file is still available from http://www.fysh.org/~mac/totem- bug-527572.mp3 . -- Totem crashed with SIGSEGV in volume_process_int32 https://bugs.launchpad.net/bugs/216462 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gstreamer0.10 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 216462] [NEW] Totem crashed with SIGSEGV in volume_process_int32
Public bug reported: Binary package hint: totem Apologies for the lack of extra debug information but apport didn't seem to want to catch this one. :( When seeking to near the end of a half hour 128Kbit/s CBR MP3 using the seek slider I can reliably reproduce a segfault every time. Please let me know if you'd like the file I used - it's not small though. :( I'm going to start the file playing from the beginning to see if the same fault occurs when that part of the file is reached normally. I'm no gstreamer expert but n_bytes looks suspiciously large. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb33f4b90 (LWP 5021)] 0xb41ba468 in volume_process_int32 (this=0x8504030, bytes=0xb2a03c00, n_bytes=1063639424) at gstvolume.c:503 503 gstvolume.c: No such file or directory. in gstvolume.c (gdb) bt #0 0xb41ba468 in volume_process_int32 (this=0x8504030, bytes=0xb2a03c00, n_bytes=1063639424) at gstvolume.c:503 #1 0xb41bb2e5 in volume_transform_ip (base=0x8504030, outbuf=0x8393068) at gstvolume.c:709 #2 0xb7cba5a7 in ?? () from /usr/lib/libgstbase-0.10.so.0 #3 0x08504030 in ?? () #4 0x08393068 in ?? () #5 0x1fc276f4 in ?? () #6 0x017f in ?? () #7 0x083ca050 in ?? () #8 0x0001 in ?? () #9 0xb33f3d38 in ?? () #10 0xb73c4a54 in g_type_check_instance_is_a () from /usr/lib/libgobject-2.0.so.0 #11 0xb7cbb59b in ?? () from /usr/lib/libgstbase-0.10.so.0 #12 0x08614988 in ?? () #13 0x0839ed58 in ?? () #14 0xb33f3dd8 in ?? () #15 0xb7348180 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0 #16 0xb7c454f9 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #17 0x0860c400 in ?? () #18 0x08393068 in ?? () #19 0xb7129531 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #20 0xb7c45bc6 in gst_pad_push () from /usr/lib/libgstreamer-0.10.so.0 #21 0xb7cbb5fe in ?? () from /usr/lib/libgstbase-0.10.so.0 #22 0x0860c340 in ?? () #23 0x08393068 in ?? () #24 0x5661dea0 in ?? () #25 0x0186 in ?? () #26 0x08525d0c in ?? () #27 0x08370820 in ?? () #28 0x in ?? () ProblemType: Bug Architecture: i386 Date: Sat Apr 12 19:55:04 2008 DistroRelease: Ubuntu 8.04 ExecutablePath: /usr/bin/totem-gstreamer Package: totem-gstreamer 2.22.1-0ubuntu2 PackageArchitecture: i386 ProcEnviron: SHELL=/usr/bin/zsh LANG=en_GB.UTF-8 PATH=/home/username/bin/i386-linux:/home/username/bin/scripts:/usr/local/bin:/usr/bin:/bin:/usr/local/bin/X11:/usr/bin/X11:/usr/local/games:/usr/games:/sbin:/usr/sbin:. SourcePackage: totem Uname: Linux 2.6.24-15-386 i686 ** Affects: totem (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug -- Totem crashed with SIGSEGV in volume_process_int32 https://bugs.launchpad.net/bugs/216462 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 216462] Re: Totem crashed with SIGSEGV in volume_process_int32
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/13384218/Dependencies.txt ** Attachment added: ProcMaps.txt http://launchpadlibrarian.net/13384219/ProcMaps.txt ** Attachment added: ProcStatus.txt http://launchpadlibrarian.net/13384220/ProcStatus.txt -- Totem crashed with SIGSEGV in volume_process_int32 https://bugs.launchpad.net/bugs/216462 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 216462] Re: Totem crashed with SIGSEGV in volume_process_int32
I wrote: I'm going to start the file playing from the beginning to see if the same fault occurs when that part of the file is reached normally. The entire file played through from start to finish without causing a crash. This would seem to imply that the fault is caused by the seeking. -- Totem crashed with SIGSEGV in volume_process_int32 https://bugs.launchpad.net/bugs/216462 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 215386] Re: Totem: Seeking in CBR MP3 is no longer accurate
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/13342727/Dependencies.txt ** Attachment added: ProcMaps.txt http://launchpadlibrarian.net/13342728/ProcMaps.txt ** Attachment added: ProcStatus.txt http://launchpadlibrarian.net/13342729/ProcStatus.txt -- Totem: Seeking in CBR MP3 is no longer accurate https://bugs.launchpad.net/bugs/215386 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 215386] [NEW] Totem: Seeking in CBR MP3 is no longer accurate
Public bug reported: Binary package hint: totem Upon upgrading from Gutsy to Hardy (Beta) I've discovered that the time codes displayed by totem after seeking are no longer accurate on CBR MP3 files. With the Gutsy version of totem I was able to seek repeatably and accurately within long (half an hour or more) 128kbit/s MP3 files in order to locate precise times for edit points. With the current Hardy version the location in the file can vary by four or more seconds from the reported time code when mixing seeking with the slider and using the cursor keys. I've not found a pattern to the inaccuracy. redbox:~ dpkg -l '*totem*' '*gstreamer*'|grep '^.i' ii gstreamer0.10-alsa 0.10.18-3 GStreamer plugin for ALSA ii gstreamer0.10-esd 0.10.7-3 GStreamer plugin for ESD ii gstreamer0.10-ffmpeg 0.10.3-6 FFmpeg plugin for GStreamer ii gstreamer0.10-gnomevfs 0.10.18-3 GStreamer plugin for GnomeVFS ii gstreamer0.10-pitfdll 0.9.1.1+cvs20080215-1 GStreamer plugin for using MS Windows binary ii gstreamer0.10-plugins-bad 0.10.6-5 GStreamer plugins from the bad set ii gstreamer0.10-plugins-bad-multiverse 0.10.6-1 GStreamer plugins from the bad set (Multiv ii gstreamer0.10-plugins-base 0.10.18-3 GStreamer plugins from the base set ii gstreamer0.10-plugins-base-apps0.10.18-3 GStreamer helper programs from the base se ii gstreamer0.10-plugins-good 0.10.7-3 GStreamer plugins from the good set ii gstreamer0.10-plugins-ugly 0.10.7-3 GStreamer plugins from the ugly set ii gstreamer0.10-pulseaudio 0.9.7-2 GStreamer plugin for PulseAudio ii gstreamer0.10-tools0.10.18-4ubuntu1 Tools for use with GStreamer ii gstreamer0.10-x0.10.18-3 GStreamer plugins for X11 and Pango ii libgstreamer-plugins-base0.10-00.10.18-3 GStreamer libraries from the base set ii libgstreamer0.10-0 0.10.18-4ubuntu1 Core GStreamer libraries and elements ii libgstreamer0.10-dev 0.10.18-4ubuntu1 GStreamer core development files ii libtotem-plparser102.22.2-0ubuntu1 Totem Playlist Parser library - runtime vers ii totem 2.22.1-0ubuntu1 A simple media player for the Gnome desktop ii totem-common 2.22.1-0ubuntu1 Data files for the Totem media player ii totem-gstreamer2.22.1-0ubuntu1 A simple media player for the Gnome desktop ii totem-mozilla 2.22.1-0ubuntu1 Totem Mozilla plugin ii totem-plugins 2.22.1-0ubuntu1 Plugins for the Totem media player redbox:~ apt-cache policy totem totem: Installed: 2.22.1-0ubuntu1 Candidate: 2.22.1-0ubuntu1 Version table: *** 2.22.1-0ubuntu1 0 500 http://gb.archive.ubuntu.com hardy/main Packages 500 http://archive.ubuntu.com hardy/main Packages 100 /var/lib/dpkg/status redbox:~ lsb_release -rd Description:Ubuntu hardy (development branch) Release:8.04 ProblemType: Bug Architecture: i386 Date: Thu Apr 10 22:15:48 2008 DistroRelease: Ubuntu 8.04 ExecutablePath: /usr/bin/totem-gstreamer Package: totem-gstreamer 2.22.1-0ubuntu1 PackageArchitecture: i386 ProcEnviron: SHELL=/usr/bin/zsh LANG=en_GB.UTF-8 PATH=/home/username/bin/i386-linux:/home/username/bin/scripts:/usr/local/bin:/usr/bin:/bin:/usr/local/bin/X11:/usr/bin/X11:/usr/local/games:/usr/games:/sbin:/usr/sbin:. SourcePackage: totem Uname: Linux 2.6.24-15-386 i686 ** Affects: totem (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug -- Totem: Seeking in CBR MP3 is no longer accurate https://bugs.launchpad.net/bugs/215386 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 215386] Steps to reproduce
Detailed steps to reproduce: 1. gnome-open half-hour.mp3 2. Press right cursor key once to seek to around 1:00. Listen for a few seconds to identify the position (it just so happened that there was something easily identifiable at 1:02 in this file). 3. Press right cursor key repeatedly until timecode reaches around 7:00. 4. Press left cursor key repeatedly until timecode reaches under 1:00. 5. Listen again (in my file the identifiable event occurred just before 1:01 this time). In my testing with this test the timecode was different by about a second. With further movement with the cursor keys and dragging the slider with the mouse I've been able to exceed four seconds discrepancy. -- Totem: Seeking in CBR MP3 is no longer accurate https://bugs.launchpad.net/bugs/215386 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to totem in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
