by TIV73 » Wed Aug 07, 2024 3:43 pm
I've had little to no success getting mediamonkey in a usable state with wine or bottles. Crossover fared way better right off the bat, and I got the application in a semi-stable state with close to no effort. The biggest issue that persists for me is are occasional, and seemingly random, hard crashes with the `not implemented` error that were mentioned before. When doing a quick trace in wine it looked like these errors come mostly from two different sources.
The first one is networking. I noticed that whenever mediamonkey wants to do a network call and it doesn't work for whatever reason, the error occurs. I guess it's some outgoing calls where mediamonkey tries to check for updates, query local upnp devices, or something along those lines. Turning off the local firewall to open all ports before starting mediamonkey greatly reduced these errors. It's not ideal, but at least a starting point.
The second one seems to be, and I could be totally wrong about this, related to oledb calls. I have no idea if that's correct or not, and if mediamonkey even uses oledb to talk to its database or not, but judging from the logs wine seems to think so.
If we just need to find the right dependencies to make everything work, or if some calls are just not yet implemented by wine is anybodies guess, though.
Another thing that makes matters more complicated is the frontend mediamonkey uses. From what I can tell chromium (and by extension cef) has traditionally been a little rocky to get working on wine, for various reasons. It doesn't help that chromium already runs natively on linux, as do most framework that depend on the engine, like electron. Applications like mediamonkey that rely on the chromium engine but are strictly windows-only are, in the grand scheme of things, outliers, so there is also not much incentive or huge push from wine to get chromium to run better.
There are various proposed workarounds related to hardware acceleration, passing startup parameters to chrome (which is not applicable in our case), setting different desktop modes, switching between xorg and wayland, or getting different hardware. It's all very trial-and-error.
I've had little to no success getting mediamonkey in a usable state with wine or bottles. Crossover fared way better right off the bat, and I got the application in a semi-stable state with close to no effort. The biggest issue that persists for me is are occasional, and seemingly random, hard crashes with the `not implemented` error that were mentioned before. When doing a quick trace in wine it looked like these errors come mostly from two different sources.
The first one is networking. I noticed that whenever mediamonkey wants to do a network call and it doesn't work for whatever reason, the error occurs. I guess it's some outgoing calls where mediamonkey tries to check for updates, query local upnp devices, or something along those lines. Turning off the local firewall to open all ports before starting mediamonkey greatly reduced these errors. It's not ideal, but at least a starting point.
The second one seems to be, and I could be totally wrong about this, related to oledb calls. I have no idea if that's correct or not, and if mediamonkey even uses oledb to talk to its database or not, but judging from the logs wine seems to think so.
If we just need to find the right dependencies to make everything work, or if some calls are just not yet implemented by wine is anybodies guess, though.
Another thing that makes matters more complicated is the frontend mediamonkey uses. From what I can tell chromium (and by extension cef) has traditionally been a little rocky to get working on wine, for various reasons. It doesn't help that chromium already runs natively on linux, as do most framework that depend on the engine, like electron. Applications like mediamonkey that rely on the chromium engine but are strictly windows-only are, in the grand scheme of things, outliers, so there is also not much incentive or huge push from wine to get chromium to run better.
There are various proposed workarounds related to hardware acceleration, passing startup parameters to chrome (which is not applicable in our case), setting different desktop modes, switching between xorg and wayland, or getting different hardware. It's all very trial-and-error.
