So the 0x is being ommitted when putting it into the chordlist.xml, right?

Yes. I assume it somehow has to do with the XML read/write functions, something not being escaped that needs to be.

Meanwhile, a workaround seems to be, edit the XML file to replace the 0x266d with the more HTML-friendly ♭

Might be related to the 'home-brew' string lib

Additional info

The issue happens only on the score, NOT on the parts.
It's not only accidentals that are incorrectly rendered. Content inside parenthesis disappear.
custom chrods file : chords_jazz_mod.xml.zip

Part

Score

Workaround (kind of ...)

step 1 : format --> style --> chord symbols --> select jazz (or standard)
step 2 : format --> style --> chord symbols --> select "custom" and chose your custom xml file again.
==> chord symbols are fixed on the score
==> close and re-open the file, the issue appears again

Open *.mscz file with archiver and delete 'chordlist.xml'. Then MuseScore 4 shows chords normally.
What's the reaseon?

Probably because now you’ve removed the custom chord symbol definition that caused the problem, and you are back to using the default which works.

Is the issue still present on your side ? On the scores I'm working on at the moment, the issue is gone on the newest version.

As mentioned, it only occurs in scores using custom chord description files, and even then, only those using a specific syntax for specifying flats. For me it's still reproducible in 4.0.2. Maybe you implemented the fix I mentioned above in your XML and that's why it is working?

I'm using MuseScore 4.02 and Windows 10(Korean language).
Before, I copied 'chords_jazz.xml' to [documents] musescore folder, and edited just slash chord part(a little positioning fix).
But the error like screenshot above occured.. 😥

Now, I ran into [program files] muscescore folder, and backup the 'chord_jazz.xml' and edit directrly.
Set score's chord style to 'Jazz', and save it. Then I re-open the file and sharps(#) and flats(b) are shown correctly.

I also have this issue when using an custom chord style file. Is there a fix already? I have about 350 files top render with a custom style file and this is really annoying...

Windows 11 Musescore 4.0.2

I don't think there is anyone working on a fix in the code, but the solution for now is to fix your custom XML file to use the better syntax I described above in #16363 (comment)

I took a quick look and probably it has gone wrong either here: ce2473b#diff-34fc1099345fb1b9e716cbe1602692db544d21858204ce45642aa36e99f779afR1794 or here: 0a13b86#diff-34fc1099345fb1b9e716cbe1602692db544d21858204ce45642aa36e99f779afR1792 (see the Git Blame for ChordList::write)

I keep experiencing this issue, but I have never (intentionally) set a custom file for chord symbol styles. I didn't even know it was possible until I found this issue page. However in the past few days, my score has started exhibiting this problem a couple times. I just looked in Format --> Style --> Chord symbols and found it was set to Custom with "chords_std.xml". I don't know where this file came from so I assume its automatically built by MuseScore. The file says the version is 1.24, and it seems to be formatted correctly in terms of the XML but I don't know any of the specifics of this chord symbol style. So, I don't know why it would exhibit this problem. I had to first zip the XML to attach it since GitHub doesn't allow uploading XML files.
chords_std.zip

I don't know how this got set this way as I have never opened this Style menu before. Is there some keybaord shortcut or some other action that can automatically set this? I don't know how it keeps getting set this way and I would like to avoid it since this problem is still present.

Seems to happen on importing scores from older MuseScore versions

Seems to happe on importing scores from older MuseScore versions

Ah yes you are right, this score I'm working on was originally an older MuseScore version file. I'm guessing the chords_std.xml is a sort of bridge to make the new chord style system compatible with some previous one?

Which version stemmed the score from?
That chords_std.xml is part of MuseScore since Mu2. Only in Mu4 there are problems reading it properly (and that's what this issue here is all about)

chords_std is the default standard style; it it is just supposed to be accompanied by a tag marking it as such rather than as Custom. So simply change the style to Standard instead of Custom to workaround this.

Still an issue
ILikeTheFlowersLEAD.zip

That score doesn't show any evidence having been imported from XML though not from an older version of MuseScore

Except: it does have a(n empty) Poet tag in Score properties and a mscVersion tag of "4.20", and a creation date of 11.Dec.22. so before 4.0 release, so indeed got have been imporeted ort updated somehow

I had this when loading MS3 music into MS4. I went into format style - chord symbols: changed it to Jazz & it gave me the correct flat chords. Changed it back again and it was still correct.

Yes, that is the workaround

Came up again in https://musescore.org/en/node/363221

I believe it got go wrong somehere here:

            while (e.readNextStartElement()) {
                if (e.name() == "sym") {
                    ChordSymbol cs;
                    cs.fontIdx = fontIdx;
                    cs.name    = e.attribute("name");
                    cs.value   = e.attribute("value");
                    String code = e.attribute("code");
                    String symClass = e.attribute("class");
                    if (!code.empty()) {
                        bool ok = true;
                        char32_t val = code.toUInt(&ok, 0);
                        if (!ok) {
                            cs.code = 0;
                            cs.value = code;
                        } else if (Char::requiresSurrogates(val)) {
                            cs.code = 0;
                            cs.value = String::fromUcs4(val);
                        } else {
                            cs.code = val;
                            cs.value = String(cs.code);
                        }

probably in the toUInt() method

No it is not (not only though, see below), it is going wrong on write, this fixes it:

$ git diff
diff --git a/src/engraving/dom/chordlist.cpp b/src/engraving/dom/chordlist.cpp
index 8ddcd824d9..c80a218617 100644
--- a/src/engraving/dom/chordlist.cpp
+++ b/src/engraving/dom/chordlist.cpp
@@ -1780,7 +1780,7 @@ void ChordList::write(XmlWriter& xml) const
                 if (s.code.isNull()) {
                     xml.tag("sym", { { "name", s.name }, { "value", s.value } });
                 } else {
-                    xml.tag("sym", { { "name", s.name }, { "code", String::number(s.code.unicode(), 16) } });
+                    xml.tag("sym", { { "name", s.name }, { "code", u"0x" + String::number(s.code.unicode(), 16) } });
                 }
             }
         }

And indeed @cbjeukendrup was right in #16363 (comment).

But for all scores that had been written already it is too late, so the reading needs to get fixed too, prefixing a 0x it every value not having one and not starting with & (and ending with a ;, so basically being alpha-numerical.

Like this probably:

diff --git a/src/engraving/dom/chordlist.cpp b/src/engraving/dom/chordlist.cpp
index 8ddcd824d9..72936bd543 100644
--- a/src/engraving/dom/chordlist.cpp
+++ b/src/engraving/dom/chordlist.cpp
@@ -1685,6 +1685,9 @@ void ChordList::read(XmlReader& e)
                     String code = e.attribute("code");
                     String symClass = e.attribute("class");
                     if (!code.empty()) {
+                        if (!code.startsWith(u"0x") && !code.startsWith('&') && !code.endsWith(';')) {
+                            code = u"0x" + code; // fix broken chord lists
+                        }
                         bool ok = true;
                         char32_t val = code.toUInt(&ok, 0);
                         if (!ok) {

Let me PR that...

Came up again in https://musescore.org/en/node/364006