Steps to reproduce:
Actual results:
There’s no copy of the page in the target directory. Going to about:downloads reveals that the download has failed, without further details.
Expected results:
For the directory to contain a downloaded copy of the page.
Tested all combinations of both (Ctrl-s/context menu in safe mode and normal mode), all with the same results. Could this be locale-dependent? The UI is in English in safe mode though, so I’m guessing safe mode should be locale-independent, as I’m on fi_FI.UTF-8 otherwise.
And just to clarify: my testing of Bionic was on real hardware as well, and I ran these latest tests on Cosmic on another computer (real hardware).
== Steps to reproduce ==
1. Open https://forums.tomshardware.com/threads/what-is-the-actually-difference-between-udimm-and-dimm.1575984/
2. Right-click and select ’Save page as’. Point the dialog to your directory of choice.
== What I expect to happen ==
For the directory to contain a downloaded copy of the page.
== What happens ==
There’s no copy of the page in the target directory. Going to about:downloads reveals that the download has failed, without further details.
== Other info ==
I’m reporting this from up-to-date Disco, albeit with a 4.* kernel (as gdm currently fails to start in my VirtualBox VM with 5.*) but it’s equally reproducible in Bionic.
Any page under https://forums.tomshardware.com/ seems to trigger this, but I have yet to come across other sites that do. Pages can even be saved from the main Tom’s Hardware domain (https://www.tomshardware.com/) without issues.
I’m using yle-dl from the HEAD and ffmpeg & ffprobe built from git. For the three URLs listed above, I could only get subtitles to download for the last one (with --debug) until I tried playing it in the web player, after which they were no longer downloaded for that one either. Aargh :)
Here’s --debug output for the first download (before opening in webplayer), resulting in subtitles being downloaded.
Here’s --debug output for the latter download (after opening in webplayer), resulting in subtitles not being downloaded.
Another option missing from the man page is -ow (for overwriting the input file in-place), available since version 1.7.22.
$ pngcrush 2>&1 | grep -- -ow
pngcrush -ow [other options] file.png [tempfile.png]
-ow (Overwrite)Tested this again and it seems to have been fixed at some point by some Ubuntu (18.04) updates: my test user still had version 8 of the extension, and I could no longer reproduce the issue, neither before nor after updating the extension to release v9. My main user’s desktop now also appears unaffected.
(I was going to try the workaround reported by @ChrisLancs, but ended up not having to. My ”List type” is set to ”Disabled”.)
I’m using version 20190203.
Yesterday I noticed a couple of videos took a particularly long time to download, and the resulting files contained all the available streams, as opposed to just the best. For instance, the streams downloaded for https://areena.yle.fi/1-50067640:
$ ffprobe Mäkihypyn\ maailmancup\:\ Mäkihypyn\ MC\:\ HS\ 130\,\ miesten\ karsinta-2019-02-08T20\:31.mp4 2>&1 | grep Stream
Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 480x270 [SAR 1:1 DAR 16:9], 299 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc (default)
Stream #0:1(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 480x270 [SAR 1:1 DAR 16:9], 299 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:2(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 749 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:3(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 749 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:4(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 960x540 [SAR 1:1 DAR 16:9], 1499 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:5(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 960x540 [SAR 1:1 DAR 16:9], 1499 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:6(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 2499 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:7(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 2499 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:8(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 3499 kb/s, 50 fps, 50 tbr, 90k tbn, 100 tbc
Stream #0:9(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 3499 kb/s, 50 fps, 50 tbr, 90k tbn, 100 tbc
Stream #0:10(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s (default)
Stream #0:11(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:12(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:13(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:14(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:15(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:16(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:17(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:18(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
Stream #0:19(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s
The only other one exhibiting this I’ve come across so far is https://areena.yle.fi/1-50044648 (a hefty download even without the excess streams due to the length, but with all streams 25 GB in total).
An example of the previous behavior is https://areena.yle.fi/1-4538143 (published after the other two mentioned, so this is apparently not enacted for all recent publications):
$ ffprobe file:"Sohvaperunat: S07E02-2019-02-09T10:31.mp4" 2>&1 | grep Stream
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 3819 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default)
The lower quality streams should be easy enough to slice out of the mp4 after downloading, but of course it’d be optimal not to waste the bandwidth downloading them in the first place
Fixed for me by the latest -proposed package. I’m running Bionic, non-EFI, and was affected by the issue with the earlier package.
A new log; still nothing useful from colord AFAICT, despite the –verbose.
…except that –debug isn’t one of gsd-color’s recognized parameters, and adding it caused GDM to fail to start. I changed it to –verbose which is available.
10.08 jani@saegusa:~$ LC_ALL=C /usr/lib/gnome-settings-daemon/gsd-color –help-all
Usage:
gsd-color [OPTION?] color
Help Options:
-h, –help Show help options
–help-all Show all help options
–help-gtk Show GTK+ Options
GTK+ Options
–class=CLASS Program class as used by the window manager
–name=NAME Program name as used by the window manager
–gdk-debug=FLAGS GDK debugging flags to set
–gdk-no-debug=FLAGS GDK debugging flags to unset
–gtk-module=MODULES Load additional GTK+ modules
–g-fatal-warnings Make all warnings fatal
–gtk-debug=FLAGS GTK+ debugging flags to set
–gtk-no-debug=FLAGS GTK+ debugging flags to unset
Application Options:
–exit-time Exit after n seconds time
–dummy-name Name when using the dummy daemon
-v, –verbose Verbose
–display=DISPLAY X display to use
There’s also –gtk-debug and –gdk-debug, but I could do with a little help for what to select for those, as just giving ’all’ seems a little counterproductive (for instance, ”touchscreen” and ”interactive” don’t seem very useful here).
10.03 jani@saegusa:~$ LC_ALL=C /usr/lib/gnome-settings-daemon/gsd-color –gtk-debug help
Supported debug values: misc plugsocket text tree updates keybindings multihead modules geometry icontheme printing builder size-request no-css-cache baselines pixel-cache no-pixel-cache interactive touchscreen actions resize layout all help
10.04 jani@saegusa:~$ LC_ALL=C /usr/lib/gnome-settings-daemon/gsd-color –gdk-debug help
Supported debug values: events misc dnd xim nograbs input cursor multihead xinerama draw eventloop frames settings opengl all help
Error parsing option –gdk-debug
(Looks like –gdk-debug reports an error with ’help’, despite having just listed it as one of the options.)