[Bug 1901538] Re: Output Device selection messed (Line Out <-> HDMI)
OK, so deletion of pulse config helped. First deletion only temporarly and the weird behavior came back after some switching. But after the second one it seems to be permanently fixed and I can't reproduce the faulty behavior. So I assume it can be seen as fixed?! If it happens again and is reproducible, I'll report again. Thank you for your help! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1901538 Title: Output Device selection messed (Line Out <-> HDMI) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1901538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1901538] [NEW] Output Device selection messed (Line Out <-> HDMI)
Public bug reported: [System] - Freshly installed Ubuntu 20.04.1 LTS with 3rd party software/drivers enabled - pulseaudio 1:13.99.1-1ubuntu3.7 - NVIDIA graphics card (GeForce GTX 650 Ti Boost) using nvidia-driver-450 - Monitor with build-in (stereo) speakers connected via HDMI to graphics card - External (stereo) speakers connected via audio jack to mainboard [Expected Behavior] 1. Go to "Settings" -> "Sound" -> "Output" -> "Output Device" 2. Switch from "HDMI / DisplayPort 2 - GK106 HDMI Audio Controller" to "Line Out - Built-in Audio" 3. The switching should enable the chosen output device. [Bug Description and Behavior] If I switch from "HDMI / DisplayPort 2 - GK106 HDMI Audio Controller" to "Line Out - Built-in Audio" and test the output, sound comes still from monitor speakers and not from my external speakers. [Workaround] While "HDMI / DisplayPort 2 - GK106 HDMI Audio Controller" selected, go to "Configuration" and switch from "Digital Stereo (HDMI 2) Output" to "Digital Surround 5.1 (HDMI 2) Output". Instantly "Configuration" row disappears, in Output Device "Line Out - Built-in Audio" is selected and external speakers are active. [Further comments] I'm affected by this bug and the "wrong audio output on every reboot/wake up/login" since upgrade to 20.04 but the latter may be worth another bug report or maybe you could guide me to an active bug report that isn't linked to a previous Ubuntu version and already marked as fixed. At first I thought it may be caused by failed upgrade or my system configurations, but now I tested with a freshly installed Ubuntu on a spare SSD and the problem still exists, so here I am. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-control-center 1:3.36.4-0ubuntu1 ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65 Uname: Linux 5.4.0-52-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.10 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Mon Oct 26 13:15:41 2020 ExecutablePath: /usr/bin/gnome-control-center InstallationDate: Installed on 2020-10-26 (0 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: gnome-control-center UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-control-center (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1901538 Title: Output Device selection messed (Line Out <-> HDMI) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1901538/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874217] Re: [nvidia] Dual monitor setup with secondary monitor in portrait-right mode cause tiled windows to occupy 1.5 monitors
Issue is fixed for me with mutter 3.36.4. And yes, I got the scaling bug mentioned by Wallo013, too. Although mine isn't that heavy. I use 100 % and something is setting it below that (75 % - 90 %?). If I change scaling to 125 % and back to 100 %, everything is fine. After Relogin or Reboot, scaling is wrong again. But this bug is not linked to multiple screens at least for me, so maybe should get reported in another bug ticket. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874217 Title: [nvidia] Dual monitor setup with secondary monitor in portrait-right mode cause tiled windows to occupy 1.5 monitors To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-control-center/+bug/1874217/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1874217] Re: [nvidia] Dual monitor setup with secondary monitor in portrait-right mode cause tiled windows to occupy 1.5 monitors
The problem isn't fixed (at least for me). My system: OS: Ubuntu 20.04 - Linux [...] 5.4.0-40-generic [...] x86_64 Graphics: GeForce GTX 650 Ti BOOST, nvidia-driver-440 Monitors: Primary monitor connected via HDMI, secondary rotated monitor connected via display port, staying left from my primary monitor. Before upgrading from 19.10 to 20.04 rotation with gnome-control-center settings worked quiet fine (I only had to configure this once). Now I have the same problem as described above. Each time I power on my secondary monitor I have to manually change orientation by using xrandr commands. Rotating via gnome-control-center results in weird unrotated overlapping display contents. Once configured manually via xrandr, after suspension and wake up the settings are still working. After reboot settings are lost again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1874217 Title: [nvidia] Dual monitor setup with secondary monitor in portrait-right mode cause tiled windows to occupy 1.5 monitors To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-control-center/+bug/1874217/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1782535] Re: cifs - poor upload speed with nautilus compared to rsync
Issue may get closed. Solved with upgrading to Ubuntu 19.04. Nevertheless thanks for your help. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1782535 Title: cifs - poor upload speed with nautilus compared to rsync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1782535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1782535] Re: cifs - poor upload speed with nautilus compared to rsync
As you proposed: https://gitlab.gnome.org/GNOME/glib/issues/1688 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1782535 Title: cifs - poor upload speed with nautilus compared to rsync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1782535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1782535] Re: cifs - poor upload speed with nautilus compared to rsync
By the way, due to freezing issues with copying many small files last august, I was forced to change fstab. The cifs/smb version is now 2.0: //ip-address/home /mnt/cifs_nas_home cifs uid=florian,gid=florian,credentials=/home/florian/.smbcredentials,dir_mode=0700,vers=2.0 0 0 Restrictions to the .exe speed drop exception: If the .exe-file already exists in the destination, replacing is as slow as coping iso files (7 MB/s) Same behaviour with gio copy. Because of the replacement issue above I repeated the measurements with following approach: - test file size 8 GB - only upload - fast copies are repeated 3 times and averaged performance chosen (only if no freak value) - slow copies are repeated 3 times too but aborted after ca. 20 seconds Results Tool/CMDtypeending performance (in MB/s) nautiluscopyiso ~ 7 nautilusrepl. iso ~ 7 nautiluscopyexe ~ 110 nautilusrepl. exe ~ 7 gio copycopyiso ~ 7 gio copyrepl. iso ~ 7 gio copycopyexe ~ 110 gio copyrepl. exe ~ 7 cp copyiso ~ 75 cp repl. iso ~ 110 cp copyexe ~ 110 cp repl. exe ~ 110 Commands gio copy -pT /home/florian/testfile-upload-8gb.[iso/exe] /mnt/cifs_nas_media_flo/testfile-upload-8gb.[iso/exe] time cp -T /home/florian/testfile-upload-8gb.[iso/exe] /mnt/cifs_nas_media_flo/testfile-upload-8gb.[iso/exe] Annotation: Because "cp" has no progress function, the less accurate time command is used. Through comparing "gio copy -pT" and "time gio copy -pT", I translated "cp" time results to performance. Very first copy issue This part needs to be observed more closely. Resetting cifs mount (umount, mount) appears to help for a few 8 GB copies. But after a few it starts fast but drops hard down to 7 MB/s after 4 GB transmitted. After some more beginning and cancelling copies it stays at 7 MB/s permanently. Summary: - massive speed drop with upload copy is only observed with "nautilus" and "gio copy", not "cp", although the last one has also a weird behaviour, but that's probably another matter - the very first copy issue needs closer observation - speed drop is depending on file ending, ".iso" is always slow, ".exe" only if replacing existing file -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1782535 Title: cifs - poor upload speed with nautilus compared to rsync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1782535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1782535] Re: cifs - poor upload speed with nautilus compared to rsync
Thank you for looking into this problem. What I observed additionally: * the very first upload copy with nautilus is normal maximum speed (~110 MB/s) * then every upload copy is about 7 MB/s * if I change the file ending to ".exe" and upload, I get maximum speed! Results to your requested data: 1st cp: time cp -T /home/florian/upload.iso /mnt/cifs_nas_media_flo/upload.iso real1m21,701s user0m0,054s sys 0m4,832s 2nd cp: time cp -T /home/florian/upload.iso /mnt/cifs_nas_media_flo/upload.iso real1m23,342s user0m0,059s sys 0m4,879s => so maximum speed (8GB need ca. 80 seconds) 1st gio copy: gio copy -pT /home/florian/upload.iso /mnt/cifs_nas_media_flo/upload.iso Transferred 114,8 MB out of 8,0 GB (6,8 MB/s)^C 2nd gio copy with ".exe" file ending: gio copy -pT /home/florian/upload.exe /mnt/cifs_nas_media_flo/upload.exe Transferred 8,0 GB out of 8,0 GB (115,0 MB/s) So all this speed drop is somehow linked to the file ending. What could interfere just because of different file endings? And why are only nautilus and gio copy affected and not all copy utilities? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1782535 Title: cifs - poor upload speed with nautilus compared to rsync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1782535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1782535] Re: cifs - poor upload speed with nautilus compared to rsync
Some additional performance measurements with dd... speed test with /dev/zero upload/write: dd if=/dev/zero of=/mnt/cifs_media/test.iso bs=10M count=400 400+0 records in 400+0 records out 4194304000 bytes (4,2 GB, 3,9 GiB) copied, 40,4893 s, 104 MB/s download/read: dd if=/mnt/cifs_media/test.iso of=/dev/zero bs=10M 400+0 records in 400+0 records out 4194304000 bytes (4,2 GB, 3,9 GiB) copied, 37,393 s, 112 MB/s More practical up- and download speeds upload: dd if=/home/me/file.iso of=/mnt/cifs_media/file.iso bs=10M 767+1 records in 767+1 records out 8048736256 bytes (8,0 GB, 7,5 GiB) copied, 93,209 s, 86,4 MB/s download: dd if=/mnt/cifs_media/file.iso of=/home/me/file2.iso bs=10M 767+1 records in 767+1 records out 8048736256 bytes (8,0 GB, 7,5 GiB) copied, 81,2462 s, 99,1 MB/s So cifs and other underlying systems and hardware seem to be capable to use maximum speed. But more important, if I lower bs, the speed drops down really hard. Upload with bs=... - Default (512) -> 830 kB/s - 4096 -> 6,2 MB/s So maybe the file managers and rsync or their underlying systems are using these small bs? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1782535 Title: cifs - poor upload speed with nautilus compared to rsync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1782535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1782535] [NEW] cifs - poor upload speed with nautilus compared to rsync
Public bug reported: I'm mounting folders from my NAS on my computer (Ubuntu 18.04) with cifs. Copying an 8 GB file... Upload (local -> mounted) - Nautilus/Nemo -> 6 MB/s - rsync -> 50-60 MB/s Download performance is also strange, but not my biggest concern. Download (mounted -> local) - Nautilus/Nemo -> 90 MB/s - rsync -> 50-60 MB/s rsync command (upload): rsync --progress /home/me/file.iso /mnt/cifs_media/ fstab entry: //nas/media /mnt/cifs_media cifs vers=3.0,uid=me,gid=me,credentials=/home/me/.smbcredentials,dir_mode=0700,file_mode=0700 0 0 Any idea, why Nautilus is uploading up to 10 times more slowly than rsync, although both using the same cifs, os, hardware, network etc.? PS: Further info for bug report 1) The release of Ubuntu: Ubuntu 18.04 LTS 2) The version of the package: Nautilus 3.26.3 3) What you expected to happen: At least same speed as with using rsync 4) What happened instead: See above ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Description changed: I'm mounting folders from my NAS on my computer (Ubuntu 18.04) with cifs. Copying an 8 GB file... Upload (local -> mounted) - Nautilus/Nemo -> 6 MB/s - rsync -> 50-60 MB/s Download performance is also strange, but not my biggest concern. Download (mounted -> local) - Nautilus/Nemo -> 90 MB/s - rsync -> 50-60 MB/s - rsync command (upload): + rsync command (upload): rsync --progress /home/me/file.iso /mnt/cifs_media/ - fstab entry: + fstab entry: //nas/media /mnt/cifs_media cifs vers=3.0,uid=me,gid=me,credentials=/home/me/.smbcredentials,dir_mode=0700,file_mode=0700 0 0 Any idea, why Nautilus is uploading up to 10 times more slowly than rsync, although both using the same cifs, os, hardware, network etc.? PS: Further info for bug report 1) The release of Ubuntu: Ubuntu 18.04 LTS 2) The version of the package: Nautilus 3.26.3 - 3) What you expected to happen: At least same speed as rsync + 3) What you expected to happen: At least same speed as with using rsync 4) What happened instead: See above -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1782535 Title: cifs - poor upload speed with nautilus compared to rsync To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1782535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1530138] [NEW] Package no longer works and needs to be updated to 1.26
Public bug reported: Due to a change of the Flickr API, this version of flickcurl does no longer work and needs to be updated to version 1.26. ** Affects: flickcurl (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/1530138 Title: Package no longer works and needs to be updated to 1.26 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flickcurl/+bug/1530138/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
