frustration with MediaMonkey...

[stax76]

I'm currently pretty frustrated with MediaMonkey, at a point I seriously consider to migrate to MusicBee or start a new private or open source project, StaxRip is in maintenance mode so I have time and I have interest in learning new languages and frameworks. There is only one issue I have and it's called ugly or broken UI in both MM4 and MM5, in particular with my High DPI display, problems started 2015 when I migrated from Win 7 to Win 10 and got serious when I got 4K hardware few weeks ago.

There are different people with different problems and many have spent a great amount time writing extension code or learning how MM4 works and customize it. My extension is private/personal and I spent quite some time for it so migrating to MM5 won't be easy, migrating to MusicBee would even be harder because of the custom and db only fields, I really would like the MM4 UI to be fixed so I can use it without frustration until a new solution is running, be it MM5, MusicBee or anything else, I always liked MediaMonkey a lot similar how I like Firefox, both pioneers with great extensibility so I want to be loyal and hope the best for their future.

Many people donated money for StaxRip for bug fixes and present and future features and I donated to get bugs fixed in tools StaxRip uses, last time to the current main developer of AviSynth+ because it was crashing StaxRip, he fixed it with remote debugging because it was happening only in Windows 10 and he had only Windows 7 and it happened only when the .NET framework was loaded into the process and only with x64 and not x86, there were numerous bugs that happened only in Win 10 and not in Win 7 and numerous only with x64 and not x86, what I try to say is sometimes a remote machine or a virtual machine is needed for debugging and donations can motivate and help, working on StaxRip I struggled hard with DPI scaling until I figured out how to test it with a virtual machine.

[stax76]

This was intended as reply to a PM I received from PetrCBR about a bug report but since these private discussions and bug tracker issues weren't very effective before I decided to add it as another public rant to my previously posted rant, bear with me those rants have much room for improvement social and language wise, I have more talent for the tech it talks about.

You can reproduce it with vmware/virtualbox by setting 144 DPI in the client OS, you can also include vmware/virtualbox in your debugging environment for instance with a script to copy files from host to client and to start the app in the client, and for hard cased attach the debugger remotely or setup a dev environment in the client OS. That is how I've build and tested my apps for different platforms and environments. I've explained all this before both in PM and public forum and not much has happened. The fact that MM hasn't working high DPI support ten years after Windows Vista introduced that feature 2007 show that there is little interest in finally getting it done and doing it right, currently there is little reason to have confidence that the situation will improve in coming years, there is a better UI framework now with MM5 but the core problem off not developing and testing for high DPI remains. It's exhausting to make bug reports and waiting countless days for a new build just to learn that it's as severely defect like it was before. I fixed hundreds of bugs and glitches uploading a test build in less then 2 days, often within 3 hours after it was reported, I've scripted building and uploading test builds and included the script in a keyboard driven app launcher to make uploading a fix a matter of a shortcut key. I reported the app TreeSize being broken on high DPI this week, the same day I got a kind and professional reply thanking me for interest and reporting and giving a link to a test build of the upcoming major release which completely fixed it.

If you don't work and test with at least 144 DPI then likely issues will linger for months if not years until more people use high DPI, why there aren't more complains about MM is beyond me, maybe people don't report them and use MusicBee instead which looks pretty good on high DPI, only sub dialogs have a couple of issues, according to spy++ it's WinForms/WinAPI based which surprises, it makes the impression being based on something more modern. I stopped testing it however when I saw the poor and ugly extension API.

Maybe many people don't use high DPI because they are young and have good eyes, I don't know why apparently I'm the only user with 288 DPI, I tested the last MM5 build in vmware with 144 DPI and 1920x1080, it's not working correctly so I conclude there is not a single MM dev using or testing more then 120 DPI, seriously, I don't get it.

Every time I see the MM issues which is everyday and no solution in sight I automatically think if it's finally time to do something to leave the issues behind, the most simple solution would be a basic WPF based front-end on top of MM4, a complete UWP app with XAML or HTML or a app based on electron/chromium with dart or typescript would be more ambitious, maybe too ambitious, I contribute to free software since 15 years and have little motivation to start a big project so I build things for personal use only like my personal video player, I wrote lately about it here.

[PetrCBR]

Here are 4 screens from my testing environment (FullHD, DPI at 150% and 2K, DPI at 150%) ... to me it doesn't look unusable.

[stax76]

On 144 DPI or more if you open/close options/properties dialog several times you don't see problems with dialog location and size? Both dialogs went off screen here in no time at 288 DPI 4K so I tried it in vmware 144 DPI 1920x1080 getting the same issue.

Off screen means they are gone and only winlister can bring them back, also height did collapse totally dialog height being reduced to title bar height.

I'll post some screenshots and specs later today (no time right now).

[PetrCBR]

No, tried ~10 times and work just fine ... but i've tried to set 4K and 300% DPI and window is always on screen, but size and position isn't always same (looks like it's at correct size or maximized).

EDIT: i've found the reason of inconsistence.

[stax76]

if you restore window position you absolutely must check if the window is within bounds of working area when you restore or I promise you it will be totally off screen or half off screen again! For instance when people use and change setups with multiple displays and extend mode, please note I have single display connected only when I use MM and duplicate mode only when I watch TV, single or duplicate make no difference here. Your x pos was -1506, y 3636 !

https://postimg.org/image/dzjzo49ar/

Of course I had the same bug about 8 years ago btw.

https://github.com/stax76/staxrip/blob/ ... sc.vb#L225

[PetrCBR]

We already have that function to check window is on monitor ... but there was an bug.

[stax76]

thanks for fixing it, a test build would be gladly appreciated