[Bug 230102]

[Misaki]

I think this has been fixed. I changed browser.sessionstore.warnOnQuit
to true, have all the other warnings set to true, and when I tried to
close this private browsing window it warned me. I also have 'restore
previous session' set (http://kb.mozillazine.org/Browser.startup.page is
3). I didn't have this warning before, ever since it changed in like
Firefox 4 or whatever. This is probably the new name for the bug, with
more info: bug 550559

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/230102

Title:
  No warning when closing multiple tabs

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/230102/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

This is due to color management. I think I filed a bug report on the
Gnome bugtracker with slightly different information, but regarding
brightness jumping from 0 to ~5 out of 255:

According to http://www.lagom.nl/lcd-test/black.php, with 6-bit
dithering, usually "the darkest four shades (0, 1, 2, 3) all are
displayed as black regardless of the monitor settings." Most models of
my laptop didn't have LED backlights, and maybe the default color
profile for my laptop model was intended for those non-LED backlights.
Although my screen is 6-bit, shades 1~3 are still discernible. In any
case, turning off color management fixed the problem for eog, and
presumably for Firefox as well after a restart.

** Changed in: eog (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1759300] Re: Gnome Shell: Touchpad right click (bottom right) area does not work

[Misaki]

Would it be possible to make 'area' mode the default if the touchpad
doesn't support multi-finger input?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1759300

Title:
  Gnome Shell: Touchpad right click (bottom right) area does not work

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1759300/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 711061] Re: [MIR] openjpeg2

[Misaki]

Regarding security: it seems that ffmpeg has retained jpeg-2000 support
during this time. ffmpeg's configuration,

ffmpeg version 3.4.2-2 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 7 (Ubuntu 7.3.0-16ubuntu2)

[...]
--enable-libopenjpeg
[...]

ffplay will display a jpeg2000 image, although I get a lot of warnings
about 'End mismatch '.

Is ffmpeg not exposed to any potential security flaws that imagemagick
would be?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/711061

Title:
  [MIR] openjpeg2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjpeg2/+bug/711061/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1447968] Re: ImageMagick is missing JPEG2000 support (needs to be built with openjpeg)

[Misaki]

** Tags added: bionic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1447968

Title:
  ImageMagick is missing JPEG2000 support (needs to be built with
  openjpeg)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1447968/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 711061] Re: [MIR] openjpeg2

[Misaki]

** Tags added: bionic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/711061

Title:
  [MIR] openjpeg2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjpeg2/+bug/711061/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744543] Re: Screen updating with Compiz or Wayland causes high-CPU kworker thread in recent kernels

[Misaki]

** Description changed:

  Originally filed under compiz:
  https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Testing
  indicates it affects Wayland as well.
  
  The automatically-included information for this reports notes that I'm
  using kernel 4.8, where this issue doesn't occur.
  
  When the screen updates in recent versions of the Linux kernel,
  including 4.13 and 4.15 while running Compiz or Wayland, it causes high
  CPU usage in a kworker thread. This was 30~40% of a CPU core on my
  system with 4.13 kernel, and is 65% with 4.15. This doesn't happen with
  Metacity or non-Wayland Gnome. Since Unity uses Compiz, it happens there
  as well.
  
  This seems unrelated to how much of the screen is being repainted, as
  the 'Show Repaint' plugin in Compiz can show that only a few pixels are
  being updated and the kworker load is the same.
  
  Updated test results, having upgraded to Bionic Beaver 18.04, with
  kernel 4.15.0-15-generic,
  
  -my Flashback compiz login no longer works, it just crashes back to the login 
screen, so I can't test it.
  -Unity uses compiz and still works for me, and still has this bug.
  -Wayland has this bug and doesn't use compiz.
  
  Other display managers remain the same. Metacity is the best in terms of
  not causing the kernel to waste CPU; 'Ubuntu with Gnome' is the second-
  best, only causing an extra 10~20% of CPU usage from gnome-shell, and no
  high-CPU kworker threads.
  
  When screen is updating under Wayland, one or two kworker threads use a
  combined 65% of a CPU core, with gnome-shell using an additional 8% CPU.
  
  This can be trivially triggered by running glxgears, the command 'ffmpeg
  -filter_complex color=orange:2x2 -f opengl -', or the command 'ffplay
  dummy -f lavfi  -graph color=orange:2x2:60' which all should update a
  small part of the screen at a tiny CPU cost. For me glxgears uses 1.5%,
  while ffplay or ffmpeg use 7~12% to create a 2x2 pixel video, but all
  three programs cause an extra 65% CPU use from the kernel.
  
  My laptop's battery is completely dead so I have to keep it plugged in
  all the time, but this should be a concern to anyone with a laptop as it
  will affect battery life.
  
  The 18.04 kernel is not one for which bugs can be filed at kernel.org:
  https://www.kernel.org/doc/html/v4.10/admin-guide/reporting-bugs.html
  
  I already confirmed the bug upstream, I assume from Debian; can someone
  who can replicate this bug test the latest -rc kernel from kernel.org?
  
  NEW DATA POINT! I followed the instructions here to stop screen tearing
  in Metacity: http://dan.bodar.com/2018/02/26/stop-screen-tearing-on-
  ubuntu-by-changing-compositor/
  
  However, after testing for this bug with compton running, I found that
  the bug does occur. Seeing 55% CPU from kworker. If I kill compton while
  glxgears is running, the kworker thread immediately disappears from
  'top'.
  
  I'm guessing the kernel is trying too hard to match screen vsync
  (vertical sync).
  
  The command in the link is 'compton --backend glx --paint-on-overlay
  --vsync opengl-swc'. Leaving out '--backend glx' both stops the high CPU
  use from kworker and causes screen tearing, as shown by
  https://www.youtube.com/watch?v=5xkNy9gfKOg.
  
+ Screen tearing exists for Gnome+Ubuntu login option, which also does not
+ exhibit this bug. Regarding vsync connection as confirmed, changing bug
+ title accordingly. I can't fix the bug myself though.
+ 
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-generic 4.13.0.25.26
  ProcVersionSignature: Ubuntu 4.8.0-34.36-generic 4.8.11
  Uname: Linux 4.8.0-34-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   misaki 1685 F...m pulseaudio
   /dev/snd/controlC0:  misaki 1685 F pulseaudio
  CurrentDesktop: GNOME-Flashback:GNOME
  Date: Sun Jan 21 00:17:16 2018
  HibernationDevice: RESUME=UUID=ea8d7b22-9a3e-412e-af6a-8fc260a76a2c
  MachineType: ASUSTeK Computer Inc. N50Vn
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic 
root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.8.0-34-generic N/A
   linux-backports-modules-4.8.0-34-generic  N/A
   linux-firmware1.169.1
  SourcePackage: linux
  UpgradeStatus: Upgraded to artful on 2018-01-09 (12 days ago)
  WpaSupplicantLog:
  
  dmi.bios.date: 03/05/2009
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 211
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: N50Vn
  dmi.board.vendor: ASUSTeK Computer Inc.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: ATN12345678901234567
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK Computer Inc.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0

[Bug 1766480] [NEW] Touchpad scroll and middle/right click not working as expected

[Misaki]

Public bug reported:

This could probably fixed through configuration, but it should work
automatically. Testing Ubuntu 18.04 beta, the touchpad has no special
regions for scrolling or anything.

By default in Xorg-based Ubuntu, top right corner of touchpad is middle-
click (mouse button 2), bottom right is right-click (mouse button 3),
and right side is vertical scrolling. For a while the bottom edge
defaulted to horizontal scrolling, but that changed in 17.10 or
something.

I'm aware that new touchpad interaction methods have developed, like
dragging with two fingers anywhere on the touchpad to scroll or
something. But people may not know this, or their touchpad might not
support multitouch.

(The Xorg-based settings for touchpad remain when switching back to Xorg
like with the Metacity Flashback login option.)

** Affects: wayland (Ubuntu)
 Importance: Undecided
 Status: New

** Description changed:

  This could probably fixed through configuration, but it should work
  automatically. Testing Ubuntu 18.04 beta, the touchpad has no special
  regions for scrolling or anything.
  
  By default in Xorg-based Ubuntu, top right corner of touchpad is middle-
  click (mouse button 2), bottom right is right-click (mouse button 3),
  and right side is vertical scrolling. For a while the bottom edge
  defaulted to horizontal scrolling, but that changed in 17.10 or
  something.
  
  I'm aware that new touchpad interaction methods have developed, like
  dragging with two fingers anywhere on the touchpad to scroll or
  something. But people may not know this, or their touchpad might not
  support multitouch.
+ 
+ (The Xorg-based settings for touchpad remain when switching back to Xorg
+ like with the Metacity Flashback login option.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1766480

Title:
  Touchpad scroll and middle/right click not working as expected

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/1766480/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744543] Re: Screen updating with Compiz or Wayland causes high-CPU kworker thread in recent kernels

[Misaki]

** Description changed:

  Originally filed under compiz:
  https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Testing
  indicates it affects Wayland as well.
  
  The automatically-included information for this reports notes that I'm
  using kernel 4.8, where this issue doesn't occur.
  
  When the screen updates in recent versions of the Linux kernel,
  including 4.13 and 4.15 while running Compiz or Wayland, it causes high
  CPU usage in a kworker thread. This was 30~40% of a CPU core on my
  system with 4.13 kernel, and is 65% with 4.15. This doesn't happen with
  Metacity or non-Wayland Gnome. Since Unity uses Compiz, it happens there
  as well.
  
  This seems unrelated to how much of the screen is being repainted, as
  the 'Show Repaint' plugin in Compiz can show that only a few pixels are
  being updated and the kworker load is the same.
  
  Updated test results, having upgraded to Bionic Beaver 18.04, with
  kernel 4.15.0-15-generic,
  
  -my Flashback compiz login no longer works, it just crashes back to the login 
screen, so I can't test it.
  -Unity uses compiz and still works for me, and still has this bug.
  -Wayland has this bug and doesn't use compiz.
  
  Other display managers remain the same. Metacity is the best in terms of
  not causing the kernel to waste CPU; 'Ubuntu with Gnome' is the second-
  best, only causing an extra 10~20% of CPU usage from gnome-shell, and no
  high-CPU kworker threads.
  
  When screen is updating under Wayland, one or two kworker threads use a
  combined 65% of a CPU core, with gnome-shell using an additional 8% CPU.
  
  This can be trivially triggered by running glxgears, the command 'ffmpeg
  -filter_complex color=orange:2x2 -f opengl -', or the command 'ffplay
  dummy -f lavfi  -graph color=orange:2x2:60' which all should update a
  small part of the screen at a tiny CPU cost. For me glxgears uses 1.5%,
  while ffplay or ffmpeg use 7~12% to create a 2x2 pixel video, but all
  three programs cause an extra 65% CPU use from the kernel.
  
  My laptop's battery is completely dead so I have to keep it plugged in
  all the time, but this should be a concern to anyone with a laptop as it
  will affect battery life.
  
  The 18.04 kernel is not one for which bugs can be filed at kernel.org:
  https://www.kernel.org/doc/html/v4.10/admin-guide/reporting-bugs.html
  
  I already confirmed the bug upstream, I assume from Debian; can someone
  who can replicate this bug test the latest -rc kernel from kernel.org?
  
  NEW DATA POINT! I followed the instructions here to stop screen tearing
  in Metacity: http://dan.bodar.com/2018/02/26/stop-screen-tearing-on-
  ubuntu-by-changing-compositor/
  
  However, after testing for this bug with compton running, I found that
  the bug does occur. Seeing 55% CPU from kworker. If I kill compton while
  glxgears is running, the kworker thread immediately disappears from
  'top'.
  
  I'm guessing the kernel is trying too hard to match screen vsync
  (vertical sync).
  
+ The command in the link is 'compton --backend glx --paint-on-overlay
+ --vsync opengl-swc'. Leaving out '--backend glx' both stops the high CPU
+ use from kworker and causes screen tearing, as shown by
+ https://www.youtube.com/watch?v=5xkNy9gfKOg.
+ 
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-generic 4.13.0.25.26
  ProcVersionSignature: Ubuntu 4.8.0-34.36-generic 4.8.11
  Uname: Linux 4.8.0-34-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   misaki 1685 F...m pulseaudio
   /dev/snd/controlC0:  misaki 1685 F pulseaudio
  CurrentDesktop: GNOME-Flashback:GNOME
  Date: Sun Jan 21 00:17:16 2018
  HibernationDevice: RESUME=UUID=ea8d7b22-9a3e-412e-af6a-8fc260a76a2c
  MachineType: ASUSTeK Computer Inc. N50Vn
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic 
root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.8.0-34-generic N/A
   linux-backports-modules-4.8.0-34-generic  N/A
   linux-firmware1.169.1
  SourcePackage: linux
  UpgradeStatus: Upgraded to artful on 2018-01-09 (12 days ago)
  WpaSupplicantLog:
  
  dmi.bios.date: 03/05/2009
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 211
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: N50Vn
  dmi.board.vendor: ASUSTeK Computer Inc.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: ATN12345678901234567
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK Computer Inc.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
  dmi.product.name: N50Vn
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK Computer Inc.

-- 
You received this bug notification

[Bug 1744543] Re: Screen updating with Compiz or Wayland causes high-CPU kworker thread in recent kernels

[Misaki]

** Tags added: vsync

** Description changed:

  Originally filed under compiz:
  https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Testing
  indicates it affects Wayland as well.
  
  The automatically-included information for this reports notes that I'm
  using kernel 4.8, where this issue doesn't occur.
  
  When the screen updates in recent versions of the Linux kernel,
  including 4.13 and 4.15 while running Compiz or Wayland, it causes high
  CPU usage in a kworker thread. This was 30~40% of a CPU core on my
  system with 4.13 kernel, and is 65% with 4.15. This doesn't happen with
  Metacity or non-Wayland Gnome. Since Unity uses Compiz, it happens there
  as well.
  
  This seems unrelated to how much of the screen is being repainted, as
  the 'Show Repaint' plugin in Compiz can show that only a few pixels are
  being updated and the kworker load is the same.
  
  Updated test results, having upgraded to Bionic Beaver 18.04, with
  kernel 4.15.0-15-generic,
  
  -my Flashback compiz login no longer works, it just crashes back to the login 
screen, so I can't test it.
  -Unity uses compiz and still works for me, and still has this bug.
  -Wayland has this bug and doesn't use compiz.
  
  Other display managers remain the same. Metacity is the best in terms of
  not causing the kernel to waste CPU; 'Ubuntu with Gnome' is the second-
  best, only causing an extra 10~20% of CPU usage from gnome-shell, and no
  high-CPU kworker threads.
  
  When screen is updating under Wayland, one or two kworker threads use a
  combined 65% of a CPU core, with gnome-shell using an additional 8% CPU.
  
  This can be trivially triggered by running glxgears, the command 'ffmpeg
  -filter_complex color=orange:2x2 -f opengl -', or the command 'ffplay
  dummy -f lavfi  -graph color=orange:2x2:60' which all should update a
  small part of the screen at a tiny CPU cost. For me glxgears uses 1.5%,
  while ffplay or ffmpeg use 7~12% to create a 2x2 pixel video, but all
  three programs cause an extra 65% CPU use from the kernel.
  
  My laptop's battery is completely dead so I have to keep it plugged in
  all the time, but this should be a concern to anyone with a laptop as it
  will affect battery life.
  
  The 18.04 kernel is not one for which bugs can be filed at kernel.org:
  https://www.kernel.org/doc/html/v4.10/admin-guide/reporting-bugs.html
  
  I already confirmed the bug upstream, I assume from Debian; can someone
  who can replicate this bug test the latest -rc kernel from kernel.org?
  
+ NEW DATA POINT! I followed the instructions here to stop screen tearing
+ in Metacity: http://dan.bodar.com/2018/02/26/stop-screen-tearing-on-
+ ubuntu-by-changing-compositor/
+ 
+ However, after testing for this bug with compton running, I found that
+ the bug does occur. Seeing 55% CPU from kworker. If I kill compton while
+ glxgears is running, the kworker thread immediately disappears from
+ 'top'.
+ 
+ I'm guessing the kernel is trying too hard to match screen vsync
+ (vertical sync).
+ 
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-generic 4.13.0.25.26
  ProcVersionSignature: Ubuntu 4.8.0-34.36-generic 4.8.11
  Uname: Linux 4.8.0-34-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   misaki 1685 F...m pulseaudio
   /dev/snd/controlC0:  misaki 1685 F pulseaudio
  CurrentDesktop: GNOME-Flashback:GNOME
  Date: Sun Jan 21 00:17:16 2018
  HibernationDevice: RESUME=UUID=ea8d7b22-9a3e-412e-af6a-8fc260a76a2c
  MachineType: ASUSTeK Computer Inc. N50Vn
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic 
root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-4.8.0-34-generic N/A
   linux-backports-modules-4.8.0-34-generic  N/A
   linux-firmware1.169.1
  SourcePackage: linux
  UpgradeStatus: Upgraded to artful on 2018-01-09 (12 days ago)
  WpaSupplicantLog:
  
  dmi.bios.date: 03/05/2009
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 211
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: N50Vn
  dmi.board.vendor: ASUSTeK Computer Inc.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: ATN12345678901234567
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK Computer Inc.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
  dmi.product.name: N50Vn
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK Computer Inc.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744543

Title:
  Screen updating with Compiz or Wayland causes high-CPU kworker thread
  in recent kernels

To manage

[Bug 1766479] [NEW] Resizing a window's left border to the right can cause it to scoot right

[Misaki]

Public bug reported:

Tested with 18.04 beta.

Created a small window, ffmpeg or ffplay showing a 2x2 pixel video. When
trying to move it, instead selected left border. Dragging right caused
the window to scoot away faster than the pointer was moving, vanishing
in less than a second.

** Affects: wayland (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1766479

Title:
  Resizing a window's left border to the right can cause it to scoot
  right

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/1766479/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744543] Re: Screen updating with Compiz causes high-CPU kworker thread in 4.13 or earlier

[Misaki]

** Tags added: battery

** Description changed:

- This duplicates the information in
- https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Filing
- this to get more exposure.
+ Originally filed under compiz:
+ https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Testing
+ indicates it affects Wayland as well.
  
  The automatically-included information for this reports notes that I'm
- using kernel 4.8, where this issue doesn't occur. I don't have any other
- kernels to test with.
+ using kernel 4.8, where this issue doesn't occur.
  
  When the screen updates in 4.13 while running Compiz, it causes high CPU
  usage in a kworker thread. This was 30~40% of a CPU core on my system.
  This doesn't happen with other window managers tested, like Metacity, or
  whatever non-Compiz Gnome and Ubuntu use (gnome-shell maybe, though that
  15% CPU load more than Metacity when I checked). Since Unity uses
  Compiz, it happens there as well as with 'Ubuntu flashback Compiz'.
  
  This seems unrelated to how much of the screen is being repainted, as
  the 'Show Repaint' plugin in Compiz can show that only a few pixels are
  being updated and the kworker load is the same.
  
+ 
+ Updated test results, having upgraded to Bionic Beaver 18.04, with
+ kernel 4.15.0-15-generic,
+ 
+ -my Flashback compiz login no longer works, it just crashes back to the login 
screen, so I can't test it.
+ -Unity uses compiz and still works for me, and still has this bug.
+ -Wayland has this bug and doesn't use compiz.
+ 
+ Other display managers remain the same. Metacity is the best in terms of
+ not causing the kernel to waste CPU; 'Ubuntu with Gnome' is the second-
+ best, only causing an extra 10~20% of CPU usage from gnome-shell, and no
+ high-CPU kworker threads.
+ 
+ When screen is updating under Wayland, one or two kworker threads use a
+ combined 65% of a CPU core, with gnome-shell using an additional 8% CPU.
+ 
+ This can be trivially triggered by running glxgears, the command 'ffmpeg
+ -filter_complex color=orange:2x2 -f opengl -', or the command 'ffplay
+ dummy -f lavfi  -graph color=orange:2x2:60' which all should update a
+ small part of the screen at a tiny CPU cost. For me glxgears uses 1.5%,
+ while ffplay or ffmpeg use 7~12% to create a 2x2 pixel video, but both
+ cause ~70% CPU use from the kernel and other processes.
+ 
+ My laptop's battery is completely dead so I have to keep it plugged in
+ all the time, but this should be a concern to anyone with a laptop as it
+ will affect battery life.
+ 
+ The 18.04 is not one for which bugs can be filed at kernel.org:
+ https://www.kernel.org/doc/html/v4.10/admin-guide/reporting-bugs.html
+ 
+ I already confirmed the bug upstream, I assume from Debian; can someone
+ who can replicate this bug test the latest -rc kernel from kernel.org?
+ 
+ 
  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: linux-generic 4.13.0.25.26
  ProcVersionSignature: Ubuntu 4.8.0-34.36-generic 4.8.11
  Uname: Linux 4.8.0-34-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  AudioDevicesInUse:
-  USERPID ACCESS COMMAND
-  /dev/snd/pcmC0D0p:   misaki 1685 F...m pulseaudio
-  /dev/snd/controlC0:  misaki 1685 F pulseaudio
+  USERPID ACCESS COMMAND
+  /dev/snd/pcmC0D0p:   misaki 1685 F...m pulseaudio
+  /dev/snd/controlC0:  misaki 1685 F pulseaudio
  CurrentDesktop: GNOME-Flashback:GNOME
  Date: Sun Jan 21 00:17:16 2018
  HibernationDevice: RESUME=UUID=ea8d7b22-9a3e-412e-af6a-8fc260a76a2c
  MachineType: ASUSTeK Computer Inc. N50Vn
  ProcFB: 0 nouveaufb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic 
root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
-  linux-restricted-modules-4.8.0-34-generic N/A
-  linux-backports-modules-4.8.0-34-generic  N/A
-  linux-firmware1.169.1
+  linux-restricted-modules-4.8.0-34-generic N/A
+  linux-backports-modules-4.8.0-34-generic  N/A
+  linux-firmware1.169.1
  SourcePackage: linux
  UpgradeStatus: Upgraded to artful on 2018-01-09 (12 days ago)
  WpaSupplicantLog:
-  
+ 
  dmi.bios.date: 03/05/2009
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 211
  dmi.board.asset.tag: ATN12345678901234567
  dmi.board.name: N50Vn
  dmi.board.vendor: ASUSTeK Computer Inc.
  dmi.board.version: 1.0
  dmi.chassis.asset.tag: ATN12345678901234567
  dmi.chassis.type: 10
  dmi.chassis.vendor: ASUSTeK Computer Inc.
  dmi.chassis.version: 1.0
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
  dmi.product.name: N50Vn
  dmi.product.version: 1.0
  dmi.sys.vendor: ASUSTeK Computer Inc.

** Tags added: bionic compiz wayland

** Description changed:

  Originally filed under compiz:
  https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515

[Bug 1744515] Re: Compiz flashback has high-CPU kworker thread when screen updates

[Misaki]

Confirmed to not be (just) a compiz bug because it also affects Wayland,
which doesn't use compiz. Using Bionic beta with kernel
4.15.0-15-generic.

This bug filed for Linux package, when I wasn't sure which project was
responsible:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1744543

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744515

Title:
  Compiz flashback has high-CPU kworker thread when screen updates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744543] Re: Screen updating with Compiz causes high-CPU kworker thread in 4.13 or earlier

[Misaki]

Tested, and if anything the %CPU of kworker threads is even higher,
often staying around 65% in 'top'.

An easy way to get the screen to update is to run glxgears, which should
run at screen refresh rate with very low CPU usage.

** Tags added: kernel-bug-exists-upstream

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744543

Title:
  Screen updating with Compiz causes high-CPU kworker thread in 4.13 or
  earlier

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1744543/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744543] [NEW] Screen updating with Compiz causes high-CPU kworker thread in 4.13 or earlier

[Misaki]

Public bug reported:

This duplicates the information in
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515. Filing
this to get more exposure.

The automatically-included information for this reports notes that I'm
using kernel 4.8, where this issue doesn't occur. I don't have any other
kernels to test with.

When the screen updates in 4.13 while running Compiz, it causes high CPU
usage in a kworker thread. This was 30~40% of a CPU core on my system.
This doesn't happen with other window managers tested, like Metacity, or
whatever non-Compiz Gnome and Ubuntu use (gnome-shell maybe, though that
15% CPU load more than Metacity when I checked). Since Unity uses
Compiz, it happens there as well as with 'Ubuntu flashback Compiz'.

This seems unrelated to how much of the screen is being repainted, as
the 'Show Repaint' plugin in Compiz can show that only a few pixels are
being updated and the kworker load is the same.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: linux-generic 4.13.0.25.26
ProcVersionSignature: Ubuntu 4.8.0-34.36-generic 4.8.11
Uname: Linux 4.8.0-34-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
AudioDevicesInUse:
 USERPID ACCESS COMMAND
 /dev/snd/pcmC0D0p:   misaki 1685 F...m pulseaudio
 /dev/snd/controlC0:  misaki 1685 F pulseaudio
CurrentDesktop: GNOME-Flashback:GNOME
Date: Sun Jan 21 00:17:16 2018
HibernationDevice: RESUME=UUID=ea8d7b22-9a3e-412e-af6a-8fc260a76a2c
MachineType: ASUSTeK Computer Inc. N50Vn
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic 
root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.8.0-34-generic N/A
 linux-backports-modules-4.8.0-34-generic  N/A
 linux-firmware1.169.1
SourcePackage: linux
UpgradeStatus: Upgraded to artful on 2018-01-09 (12 days ago)
WpaSupplicantLog:
 
dmi.bios.date: 03/05/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 211
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: N50Vn
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: N50Vn
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Confirmed


** Tags: amd64 apport-bug artful

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744543

Title:
  Screen updating with Compiz causes high-CPU kworker thread in 4.13 or
  earlier

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1744543/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744515] Re: Compiz flashback has high-CPU kworker thread when screen updates

[Misaki]

Problem does not happen when booting from linux kernel 4.8.0-34-generic;
CPU usage is slightly higher than Metacity, no significant kworker
threads.

It does happen with updated kernel 4.13.0-25-generic (previously -21).
When I went to recovery mode for 4.13.0-25, tried to select failsafeX
graphics, then resumed normal boot, resolution was messed up and Compiz
and Xorg were at 50~60% of a CPU instead of 5~8%. Unfortunately, did not
note whether there was a high kworker thread.

Hope this helps. I don't have any other kernels installed.

Could someone please at least try to verify this? If they don't
experience it, that's useful to know as well.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744515

Title:
  Compiz flashback has high-CPU kworker thread when screen updates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744515] Re: Compiz flashback has high-CPU kworker thread when screen updates

[Misaki]

The 'Show Repaint' plugin in compiz showed that most of the screen was
not getting repainted. Disabling 'Framebuffer object' under OpenGL, in
ccsm (CompizConfig Settings Manager), caused the whole screen to be
repainted but CPU usage of compiz stayed the same. If Workarounds >
'Force full screen redraws (buffer swap) on repaint' was enabled, CPU
usage without Framebuffer object was the same, but with both on, CPU
usage of compiz was ~3% higher (from 13% to 16% with CPUs at lowest
frequency).

Kworker CPU usage doesn't seem to change when I switch CPUs from 1/3
frequency, to maximum frequency. Compiz drops about 1/3 when I do so
(instead of 2/3). On highest frequency, the problem kworker thread uses
three times the CPU of compiz.

kworker CPU usage seems proportional to the frames-per-second recorded
in the Benchmark plugin. When the ffplay window is reduced to 1 pixel
height, so it shows only a constant blue line for audio frequencies, the
Benchmark still shows ~55 fps. Toggling on or off the benchmark makes it
fade with high fps (from 60 fps), which shows same high kworker usage.

(Metacity has screen tearing.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744515

Title:
  Compiz flashback has high-CPU kworker thread when screen updates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744515] Re: Compiz flashback has high-CPU kworker thread when screen updates

[Misaki]

This also affects the 'Unity' login option, which uses compiz.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744515

Title:
  Compiz flashback has high-CPU kworker thread when screen updates

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1744515/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1744515] [NEW] Compiz flashback has high-CPU kworker thread when screen updates

[Misaki]

Public bug reported:

When the screen updates, there is one or two kworker threads with high
CPU. This is 30~40% of a CPU as shown in top, on my old system with two
CPU cores.

This did not happen in 16.10. I recently upgraded a badly out-of-date
16.10 to 17.04 and then immediately to 17.10, so I don't know when it
showed up.

Examples of when it happens is when a video player like ffplay is
running, even if it's just showing something very simple like the sound
frequencies in a music file, or when I scroll up and down in this
browser window. The size of the window is unimportant; the same kworker
activity is shown whether the window is maximized or reduced to a small
width and zero height. It goes away if the window is minimized.

It doesn't happen in Metacity flashback, in "Ubuntu with Xorg", or with
"Gnome with Xorg" from the login screen. For some reason I have
duplicates of those last two options, that differ in that one of them
has a blank circle for the icon. What are presumably the Wayland options
don't let me login — if I try to select them, there's a white outline
and the previous option stays selected with a filled background, and the
selection menu stays there until I select an Xorg-based option. So I
can't test those. '"Ubuntu with Xorg" and "Gnome with Xorg" did show
gnome-shell with ~15% CPU usage of a core, which is probably unnecessary
but completely unrelated to this bug.

Metacity flashback in 17.10 showed the CPU usages I experienced in 16.10
with Compiz flashback, which is about 10% of total CPU from user and
system while playing an audio file with frequency display in ffplay.
This bug brings system CPU as shown in 'top' to 25%.

If it helps, the active kworker thread seems to always be named
'kworker/u4:number', usually the same one or two threads.

I tried enabling or disabling some compiz options related to screen
drawing, but it didn't seem to do anything. I didn't disable the
'Composite' or 'OpenGL' plugins as they were required by too many
others.

This is filed under compiz because no other window manager leads to the
problem, even though it isn't the compiz process with high CPU.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: compiz 1:0.9.13.1+17.10.20170901-0ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-21.24-generic 4.13.13
Uname: Linux 4.13.0-21-generic x86_64
.tmp.unity_support_test.0:
 
ApportVersion: 2.20.7-0ubuntu3.7
Architecture: amd64
CompizPlugins: 
[core,composite,opengl,compiztoolbox,decor,imgpng,regex,gnomecompat,place,move,vpswitch,mousepoll,obs,wall,animation,shift,snap,resize,expo,session,ezoom,workarounds,staticswitcher,fade]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: GNOME-Flashback:GNOME
Date: Sat Jan 20 16:04:52 2018
DistUpgraded: 2018-01-08 23:06:14,204 DEBUG Running PostInstallScript: 
'./xorg_fix_proprietary.py'
DistroCodename: artful
DistroVariant: ubuntu
GraphicsCard:
 NVIDIA Corporation G96M [GeForce 9650M GT] [10de:064c] (rev a1) (prog-if 00 
[VGA controller])
   Subsystem: ASUSTeK Computer Inc. G96M [GeForce 9650M GT] [1043:1912]
GsettingsChanges:
 b'org.compiz.core' b'outputs' b"['1024x768+0+0', '1024x768+0+0']"
 b'org.compiz.core' b'hsize' b'2'
 b'org.compiz.core' b'active-plugins' b"['core', 'composite', 'opengl', 
'compiztoolbox', 'showrepaint', 'imgjpeg', 'decor', 'imgpng', 'regex', 
'gnomecompat', 'place', 'move', 'mousepoll', 'obs', 'ezoom', 'workarounds', 
'dbus', 'text', 'wall', 'snap', 'resize', 'staticswitcher', 'session', 'fade', 
'bench']"
 b'org.compiz.core' b'vsize' b'2'
 b'org.compiz.core' b'lower-window-button' b"'Disabled'"
MachineType: ASUSTeK Computer Inc. N50Vn
PackageArchitecture: all
ProcKernelCmdLine: root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet 
splash
SourcePackage: compiz
UpgradeStatus: Upgraded to artful on 2018-01-09 (11 days ago)
dmi.bios.date: 03/05/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 211
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: N50Vn
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: N50Vn
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.
version.compiz: compiz 1:0.9.13.1+17.10.20170901-0ubuntu1
version.libdrm2: libdrm2 2.4.83-1
version.libgl1-mesa-dri: libgl1-mesa-dri 17.2.4-0ubuntu1~17.10.2
version.libgl1-mesa-glx: libgl1-mesa-glx 17.2.4-0ubuntu1~17.10.2
version.xserver-xorg-core: xserver-xorg-core 2:1.19.5-0ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.10.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 

[Bug 1307144] Re: 'unredirect fullscreen windows' causes tearing

[Misaki]

I am experiencing this bug on Ubuntu 15.10 Wily, using Nvidia drivers
and Gnome (not Unity, if that's the name of the touchscreen-based
interface).

It appears that vlc must be spelled lowercase in order to be matched,
but the default for Unredirect Match spells it Vlc. Totem works. firefox
must also not be capitalized for it to match, but the default is for it
to be capitalized.

Using this video, linked in the previous bug +1051802

https://www.youtube.com/watch?v=ZCPkOpMHB7g

It's possible to test whether a video is full-screen by enabling compiz
effects, like Opacity (in which case the behaviour seems to be that if
you try to initiate transparency while a window is fullscreen
unredirected, it won't take effect until compositing turns on again,
such as by moving the mouse to activate the menu in vlc) or, much
easier, the Benchmark plugin, which shows a frames/sec overlay that
disappears when a window goes fullscreen-unredirected.

When playing the test video in Firefox, occasionally when pausing, it
actually shows a frame mid-tear, with the middle out of synch with the
top and bottom. This is a completely unrelated issue though, since it
still happens when pixels are being redirected (benchmark is displayed)
and no tearing is occurring during playback.

Adding video players to the default matchings to exclude (! = not, for
people like me who don't know programming languages) may have been the
"fix" referenced in the previous bug report. The "impossible to fix"
comment in that report seems accurate, it's probably an Nvidia bug.

It is still a little mystifying whether some Compiz options have any
effect, like the vsync-related ones in Workarounds, but vlc and firefox
being capitalized is a bug. The description of Composite > Unredirect
Match suggests that "you might want to exclude video players, for
example, to avoid tearing", but is this only because of a bug in Nvidia
(or other graphics providers' configuration options)?

Not sure what the bug report submitter is using, but nvidia-settings has
the option "Sync to Vblank", and "Allow Flipping". I found that turning
off Allow Flipping leads to occasional tearing when recording video
using  the x11grab device in ffmpeg, and 'Sync to Vblank' limits the
framerate of the glxgears test program, but the description of Sync to
Vblank is this:

"When enabled, OpenGL applications will swap buffers during the vertical
retrace; this option is applied to OpenGL applications that are started
after this option is set."

I'm not sure if this is supposed to apply to video playback. When a
video player is being unredirected, I find that there is tearing and no
other options will prevent it.

When output is not being unredirected, I find that the only option that
affects tearing is "Allow Flipping" in nvidia-settings. When it's on,
there is no tearing. When it's off, there is always tearing. The
following options seem to have no effect:

compiz:
OpenGL plugin:
Sync to VBlank
Framebuffer object
Vertex buffer object (this might just be a games thing, and I'm just testing 
video)
Always use buffer swapping

Workarounds plugin
Legacy Fullscreen Support (not completed tested with all other options 
combinations though)
Fix screen updates in XGL with fglrx
Force synchronization between X and GLX
Don't wait for video sync

I didn't completely test these:
Force complete redraw on initial damage
Force full screen redraws (buffer swap) on repaint

But they don't seem to prevent or cause tearing. They do show up when
using the 'Show Repaint' plugin but require 'Vertex Buffer Object'
option to be enabled.

in nvidia-settings, "Sync to Vblank" has no effect on tearing during
video playback regardless of any other settings, even after the video
player is restarted.

Ok, I guess maybe the answer to the question is that "vertical synch
only works with buffers"?  I have no idea what other ways exist to swap
buffers other than flipping, but that may be the issue here. Turning on
Allow Flipping might prevent tearing in fullscreen applications like
games, when Compiz isn't getting involved.

HOWEVER, I did most of that testing using totem. Tearing when
unredirecting totem seems to be slightly worse than when it's
redirected, and then swapped in by Compiz. With the nvidia-settings
option "Allow Flipping" enabled, there is no tearing in totem with the
default Compiz settings (where Totem is correctly capitalized), but
there is tearing in vlc, which is incorrectly capitalized when it should
be uncapitalized, as well as firefox with html5.

But when compiz is handling vlc's output, there's no tearing even with
"Allow Flipping" disabled. It appears no combination of options will
cause tearing in vlc, other than unredirecting output (by incorrectly
spelling vlc as Vlc, which also requires "Unredirect Fullscreen Windows"
to be enabled, both of which are the default settings).

** Changed in: compiz (Ubuntu)
   Status: Invalid => Confirmed

-- 
You received this bug notification because you 

[Bug 1307144] Re: 'unredirect fullscreen windows' causes tearing

[Misaki]

When I first started testing, one way to confirm that a window was being
unredirected was that Alt-Tab would not show a window switcher (I use
Static Application Switcher). However, after I had tested different
options and video players (particularly ones in Workarounds), this
stopped being accurate and always worked. I tried changing all options
back but could not replicate this behaviour.

I had left Unredirect Fullscreen Windows to disabled for a long time, at
random, when I was testing how options affected video playback in ways
unrelated to tearing. In the past I experienced issues where eog, or eye
of gnome, the image display program, would not display the application
switcher when in fullscreen. This doesn't seem to be an issue for me but
it seems like it might be related this particular option, unredirect
fullscreen windows.

I don't know why I had this issue with application switcher not showing
up while in fullscreen video, after I had enabled Unredirect Fullscreen
Windows but before I started messing with other settings, but if other
people experience, or can replicate the same issue maybe they could
comment on it or create a new bug report.

At the moment, I have no strong reason to turn the option off, even
though it causes tearing. In marginal cases, it seems it can be the
difference between a video player dropping frames and being able to
continue (when these players aren't excluded through matching). But if
other programs or drivers are bugged to the point where they have
tearing, and people dislike tearing, it may be better to have this
option off by default.

So: does "Allow Flipping" in nvidia-settings prevent tearing in games
when this compiz option is at its default setting of on?

*My testing result is that with both totem and vlc, when the fullscreen
output isn't being redirected, even Allow Flipping doesn't prevent
tearing. But when I changed vlc's video output method from XVideo, which
works the best, to OpenGL, which is slightly slower, the tearing is
almost, but not completely, eliminated. Sync to VBlank in nvidia-
settings still doesn't seem to do anything, but turning Allow Flipping
back on does bring tearing back to zero. The other output methods also
don't eliminate tearing by themselves.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307144

Title:
  'unredirect fullscreen windows' causes tearing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1307144/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1307144] Re: 'unredirect fullscreen windows' causes tearing

[Misaki]

I'm sorry for triple-posting, but to summarize the end of my previous
comment: "Allow Flipping" in nvidia-settings > OpenGL Settings does
completely eliminate tearing for fullscreen, unredirected output for
OpenGL GLX output in vlc. It does eliminate, or affect tearing for the
XVideo output method. So it will probably help for OpenGL games.

There is still a minor amount of tearing, maybe one frame in 30~100,
even with OpenGL output and flipping enabled, when redirected by compiz
(not fullscreen). It seems the only thing that prevents this is the
"Force full screen redraws (buffer swap) on repaint" option... ok but
actually, as shown by the "Show Repaint" plugin, that was because there
was another vlc instance behind several other windows, that was paused
and therefore causing repaints.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1307144

Title:
  'unredirect fullscreen windows' causes tearing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1307144/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1444839] [NEW] jpeg-2000 files cause Nautilus to crash

[Misaki]

Public bug reported:

Diagnosing this bug may be complicated by Bug #1443809. I am currently
using a custom thumbnailer for jpeg-2000 files, but before I did so, I
had created a number of jpeg-2000 files. While there were some cases
where they caused a crash, I think the eventual result was that they all
had 'failed thumbnails' created for them. Possibly eog created valid
thumbnails for them. (I can't check to see what happened because I
deleted my old thumbnails folder after upgrading.)

With no custom thumbnailers, nautilus will crash upon encountering a
jpeg-2000 file, with file suffix .jp2. As noted in Bug #1444790, it
doesn't crash if the jpeg-2000 file has a different suffix; it just
produces a 'failed thumbnail' in the thumbnails folder, which for
current Ubuntu versions is ~/.cache/thumbnails/fail. If the file was
created by copying an existing jpeg-2000 file in nautilus, nautilus
still crashes but only after invoking eog to create a thumbnail, so
after this is complete, navigating to that folder won't cause a crash.

If the thumbnail check was performed because the jpeg-2000 file was
renamed from an inappropriate suffix to .jp2, or because it was renamed
by some other method while not looking at the directory containing that
file (such as the command line, or maybe using the 'undo' function in
nautilus though this would require 1) having a normal or failed
thumbnail 2) renaming the file 3) deleting the thumbnail 4) nautilus
would have to stop using the cached thumbnail, and I don't think it
does), nautilus will crash without invoking eog for thumbnail creation,
and so will continue to crash whenever that folder is viewed.

A jpeg-2000 file can be generated using mogrify from imagemagick with
the command 'mogrify -format jp2 image.jpg'.

The advantages and disadvantages of jpeg-2000, compared to jpeg, are
described here: http://x264dev.multimedia.cx/archives/317 The type of
encoding used by jpeg-2000 is better for edges, while that used for jpeg
is better for broad areas of smaller, but nonzero amounts of variation.
There are definitely cases where jpeg-2000 is a better choice than jpeg
for retaining what is viewed as a sufficient level of quality in an
image, but users are unlikely to use it more if their applications don't
support it very well.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 15 22:52:39 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 
'date_modified', 'date_accessed', 'type']
 b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 
'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 
'owner', 'permissions']
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: nautilus (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444839

Title:
  jpeg-2000 files cause Nautilus to crash

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444839/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1444881] [NEW] Autocomplete in 'open file' works wrong with folders

[Misaki]

Public bug reported:

This is related to what might also be a bug, where directories aren't
displayed at the top when sorting files by name in the 'open file'
dialogue. I think it used to work this way, but changed between Ubuntu
12.04 and 14.10.

So the fastest way to open files is often by typing. When an
autocompleted folder name is displayed and is the only possible result
for a path starting with those characters, pressing tab will cause the
autocompleted text to be entered, while pressing enter normally causes
the autocompleted folder to be navigated to.

If there is a file that starts starts with that folder's name in the
same directory, the bug described in this report doesn't occur.

But if no such file exists, then if all files in the autocompleted
folder start with the same letters, then pressing tab while the
autocompleted folder's name is highlighted will cause those common
letters to appear. Pressing enter instead of tab at the first step will
instead cause a file to be opened with the name of those common letters.

The case where I encounter this bug is manual files for ffmpeg, which
all start with 'ff' (and Ubuntu doesn't package ffmpeg which is why I'm
opening them with gedit).

Autocompletion includes the '/' used to denote folders.

So, for example, in the folder /tmp/h, you have these files:
i
il
iif/
iiif/

In the 'open files' dialogue, if you type '/tmp/h', an autocompleted '/'
appears. The expected behaviour is that if you press enter, you'll
navigate to /tmp/h and view the files it contains. What actually happens
is it opens '/tmp/h/i' for editing. Immediately after presseing enter
while the autocompleted '/' is displayed, it turns a normal colour
(instead of having autocompletion highlighting), an autocompleted 'i'
appears, and the open file dialogue closes, having selected 'i' to open.

If there is also a file '/tmp/hi', then the '/' is not autocompleted,
and pressing enter will just open the folder and display the letter 'i'.
If, instead, there is a folder /tmp/h/uuu/ and a file /tmp/h/,
and the folder uuu contains another folder u/ and a file ,
typing '/tmp/h/u' will cause an autocompleting 'uu' to be displayed (no
'/' at the end), and pressing enter will just display the folder.

If the file /tmp/h/ is removed or renamed to be shorter than
uuu/, then instead of 'uu', 'uu/' will be autocompleted, and pressing
enter will cause the folder /tmp/h/uuu/u/ to be opened, which is empty.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: gedit 3.10.4-0ubuntu6
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.3
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Apr 16 01:32:26 2015
SourcePackage: gedit
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gedit (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444881

Title:
  Autocomplete in 'open file' works wrong with folders

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1444881/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1407644] Re: eog doesn't show WebP images

[Misaki]

The bug for eog seems to be Bug #1318327. Should one of these bugs be
marked as a duplicate and the other project added to the list of
affected projects?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1407644

Title:
  eog doesn't show WebP images

To manage notifications about this bug go to:
https://bugs.launchpad.net/libwebp/+bug/1407644/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1444790] Re: crash if thumbnailer fails to produce output

[Misaki]

After removing custom thumbnailers, copying a jp2 file using ctrl-C
ctrl-V causes nautilus to crash about one time. gnome-thumbnailer tries
to create a thumbnail, but it can take several seconds, and if nautilus
is reopened and navigated to that folder again, it will crash again.
However, after this has been completed, nautilus won't crash. (In fact,
top reveals that it's eog that creates the new thumbnail if you use
ctrl-C ctrl-V in nautilus.)

If the new file name is obtained a different way, like using 'mv' on the
command line, navigating to that folder in nautilus will cause a crash
without attempting to generate a new thumbnail.

So even if you wait several seconds, no thumbnail will exist for the
file and nautilus will crash every time you navigate to that folder
until you delete the file or rename it to a path for which it will have
a valid thumbnail (meaning the file's mtime is correct).

So this might only affect jpeg-2000 files, and not all files for which
there is no valid output. Maybe with other files, the default thumbnail
options (the ones not recorded in /usr/share/thumbnailers) consistently
create at least a failed thumbnail, while this doesn't happen with
jpeg-2000 files. But since nautilus is crashing before eog finishes
creating a thumbnail (if using ctrl-C ctrl-V to copy), nautilus might be
relying on a separate process from what it depends on for, say,
obtaining a 'failed thumbnail' result for incomplete mp4 files, which
don't cause a crash.

One difference is that while gnome-thumbnailer has code for handling
image formats as a fallback method, it isn't for video formats. I'm not
sure if it's nautilus or gnome that's calling eog to create a thumbnail
when ctrl-C ctrl-V is used.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444790

Title:
  crash if thumbnailer fails to produce output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444790/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1318327] Re: Can't open .webp files

[Misaki]

The bug for libwebp seems to be Bug #1407644. Should one of these bugs
be marked as a duplicate and the other project added to the list of
affected projects?

I notice that ffmpeg (possibly with the right compile options) can open
.webp files, and ffmpeg uses the GNU General Public License version 2+
though that particular decoder might not.

eog also seems to use the GNU General Public License version 2+.

The other bug report says that using a gdk-pixbuf loader is the right
way to extend support, but in the meantime, could eog just use code from
ffmpeg, or even ffmpeg directly? (Imagemagick, for example, uses ffmpeg
to open video files.) It seems that having a poor solution may be better
than having no solution, if there is currently no motivation to
implement the 'correct' solution.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1318327

Title:
  Can't open .webp files

To manage notifications about this bug go to:
https://bugs.launchpad.net/eog/+bug/1318327/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1444790] Re: crash if thumbnailer fails to produce output

[Misaki]

If you rename a jp2 file to jpg, it doesn't cause nautilus to crash. It
just shows the 'generic image' icon that's also used if an image is
larger than the limit set for previewing, and eog is unable to open it.

If a jp2 file is renamed to have a non-image suffix, nautilus will be
busy (100% cpu) for a second or two and then the image will use the
'generic icon', without nautilus crashing. With image suffixes, this
doesn't occur.

I also managed to replicate a bug that I avoided reporting earlier
because I couldn't replicate it again. A png image has a 'corrupted'
thumbnail, what is obviously the result of the file being read in an
unfinished state. That is, gnome-thumbnailer or nautilus, or whatever is
creating thumbnails, should be waiting until a file's modification time
is 3 seconds in the past before trying to create a thumbnail for it,
based on the code I looked at. This seems to work for video files, but
not for images. When this happened before I verified that the difference
between the modification time for the thumbnail (now in
~/.cache/thumbnails in Ubuntu, previously in ~/.thumbnails), and the
time for the file as recorded in the thumbnail's PNG data and the same
as for the actual file, was less than three seconds, being around 1
second. Maybe nautilus is not using this code though.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444790

Title:
  crash if thumbnailer fails to produce output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444790/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1444807] [NEW] jpeg-2000 images appear in a window of the wrong size

[Misaki]

Public bug reported:

jpeg-2000 images appear in a small window, the smallest allowed by eog,
instead of at the size of the image (or some other large size if the
image is larger than the screen).

This happens for both jp2 images output from imagemagick's convert and
mogrify, and from a reference image at http://opf-labs.org/format-corpus
/jp2k-formats/ . Note that due to Bug #1444790, the reference .jp2 image
on that site may cause nautilus to crash when viewing a directory it's
saved in, but eog can display the image fine (and creates a thumbnail so
viewing the directory won't cause another crash).

eog can correctly display these images, and their image size shows up in
exiftool or imagemagic's 'identify', so this information should also be
available to eog when opening them.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: eog 3.12.2-0ubuntu2
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 15 20:00:46 2015
SourcePackage: eog
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: eog (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444807

Title:
  jpeg-2000 images appear in a window of the wrong size

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1444807/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1444790] [NEW] crash if thumbnailer fails to produce output

[Misaki]

Public bug reported:

Step 1: Use a custom thumbnailer which doesn't always produce output.
I'm personally using this one, since the default size (256x256) often
produces a png thumbnail which takes more space than the original jpg
image, and imagemagick's convert seems to have a bug for palette-png to
grayscale conversion:

[Thumbnailer Entry]
TryExec=ffmpeg
Exec=ffmpeg -i %i -vf 
scale='min(iw,128):min(ih,128):force_original_aspect_ratio=decrease',format=rgba|rgb24
 -frames 1 -y -f image2 -c:v png %o
MimeType=image/gif;image/jpeg;image/png;image/jp2;image/x-webp

Step 2: navigate to a folder that the thumbnailer can't handle. For me,
that was balloon.jp2 from http://opf-labs.org/format-corpus/jp2k-
formats/

My version of ffmpeg says on the command line that Progression order
RPCL is not implemented. [...] Output file is empty, nothing was
encoded. Not having any file from the thumbnailer, or maybe having an
empty, 0-byte file (ffmpeg does not produce a 0-byte output file from
the command line), causes nautilus to freeze and crash.

This happened multiple times. However, just now I checked and it didn't
crash, and a thumbnail exists for the jp2 image, /sigh. But creating a
copy of the jp2 image does lead to crashes. Ok, the reason is that eog
creates a thumbnail when one doesn't exist and the system's default
thumbnailers fail. Opening the image gallery in eog causes thumbnails to
be created for all visible images.

That is, when running eog from a terminal, opening the image gallery
caused ffmpeg's output (with the error message) to be displayed in that
terminal. But the thumbnail is still created, and eog must have done it.

It's also possible nautilus crashes when the fallback gnome-thumbnailer
fails to create a file, which I think is what happens when it tries to
open a jpeg-2000 file. A few months ago I noted this bug:

Another bug, crashes when trying to generate thumbnail for jpeg-2000
(jp2). Avoided if thumbnail is already created, maybe in some other
cases too. Possibly just when thumbnail isn't created quickly enough
(thumbnailer fails or something).

...but apparently I fixed it somehow, not sure.

So it's totally fine that no thumbnail is created when the existing
thumbnailer entries aren't sufficient. But nautilus shouldn't crash.
When running nautilus from the command line, it says there was a
segmentation fault, core dumped, with a crash file being generated in
/var/crash (which I'm deleting).

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 15 20:48:20 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 
'date_modified', 'date_accessed', 'type']
 b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 
'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 
'owner', 'permissions']
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: nautilus (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444790

Title:
  crash if thumbnailer fails to produce output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444790/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443794] [NEW] Folders with large names cause icons to disappear

[Misaki]

Public bug reported:

if displayed path is too long, window expands. Might be related to font,
if number of characters before inserting ellipsis is decided before font
is rendered.

the tools to the right of the path are pushed right, even if this pushes
them off the rendered window.

minimum is apparently 675 pixels, before borders from window manager.

icons also expand into the new space, so the rightmost rows can end up
off-screen.

reset by using a path that avoids folders with names that are too long,
either before or after the current folder.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 00:34:47 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 
'date_modified', 'date_accessed', 'type']
 b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 
'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 
'owner', 'permissions']
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: nautilus (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

** Attachment added: Screenshot from 2015-04-14 00:37:17.png
   
https://bugs.launchpad.net/bugs/1443794/+attachment/4374731/+files/Screenshot%20from%202015-04-14%2000%3A37%3A17.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443794

Title:
  Folders with large names cause icons to disappear

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443794/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 797485] Re: Status Bar Covers File Name at Bottom

[Misaki]

I don't feel like commenting on the Bugzilla bug report, which states that . . .
blockquoteWe will remove the floating bar after releasing 3.16, so probably 
this won't be need at all./blockquote

. . . but this could be fixed by increasing the vertical scrollable size
of the window when the last row is selected.

The vertical size already increases based on the length of file names in
the last row, this would just be an extension of that. The comment on
Bugzilla also does not say what they are replacing the floating bar
with. Being able to see the size of a file, without having file size
always enabled at default zoom level, using just a single click is
useful and it shouldn't go away.

Alt-enter is not a replacement because it takes longer, and not everyone
has a fast computer. The lag it takes to open the properties window also
seems to scale with the number of items in the folder.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/797485

Title:
  Status Bar Covers File Name at Bottom

To manage notifications about this bug go to:
https://bugs.launchpad.net/nautilus/+bug/797485/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443849] [NEW] Copying a line with full-width character at end adds a space

[Misaki]

Public bug reported:

If a full-width character, such as a Chinese character, starts at the
last column of a line, it is moved to the start of the next line. The
last column is then displayed as being empty. However, if that line is
selected using the mouse and copied using shift-ctrl-C, or simply using
middle-click paste, a space is added to the line at that location.

A common place where this can occur is in filenames.

I assume this is a bug in gnome-terminal, and not bash, but I'm not
entirely sure.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: gnome-terminal 3.6.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 02:36:30 2015
SourcePackage: gnome-terminal
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gnome-terminal (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443849

Title:
  Copying a line with full-width character at end adds a space

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443849/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 952108] Re: [Precise] Nautilus: memory leak

[Misaki]

I don't know if there are multiple memory leaks, but I am reporting on
this one. The Bugzilla report is not relevant to my particular version
as one comment on Bugzilla says this:

Obviously also related to wcslen so correctly closed as NOTABUG in
Nautilus because it is not a bug in Nautilus.

wcslen is described as Get wide string length. Returns the length of
the C wide string wcs. This is the number of wide characters between
...


So while the Bugzilla report as marked as RESOLVED DUPLICATE, I am reporting a 
new issue.

Steps to replicate:

1) Open a folder with many image files.
2) Change to list view.
3) zoom to maximum size, it's faster this way but still happens at normal size.
4) Scroll up and down.

Result, nautilus will use more memory.

The fact that it leaks memory faster at a higher zoom level indicates
that it isn't related to the length of strings, but rather has to do
with images somehow.

This doesn't happen in icon view. What does happen in icon view, if you
zoom to maximum size, is that nautilus temporary uses more memory while
it caches higher-resolution thumbnails it generates, possibly only if
the existing thumbnails aren't large enough. But most or all of this
memory is freed when you reload the folder or navigate away. This
doesn't happen with the memory from this leak. Memory usage does go down
slightly, like for me it just went from ~830 MiB or something to 780
when I went from list view to icon view, but when I did this after
zooming in icon view, it went from ~230 to ~60 MiB.

When I was testing this before, it seemed like the memory didn't leak
until you had scrolled far enough; just scrolling a bit, like half a
page on normal zoom, didn't seem to cause a leak even when repeated. But
using a high zoom makes it easy enough to replicate that details like
that shouldn't matter.

In fact, simply increasing the zoom level could cause a memory leak. I
just did that, without scrolling, and watched memory usage go from ~780,
where I was before, up to 975 MiB. After returning to normal zoom and
refreshing, memory went down to ~914. After repeating the process, over
1 GiB.

At normal size, in list view, scrolling down to the bottom of 342 images
and then back up to the top causes Nautilus to use about 20 MiB more
memory, each time you do it. In icon view, doing this has no noticeable
effect. However, changing to list view, and then changing back to icon
view, with no other actions taken, does cause memory to increase by
about 6 MiB each time I do it.

New thumbnail creation is probably happening because there is high CPU
use; it's possible it's not caching thumbnails in list view., or caching
a limited amount or number and not freeing memory after it decides a
thumbnail is no longer cached. At largest zoom, each image was adding
1.3 MiB of memory to Nautilus when I pressed down once; same thing if I
pressed 'home' and 'end' repeatedly.

I'm using Nautilus 3.10.1, with Ubuntu 14.10.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/952108

Title:
  [Precise] Nautilus: memory leak

To manage notifications about this bug go to:
https://bugs.launchpad.net/nautilus/+bug/952108/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443809] [NEW] Failed thumbnail check not working properly

[Misaki]

Public bug reported:

This is related to the gnome-thumbnailer code which is part of Nautilus.
However, I don't know enough about programming to fix it myself.

If a failed thumbnail exists for a file, or specifically a universal
resource identifier, Nautilus will not try to create a valid thumbnail
for it, unless a non-failed thumbnail also exists for that URI/path.

Steps to replicate:

1) Create a new, blank document named image.jpg
2) make sure the failed thumbnail has been created, such as by restarting 
nautilus with 'nautilus --quit'
3) navigate back to that folder, rename or delete the blank file, and rename 
another image to image.jpg.

Result: no thumbnail will be created for the image.

When I was checking the thumbnail code for an unrelated issue (256x256
thumbnails take up too much space as PNG, sometimes larger than original
file), I also saw enough to be able to investigate this issue a little.
In the code for Nautilus, or gnome-thumbnailer, that I looked at, it
appeared that the code was doing a check to see if the failed thumbnail
was valid.

That is, if the modification time of the file as recorded in the PNG
Chunk data does not match, it probably shouldn't count as a match for
the file. But either it is incorrectly matching, or something else is
wrong.

While testing for an unrelated issue that seemed like it might no longer
exist, I found that as Firefox saves an item by creating a placeholder
and then saving the actual file using a .part suffix (unless changed in
options probably), it leads to this bug.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 00:40:58 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 
'date_modified', 'date_accessed', 'type']
 b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 
'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 
'owner', 'permissions']
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: nautilus (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443809

Title:
  Failed thumbnail check not working properly

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443809/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443809] Re: Failed thumbnail check not working properly

[Misaki]

** Also affects: gnome-desktop
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443809

Title:
  Failed thumbnail check not working properly

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443809] Re: Failed thumbnail check not working properly

[Misaki]

I may have misfiled this, but not quite sure which project is
responsible.  I also note that when adding gnome-desktop to the list of
affected projects, it said gnome-desktop does not use Launchpad to
track bugs. Nobody will be notified about this issue.

Added a screenshot of an image not being thumbnailed.

The relevant function seems to be 
gnome_desktop_thumbnail_factory_has_valid_failed_thumbnail ()
https://developer.gnome.org/gnome-desktop/stable/GnomeDesktopThumbnailFactory.html#gnome-desktop-thumbnail-factory-has-valid-failed-thumbnail

This is old code because I don't know how to reference the latest code:
http://sourcecodebrowser.com/gnome-desktop/2.32.0/gnome-desktop-thumbnail_8h.html#ab9946e6856418572e55147637a1493ab

It includes this:

  pixbuf = gdk_pixbuf_new_from_file (path, NULL);
  g_free (path);

  if (pixbuf)
{
  res = gnome_desktop_thumbnail_is_valid (pixbuf, uri, mtime);
  g_object_unref (pixbuf);
}

  g_checksum_free (checksum);

It mentions mtime, yet evidently that is not being checked if the
process described in this report can cause a new thumbnail to fail to be
generated.

As implied in the original report, if there is a valid thumbnail and
also a failed thumbnail for the same path to a file, if the valid
thumbnail doesn't match the mtime of the actual file, a new thumbnail
will be generated. So it seems to work unless no 'normal' thumbnail
(whether normal or large-sized) already exists.

** Attachment added: Screenshot from 2015-04-14 01:15:35.png
   
https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+attachment/4374819/+files/Screenshot%20from%202015-04-14%2001%3A15%3A35.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443809

Title:
  Failed thumbnail check not working properly

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443835] [NEW] 'Advance by one frame' doesn't work at video's end

[Misaki]

Public bug reported:

Using the 'advance by one frame' feature (default key 'e')doesn't work
for around the last second of a video. It might instead affect a certain
number of frames.

If you play a file at normal speed until just before the end, 'e' will
work one time. After that, it won't work until you rewind, or possibly
if you press start and stop very fast without reaching the video's end.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: vlc 2.2.0-0ubuntu0.14.10.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 02:12:01 2015
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: vlc (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443835

Title:
  'Advance by one frame' doesn't work at video's end

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443835/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443846] [NEW] 'Advance by one frame' no longer works at beginning of video

[Misaki]

Public bug reported:

This might be a totem issue, not a gstreamer one; the ubuntu-bug program
asked what was happening and I selected video not playing correctly.

After I upgraded from Ubuntu 12.04 to Ubuntu 14.10, with whatever
gstreamer or totem changes were involved with that, 'advance by one
frame' (the '.' key) didn't work as well. It will almost always not work
at the very start of a video. Sometimes instead of one frame, it will
advance around half a second. Other times, maybe related to seeking in
the video after using it without first starting normal playback again,
it will not work properly or will send you back to where you were in the
video before you seeked to a different time.

Occasionally, it will work at the start of a video, but very rarely if
ever can you do this by pausing, seeking to the start of a video, and
then pressing '.' . You used to be able to do this though.

Right now, trying to seek near the start of a video, if it doesn't just
send you back to wherever you were, usually skips several frames, like 6
frames or so, then starts normal behaviour of advancing 1 frame at a
time.

On a related note, the 'one frame back' key (the ',' key) is either
broken by design or partly by accident. Pressing it usually either
freezes the video, so you have to seek to a different location in order
for the video to start playing normally, or it causes the video to seek
to a totally separate time, and subsequently pressing '.' causes a frame
to be shown which is at a completely separate time than what ',' was
returning. When ',' works instead of freezing the video (possibly only
before I upgraded to 14.10 several months ago), it seemed to usually
seek to near the start of the video before returning frames, though the
'.' key would sort of let you reset playback to where it was before.

As a quick test, I just tried it on a webm/VP9 video, though I think the
same thing happens with other videos:

1) Played for a few seconds, then pressed and held '.' . Result, video advances 
at the rate of keyboard sending '.' events.
2) Pressed and held ','. Result, video went back maybe a second, but then 
actually played backwards.
3) Pressed and held '.' again. Result, video played backwards instead of 
advancing forwards like the key should do.
4) With video paused, seeked forward by 15 sec, and pressed '.' again. Result, 
progress bar moved back to video start where it was before seeking, and video 
didn't advance as probably still trying to go backwards.
5) With video paused, seek forward by clicking. Unpause video. Result, it goes 
back to start and doesn't play.
6) With video on play but not playing, seeked forward again. Result, starts 
playing from beginning.
7) With video on play and playing, seeked to a different location. Result, 
video still on play but not playing.
8) Paused and then unpaused, video starts playing again.
9) Pressed and held '.' again, video slowly moves forward.
10) Pressed ',' , totem crashes. (don't remember this happening before)

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: libgstreamer1.0-0 1.4.3-1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 02:12:17 2015
SourcePackage: gstreamer1.0
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gstreamer1.0 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443846

Title:
  'Advance by one frame' no longer works at beginning of video

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gstreamer1.0/+bug/1443846/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443852] [NEW] Display bug for editing lines with full-width characters

[Misaki]

Public bug reported:

I'm not entirely sure this isn't a bug with bash, instead of gnome-
terminal.

Full-width character, followed by at least one full word with a space
after it.

Example: あa a

With trailing space.

Typing before the full-width character causes the 'あ' to be pushed to
next line, with a blank space on previous line though if selected and
copied it will actually produce a space.

The 'あ' occupies two columns on the new line, but characters after the
first a are only moved one column to the right. The first a, or the
first character after the 'あ' including a space, is pushed two columns
to the right, covering the second character after the 'あ'.

A similar bug occurs when deleting characters before the 'あ', except no
trailing space is required. A character is duplicated but might be first
letter of first word on second line, or last letter of next word.
Duplicating one letter as soon as 'あ' goes to previous line is easy to
replicate; duplicating other letters as further characters before 'あ'
are deleted might only happen after resetting the line using up arrow
then down arrow, but actually just because of forward bug because
displayed characters change after pressing up then down. Second word on
line only seems to be affected if no other words after it.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: gnome-terminal 3.6.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 02:37:03 2015
SourcePackage: gnome-terminal
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gnome-terminal (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443852

Title:
  Display bug for editing lines with full-width characters

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443852/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443852] Re: Display bug for editing lines with full-width characters

[Misaki]

The trailing space doesn't show up as excess whitespace is removed on
launchpad, however it was necessary to replicate the bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443852

Title:
  Display bug for editing lines with full-width characters

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443852/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443864] [NEW] Possible freeze and crash if loop for nonexisting file

[Misaki]

Public bug reported:

If vlc is trying to load a file, or multiple files that don't exist, CPU
usage will increase while many error messages announcing this problem
will appear. This can lead to a freeze and crash, and pressing 'hide
future errors' might not help since CPU usage will still be high.
Sometimes it's possible to fix this by quickly pressing the stop button,
but this doesn't always work.

Desired result: if a full loop of a playlist, or always if set to loop a
single item, results in no items being found, VLC should wait for a bit
before trying again. Pressing spacebar or any other key that normally
pauses the video (as opposed to stopping it) should also cause it to
stop trying to load more items.

It doesn't seem to be easy to cause VLC to actually lock up... ok in
fact, what just happened was that by trying to play a file that didn't
exist several times, after I stopped trying my CPU usage was high
despite that VLC was supposedly not trying to open anything as no error
messages were showing up. Pressing the stop button repeatedly did not
change this, despite that pressing it caused it to change to the 'button
pressed' animation.

Then after playing a video and then stopping it, CPU usage was back to
0.

Locking up might only seem to happen when VLC has been trying to open
non-existent files for a few seconds too long; the 'non-responsive' test
in Compiz that causes unresponsive windows to darken can activate. Just
now, with vlc running at 100% of a CPU despite that no error messages
were turning up, I tried starting it (to play a non-existent file) and
then immediately stopping it, yet despite continually trying to click on
the stop button, it took probably 12 seconds to stop.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: vlc 2.2.0-0ubuntu0.14.10.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 02:46:27 2015
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: vlc (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443864

Title:
  Possible freeze and crash if loop for nonexisting file

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443864/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443864] Re: Possible freeze and crash if loop for nonexisting file

[Misaki]

If VLC is actively trying to open a new file, it can use all available
CPUs, or at the very least two of them. After that, if it has an
anomalously high CPU usage, it will only use 100% of one CPU. However,
it seems that after a while this will stop even if no other videos are
played; and in fact, playing an existing video does not actually cause
the high CPU usage to stop; only after enough time has passed will it
stop.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443864

Title:
  Possible freeze and crash if loop for nonexisting file

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443864/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443886] Re: Scrollbar disappears in windows like gnome-terminal

[Misaki]

gnome-terminal seems to have an additional bug though, maybe related to
tabs, that makes the scroll bar not appear even when doing the steps
described in this report.  It might be as simple as after switching
tabs, the scrollbar doesn't appear until you create a new line at the
bottom of the terminal.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443886

Title:
  Scrollbar disappears in windows like gnome-terminal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1443886/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443886] [NEW] Scrollbar disappears in windows like gnome-terminal

[Misaki]

Public bug reported:

Not sure if this is a Compiz bug, but it's related to windows
management. The type of scroll bar used in gnome-terminal was also the
same as that in Firefox before I upgraded my system to Ubuntu 14.10 at
the same time I upgraded Firefox to version 34 or so (so either Firefox,
or some other program changed how scrollbars look).

Switching to windows that use 'thin scroll bar', only ~3 pixels wide
with no arrows

If done quickly, it works fine as long as the mouse cursor is pointing
at the window being focused to. If done slowly, by pressing alt-tab and
holding alt, the scroll bar will disappear or become faded. Faded
scrollbar is when alt is held for a very short period of time, so the
application switcher menu only shows up for ~0.1 sec.

Using static application switcher in compiz.

Window's shadow border also sometimes longer to appear if alt is held,
but it doesn't seem consistent or related to scrollbar.

The 'invisible' part is an overlay that's the same colour as the
background. If scrolling up or down, when the line representing the
current location moves past the 'invisible' part, it's erased, so that
if the line representing the visible portion is returned to that area,
the 'invisible' part is smaller.

Nautilus, gedit, and gnome-terminal all seem to be affected by this bug.
The line isn't totally invisible, but being able to see it could depend
on having an LCD screen that provides high contrast near the white range
at that viewing angle. All three of these applications are demonstrating
the bug for me right now, but I'm not sure if they always do.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: compiz 1:0.9.12+14.10.20140918-0ubuntu1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
.proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: 
'/proc/driver/nvidia/gpus/0'
.proc.driver.nvidia.registry: Binary: 
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module  331.113  Mon Dec  1 21:08:13 
PST 2014
 GCC version:  gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)
.tmp.unity.support.test.0:
 
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CompizPlugins: 
[core,composite,opengl,compiztoolbox,decor,imgpng,regex,gnomecompat,place,move,vpswitch,mousepoll,obs,wall,animation,shift,snap,resize,expo,session,ezoom,workarounds,staticswitcher,fade]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Tue Apr 14 03:45:07 2015
DistUpgraded: Fresh install
DistroCodename: utopic
DistroVariant: ubuntu
DkmsStatus:
 bbswitch, 0.7, 3.16.0-30-generic, x86_64: installed
 nvidia-331, 331.113, 3.16.0-30-generic, x86_64: installed
 nvidia-331-uvm, 331.113, 3.16.0-30-generic, x86_64: installed
GraphicsCard:
 NVIDIA Corporation G96M [GeForce 9650M GT] [10de:064c] (rev a1) (prog-if 00 
[VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:1912]
MachineType: ASUSTeK Computer Inc. N50Vn
PackageArchitecture: all
ProcKernelCmdLine: root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet 
splash
SourcePackage: compiz
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/05/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 211
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: N50Vn
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: ATN12345678901234567
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: N50Vn
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.
version.compiz: compiz 1:0.9.12+14.10.20140918-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.56-1
version.libgl1-mesa-dri: libgl1-mesa-dri 10.3.2-0ubuntu0.1
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 10.3.2-0ubuntu0.1
version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A
version.xserver-xorg-core: xserver-xorg-core 2:1.16.0-1ubuntu1.3
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.9.0-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.4.0-2ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.914-1~exp1ubuntu4.2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.11-1ubuntu2
xserver.bootTime: Mon Apr 13 00:44:08 2015
xserver.configfile: /etc/X11/xorg.conf
xserver.errors: Error loading keymap 
/var/lib/xkb/server-09D1F3CDBE4F6C8C6E82A68933E164F92A33A272.xkm
xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 
xserver.version: 2:1.16.0-1ubuntu1.3

** Affects: compiz (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 

[Bug 1443856] Re: Very short videos won't play

[Misaki]

** Description changed:

  A very short video, such as 1 frame long, won't play in VLC. Nothing
  will show up, even if the video is paused.
  
  A 1-frame video can be useful for things like testing the performance of
  different encoding settings. While it's possible that VLC (maybe
  depending on vout display module) causes the appearance of a video to
  change slightly so it's not directly comparable to display by other
  software, the display of two VLC instances can generally be compared to
  each other.
  
  The 1-frame video can be converted to a different format, but sometimes
  this is lossy.
  
  A bit related, if a video is very slow, like 1 frame per second, it
  won't show up for a while in VLC. It's possible VLC is trying to buffer
  several frames before showing anything.
  
  Maybe also related, I noticed in ffmpeg, which VLC uses for decoding,
  that a filtergraph wasn't receiving frames until at least two frames had
- a DTS that was before the PTS of the frame entering the filtergraph. So
+ a DTS that was after the PTS of the frame entering the filtergraph. So
  it's possible VLC is not receiving frames from libav (?).
  
  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: vlc 2.2.0-0ubuntu0.14.10.1
  ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
  Uname: Linux 3.16.0-30-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.14.7-0ubuntu8.2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Apr 14 02:45:45 2015
  SourcePackage: vlc
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443856

Title:
  Very short videos won't play

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443856/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443856] [NEW] Very short videos won't play

[Misaki]

Public bug reported:

A very short video, such as 1 frame long, won't play in VLC. Nothing
will show up, even if the video is paused.

A 1-frame video can be useful for things like testing the performance of
different encoding settings. While it's possible that VLC (maybe
depending on vout display module) causes the appearance of a video to
change slightly so it's not directly comparable to display by other
software, the display of two VLC instances can generally be compared to
each other.

The 1-frame video can be converted to a different format, but sometimes
this is lossy.

A bit related, if a video is very slow, like 1 frame per second, it
won't show up for a while in VLC. It's possible VLC is trying to buffer
several frames before showing anything.

Maybe also related, I noticed in ffmpeg, which VLC uses for decoding,
that a filtergraph wasn't receiving frames until at least two frames had
a DTS that was before the PTS of the frame entering the filtergraph. So
it's possible VLC is not receiving frames from libav (?).

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: vlc 2.2.0-0ubuntu0.14.10.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 02:45:45 2015
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: vlc (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443856

Title:
  Very short videos won't play

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443856/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443879] [NEW] Find from typing selects hidden files

[Misaki]

Public bug reported:

I think this changed when I upgraded from Ubuntu 12.04 to 14.10.

When searching by typing, which only searches in the current directory,
hidden files are now selected. This would maybe be fine except that
there's no feedback that a hidden file has been selected. Normally, if a
file exists it's selected and nautilus will scroll to its location. If
it's hidden, it seems like it doesn't scroll to its location.

So if you want a file that does exist, but there's also a hidden file
that begins the same way, there's no feedback that any file named what
you want exists in that folder.

As a practical example, gedit automatically saves the previous version
of a file to name~ when one is saved, which is a hidden file. When
sorted by modification date, that older file will come first, and
automatically typing will not indicate that the desired, non-hidden file
exists, although it can still be selected by scrolling after typing.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: nautilus 1:3.10.1-0ubuntu15.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 03:29:12 2015
GsettingsChanges:
 b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 
'date_modified', 'date_accessed', 'type']
 b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 
'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 
'owner', 'permissions']
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: nautilus (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443879

Title:
  Find from typing selects hidden files

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443879/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 495880] Re: File Roller cannot handle archive that doesn't encode filenames in UTF-8

[Misaki]

The undocumented -O/-I option~

So unzip can handle different encodings, at least when I tested it. But
it doesn't handle them automatically. p7zip doesn't work because, as
noted in Bug #269482, it only handles UTF-8 and ASCII (or maybe
ISO-8859).

When I uninstalled p7zip and p7zip-full and looked at archives, some had
the pattern of mojibake that I'm used to, and some had a new type. None
of them were correct. So it's possible there is some automatic
correction and this is why Bug #580961 for unzip has been marked as
fixed.

Automatic detection can probably usually be correct, but it could also
sometimes be wrong. Either file-roller or unzip could probably improve
their automatic detection, and in case certainty is low communicate this
to users so they know there might be a problem.

Two other bugs, #592109 and #1199239, refer to non-ASCII filenames
encoded in UTF-8, which is likely to be the output from Unix-like
systems.

So non-UTF-8 encodings are probably from computers running Windows (?).

Some open-source programs that do automatic detection of encodings
include Firefox and, I think, gedit. Also maybe a bit similar to magic
numbers used to determine file types..?

This might be how those programs already do this, but I think the way to
detect the proper encoding is to interpret the filenames as a certain
type, and then look for characters, or character combinations, that are
unlikely to appear in a normal filename, or that can't even be output on
the file system type.

For example, the character '‚', U+0082 control BREAK PERMITTED HERE,
often appears in some languages when common encodings are interpreted as
iso8859(-number?). Either file-roller or unzip could test various
combinations to see what looks valid.

This is worse than an archive file saying what encoding it uses, but
basically it seems like some regions (like Japan) don't feel like using
UTF-8. The zip format, which is probably worse than other formats in
handling filenames, is probably still used because it encodes the
contents of files separately, which means it's faster but gives worse
compression than other archive formats. Maybe there are other reasons
it's faster too.

Having a unique file suffix for a certain set of compression options or
quality means that people don't have to worry about which options to
choose, and can't argue about which ones other people should use for
that suffix. There is probably also a sort of stigma attached to having
a poor compression ratio for many types of files, compared to other
formats. (For example, some non-zip archive formats can compress a
windows bmp file so that it's smaller than a png of the same image,
especially if the image has repeating portions.)

So either people can agree on a 'low-quality' archive suffix to use in
cases where actual compression isn't important, that's also operating-
system independent, or we will continue to encounter zips from different
languages that don't tell you how to decode the file names.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/495880

Title:
  File Roller cannot handle archive that doesn't encode filenames in
  UTF-8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/495880/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1444210] [NEW] Previewed files are not deleted

[Misaki]

Public bug reported:

It seems like this could be related to Bug #137308, where a user
complained that previewed files were being deleted.

file-roller, also known as Archive Manager, doesn't delete files that
are previewed without extracting them to a known location first. These
previews are stored in ~/.cache/.fr-random string.

I believe the /tmp directory is cleared each time the system is
restarted, but maybe the preview files aren't stored there for security
reasons.

eog seems to not store references to a file maybe by design; sometimes
when you change a file on disk, eog will reload the file, but it doesn't
always do so. So maybe can't rely on other applications that have the
file 'open' to actually have a reference to the index node or whatever,
and users will expect the preview not to be deleted immediately.

Currently, it seems like some, and maybe all preview files are retained
indefinitely, unless manually deleted. If a file is previewed more than
once, multiple copies are created. Over time this can add up to a
considerable amount of disk space.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: file-roller 3.10.2.1-0ubuntu5
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Apr 14 17:05:57 2015
SourcePackage: file-roller
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: file-roller (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1444210

Title:
  Previewed files are not deleted

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/1444210/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 495880] Re: File Roller cannot handle archive that doesn't encode filenames in UTF-8

[Misaki]

Along with the command-line version of unzip with the -O option, you can
also use the convmv command to change filenames of previously extracted
files. This works on an ext3 filesystem, but NTFS may give an error
because filenames are invalid. ext3 says the encoding is invalid but
still lets them be renamed to that.

So for anyone who encounters this bug report and is concerned
specifically with extracting filenames from shift-jis encoded archives,
these are the commands you can use:

(navigate to directory, and...)
unzip -O shift-jis filename
or
convmv * -f utf8 -t iso8859-1 -r
convmv * -f utf8 -t iso8859-1 --notest -r ; convmv -f shift-jis -t utf8 * 
--notest -r

One of the other bug reports links to this, which lists solutions and problems:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483290

One consideration might be if files in the same archive use different
encoding types. It seems reasonable that they appeared that way to the
archive's creator, and thus they shouldn't be interpreted separately,
but it could lead to the wrong conversion method being selected.

The patch linked in that bug report describes the options -O and -I,
which aren't documented in unzip's manual pages, so it's possible that
patch is already applied. But it still didn't detect 'proper' encodings
for me when I tested file-roller, using unzip, on several archives after
uninstalling p7zip.

The patch also talks the current locale charset. Making assumptions
about the encoding used on files could be correct for many people, most
of the time, but will be incorrect for other people, and so is at best
only a partial solution. I don't know what the patch does after that
though.

Just for reference, these are other Debian bugs mentioned in that
report:

 Bug#197427: unzip: chinese filenames unwrapped on unix wrongly
 Bug#197428: unzip: zipinfo (and unzip) can't deal with chinese filenames like 
 miniunzip can
 Bug#339021: unzip: incorrectly converts cyrillic file names from 
 Windows-created ZIPs

** Bug watch added: Debian Bug tracker #483290
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483290

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/495880

Title:
  File Roller cannot handle archive that doesn't encode filenames in
  UTF-8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/495880/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443856] Re: Very short videos won't play

[Misaki]

'Drop late frames' makes all frames other than the first one be dropped,
because they're late, despite the video being only 1 fps and taking
almost no CPU percent to play.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443856

Title:
  Very short videos won't play

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443856/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443856] Re: Very short videos won't play

[Misaki]

This video demonstrates the problem. The video starts at 0, as
demonstrated by looking at the frames such as with ffprobe
-select_streams 0 -show_frames timing.mp4 |less.

But vlc starts video playback around 2, showing frame 0 at that time,
and ends at the 6th frame (frame 5), not displaying the last four frames
at all. As with bug #1443835, pressing 'e' to advance a frame doesn't
work.

Changing decoding and output options doesn't change this. Seeking to the middle 
of the video, though, does cause vlc to...
1) display frame 5
2) very briefly display frame 6
3) display frames 7, 8, and 9 for the normal time duration.

This could be related to frames 8 and 9 having no decoding-time-stamp
listed in ffprobe, so vlc or libav could decide to decode them
simultaneously (instead of 1 sec apart), and then display the most
recent frame in the buffer (since it's already 2 sec late) each time one
of those frames is decoded. It isn't clear why this doesn't happen for
normal playback though, without seeking.

The video was generated with this command:
 ffmpeg -ss 4.5 -i '『-Project DIVA F-』 - Nostalgic [40_XMJzyQPE].webm' -vf 
fps=1,split[crop],lutyuv=val/1.2-10:val/2+64:val/2+64[bottom],[crop]crop=iw:ih/4:0:'mod(n,4)*ih/4',[bottom]overlay=0:'mod(n,4)*h'
 -hide_banner -t 10 timing.mp4

I note that avplay (I don't have ffplay) plays it better; it does
display the first frame only briefly, and then turns black, but all the
rest of the frames are displayed at the correct times. (Totem also works
correctly.)

So it seems like vlc should be getting frames earlier than it is. Since
framerate can be variable, this wouldn't be based on a buffer of a
certain length of time.

** Attachment added: timing.mp4
   
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443856/+attachment/4375581/+files/timing.mp4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443856

Title:
  Very short videos won't play

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443856/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1443856] Re: Very short videos won't play

[Misaki]

If it helps, the OpenH264 codec by Cisco provided with Firefox does even
worse; it stops after frame 1 (2nd frame) and then causes 100% CPU, I
have to restart

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1443856

Title:
  Very short videos won't play

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1443856/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264

[Misaki]

Well I'm linking this unrelated thing just for the lulz
http://pastebin.com/1htuH2jX

But I have found that all the videos that appear to 'work' using the
combination of VDPAU hardware decoding and xcb_xv as the vout display
module only due so because the decoder profile is above the limits for
the hardware's settings.

Specifically, it appears my graphics card is rated in VDPAU up to h264
profile 4.2, while anything that is detected as being at level 5 or
above will not use hardware acceleration with VDPAU.

Other hardware acceleration options, like VA-API with X11, do attempt to
decode videos above this level even if they're not fast enough to do so
but they are also not affected by the bug that's the subject of this
report.

'Ultrafast' output from x264 (using ffmpeg) is reported in vlc as being
level 6. 'Format 18' in YouTube is reported as level 6 as well. The
video sample reported as working attached to the original report shows
up as level 51, meaning level 5.1, as it omits the decimal point for
some reason.

The larger YouTube videos that worked did so because they are level 5 or
5.1 as well.

It's unclear whether the videos that are reported as being level 6 are
shown as such incorrectly. I think I didn't bother to test all the
options that the ultrafast preset in x264 uses, but I did notice that
when playing a video output from the ultrafast preset, my 'GPU
Utilization' as reported in the Nvidia X Server settings was high,
whereas normally for VLC it isn't high.

A quick summary, the hardware acceleration options in VLC mostly use the
'Video Engine Utilization', instead of the 'GPU Utilization'. In
contrast, totem (which might be using ffmpeg plugins though) uses GPU
Utilization, and no Video Engine Utilization at all.

It might vary a bit depending on the options (the 'overlay output' and
'direct rendering' settings affect it too I think), but disabling
hardware acceleration in VLC causes 'Video Engine Utilization' to go to
zero, while GPU Utilization is unaffected and still significantly lower
than totem. I think in this case, CPU use is higher than what totem uses
but only a little.

So vlc might be using the same options as totem when decoding and
playing a video output from the ultrafast preset in x264, and it's
possible this is a legitimate reason for it to be reported as level 6 in
vlc's debug output.

For videos that are reported as level 5, it's generally some predictable
thing, like using more than 4096 macroblocks, or some combination of
macroblocks and number of reference frames or framerate. None of these
seem likely to apply to the 'ultrafast' preset or YouTube's format 18
(which are small videos, around 480x360, with a framerate of around 25)
but it's possible the 'working' video attached to the original report is
using a high number of reference frames.

As a totally unrelated issue which should have its own bug report, there
doesn't seem to be any way to avoid having VP9 videos display lots of
bad frames when decoding is too slow, and it sort of seems like the VP9
decoder might only use one thread as CPU use does not go to maximum.
Even with 'hurry up' for ffmpeg decoding, and 'drop late frames' and
'skip late frames' (even though it says it's for mpeg2 video) turned
off, large-sized VP9/webm videos from YouTube still end up with problems
when played on a slow computer, where frames degenerate into
incorrectly-decoded output with no apparent visual relationship to the
original video.

ffmpeg's output of VP9 videos also sometimes has problems when viewed on
vlc (in a different problem, the avconv fork of ffmpeg wasn't even able
to copy VP9 videos into a new webm container without problems and
repeated outputs having varying lengths) but I think that was an ffmpeg
problem, not a vlc one. Ideally Google would help to fix bugs in
software that doesn't deal with their codecs very well.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264

[Misaki]

Just to explain the practical relevance, the only situation I could
really think of where you would want to have multiple video streams
playing at once in VLC is when you want to play multiple angles that
were recorded of the same event at the same time.

I discovered VLC did this by accident when combining a video that didn't
have its original sound due to the copyrights being blocked by YouTube
with a different video that did have sound. Instead of just playing one
video stream in the main window, a second window opened with the video
stream that started late.

If you don't care about synchronization and resizing videos
independently in the player, there would be no reason to do this. A home
security system with multiple camera views, for example, could either
combine videos into one or or just record them separately, and probably
wouldn't be using VLC for live streaming of different angles.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264

[Misaki]

It's working again. It happened after I was changing a few things in the
UI, and restarting if I wasn't sure the changes would be applied without
it (like Always on top required a restart). It's possible it might
have somehow been related to trying various output methods, and pressing
stop button then restarting again after each one (required to use a new
output device). I did this even with output methods I expected not to
work, such as DirectFB video output and GNU/Linux framebuffer output.

But if this is a way to fix the problem if it occurs, I don't know how
to replicate it.

I had previously tried restarting Xorg, then restarting my computer,
which hadn't fixed it.

As this bug is not confirmed to consistently affect even a single user,
it's not a high-priority bug.

I don't know if it could possibly be relevant that I disabled my syslog
and kern.log by changing write permissions due to low disk space; it
seemed like after that, a USB wireless device would take longer to start
working. It might be waiting for logging to timeout or something, and
not sure if this could somehow affect video rendering too. (Pausing the
rsyslogd daemon causes more problems than just making the logs
unwriteable.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

While it isn't completely clear what the correct way to display images
is, if eog is in fact currently displaying them correctly it would help
to have an option to display them 'literally'. It doesn't seem like
there is any way to do this. Exact comparisons are helpful to diagnose
problems in other programs, or even for things like just understanding
whether the rgb to yuv conversion is linear or follows some other
equation, for someone who has encountered that situation without much
knowledge about it.

For example, suppose you want to compare whether Youtube's video player
is displaying a video the same as your local player does. You could
press F every time you switch to Youtube to cause it to go fullscreen,
then switch to the other player while staring at the same spot. Or you
could screenshot Youtube's display and compare to the screenshot. But if
eog is the default image viewer and it displays it differently from how
it originally appeared, you might make the wrong diagnosis and waste
time.

** Attachment added: geq-255.png
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366261/+files/geq-255.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264

[Misaki]

I wish I could say it was still working. But either it stopped working,
or I confused X11 video output (XCB) for XVideo output (XCB) because
it was late. XVideo output (XCB), or xcb_xv, is not working for me for
most h264 videos, and the things I speculated about in my last comment
did not affect this (including re-enabling logging and restarting
rsyslogd).

It's not directly related to video quality or the h264 'level' or
profile. I can play a 3840x2160 h264 dash video from Youtube with no
audio, but a 1280x720 h264 dash video from the same source, with a
creation date in its metadata of just 7 minutes before the other video,
won't play and gives the same errors in debug as in the original report.

VP9 and VP8 work fine, h265 seems to work fine, mpeg4 (divx tag) works
fine, apparently mpeg2 doesn't work either. Some files with the 'wmv'
suffix don't work, with the same error.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264

[Misaki]

On a particular Youtube video, using the formats listed through
youtube-dl -F video-ID,

Formats 266 (2160p), 264 (1440p), 160 (144p), and 18 (360p with audio)
are successfully opened by the xcb_xv vout display module.

Formats 137 (1080p), 136 (720p), 135 (480p), 134 (360p), 133 (240p), and
22 (720p with audio and more keyframes) result in an error.

With a different video, format 18 is the only h264 format that can be
opened, out of 10 formats. Format 18 works for two other videos as well.
Out of four videos with format 160 tested, two worked.


So it's possible there is a consistent explanation for which videos can be 
displayed, and which ones can't, though it might not be entirely predictable. 
Most h264 files from Youtube that aren't format 18 can't be opened. Youtube 
does use different processes for some of its videos, resulting in different 
frames being showed from a 60-fps source video or not having a certain pattern 
of '~18 frames of motion followed by 12 frames of stillness', but the fact that 
'newer' formats (as evidenced by the higher format number) worked in the first 
video tested could have been a coincidence.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264

[Misaki]

It's looking hardware-related, and I apologize for not being able to
provide more detailed information about the source of the problem
earlier. Right now at least, changing hardware-accelerated coding fixes
the problem. I have an Nvidia GeForce 9650M GT GPU, with Nvidia driver
version 331.113. The first and default option for hardware decoding is
VDPAU, and selecting a different option (VA-API video decoder via DRM,
or via X11) or disabling it lets all h264 videos be played with the
XVideo XCB display module.

This is still different from a week or two ago though. After testing, I
found that VA-API video decoder via X11 was crashing on a windows media
video file, or I wouldn't see it as a problem if VDPAU isn't working.

It would be easier for me to report problems properly if I knew to what
extent they could depend on hardware. I don't know if my bugs for
hardware decoding, output modules etc. are hardware specific.

I also found that videos that have a resolution change, through
h264_mp4toannexb, cause VLC to crash if it's using hardware decoding.
This is a different bug, and bugs are supposed to reported separately,
but~

'VA-API video decoder via DRM' only works in this case because it's
failing to find a hardware decoding module. The others crash with a
segmentation fault after the second video. If the second video has
audio, it plays the audio and then crashes when it's finished with VDPAU
(which doesn't display the video that accompanies the audio, possibly
only because of the bug in the original report). If it's VA-API via X11,
it crashes immediately at the second video before playing any audio from
it.

I would upload a sample video if requested. This is the output from
ffmpeg with -f concat -auto_convert 1, which inserts the
h264_mp4toannexb bitstream filter to H.264 streams in MP4 format. If
this is done without the -auto_convert option, vlc simply stops playing
the file, or rewinds it if on loop, without crashing.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

Some examples of how eog displays colours compared to imagemagick's display.  
These files were generated as follows, using ffmpeg:
 ffmpeg -filter_complex color=black:256x256,geq=X:240:128 -hide_banner -frames 
1 geq.png
 ffmpeg -filter_complex color=black:256x256,geq=X:240:128 -hide_banner -frames 
1 geq.jpg
 ffmpeg -filter_complex color=black:256x256,geq=X:200:128 -hide_banner -frames 
1 geq-200.png
 ffmpeg -filter_complex color=black:256x256,geq=X:200:128 -hide_banner -frames 
1 geq-200.jpg
 ffmpeg -filter_complex color=black:256x256,geq=X:128:128 -hide_banner -frames 
1 geq-128.png

convert geq-200.png -quality 100 geq-200.png.jpg
convert geq-200.png geq-200-convert.png


So these are images with a y (or is it y'?) value that ranges from 0 to 255, 
while the u value is at the mpeg range maximum for u of 240. The jpg and png 
images are different because the jpg images clip the y range when expanding it 
from 16~235 to 0~255, while the png images when converted to rgb allow the y 
values outside the normal range to affect the output colour. So the jpg output 
from convert is visually identical to the png it comes from, but on the edges u 
and v both have a gradient to produce those colours.

Then I took a screenshot of how eog displays geq-200.png, as well as a
screenshot of how imagemagick (display) displays png, and combined them
in GIMP. The jpgs are displayed roughly the same in both programs, other
than the differences due to clipping when expanding to jpeg range.


Firefox displays the images output from ffmpeg the same way as imagemagick, but 
displays the png output from imagemagick's convert almost the same as eog does. 
This similarity is much higher than for the images I tested for the original 
bug report. I took a screenshot of Firefox's display of geq-200-convert.png, 
cropped it and placed it on top of a screenshot of eog's output of geq-200.png 
(which is displayed exactly the same as geq-200-convert.png by eog), used the 
difference filter and flattened the image. (flattening an image might be used 
incorrectly here, but it's what the option is called.)

Then I used the threshold operation, from 1 to 255, so the vertical
lines are where they differed. All but one of the lines disappear at
threshold 2, the last disappears at threshold 5.

** Attachment added: geq.png
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366249/+files/geq.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: geq-200.jpg
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366252/+files/geq-200.jpg

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: geq-200-convert.png
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366256/+files/geq-200-convert.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: comparison.png
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366255/+files/comparison.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: geq-200.png
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366251/+files/geq-200.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: geq-128.png
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366253/+files/geq-128.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: eog-firefox diff-threshold.png
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366257/+files/eog-firefox%20diff-threshold.png

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: geq.jpg
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366250/+files/geq.jpg

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] Re: Images too bright

[Misaki]

** Attachment added: geq-200.png.jpg
   
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366254/+files/geq-200.png.jpg

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1436595

Title:
  Images too bright

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] Re: Recent update broke XVideo/XCB output for h264

[Misaki]

** Attachment added: xcb_xv vout fails
   
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+attachment/4365499/+files/notworking_%E5%B0%8F%E5%BC%BA%20www%20%5B%E5%8B%95%E9%AD%84%E5%BD%B1%E9%9F%B3%5D%20%5BXMjgxMjEwNzUy%5D.mp4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1440254] [NEW] Recent update broke XVideo/XCB output for h264

[Misaki]

Public bug reported:

The most recent VLC update seems to have broken h264 video playback
using the XVideo output (XCB). This method is preferable to the default
output method, which for me is VDPAU for h264 videos, because it can
play multiple video streams at once, while VDPAU locks up in this case.

This only happened to me today, and I think I updated to the latest
version of VLC yesterday, although it had been available for several
days.

Debug output from 'vlc -vv' when opening a video that doesn't display:

[7f49380547b8] core video output debug: Opening vout display wrapper
[7f493c0020e8] core vout display debug: looking for vout display module 
matching xcb_xv: 15 candidates
[7f493c0020e8] core vout display debug: no vout display modules matched
[7f49380547b8] core video output error: video output creation failed
[7f4938001ca8] core spu text debug: removing module freetype
[7f49380be198] core scale debug: removing module yuvp
[7f49380047e8] core scale debug: removing module swscale
[7f4960c03978] core decoder error: failed to create video output
[7f4960c03978] core decoder warning: can't get output picture
[7f49640065e8] core input debug: Decoder wait done in 85 ms


For a video that works, the reason why isn't clear from debug output:

[7f494c000958] core video output debug: Opening vout display wrapper
[7f4948057cc8] core vout display debug: looking for vout display module 
matching xcb_xv: 15 candidates
[7f4948052918] core window debug: looking for vout window xid module 
matching qt4,any: 4 candidates
[7f4948052918] qt4 window debug: requesting video window...
[0258bab8] qt4 interface debug: Video was requested 0, 0
[7f4948052918] core window debug: using vout window xid module qt4
[7f4948057f68] core inhibit debug: looking for inhibit module matching 
any: 2 candidates
[7f4948057f68] dbus_screensaver inhibit debug: found service 
org.freedesktop.ScreenSaver
[7f4948057f68] core inhibit debug: using inhibit module dbus_screensaver
[7f4948057cc8] xcb vout display debug: connected to X11.0 server
[7f4948057cc8] xcb vout display debug:  vendor : The X.Org Foundation
[7f4948057cc8] xcb vout display debug:  version: 1160
[7f4948057cc8] xcb vout display debug: using screen 0x251
[7f4948057cc8] xcb_xv vout display debug: using XVideo extension v2.2
[7f4948057cc8] xcb_xv vout display debug: using adaptor NV17 Video Texture
[7f4948057cc8] xcb_xv vout display debug: using port 550
[7f4948057cc8] xcb_xv vout display debug: using image format 0x30323449
[7f4948057cc8] xcb_xv vout display debug: using X11 visual ID 0x21 (depth: 
24)
[7f4948057cc8] xcb_xv vout display debug: using X11 window 0x04a0
[7f4948057cc8] xcb_xv vout display debug: using X11 graphic context 
0x04a2
[7f4948057cc8] core vout display debug: VoutDisplayEvent 'fullscreen' 0

This is with 'Accelerated video output (Overlay)' enabled in vlc's basic
options, because without it the XVideo output (XCB) selection doesn't
display anything at all. Turning hardware decoding, or 'Direct
rendering' under advanced options, doesn't affect the result in this
case.

With two files that seem like they should be very similar, one works and
the other doesn't. Both are .flv files, both were created in 2011
according to the original file metadata and have the same video
resolution, but converting them to .mp4 doesn't change the result. The
output from x264 using the ultrafast preset is displayed, but any slower
presets cause the video to fail to be displayed. I tried setting turning
off trellis and b-frames, or changing reference frames to 1, but these
didn't affect the result.

I have attached samples of videos, one that works with XVideo/XCB output
and another that doesn't.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: vlc 2.2.0-0ubuntu0.14.10.1
ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3
Uname: Linux 3.16.0-30-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Apr  3 15:57:25 2015
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: vlc (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug utopic

** Attachment added: xcb_xv vout succeeds
   
https://bugs.launchpad.net/bugs/1440254/+attachment/4365495/+files/working_%E9%87%91%E9%99%B5%E5%B0%8F%E5%BC%BA%20%5BXMzU3NjgzMzI4%5D.mp4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1440254

Title:
  Recent update broke XVideo/XCB output for h264

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1440254/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1437550] [NEW] PNG image colours are off/wrong for XVideo output (XCB)

[Misaki]

Public bug reported:

I discovered this bug when testing a different package, eog:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595

When a PNG image is opened in VLC with Video output set to XVideo
output (XCB), the colours are different than in other programs that
display PNG files such as Firefox.

avplay, and presumably ffplay, display pngs the same way as vlc does
with using XVideo output (XCB). With a png that is a gradient from value
0 to 255 with one column of each value, vlc with Xvideo output (XCB)
will have very slight apparent banding due to
http://en.wikipedia.org/wiki/Lateral_inhibition or some other related
effect. A histogram shows that about every 8th value is shifted up or
down by 1. Colours are different by a greater degree and in a systematic
way, so you don't need to have a uniform graident or use a histogram to
see the difference.

With a PNG, XVideo output (XCB) also had a green line on the right
border.

With a video using the 'Sorensen video v.3' video codec, XVideo output
(XCB) caused a green line to appear on the right side.

I have no idea if this is a bug in vlc or in a different project
(XVideo, or XCB?) that vlc has no control over. It seems likely that
bugs will tend to accumulate in places where it's hard to tell what
project is doing things wrong.

With both still images (pngs and jpgs) and the Sorensen video v.3 codec,
XVideo output (XCB) is the default output method if Accelerated video
output (overlay, or Overlay video output is enabled. If it's
disabled, then OpenGL GLX video output (XCB) is the default output
method, which does not have any green lines, and renders images
'normally'. (That is, not the same as eog due to what seems like an eog
bug as described in the linked bug report, but the same as several other
programs.)

The various options have their own drawbacks, or it would be easy to
just select a better method if one was bugged. In case it helps, I am
attaching my notes on video settings.

I am using Ubuntu 14.10, and VLC version 2.2.0-pre2 Weatherwax, the
witch.

** Affects: vlc (Ubuntu)
 Importance: Undecided
 Status: New

** Attachment added: vlc video settings.txt
   
https://bugs.launchpad.net/bugs/1437550/+attachment/4358438/+files/vlc%20video%20settings.txt

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1437550

Title:
  PNG image colours are off/wrong for XVideo output (XCB)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1437550/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1437550] Re: PNG image colours are off/wrong for XVideo output (XCB)

[Misaki]

** Description changed:

  I discovered this bug when testing a different package, eog:
  https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595
  
  When a PNG image is opened in VLC with Video output set to XVideo
  output (XCB), the colours are different than in other programs that
  display PNG files such as Firefox.
  
  avplay, and presumably ffplay, display pngs the same way as vlc does
- with using XVideo output (XCB). With a png that is a gradient from value
- 0 to 255 with one column of each value, vlc with Xvideo output (XCB)
- will have very slight apparent banding due to
+ using XVideo output (XCB). With a png that is a gradient from value 0 to
+ 255 with one column of each value, vlc with Xvideo output (XCB) will
+ have very slight apparent banding due to
  http://en.wikipedia.org/wiki/Lateral_inhibition or some other related
  effect. A histogram shows that about every 8th value is shifted up or
  down by 1. Colours are different by a greater degree and in a systematic
- way, so you don't need to have a uniform graident or use a histogram to
+ way, so you don't need to have a uniform gradient or use a histogram to
  see the difference.
  
  With a PNG, XVideo output (XCB) also had a green line on the right
  border.
  
  With a video using the 'Sorensen video v.3' video codec, XVideo output
  (XCB) caused a green line to appear on the right side.
  
  I have no idea if this is a bug in vlc or in a different project
  (XVideo, or XCB?) that vlc has no control over. It seems likely that
  bugs will tend to accumulate in places where it's hard to tell what
  project is doing things wrong.
  
  With both still images (pngs and jpgs) and the Sorensen video v.3 codec,
  XVideo output (XCB) is the default output method if Accelerated video
  output (overlay, or Overlay video output is enabled. If it's
  disabled, then OpenGL GLX video output (XCB) is the default output
  method, which does not have any green lines, and renders images
  'normally'. (That is, not the same as eog due to what seems like an eog
  bug as described in the linked bug report, but the same as several other
  programs.)
  
  The various options have their own drawbacks, or it would be easy to
  just select a better method if one was bugged. In case it helps, I am
  attaching my notes on video settings.
  
  I am using Ubuntu 14.10, and VLC version 2.2.0-pre2 Weatherwax, the
  witch.

** Description changed:

  I discovered this bug when testing a different package, eog:
  https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595
  
  When a PNG image is opened in VLC with Video output set to XVideo
  output (XCB), the colours are different than in other programs that
  display PNG files such as Firefox.
  
  avplay, and presumably ffplay, display pngs the same way as vlc does
  using XVideo output (XCB). With a png that is a gradient from value 0 to
  255 with one column of each value, vlc with Xvideo output (XCB) will
  have very slight apparent banding due to
  http://en.wikipedia.org/wiki/Lateral_inhibition or some other related
  effect. A histogram shows that about every 8th value is shifted up or
  down by 1. Colours are different by a greater degree and in a systematic
  way, so you don't need to have a uniform gradient or use a histogram to
  see the difference.
  
  With a PNG, XVideo output (XCB) also had a green line on the right
  border.
  
  With a video using the 'Sorensen video v.3' video codec, XVideo output
  (XCB) caused a green line to appear on the right side.
  
  I have no idea if this is a bug in vlc or in a different project
  (XVideo, or XCB?) that vlc has no control over. It seems likely that
  bugs will tend to accumulate in places where it's hard to tell what
  project is doing things wrong.
  
  With both still images (pngs and jpgs) and the Sorensen video v.3 codec,
  XVideo output (XCB) is the default output method if Accelerated video
- output (overlay, or Overlay video output is enabled. If it's
- disabled, then OpenGL GLX video output (XCB) is the default output
- method, which does not have any green lines, and renders images
- 'normally'. (That is, not the same as eog due to what seems like an eog
- bug as described in the linked bug report, but the same as several other
- programs.)
+ output (overlay), or Overlay video output in advanced options, is
+ enabled. If it's disabled, then OpenGL GLX video output (XCB) is the
+ default output method, which does not have any green lines, and renders
+ images 'normally'. (That is, not the same as eog due to what seems like
+ an eog bug as described in the linked bug report, but the same as
+ several other programs.)
  
  The various options have their own drawbacks, or it would be easy to
  just select a better method if one was bugged. In case it helps, I am
  attaching my notes on video settings.
  
  I am using Ubuntu 14.10, and VLC version 2.2.0-pre2 Weatherwax, the
  witch.

-- 
You received this bug notification because you are a 

[Bug 609348] Re: Network connections crash from overflow when unresponsive

[Misaki]

Running that command gave this output:
(process:27099): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size 
== 0' failed

(granted authorization)

dpkg-query: no packages found matching linux

Nothing was happening so I stopped the process. I filed this under
linux because I wasn't sure where else to file it.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/609348

Title:
  Network connections crash from overflow when unresponsive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/609348/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1436595] [NEW] Images too bright

[Misaki]

Public bug reported:

Most images have their values shifted upwards when displayed in eog, and
I don't think it is intentional. Reporting this as a bug is complicated
because I am not sure if some programs, such as eog, change their
display of an image based on screen settings for colorspace or gamma. I
am not an expert on graphics, but something does seem to be wrong.

So at least for my computer, eog seems to stretch out the range just
above a 0 value. A very dark area will have a clear contrast between the
totally black pixels, with a value of zero, and the ones just above it.
In one image I tested, eog did not display any pixels with a value in
the range of 1 to 5, as in the histogram of a screenshot of eog's
display of the image.

In comparison, a screenshot of Firefox's display of the same image had
numerous pixels in the 1~5 range. The GIMP image editor displayed this
image the same as Firefox, with the histogram showing that the pixels
were being displayed without any adjustment.

Basically, if a lot of different programs display things differently and
inconsistently, some of them have to be wrong, and it seems likely that
eog is. Due to inconsistencies, I'm not actually sure what is the
correct, or the best way to display images, which might be different
from the correct way.

Programs used to test, convert, and display images:
imagemagick
ffmpeg (for conversion) and avplay (for display, since ffplay isn't provided on 
my distribution)
eog
Firefox
vlc
GIMP

I thought Firefox was displaying non-stripped pngs the same as eog does,
but it's actually slightly different. While gray areas are about the
same as eog, red areas are slightly darker in Firefox.

A description of how various programs display images:
vlc seems to be the same as avplay, and both are different from either Firefox 
or eog. Dark red is a bit more like brown or orange, while contrast for 
luminosity or luminance (?) seems to be higher; I am just noting that it is 
different. This is for a png image.

I thought eog was displaying all images the same way, until I
encountered a png that worked differently. I thought eog was displaying
this png without any adjustments, as it's slightly darker than how eog
displays other pngs, but it's actually slightly darker with more intense
colours than how other programs display the same image. But for all
other images, eog seems to make them slightly brighter.

Firefox displays jpgs without any adjustment, but most pngs are slightly
brighter. As described, this is slightly different than how eog makes
images brighter. If an image is converted with -strip action in
imagemagick, Firefox shows the png without adjustments. A png output
from ffmpeg is also displayed without adjustments. It seems to be
related to the 'png:sRGB : intent=value' property but that would be a
Firefox bug. It's relevant because it seems to adjust the display of
images in a way that's similar to eog, though still different. If a
stripped png is converted again without applying the -strip action
again, Firefox will display it as adjusted; that is, brighter. This is
also part of the evidence that the adjustment in Firefox, and therefore
in eog, is a bug.

GIMP displays images without an adjustment, so darker than eog for most
images.

The 'display' utility from imagemagick displays images the same as GIMP,
without any apparent adjustments.


So GIMP, display from imagemagick, and Firefox all display jpgs as slightly 
darker than eog, without mostly skipping over the range of values just above 0. 
GIMP and 'display' show most pngs as darker than eog, while Firefox displays 
some pngs as darker than eog while others are displayed similar but with 
slightly darker reds it seems.

I think all the images I've looked at had 'colorspace: sRGB' in their
properties when I looked at them with 'identify' from imagemagick or
exiftool., so if that's somehow related it doesn't seem like programs
should display images differently. They probably all had 'gamma: 0.45'
in 'identify' (though this shows up as gamma: 2.2 in exiftool I think),
so I don't think that should affect image display either.

For the unusual png that eog displays differently, none of the ways I
used to convert it caused the output to be displayed in eog the same as
the original. These methods included 'convert' from imagemagick with and
without the -strip action; convert with jpg output; ffmpeg with png
output; and GIMP exporting as png with background color and gamma tested
(so four GIMP outputs total). The reason for testing background color
was that 'png:bKGD' is part of the output from 'identify' when the
-strip action isn't used with 'convert', and non-stripped pngs are
treated differently in Firefox so they could potentially also be treated
differently in eog, but as it turned out they weren't treated
differently in eog.

In 'identify's output, the original png does have very slightly
different numbers under Chromaticity, with five of eight numbers
different by 

[Bug 1319233] Re: audio stutters or stops playing after seeking

[Misaki]

This might be related to timing. I'm just saying what I concluded from
looking at debug before; when I looked at it more recently, it wasn't
obvious which error messages related to audio were relevant or I didn't
look at enough of the debug output.

If a video is decoded quickly, audio won't stop playing. If it takes too
long, there is an error message in debug and audio will stop working. So
the way to replicate it, as suggested by the duplicate bug report, is to
seek to the end of a long group-of-pictures in a video, just before a
keyframe.

While switching to ALSA audio output does prevent the problem, it seems
to me that there is a small amount of static as audio starts playing
again if using the PulseAudio Sound Server as ALSA's output.

If using a hardware device, VLC can play files fine by itself, but
conflicts with other attempts to use the output device. So if you leave
VLC open, and try to play a web video, the video will freeze after a few
seconds because it's waiting for audio to start. For me at least, when I
start playing a Flash video in Firefox, in my Sound settings (Ubuntu),
'ALSA plug-in [plugin-container' starts up. Similarly, if Flash is
already using the audio, VLC will give an error message in the UI
(device busy) and audio won't play.


I don't notice this burst of static when just using Pulseaudio as output, but 
it has problems with seeking as described in this bug report.

I also only encountered this problem after upgrading, though for me it
was from Ubuntu 12.04 to 14.10 and I'm not sure what my VLC settings
were before, probably just default. I don't get stuttering, the audio
just turns off, and only turns back on if another attempt to seek within
the video is successful.


The workaround is to pause the video just before seeking, and only start 
playing again once the video decoder has finished or almost finished catching 
up. But this isn't at all obvious; at first I thought that losing audio was due 
to problems with handling the VP9 or WebM codecs/formats.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1319233

Title:
  audio stutters or stops playing after seeking

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/1319233/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 997491] Re: E: The value 'oneiric' is invalid for APT::Default-Release as such a release is not available in the sources E: _cache-open() failed, please report.

[Misaki]

*** This bug is a duplicate of bug 978821 ***
https://bugs.launchpad.net/bugs/978821

From http://ubuntuforums.org/showthread.php?p=11403493

The APT::Default-Release identifier is within Synaptic config file at
each home directory (for you and root). I have recreated this error by
manually editing those files.

Going to /root/.synaptic/synaptic.conf and changing the default distro
to precise fixed it for me.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/997491

Title:
  E: The value 'oneiric' is invalid for APT::Default-Release as such a
  release is not available in the sources E: _cache-open() failed,
  please report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/997491/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 978821] Re: E: Значение «oneiric» недопустимо для APT::Default-Release, так как выпуск недоступен в источниках E: _cache-open() failed, please report.

[Misaki]

From http://ubuntuforums.org/showthread.php?p=11403493

The APT::Default-Release identifier is within Synaptic config file at
each home directory (for you and root). I have recreated this error by
manually editing those files.

Going to /root/.synaptic/synaptic.conf and changing the default distro
to precise fixed it for me.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/978821

Title:
  E: Значение «oneiric» недопустимо для APT::Default-Release, так как
  выпуск недоступен в источниках E: _cache-open() failed, please
  report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/978821/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 868646] Re: Error when installing ubuntu 11.04 release

[Jairus Misaki]

I am trying to install the ubuntu 11.04 release on my desktop. When I
enter the sudo update-manager, password...i think it should open and
start running the update. But for this case nope.

Please help on this am stuck... I miss my Ubuntu machine...tired of
windows.


Jay

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/868646

Title:
  Error when installing ubuntu 11.04 release

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/868646/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 868646] [NEW] Error when installing ubuntu 11.04 release

[Jairus Misaki]

Public bug reported:

An unresolvable problem occurred while initializing the package
information.

Please report this bug against the 'update-manager' package and include
the following error message:

'E:Encountered a section with no Package: header, E:Problem with
MergeList /var/lib/apt/lists/us.archive.ubuntu
.com_ubuntu_dists_natty_main_binary-i386_Packages, E:The package lists
or status file could not be parsed or opened.'

** Affects: ubuntu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/868646

Title:
  Error when installing ubuntu 11.04 release

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/868646/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 609348] [NEW] Network connections crash from overflow when unresponsive

[Misaki]

Public bug reported:

OS: Lucid 10.04.1 LTS, upgraded from Karmic 9.10

If too much information is sent to an unresponsive network connection,
the connection seems to 'fail' and stops working. The unresponsive
network connection is usually the result of a proxy or NAT router
restarting.

Steps to duplicate in 10.04:

1) set up ping -f google.com -i 10
2) set up ping -f google.com -i 1
3) restart router

Result: the flood ping with interval 10 will show one or two dropped
packets while the router is restarting, and then will show no further
errors. The flood ping with interval 1 will continue to show dropped
packets after the router has restarted, as too much information is in
the connection buffer or something.

This also applies to IM connections (tested with Pidgin connected to
MSN). If update information is sent while the router is restarting, the
connection to the server 'stalls' and is only reset by the application
after 15 minutes. If no information is sent while the router is
restarting, the connection works fine immediately after the router has
finished restarting and connected to ISP.


Also tested this on 10.04 32-bit from a Live usb. First test with 10-sec 
interval stalled when restarting router, but with a 20-sec interval, there was 
only one missed packet and then resumed normal operation. Meanwhile the 1-sec 
interval ping completely stalled even after the router finished restarting.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: buffer connection overflow pidgin ping

-- 
Network connections crash from overflow when unresponsive
https://bugs.launchpad.net/bugs/609348
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 605148] Re: Application connections fail with overflow in Lucid 10.04

[Misaki]

*** This bug is a duplicate of bug 609348 ***
https://bugs.launchpad.net/bugs/609348

** This bug has been marked a duplicate of bug 609348
   Network connections crash from overflow when unresponsive

-- 
Application connections fail with overflow in Lucid 10.04
https://bugs.launchpad.net/bugs/605148
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 605148] [NEW] Application connections fail with overflow in Lucid 10.04

[Misaki]

Public bug reported:

OS: Lucid 10.04.1 LTS, upgraded from Karmic 9.10

If too much information is sent to an unresponsive network connection,
the connection seems to 'fail' and stops working. The unresponsive
network connection is usually the result of a proxy or NAT router
restarting.

Steps to duplicate in 10.04:

1) set up ping -f google.com -i 10
2) set up ping -f google.com -i 1
3) restart router


Result: the flood ping with interval 10 will show one or two dropped packets 
while the router is restarting, and then will show no further errors. The flood 
ping with interval 1 will continue to show dropped packets after the router has 
restarted, as too much information is in the connection buffer or something.

This also applies to IM connections (tested with Pidgin connected to
MSN). If update information is sent while the router is restarting, the
connection to the server 'stalls' and is only reset by the application
after 15 minutes. If no information is sent while the router is
restarting, the connection works fine immediately after the router has
finished restarting and connected to ISP.

** Affects: ubuntu
 Importance: Undecided
 Status: New


** Tags: buffer connection overflow pidgin ping

-- 
Application connections fail with overflow in Lucid 10.04
https://bugs.launchpad.net/bugs/605148
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 605148] Re: Application connections fail with overflow in Lucid 10.04

[Misaki]

Tested this on 10.04 32-bit from a Live usb. First test with 10-sec
interval stalled when restarting router, but with a 20-sec interval,
there was only one missed packet and then resumed normal operation.
Meanwhile the 1-sec interval ping completely stalled even after the
router finished restarting.

-- 
Application connections fail with overflow in Lucid 10.04
https://bugs.launchpad.net/bugs/605148
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 446889] Re: Linksys WUSB54GC v3 (ID 1737:0077) doesn't work

[Misaki]

Well, it looks like it's recognized in some way at least if there's so
much activity. The result I have in 'dmesg' when I plug it in for the
first time is similar to the first dozen or so lines of your output. I
assume you are using the generic kernel, not the server one? I don't
have WPA or WPA2, mine is an unsecured connection.

In one of the Ubuntuforums threads I noticed that there were two changes
that were supposed to be necessary to get the rt3070 (?) driver to work:
one of them was editing the source to add this particular device to the
list of matching hardware, the other was to edit the source to change
WPA and WPA2 from disabled to enabled. Possibly the wireless
backports module only currently has the first change.

I don't know how to show more test results. For the first time I plugged
it in after restarting it showed the rt2870sta: module is from the
staging directory, the quality is unknown, you have been warned.
message from your results, and then further messages. If I plug it in
again, this is the exact output in dmesg leading to connection to an
unsecured wireless network (selecting a second network before the first
showed as fully connected in the network manager icon in Gnome):


** Attachment added: Connection with Lucid using wireless backports and 
generic kernel
   
http://launchpadlibrarian.net/48470754/dmesg%20output%20for%20successful%20connect.txt

-- 
Linksys WUSB54GC v3 (ID 1737:0077) doesn't work
https://bugs.launchpad.net/bugs/446889
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 446889] Re: Linksys WUSB54GC v3 (ID 1737:0077) doesn't work

[Misaki]

The Linksys WUSB54GC v3 (ID 1737:0077) now works after installing
linux-backports-modules-wireless-lucid-generic and linux-backports-
modules-headers-lucid-generic, yay! Blinking light and everything. I
have not stress tested it to see if it has the same eventual lag and
disconnect problems that my computer's built-in wireless card does with
the ath9k driver and even another ralink-chipset external adapter
sometimes had with Karmic, but so far (~10 minutes) I do not see any
abnormally long pings.

I believe it's necessary to install both of those packages together, but
I am not sure.

-- 
Linksys WUSB54GC v3 (ID 1737:0077) doesn't work
https://bugs.launchpad.net/bugs/446889
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 446889] Re: Linksys WUSB54GC v3 (ID 1737:0077) doesn't work

[Misaki]

I am too afraid of breaking my computer, but which would we install to
test? And is there a way to add it to repositories instead of
downloading the file?

I have just upgraded to Lucid and dmesg shows the same as before for the
1737:0077 Linksys device:

[  863.290142] usb 2-1: new high speed USB device using ehci_hcd and address 3
[  863.458091] usb 2-1: configuration #1 chosen from 1 choice
[  863.624357] phy1: Selected rate control algorithm 'minstrel'
[  863.626394] Registered led device: rt2800usb-phy1::radio
[  863.626495] Registered led device: rt2800usb-phy1::assoc
[  863.626542] Registered led device: rt2800usb-phy1::quality
[  863.626912] usbcore: registered new interface driver rt2800usb
[  863.682964] rt2870sta: module is from the staging directory, the quality is 
unknown, you have been warned.
[  863.694399] rtusb init ---
[  863.694508] usbcore: registered new interface driver rt2870
[  863.740379] udev: renamed network interface wlan1 to wlan2
[  863.746992] rt2800usb 2-1:1.0: firmware: requesting rt2870.bin
[  864.381936] ADDRCONF(NETDEV_UP): wlan2: link is not ready

-- 
Linksys WUSB54GC v3 (ID 1737:0077) doesn't work
https://bugs.launchpad.net/bugs/446889
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs