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

A hint for anyone googling for this: make sure that the value of gcmSenderId in your AndroidManifest.xmlstill has the trailing backslash (\) after you’ve changed the project number to your own. Otherwise the value gets interpreted as int, when it should be a string, which is one way to trigger the issue of devices being assigned empty/null IDs.

(The building instructions do have this documented in bold, but it’s still very easy to miss, I know I did. Complicating the debugging was my Nexus 5X, which kept getting a proper device ID even when all other devices using the same broken build failed to.)

@juliushaertl Is backporting for docs also done as per the manual? It seems pretty straightforward, so I think I can produce those pull requests too, if needed.

Fix indefinite article before Nextcloud (an->a)

Fix typo: ”parameters and are” -> ”parameters are” in Using the occ command.

@skjnldsv The points you raise are about SEO, and (from what I linked to above) I believe those issues are already being worked on. In case I was unclear, I’m not arguing for my idea to supplant the SEO work currently in progress, but to augment it.

Obviously, if #915 gets implemented as requested, my issue becomes moot, but from reading the comments there I understand it’s not so cut and dried that it will be.

As discussed in #915 and #517, Google seems to prefer old versions’ documentation at the expense of newer ones for some reason. The issue was partly mitigated by the fix for #958, which added prominent links to the latest version on top of old pages.

But these links currently point to the manual root. Ideally, I’d like these links to point directly to the latest version of the specific manual page I’m viewing, if available.

For instance, a search for nextcloud occ (for me at least) currently yields the manual page for version 9 as the top result. The ”latest version” link at the top then takes me to the server manual introduction. This means it’s still easier for me to navigate to the latest version of the ”Using the occ command” page by manually replacing the version number in the current URL with ’stable’ (or the latest release number) than to follow the ”latest version” link and try to find the page there.

Producing specific links is probably more laborious than the generic top-level-pointing link. For instance, there may no longer be a corresponding page in the stable version. Detecting such cases should be automatable I think, but there may be other issues that aren’t.

This will be much less of an issue once the SEO issue is resolved, but I think direct links would still remain useful, as people can still come up with search terms that search engines think correspond to old documentation better than the latest.

As a workaround, copying the icons and manifest from public to domain root seems to work (with Wekan snap running behind Apache here). As the files have a wekan- prefix, collisions shouldn’t be an issue. Naturally, this solution does require write access to the domain root directory.

Nope, Chrome manifests this too: