Arkisto 2021

I can appreciate avoiding extra trouble for others

6. lokakuuta 2021 klo 13.16
Sijainti: Muut: Crowdin
Avainsanat: iNaturalist, kieli

Okay, I can appreciate avoiding extra trouble for others, and it’s certainly easier for me to add the workaround translation for just this one case. I’ve now done that (with your suggestion, which was probably as good as this can be).

%{month_name} %{year} would work better for Finnish, as that would allow the month name to be inflected apart from the year (which is how the current accepted translation of this string was intended to work). OTOH, the Finnish way a ”month name + year number” combination in inflected in most, if not all (relevant) cases is like that: add a suffix to the month name, leave the year number as-is. Without workarounds, %{month_year} generally only works for the nominative case.

Vastaa viestiin sen kontekstissa (Crowdin)

Finnish inflection can be a pain

2. lokakuuta 2021 klo 13.45
Sijainti: Muut: Crowdin
Avainsanat: iNaturalist, kieli

”Monthly Supporter since December 2018” would be ”Kuukausittainen tukija joulukuusta 2018 lähtien”, where ”joulukuu” is the month name (and the current translation for that string doesn’t correctly account for the inflection either). Finnish has 6 different locational cases alone, so yeah, Finnish inflection can be a pain :)

I’ve only come across this title string (%{taxon} from %{place} in %{month} by %{user}) on an observation page where the date is obscured to month, whereas the (more usual case of) title for non-obscured observations has already been translated to work around the inflection. Although the latter makes for varyingly clunky Finnish, at least it’s technically not incorrect, and hence that’s how the problem is usually worked around in Finnish software translations. I can figure out a similar workaround translation for this string too (that is, take your option b).

I’m still confused by the source string here using %{month}, which then gets turned into %{month_year}, requiring translators to pay attention to the explainer text in the reference, instead of just using %{month_year} in the source directly.

Vastaa viestiin sen kontekstissa (Crowdin)

This is apparently caused by the static build of ffmpeg

24. syyskuuta 2021 klo 20.26
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: ffmpeg, Ubuntu

All right, I got curious enough try again, and found that this is apparently caused by the static build of ffmpeg that I’m using: I used yle-dl --verbose again, then interrupted the download immediately, ran the ffmpeg command (as reported by yle-dl) directly, and this resulted in a segmentation fault.

I then tried the same command in a VM with ffmpeg from Ubuntu repositories, and there the download finished successfully.

So the only remaining issue with yle-dl in this is the terminal being broken: that did not occur with directly-run ffmpeg despite the segfault.

I’m closing this issue though, so that it remains as documentation for the problem (and cause) as originally reported.

Vastaa viestiin sen kontekstissa (Github)

elements have a %{month_year} instead of %{month}

24. syyskuuta 2021 klo 19.00
Sijainti: Muut: Crowdin
Avainsanat: iNaturalist, kieli

For some reason, instead of the %{month} here, a %{month_year} is shown instead, at least when it comes to <title> elements. So for instance, an observation from July 2020 currently has the <title> rendered as ”heinäkuu 2020ssa”, when it should be ”heinäkuussa”.

Vastaa viestiin sen kontekstissa (Crowdin)

7-hour long program not downloaded completely

21. syyskuuta 2021 klo 12.25
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: ffmpeg, Gnome, Ubuntu, Yle Areena

Trying to download this 7-hour long program only downloads (about) the first 6 hours and 40 minutes (~ 11 GB), after which the process just stops, and leaves Gnome terminal screwed up (typed characters are invisible until I run reset). In the web player the video seems to play past that point just fine.

This is on Ubuntu 20.04 with ffmpeg version N-58594-g715f63232f-static (static build from git master on 20210908).

jani@saegusa:Työpöytä$ /usr/local/bin/yle-dl 'https://areena.yle.fi/1-50934704'
yle-dl 20210808: Download media files from Yle Areena and Elävä Arkisto
Copyright (C) 2009-2021 Antti Ajanki <antti.ajanki@iki.fi>, license: GPLv3

Unsupported codec with id 98313 for input stream 2
Unsupported codec with id 98313 for input stream 5
Unsupported codec with id 98313 for input stream 8
Unsupported codec with id 98313 for input stream 11
Unsupported codec with id 98313 for input stream 14
Unsupported codec with id 98313 for input stream 17
Unsupported codec with id 98313 for input stream 20
Unsupported codec with id 98313 for input stream 23
Unsupported codec with id 98313 for input stream 26
Unsupported codec with id 98313 for input stream 29
Output file: YleX Esittää: Yle 95 - synttäribileet Linkkitornista: 2021-09-18T00:00.mkv
jani@saegusa:Työpöytä$  size=10814976kB time=06:39:40.68 bitrate=3694.5kbits/s speed=  44x

Note the prompt appearing on top of ffmpeg output on the last line. Typing echo $? reveals that the process exited with code 1.

Here’s the output when run with --verbose.

I’ve only tested this over the past couple of days so I don’t know if it’s a temporary error. Since the portion of the stream that I actually care about is all prior to the 6-hour mark, and the partial download is playable, I’m not too bothered to have the rest download. Reporting this just in case it’s a useful test of a corner case.

Vastaa viestiin sen kontekstissa (Github)

I tested the 94.0a1 nightly now, and the issue is still present

20. syyskuuta 2021 klo 21.50
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox

Also, I tested the 94.0a1 nightly now, and the issue is still present.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I ran mozregression and got the first bad revision

19. syyskuuta 2021 klo 20.00
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Wayland

I ran mozregression like this (twice, to be sure):

MOZ_ENABLE_WAYLAND=1 mozregression --profile /home/jani/.mozilla/firefox/fyaus28k.LP1940417 --bad 91 --good 89 --profile-persistence clone-first

Here’s the result (it was the same for both bisects):

5:25.73 INFO: No more integration revisions, bisection finished.
5:25.73 INFO: Last good revision: 9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8
5:25.73 INFO: First bad revision: 7b82d177a6b979036f180329be6b029d690d9e0c
5:25.73 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9f0fbb1431721c9eae68a3c94ae49a4d33fdb1f8&tochange=7b82d177a6b979036f180329be6b029d690d9e0c

According to that log, this changeset was introduced to address #1661516.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

The trigger for this is MOZ_ENABLE_WAYLAND=1 and layout.css.devPixelsPerPx=1.2

11. syyskuuta 2021 klo 13.08
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox

I can’t speak for Jeroen, but I played around with the upstream builds (both 92 and 91) and my faulty profile a bit and managed to isolate the trigger combination for this: MOZ_ENABLE_WAYLAND=1 and setting layout.css.devPixelsPerPx to my preferred value of 1.2; either resetting layout.css.devPixelsPerPx to its default (-1.0), or running Firefox without MOZ_ENABLE_WAYLAND=1 will make the toolbar items work again. Here’s the graphics portion of my about:support.

So my steps to reproduce this are:

  1. start Firefox with MOZ_ENABLE_WAYLAND=1
  2. set layout.css.devPixelsPerPx to 1.2
  3. click on the hamburger menu button

What I expect to happen:
For the hamburger menu content to show.

What happens instead:
The hamburger menu content flickers or doesn’t show at all.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Motorola probably had a good reason for this limitation

4. syyskuuta 2021 klo 12.07
Sijainti: Keskustelupalstat: XDA Forums
Avainsanat: Motorola, turvallisuus

Interesting, I wasn’t aware about that – so I assume, that you have observed that behavior yourself and not only read about that?

Yes I have: with a charger plugged in and the flash LED on, the phone does show the charging indicator, but the charge level is still dropping. Ampere also shows that it is in fact draining the battery:

MSe1969 said:
I guess, this would be a hardware limitation, I can’t think about a setting controlling this – however, honestly, I don’t know.

Okay, thanks anyway. Motorola probably had a good reason for this limitation, such as temperature control, and overriding it would thus be risky too, even if it were possible.

Vastaa viestiin sen kontekstissa (XDA Forums)

Is there any way to override the flash limitation?

23. elokuuta 2021 klo 21.03
Sijainti: Keskustelupalstat: XDA Forums
Avainsanat: Android, Motorola, reddit

Firstly, a big thank you @MSe1969 for keeping my old Moto G (falcon) secure!

My question is about a specific feature: for some reason, Motorola has apparently disabled charging the device when the camera (flash) LED is on (I’ve found at least one Reddit thread confirming this). Do you happen to know if this is a hardware-level limitation, or if there’s any way to override it in the OS/kernel?

I’ve been testing the phone as a security camera, and while it’s otherwise working, in practical use not having the flash LED means having to have a separate light source, adding its own complications (timers and so on).

Vastaa viestiin sen kontekstissa (XDA Forums)

Vanhempia »