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
Deskt
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 ter
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.
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
From: Sender
Subject: A test
There=92s
.
--
Evolution could deal better with characters in windows-1252 but not iso-885
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
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,
** 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.ne
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. T
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 te
> (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 no
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 t
** 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-
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 o
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
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
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.
--
** 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
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
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 ti
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 a
** 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:
21 matches
Mail list logo