Channelscan progress lost in translation

[Klaas de Waal]

The presentation of the progress and the signal strength by the channelscanner is wrong since a few days. See the attached picture. This regression is likely to be have been introduced by the translations recently committed.

The relevant bit of code in channelscanner_gui_scan_pane.cpp is from 15 Jul 2017, commit 24064ac6e618bc5f340c08116c6ed4dae2c0aaa6 and has always worked correct. This is the code:

void ChannelScannerGUIScanPane::SetStatusSignalStrength(int value)
{
    if (m_signalStrengthText)
        m_signalStrengthText->SetText(tr("%1%")
                               .arg(static_cast<uint>(value * 100 / 65535)));

It looks to me that it tries to translate the number. I am not aware that this is done anywhere else in the code and if the translation is done by a string to string replacement then you need a lot of strings.....

I intend to fix this now for the time being by changing the code to this:

void ChannelScannerGUIScanPane::SetStatusSignalStrength(int value)
{
    if (m_signalStrengthText)
        m_signalStrengthText->SetText(QString("%1%")
                               .arg(static_cast<uint>(value * 100 / 65535)));

which will restore the old behavior.

If the intention is really to translate the number then the original code can always be restored once the translation is fixed.

It is possible that the changed behavior of the "tr" function may have effects elsewhere as well.

[Klaas de Waal]

Channelscan Scan Progress and Signal Strength presentation wrong

[Klaas de Waal <kdewaal@…>]

In 66b7dd2d0b/mythtv:

Channelscan progress percentage

No translation is needed for percentage values such as "83%".
Change the formatting function for the percentage presentations of
the signal strength, progress etc in the SCANNING page of mythtv-setup
from tr to QString.

Refs #13585

[Klaas de Waal]

This does of course not solve the underlying problem in the translation system, which produces now the string "18:{1%?}" instead of "18%" for

tr("%1%).arg(18)

as shown in the attached screenshot.

[Klaas de Waal <kdewaal@…>]

In 8f2475fb83/mythtv:

Channelscan progress percentage

No translation is needed for percentage values such as "83%".
Change the formatting function for the percentage presentations of
the signal strength, progress etc in the SCANNING page of mythtv-setup
from tr to QString.

Refs #13585

(cherry picked from commit 66b7dd2d0b059d02e88f2d716a4e49bd0b967498)
Signed-off-by: Klaas de Waal <kdewaal@…>

[Ian Campbell <ijc@…>]

In 1236aef0a/mythtv:

Fix musicmetadata handling of compilations.

Fixes #13585
Closes #192

Signed-off-by: David Hampton <mythtv@…>

---

Squashed commit of the following:

commit ca6ffb883c9f32ec8a7f1461a0b4d71914e3c210
Author: Ian Campbell <ijc@…>
Date: Mon Mar 16 20:18:29 2020 +0800

musicmetadata: check for empty field before dumping to db

This ensures all the fields are properly filled in. In particular it ensures
that non-compilation albums have the compilation artist filled in to match the
artist, otherwise they all end up with "Unknown Artist" which in turn means
that albums which happen to have the same title (e.g. "Greatest Hits") all get
lumped into one.

commit 88418b6c7c400d04440eeeaf232f571a1463b09a
Author: Ian Campbell <ijc@…>
Date: Mon Mar 16 20:02:28 2020 +0800

musicmetadata: clear id fields when main field is set

... otherwise they are never recalculated when the actual value changes.

commit a0e93004c18f3a34c2c2d450af72366860a19b4e
Author: Ian Campbell <ijc@…>
Date: Sun Mar 15 15:35:32 2020 +0800

musicmetadata: Fully update music_albums, including name and artist

Since these may have changed.

commit 30898722aebbcfbd9d28557fcdbf2324379db2b6
Author: Ian Campbell <ijc@…>
Date: Sun Mar 15 15:33:43 2020 +0800

musicmetadata: Do not call ensureSortFields after checkEmptyFields

The latter already calls the former right at the end.

commit 2e4a0e93768142c05bcfcd1b58f1b7db7bbde609
Author: Ian Campbell <ijc@…>
Date: Fri Feb 28 07:15:41 2020 +0800

musicmetadata: ensure compilation artist id is always set

I was observing that I had one music_albums entry per track on each
compilation album after the album was scanned the second time (first time it
went in correctly).

The issue was that on reloading from the DB the field was not being initialised
so remained as -1 when the entry came to be written back, which because the
field in the DB is unsigned ended up being stored as 0, so when subsequent
lookups try to find the album it failed every time (since the 0 in the database
matches neither -1 nor the >0 correct value) and a fresh one is inserted for
every track.

Fix this by adding and using {get,set}CompilationArtistId corresponding to
the uses of {get,set}ArtistId. I broke out getCompilationArtistId from the
within exiting getArtistId implementation.

commit 56506e477ceb815081ed05aea3ff6656413b592a
Author: Ian Campbell <ijc@…>
Date: Wed Feb 19 20:05:22 2020 +0800

metaioflacvorbis: Handle ALBUMARTIST as a fallback for COMPILATION_ARTIST

Although there is no real standard this is as described in
​https://picard.musicbrainz.org/docs/mappings/ and what one gets by default
using the picard tool (as I do).

commit 1e303b005e4b613e4b965b1a5cbdc830b64020c2
Author: Ian Campbell <ijc@…>
Date: Thu Feb 27 20:00:05 2020 +0800

Support mythutil --scanmusic --force to ignore file timestamps

Useful after an upgrade (or while hacking) or if something else changed which
doesn't affect the timestamp of the file.

[Ian Campbell <ijc@…>]

In 672d45b7b/mythtv:

Fix musicmetadata handling of compilations.

Fixes #13585
Closes #192

Signed-off-by: David Hampton <mythtv@…>

(cherry picked from commit 1236aef0ae520294446ed91d91ed0e988976e183)

---

Squashed commit of the following:

commit ca6ffb883c9f32ec8a7f1461a0b4d71914e3c210
Author: Ian Campbell <ijc@…>
Date: Mon Mar 16 20:18:29 2020 +0800

musicmetadata: check for empty field before dumping to db

This ensures all the fields are properly filled in. In particular it ensures
that non-compilation albums have the compilation artist filled in to match the
artist, otherwise they all end up with "Unknown Artist" which in turn means
that albums which happen to have the same title (e.g. "Greatest Hits") all get
lumped into one.

commit 88418b6c7c400d04440eeeaf232f571a1463b09a
Author: Ian Campbell <ijc@…>
Date: Mon Mar 16 20:02:28 2020 +0800

musicmetadata: clear id fields when main field is set

... otherwise they are never recalculated when the actual value changes.

commit a0e93004c18f3a34c2c2d450af72366860a19b4e
Author: Ian Campbell <ijc@…>
Date: Sun Mar 15 15:35:32 2020 +0800

musicmetadata: Fully update music_albums, including name and artist

Since these may have changed.

commit 30898722aebbcfbd9d28557fcdbf2324379db2b6
Author: Ian Campbell <ijc@…>
Date: Sun Mar 15 15:33:43 2020 +0800

musicmetadata: Do not call ensureSortFields after checkEmptyFields

The latter already calls the former right at the end.

commit 2e4a0e93768142c05bcfcd1b58f1b7db7bbde609
Author: Ian Campbell <ijc@…>
Date: Fri Feb 28 07:15:41 2020 +0800

musicmetadata: ensure compilation artist id is always set

I was observing that I had one music_albums entry per track on each
compilation album after the album was scanned the second time (first time it
went in correctly).

The issue was that on reloading from the DB the field was not being initialised
so remained as -1 when the entry came to be written back, which because the
field in the DB is unsigned ended up being stored as 0, so when subsequent
lookups try to find the album it failed every time (since the 0 in the database
matches neither -1 nor the >0 correct value) and a fresh one is inserted for
every track.

Fix this by adding and using {get,set}CompilationArtistId corresponding to
the uses of {get,set}ArtistId. I broke out getCompilationArtistId from the
within exiting getArtistId implementation.

commit 56506e477ceb815081ed05aea3ff6656413b592a
Author: Ian Campbell <ijc@…>
Date: Wed Feb 19 20:05:22 2020 +0800

metaioflacvorbis: Handle ALBUMARTIST as a fallback for COMPILATION_ARTIST

Although there is no real standard this is as described in
​https://picard.musicbrainz.org/docs/mappings/ and what one gets by default
using the picard tool (as I do).

commit 1e303b005e4b613e4b965b1a5cbdc830b64020c2
Author: Ian Campbell <ijc@…>
Date: Thu Feb 27 20:00:05 2020 +0800

Support mythutil --scanmusic --force to ignore file timestamps

Useful after an upgrade (or while hacking) or if something else changed which
doesn't affect the timestamp of the file.

[Klaas de Waal]

Looks to me that today's commit should refer to ticket #13595