It works! Brilliant, thanks a lot!
It works! Brilliant, thanks a lot!
It works! Brilliant, thanks a lot!
I’m having a problem adding a custom image when the generated preview has already picked up an image. If I remove the automatically linked image, the ’Remove Image’ button remains as such, so there’s no ’Add Image’ button in its place to add the custom image.
As an example, here’s a recorded gif of my attempt to customize the image when linking to this page on Tukes’ website.
With few hints about preview-suitable content provided by that page, Visual Link Preview picks up an overlay image (magnifying glass), which I’d then like to replace with the actual image (a safety reflector) from that page (after already downloading it). But after I click ’Remove Image’ to remove the overlay image, I have no way to add the correct image, because the ’Add Image’ button is missing.
I’m using the current latest release of the plugin (2.0.1) in WP 5.1.
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.
Eipä tuosta enää taida puuttua kuin että käväiset A2-illassa kilpahuutamassa. :o)
Höh, noin paljon medianäkyvyyttä, ja minä silti vasta tämän kautta ensimmäistä kertaa törmäsin mihinkään noista. Hyvin olen suotimeni näköjään säätänyt (kaikki perhe- ja ihmissuhdejutut = block).
Mukava nähdä, että vaikutat tyytyväiseltä. Haters gonna hate.
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”.)
Kaatuneen koivun latva osittain tien tukkeena Annanpolulla.
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.