Copy metadata/hitsound to a difficulty while opening it in the editor causes an absurdly large file size

[Ryuusei-Aika]

For the information: I'm using Windows 10 Professional ver. 1809, and the Mapping Tools is ver. 1.3.0.0.
(Map in case you need it)

When I tried to copy hitsounds / metadata by using hitsound copier / metadata manager with a diff opening in the editor, they have randomly added many zeros in the [Hitobjects] section:

And it results in an absurdly large file size: (sorry it is in chinese but I believe you can get me)

[OliBomby]

From what I see in the screenshot, the length doesn't seem to be the only issue. All the objects have an absurd coordinate and time value and some sliders have 0 length.

Hitsound Copier and Metadata Manager also don't touch hitobjects all that much, so I think there's something wrong with the beatmap IO.

[OliBomby]

You say this only happens when you have the editor open with the beatmap you are copying to? It works completely fine when you don't have the editor open?

[Ryuusei-Aika]

Yes, But this seems quite random (for some maps, both the hitsound copier and metadata manager work fine even with a certain diff in the set opening in the editor)
So I'm doubting if that is caused by the file name of the map itself (because the map in question was created by me, so the file name just inherited the name of my .mp3 file instead of having a set number at its beginning)

[OliBomby]

I can't recreate the bug on my laptop, so I'm gonna assume it's a problem with editor reader. Next update will have an option to disable editor reader if it doesn't work on your pc for some reason. I might also add some sanity checks to see if what editor reader does makes sense.

[Karoo13]

Which diff is open in the editor, the one you are copying from or copying to?

[Ryuusei-Aika]

The one I'm copying to.

[Karoo13]

It sounds like an issue with the memory reading (which I am responsible for), where the game is taking a while to dispose of an older editor instance.

It should be a rare random occurrence when opening and closing the editor more than once, but if you are able to get this behavior consistently, please explain in detail what steps you are doing.

Otherwise, I will look into a fast way to detect multiple editor instances, it is currently not detected because it would take a few seconds every time the map is read.

[Ryuusei-Aika]

Well, I can't recreate that bug? anymore, but hours ago when I was trying to copy a complex timing to all diffs without open any of them, one of the .osu file becomes 10+ Mb again:

So yes, maybe that is just an I/O problem or something...

[OliBomby]

I dont know if it will be possible to fix this issue if it's this inconsistent and I can't reproduce it. I can't see all the internal values that could give a hint to where the problem could be.

The only option I see would be to log absolutely everything to some debug file so you can find the relevant information afterwards.

[Karoo13]

I think what you said confirms my previous comment, I will have to find a way to distinguish partially disposed editors from the active one.

[Lehepuhur]

I also got the same issue with the Slider Completionator.
Eventually got an Out Of Memory exception after a few minutes of getting large file sizes repeatedly.

[OliBomby]

Yo i think i fixed this with the latest commit. There might still be a tiny chance it does weird stuff, but at least it shouldn't create huge files anymore.
Coming in the next update.