More > JRiver Media Center 28 for Linux
installJRMC - MC installer for Linux
countryboy:
I'm afraid it didn't fix the problem for LAN hosts.
- stop the service as you suggested
- use apt and remove mediacenter28
- download b11 version of installJRMC, unzip, and run
- reboot as a precaution
once again, looks like vnc is running the service:
ps -ef |grep jriver
jim 1221 1 0 19:01 ? 00:00:00 /usr/bin/perl /usr/bin/vncserver :1 -geometry 1440x900 -alwaysshared -name jriver:1 -SecurityTypes None -autokill -xstartup /usr/bin/mediacenter28
jim 1222 1221 0 19:01 ? 00:00:00 /usr/bin/Xtigervnc :1 -rfbport 5901 -localhost=1 -SecurityTypes None -ClientWaitTimeMillis 30000 -NeverShared=0 -AlwaysShared=1 -geometry 1440x900 -desktop jriver:1 -depth 24 -auth /home/jim/.Xauthority
try clients: still get connection refused. on raspbian at least, the message from vncviewer has changed slightly, from the previous "no connection could be made because the target machine actively refused it." to "the connection was refused by the computer".
However, I used 'xtigervncviewer' on the debian mediaserver machine itself, specifying 'localhost::5901' --- and it connected fine and displayed the media server screen. I was able to interact as usual with the mediaserver. so the system seems to be working but something is messing up access from other hosts on the LAN. Maybe I need to research debian 11.2 port security?
countryboy:
sorry, hit send before fully engaging brain. both panel and gizmo work with the new configuration. I just can't display the jriver X display from a VNC client other than the mediaserver itself. progress has been made.... and I'm unclear on how the access code is supposed to be entered (or if) when using a remote VNC client.
I'll also try bringing it up headless and see if the stability issue for headless is gone with the virtual display functioning and report on that..
JimH:
You might want to try a different virtual desktop
countryboy:
well, this message is intended to be a helpful assessment, not critical. I used my headless install for a few hours last night (primarily with gizmo), and for my use there were a couple of showstoppers. This may not belong in the installJRMC subtopic.
I've tried to keep the variables under control with a clean install. I have a relatively good mini PC, an intel NUC 10i7FNH - Intel corei7-10710U, 32 G RAM, 1TB SSD. My house ethernet is all cat 6 switched, single subnet. My music files are on an NFS server on the LAN. I have a large music repository and over the years have used most of the music software out there. I have been running this exact system (music repository/NFS server, network NUC, audio system) for nearly a year with roon without issues, so I think the platform is healthy and stable. (The only systems I have found that do well with large repositories are roon and jriver. I have issues with roon's privacy policy)
so, I installed fresh copy of debian 11.2 on the NUC. Did not add any applications or packages, other than a couple of network/system packages. (debian default no longer comes with netstat?) used installJRMC specifying mediacenter28, imported my library (fastest indexing I've ever seen, BTW). Tried to run headless, got crashes predictably after about 10 minutes. As documented previously in this subtopic, got help from BryanC and reinstalled mediacenter to use xvnc. with the 11b version of installJRMC, this worked (though there is still a vnc remote client connect issue, not important for this message, and appears to be a lingering stability problem).
I connected the newly installed headless mediacenter via USB to my benchmark DAC and sat down to listen, using gizmo on an android tablet (I've also used web panel a little). There are 3 issues that I think critical:
1. fairly predictably, playback will stop after perhaps 30 minutes of play. This happened to me about 4 times in 2 hours. Usually it will come back spontaneously, but at least once I had to restart gizmo and reconnect. The symptom makes me think that some resource is being allocated and not released. Have not tried panel to compare playback with gizmo.
2. mediacenter stayed up for my listening session, but died overnight. I haven't done a log analysis yet. This same hardware and network were used with the same audio system for nearly a year with roon, and I did not experience any playback stoppage or system crashes in all that time, so this is very likely a mediacenter software issue. Update: restarted the mediacenter machine this morning, did a bit of browsing with panel, and it crashed again after perhaps 30 minutes (the machine, not just mediacenter)
3. gizmo is more like an alpha or proof of concept, and panel is limited. There does not seem to be a good client for mediacenter. To be concrete, just as examples,
- I have multiple copies of some albums: miles davis conception in both DSD (.dsf) and flac. dsf for the big fancy audio system, flac for playing on simple devices. with gizmo, I can't tell these apart and don't see how to check the encoding while playing.
- with a large music repository, search is painful or impossible. on gizmo, a search for miles davis offers me only the play options: does not let me drop down and browse all my miles davis albums. A quick look at panel indicates it does not resolve any of this.
So, perhaps mediacenter on a windows console is spiffy. for a headless linux mediacenter, there are stability and playback problems, and no good client option. I might try running the full mediacenter interface via vnc on a tablet - if I can get vnc to work on the client, but the stability would need to be resolved for production use....
again, not meaning to be negative, but this is my experience to date. a headless, stable mediacenter with a full featured client would be awesome.
BryanC:
You may want to break out your concerns into individual threads but I will try to address what I can here.
1. Gizmo is "supported" but for most intents and purposes has been superseded as the "in-house" mobile playback application by JRemote2. Therefore, your problems might actually be linked to the playback app and/or Android powersaving features (since there seems to be a time element involved).
2. On my system, MC does very infrequently crash, usually when I am taxing the import/analysis functions and clicking around the UI trying to tag stuff. But it maybe happens once a week at most and I'm a heavy user as I listen to MC nearly all day while programming. One thing that may contribute to your issues following import is that MC will build thumbnails of cover art and other images, which can be quite demanding on the disk/cpu. I like to force build them manually up front (search for "build thumbnails" in the options and you will be able to trigger it manually), after which I find MC to be more stable and less demanding on the system (I have ~100k files in my library, for reference).
3. The systemd service created by installJRMC should automatically restart the xvnc session if MC crashes, if it's not doing this, I can look into it. The cause of your original issue that I fixed was a change in how Xtigervnc forks its underlying processes, at least on Debian, which may also impact the ability of systemd to determine that the process has failed, I haven't looked into it.
4. For your multi-format files, look into using MC's "stacks" feature to treat them as a single entity, which may make browsing and playback more straightforward for you.
Hopefully this gives you some things to try out to fix your issues! I can assure you that MC is still the premier media management application for Linux despite some quirks, and it's worth working through them.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version