More > JRiver Media Center 31 for Linux

Two new MCWS issues with Linux

(1/4) > >>

avid:
As part of my ongoing porting from Windows, I have today come across two MC issues on Linux.

Firstly, the MCWS command 'Control/MCC?Command=20007' (MCC_EXIT) is documented as having parameter (default 0) 'int nMode (0: normal, 1: force close (close media server), 2: force close (allow media server))'. So on Windows I have been sending this command (with no parameter) to clear the screen, but leaving MCWS still running and responsive on the server. On Linux, it kills the server totally. But I find that I can achieve what I need with MCC_MINIMIZE_WINDOW. However, it is a difference in behaviour from Windows to Linux.

Much more significantly, I have a problem with my occasional tree-walk of the (28k-track) library to build a more efficient in-memory representation of Albums and Tracks. This uses a sequence of "Browse/Children" and "Browse/Files" MCWS. This tree-walk has worked well on Windows ever since the introduction of MCWS. But on Linux, after a few hundred calls, one of the calls simply hangs, stopping the processing dead.

I will write a stand-alone tree-walk console program to exercise this. But in the meanwhile is there anything I can check on the server to see how it is failing?

BryanC:
Re: #1, services are just a completely different beast on Linux than on Windows, thus AFAIK there isn't really a way for Media Server to co-exist in the background alongside the main MC process as there is on Windows (without launching the separate process in read-only mode). Therefore, MCC_MINIMIZE_WINDOW is going to be your best solution without really intricate and delicate workarounds.

bob:

--- Quote from: avid on August 11, 2023, 11:33:31 am ---As part of my ongoing porting from Windows, I have today come across two MC issues on Linux.
...
Much more significantly, I have a problem with my occasional tree-walk of the (28k-track) library to build a more efficient in-memory representation of Albums and Tracks. This uses a sequence of "Browse/Children" and "Browse/Files" MCWS. This tree-walk has worked well on Windows ever since the introduction of MCWS. But on Linux, after a few hundred calls, one of the calls simply hangs, stopping the processing dead.

I will write a stand-alone tree-walk console program to exercise this. But in the meanwhile is there anything I can check on the server to see how it is failing?

--- End quote ---
Try enabling logging, it might be useful to see what the last thing is did before freezing was.

avid:
Re #2, apologies all. There is no Linux MCWS capacity problem. My tree walk test program showed up a serious inefficiency in my HTTP client code (recently re-worked to allow the move to Linux). So the client was being starved of resources and would hang eventually. There is no obvious problem with MCWS server-side on Linux.

BTW and FYI, the reason for the tree-walk is shown by my test app: "Found 2343 albums with 28573 tracks in 236 seconds". So I do this only occasionally (typically overnight) and cache the album and track data as an XML file - much faster for startup.

Re #1, I am finding occasionally that my MC media server process on Linux is not always there when I expect it. On Windows, it has been rock solid. So I may need to add some process monitoring and spawn a new "MC31 /MediaServer" process as needed.

BryanC:
installJRMC can create systemd services to help facilitate that for you (--service jriver-mediaserver).

Navigation

[0] Message Index

[#] Next page