[Bug 1886326] Re: gnome-terminal does not retain maximised size when external monitor goes into power save

2020-09-01 Thread Mike Crowe
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

[Bug 1886326] [NEW] gnome-terminal does not retain maximised size when external monitor goes into power save

2020-07-05 Thread Mike Crowe
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

[Bug 373325] Re: Evolution could deal better with characters in windows-1252 but not iso-8859-1

2009-05-14 Thread Mike Crowe
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

[Bug 373325] [NEW] Evolution could deal better with characters in windows-1252 but not iso-8859-1

2009-05-07 Thread Mike Crowe
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

[Bug 373325] Re: Evolution could deal better with characters in windows-1252 but not iso-8859-1

2009-05-07 Thread Mike Crowe
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

[Bug 215386] Re: Totem: Seeking in CBR MP3 is no longer accurate

2008-09-18 Thread Mike Crowe
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

[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file

2008-09-18 Thread Mike Crowe
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.

[Bug 230089] Re: totem progress thumb stays at end after seeking to end of file and restarting playback

2008-09-18 Thread Mike Crowe
** 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

[Bug 230089] Re: totem progress thumb stays at end after seeking to end of file and restarting playback

2008-09-18 Thread Mike Crowe
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,

[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file

2008-08-16 Thread Mike Crowe
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

[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file

2008-08-16 Thread Mike Crowe
(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

[Bug 215386] Re: Totem: Seeking in CBR MP3 is no longer accurate

2008-05-13 Thread Mike Crowe
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

[Bug 230089] [NEW] totem-xine progress thumb stuck at end after seeking to end of file

2008-05-13 Thread Mike Crowe
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

[Bug 230089] Re: totem-xine progress thumb stuck at end after seeking to end of file

2008-05-13 Thread Mike Crowe
** 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

[Bug 216462] Re: Totem crashed with SIGSEGV in volume_process_int32

2008-04-29 Thread Mike Crowe
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

[Bug 216462] [NEW] Totem crashed with SIGSEGV in volume_process_int32

2008-04-12 Thread Mike Crowe
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

[Bug 216462] Re: Totem crashed with SIGSEGV in volume_process_int32

2008-04-12 Thread Mike Crowe
** 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

[Bug 216462] Re: Totem crashed with SIGSEGV in volume_process_int32

2008-04-12 Thread Mike Crowe
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. --

[Bug 215386] Re: Totem: Seeking in CBR MP3 is no longer accurate

2008-04-10 Thread Mike Crowe
** 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:

[Bug 215386] [NEW] Totem: Seeking in CBR MP3 is no longer accurate

2008-04-10 Thread Mike Crowe
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

[Bug 215386] Steps to reproduce

2008-04-10 Thread Mike Crowe
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