XLib: extension "RANDR" missing on display ":1.0".
Segmentation fault
Mediacenter is crashing on several of my pis immediately on launch with the following error (just recently upgraded them from an older version)It's not the GL stuff, it's the multiple monitor fix.Code: [Select]XLib: extension "RANDR" missing on display ":1.0".
Segmentation fault
The pis in question are running on a virtual display, so I assume this is related to the recent GL changes?
Rolling back to 22.0.36 fixes it, but I didn't try all the intervening versions, so let me know if there's a good one to test.
It's not the GL stuff, it's the multiple monitor fix.
It needs the xrandr library. Perhaps it's missing on your Pi's (and perhaps I forgot to add it to the .deb dependencies).
Good pointer, but not the answer sadly. Xrandr is installed, but tightvncserver doesn't support randr on its virtual displays. I get the same error when I try to run xrandr on the pis. Looks like I'm not alone:How about running with the dummy XServer and using a XWindows server to access the Pi?
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=16598
So it looks like I'll need to find a new VNC server that supports xrandr. In the interest of completeness, I'll note that my JRiver server instance (where I was having the drawing issues) was also being accessed via VNC (but not via a virtual display, I was using x11vnc for it).
How about running with the dummy XServer and using a XWindows server to access the Pi?
I do this on linux all the time and OSX with XQuartz. Windows can use putty and XWin as a the server.
You mean plain old X forwarding? I'll give it a shot when I have some time, but performance is usually pretty poor when I've tried it, and the windows xserver's I've used have been kind of flaky.Yup, just regular old X forwarding.
Apparently some VNC implementations do correctly support randr, and tightvnc has some other problems as well (i.e. can't display modern desktops at all), so my first stop is trying a few other vnc servers. I guess newer pi builds actually ship with RealVNC built in, so I may do a quick reinstall on a pilot system and see if that works.
What file extention is to be taken to update MC22 in my NAS QNAP 251hs. taking the doawload as is does not work.MediaCenter Arm is not packaged for non-intel QNAP boxes.
Brand new user, evaluating MediaCenter22. Hope I'm posting in the right place for a bug report.You might be running into that same xrandr issue above.
I am running MC 22.0.63 on Raspberry Pi 3/Raspbian Jessie. My requirement is that RPi be headless, and so far so good -- it has never had a monitor, keyboard, or mouse plugged into it, just power and network.
MC22 is running using Xvfb for a virtual display, and x11vnc to act as VNC Server. This works well so far (at least, overnight), and I can connect to the VNC server from a Mac using Screen Sharing. It's the only configuration I've found so far that works on both ends (RPi and Mac).
I also purchased JRemote 3.23 on iOS and tested it out. On at least 6 occasions it has crashed MC22. Here are some error messages I captured from the RPi terminal window where MC22 was invoked from:
*** Error in `mediacenter22': double free or corruption (fasttop): 0x6e5995c0 ***
*** Error in `mediacenter22': double free or corruption (fasttop): 0x667ca8c8 ***
*** Error in `mediacenter22': double free or corruption (fasttop): 0x679bcd78 ***
Another crash occurred without an error message, just a segmentation fault.
The one thing that seems to be in common in all the crashes is that JRemote was downloading artwork (or metadata?) when all the crashes occur. I can make it crash about once a minute by populating album art in the grid view on JRemote.
You might be running into that same xrandr issue above.
Otherwise if you can give us enough detail to try to duplicate that here we'll look at it.
We have not observed that behavior with a real display or the dummy X server and X forwarding.
On the RPi, one time:
* Set x11vnc password (required by Mac’s Screen Sharing) using x11vnc -storepasswd
On the RPi, each time it boots:
* Check that no leftover x11vnc or Xvfb are running
* Start xvfb: Xvfb :1 -screen 0 1280x768x24 &
* Start an X window manager: DISPLAY=:1 lxsession &
* Start MediaCenter: DISPLAY=:1 mediacenter22 /MediaServer &
On the MacOS client, if want to attach to the MediaCenter display:
* ssh -l pi -L 59000:localhost:5900 <rpi3-hostname> 'x11vnc -localhost -display :1 -forever -usepw -ultrafilexfer’
* Confirm that x11vnc is using port 5900
* Use Finder’s Connect To Server… (cmd-K) and type in vnc://localhost:59000. Password is the one given to x11vnc -storepasswd.
* In this case, the local (MacOS) port 59000 is tunneled to the RPi’s port 5900. All the RPi port numbers and screen numbers have to match (with offset of 5900).
I've not used xvfb before so I'm not sure how or if that supports xrandr.
I'll try your test with the dummy xserver and missing coverart when I can.
I've not used xvfb before so I'm not sure how or if that supports xrandr.
I'll try your test with the dummy xserver and missing coverart when I can.
Bob I'm a little confused about what you mean by "dummy xserver"; when you mentioned it earlier, I assumed you were talking about xvfb or another similar dummy xserver program (like the one bundled in tightvnc). Do you mean a different virtual display package (if so which one)? Or do you just mean telling the actual physical display hardware to initialize even if not connected to a monitor? Or something else?
xserver-xorg-video-dummy 1:0.3.7-1+b3 amd64 X.Org X server -- dummy display driver
Code: [Select]xserver-xorg-video-dummy 1:0.3.7-1+b3 amd64 X.Org X server -- dummy display driver
Tested this and it worked without a glitch in both remote desktop and xtightvncviewer
The following actions will resolve these dependencies:
Remove the following packages:
1) xserver-xorg-input-all
2) xserver-xorg-input-libinput
3) xserver-xorg-input-synaptics
4) xserver-xorg-input-void
5) xserver-xorg-video-fbturbo
Downgrade the following packages:
6) xserver-xorg [1:7.7+16 (now, stable) -> 1:7.7+7+b1 (stable)]
7) xserver-xorg-core [2:1.18.4-2+rpi1 (now, stable) -> 2:1.16.4-1 (stable)]
8) xserver-xorg-input-evdev [1:2.10.3-1 (now, stable) -> 1:2.9.0-2 (stable)]
9) xserver-xorg-video-fbdev [1:0.4.4-1+rpi2 (now, stable) -> 1:0.4.4-1+b3 (stable)]
Leave the following dependencies unresolved:
10) raspberrypi-ui-mods recommends xserver-xorg-video-fbturbo
On RPi/Raspbian, by any chance? The latest Raspbian archives have a version of xserver-xorg-video-dummy which cannot satisfy its dependencies without downgrading and removing a number of other X packages. I know, not JRiver's problem, really.Interesting. I seem to recall something like that and I don't know how I resolved it but it is on there now... Rapsbian jessie: Raspbian GNU/Linux 8
Aptitude output:Code: [Select]The following actions will resolve these dependencies:
Remove the following packages:
1) xserver-xorg-input-all
2) xserver-xorg-input-libinput
3) xserver-xorg-input-synaptics
4) xserver-xorg-input-void
5) xserver-xorg-video-fbturbo
Downgrade the following packages:
6) xserver-xorg [1:7.7+16 (now, stable) -> 1:7.7+7+b1 (stable)]
7) xserver-xorg-core [2:1.18.4-2+rpi1 (now, stable) -> 2:1.16.4-1 (stable)]
8) xserver-xorg-input-evdev [1:2.10.3-1 (now, stable) -> 1:2.9.0-2 (stable)]
9) xserver-xorg-video-fbdev [1:0.4.4-1+rpi2 (now, stable) -> 1:0.4.4-1+b3 (stable)]
Leave the following dependencies unresolved:
10) raspberrypi-ui-mods recommends xserver-xorg-video-fbturbo
ii xserver-xorg-video-dummy 1:0.3.7-1 armhf X.Org X server -- dummy display driver
Interesting. I seem to recall something like that and I don't know how I resolved it but it is on there now... Rapsbian jessie: Raspbian GNU/Linux 8It's there all right, but it won't install. Any hints on how you got it to install would be greatly appreciated ;DCode: [Select]ii xserver-xorg-video-dummy 1:0.3.7-1 armhf X.Org X server -- dummy display driver
It's there all right, but it won't install. Any hints on how you got it to install would be greatly appreciated ;DSorry I dont' remember exactly. I think I might have pulled down one or other of the packages from the debian site directly not through rapsbian (perhaps the dummy server).
dpkg -l | grep xserver
ii x11-xserver-utils 7.7+3 armhf X server utilities
ii xserver-common 2:1.17.2-1+rpi1 all common files used by various X servers
ii xserver-xorg 1:7.7+7+b1 armhf X.Org X server
ii xserver-xorg-core 2:1.17.2-1+rpi1 armhf Xorg X server - core server
ii xserver-xorg-input-all 1:7.7+7+b1 armhf X.Org X server -- input driver metapackage
ii xserver-xorg-input-evdev 1:2.9.2-1~bpo8+1 armhf X.Org X server -- evdev input driver
ii xserver-xorg-input-synaptics 1.8.2-1~bpo8+1 armhf Synaptics TouchPad driver for X.Org server
ii xserver-xorg-video-dummy 1:0.3.7-1 armhf X.Org X server -- dummy display driver
ii xserver-xorg-video-fbdev 1:0.4.4-1+rpi1 armhf X.Org X server -- fbdev display driver
ii xserver-xorg-video-fbturbo 1.20150305~205709 armhf X.Org X server -- fbturbo display driver
framebuffer_width=1920
framebuffer_height=1080
hdmi_group=2
hdmi_mode=82
hdmi_drive=2
export DISPLAY=:0
export USER=pi
sleep 5
x11vnc -display :0 -geometry 1920x1080 -auth guess -forever -bg
sleep 5
mediacenter22 /mediaserver
You can set a passwd in x11vnc as well and add that to the config as well. Ok, thanks for clarifying. That package is (as noted) not well supported on the pi. The good news is that you don't need the dummy server to have working VNC.
I think I've got a working solution (at least for my problem) and it's the least complex solution (i.e. involves the least additional software) so seems the least likely to fail in the future. It's partially based on Hilton's solution from way back when.
...
That seems like the most durable solution as x11vnc isn't relying on any kind of virtual display and is instead just forwarding what would be coming out of the HDMI port if it were plugged in. No moving parts ;D
I'm going to try and update my guide in the next few days as the headless solution there no longer works with the latest MC.
Mwillems, nice solution and it works all right. That goes on the list of "Why didn't I think of that?" :P
However, I start up JRemote on iOS, start scrolling through Albums, and after a few seconds of filling in missing artwork, MC crashes.
I used the dummy server because I figured it would use less memory and because on intel the hardware didn't want to boot in some situations using real video memory with hdmi but since the rpi allocates memory video from general purpose memory and it can boot without a cable attached your solution may actually use less memory.
That's ringing a bell for me: thumbnailing is memory and cpu intensive and my recollection is that MC used to crash like that for me occasionally whenever I did something that forced it to generate a bunch of thumbs at once.
Two suggestions:
1) Go into options-->tree&view-->thumbnail creation threading and set it to "low." That option was specifically created to mitigate thumbnail related crashing on the pi.
2) Try the "build all thumbnails" option in the same part of options (after setting priority to low). That will suck up a lot of CPU for several hours, but once they're built, they're built for good and you will get massive gains in speed and stability (I always do this on new pis).
Mwillem, you nailed it! Yes, that was it. I don't know if just setting threading to low would have done it by itself. But now I can scroll through artwork in JRemote to my heart's content and it is very fast and does not crash MC22. (At least not yet!)
I have to say, though, that the HDMI interception by x11vnc is much, much slower than sending MC output to Xvfb and attaching x11vnc to that. Maybe 10x slower. I switched back to using Xvfb + x11vnc after building the thumbnails, and no crashing problem either with that combination.
One down ;DAgain, your info is correct. Reducing the frame buffer size (I went to 1440x900, hdmi_mode = 47) has performance on par with the Xvfb approach (which may mean that the performance bottleneck is the network or VNC endpoints). And the setup for this is simpler on both server and client sides.
It shouldn't really be slower as it's using the native hardware acceleration. One thing to consider (if you care, you may not) would be increasing the video memory available to the pi. Because my method uses the actual display, it relies (to some limited extent) on the video memory that the pi makes available from the main memory split. Obviously the virtual xservers just work entirely out of main memory and don't get any hardware acceleration.
I'm getting further along in working through my first-ever MC setup. Same platform as in my posts above (RPi 3, Raspbian Jessie, now attached a Schiit Modi USB DAC driving some pretty high quality amp and speaker combo [Waveform Mach Solo]). Wonderful, still haven't plugged a monitor, mouse, or keyboard into the RPi. Really like JRemote.I don't know what is going on here but you could try the alternate resampler.
But I have run into a problem on audio quality and am looking for suggestions or pointers. When I resample to 88.2 or 96 kHz as appropriate (i.e. an integer multiple of the original sampling rate), the output is badly distorted, sounding like clipping, but occurring at all volumes. I found a thread on MC21 on Windows where the author had a similar sounding problem. It goes away when I turn off DSP Studio's Output Format or when I set Output Format to be the same as source sampling rate. But it does not go away when I change internal volume to 100% (0 dB). With 2x resampling CPU usage is about 20-25%; without it is about 10%.
I've tried selecting a number of different output devices that show up: ALSA direct hardware device, ALSA hardware device with software conversions, ALSA PulseAudio Sound Server, all behave the same. I have previously run the Schiit DAC without problems on all ranges of HD audio up to 24/192, from a Mac Mini running iTunes.
Interestingly, I also have installed Room EQ Wizard and tried that out, just an initial experiment so far. It also works well on the RPi 3. But it reports during waveform acquisition that it detected distortion and suggested the waveform was being clipped and to reduce input volume. I was nowhere near saturation in the digital domain; REW reported the waveform was under 10% of peak. In going through all the analysis types I found very high harmonic distortion in the frequency range < 200 Hz, peaking at 13%. Essentially all of it is second harmonic.
So, this issue may be endemic to the RPi somewhere that affects both MC22 and REW.
BTW, I am looking at this as a start to doing room correction, assuming that I should be able to do a variety of DSP operations on the RPi as required. This was the first simple experiment, and should be something easily handled.
I don't know what is going on here but you could try the alternate resampler.Bob, thanks. I tried your suggestion and it did not help. On individual instruments, like single notes on a piano or a voice, it sounds very obvious, like the sound is being modulated with a signal of maybe 15-20 Hz?? Kind of like a light fluttering.
Tools->Options->Audio->Settings-> Use SoX ....
Bob, thanks. I tried your suggestion and it did not help. On individual instruments, like single notes on a piano or a voice, it sounds very obvious, like the sound is being modulated with a signal of maybe 15-20 Hz?? Kind of like a light fluttering.Is that only with the USB DAC as the output device?
Is that only with the USB DAC as the output device?So far I have only tested it with a USB DAC. I have a HiFiBerry on the way. Have not tried the headphone jack.
So far I have only tested it with a USB DAC. I have a HiFiBerry on the way. Have not tried the headphone jack.Try the headphone jack or HDMI.
Try the headphone jack or HDMI.Hi Bob, I've been working on a number of other things like trying to integrate a HiFiBerry DAC+ Pro (it has issues with WiFi) and starting on room correction, so I haven't done a thorough test. I did some quick tests and my poorly-supported conclusions are: headphone jack does not show the issue, and HiFiBerry does not either. It seems specific to USB. I did not try HDMI.
I'm wondering if it's a power issue.
Hi Bob, I've been working on a number of other things like trying to integrate a HiFiBerry DAC+ Pro (it has issues with WiFi) and starting on room correction, so I haven't done a thorough test. I did some quick tests and my poorly-supported conclusions are: headphone jack does not show the issue, and HiFiBerry does not either. It seems specific to USB. I did not try HDMI.From what I understand, the USB bus shares I/O bandwidth with the Networking on the RPi. I don't think that is too likely to be the issue though.
Wait, I just measured some performance data with convolution and parametric equalizers and find that 22.0.71 is running nearly 2x the speed of the same test on 22.0.63 on a Raspberry Pi 3 B. Either that or my hardware is suddenly twice as fast which seems very unlikely. Was that an improvement in this release?Interesting, I'm not sure what that would be. You might want to check the windows changelog where the general purpose changes show up.
Playing a 24/88 file now on RPi 3 with Raspbian, with 22 parametric eq filters enabled, and MediaCenter is running around 25 - 32% of one CPU core. Reasonable headroom, definitely no clicks or crackling. FYI.Thanks for the report, that sounds really good.
One more update. I now have 22 parametric EQ filters (frequency EQ from REW) as before combined with a stereo 16k-tap .wav convolution file (phase linearization from rePhase) running on the RPi 3, MC 22.0.75, and it's doing fine. It gets a little uncomfortably high CPU playing 24/96 files, running around 2.5 - 3x real time and using about 65-70% of one CPU core on average. 16/44 files are running at 6.5 - 7x real time and use about 30-35% of one CPU core. I think I hear an occasional click when I'm doing something with the MC GUI which temporarily loads the CPU core higher, but while just playing music it seems to be running without issue. The default Raspbian "ondemand" speed governor seems to work fine; it bumps CPU frequency from 600 to 1200 MHz at 50% core usage. Whenever MC is playing the core clock is 1200 MHz (settings are in the file /etc/init.d/raspi-config and from some searching it appears previous Raspbian releases may have set the threshold at 95%).I appreciate the detailed testing information. It lets us know when we are bumping against the limitations of the system.
I have gotten Media Center to work on my Raspberry Pi 3 . However, the network & disk I/O on the Pi is too slow for my needs.Ubuntu is just debian with some bells and whistles (in my abbreviated definition).
I'm considering purchasing an Odroid XU4 . This is an ARM single board computer . However, it uses Ubuntu as the default distribution, rather than Debian, unlike the Pi.
Is there any chance that Media Center would run on the Odroid ? I understand it won't have a Debian package installer, but could the bits be extracted manually ? Or is there no chance that it will run ?
One thing to be aware of is that many previous odroid models lacked adequate color depth in their graphics driver to correctly display MC (i.e. only 16 or 24 bit color, I can't recall at this remove). I never got MC working correctly on an ODROID C1 or U3. The XU4 may have solved the issue, or may not have. If you install MC and start it, and only see an all white or all black window that's the color depth issue at work.MC requires 24 bits.
The latest build is up at:
http://files.jriver.com/mediacenter/channels/v22/latest/MediaCenter-22.0.106-armhf.deb (Also in the latest apt repository)
22.0.106 (5/11/2017)
1. Fixed: The audio options configuration dialog could crash upon close.
2. Platform independent changes from the main windows changelog.
22.0.97 (4/21/2017)
1. Platform independent changes from the main windows changelog.
cubox-i:~$ sudo apt-get update
[sudo] password for cubox:
Hit:1 http://ports.ubuntu.com xenial InRelease
Hit:2 http://ppa.launchpad.net/gerardpuig/ppa/ubuntu xenial InRelease
Hit:3 http://apt.armbian.com xenial InRelease
Get:4 http://ports.ubuntu.com xenial-security InRelease [102 kB]
Hit:5 http://dist.jriver.com/beta/mediacenter wheezy InRelease
Get:6 http://ports.ubuntu.com xenial-updates InRelease [102 kB]
Get:7 http://ports.ubuntu.com xenial-backports InRelease [102 kB]
Get:8 http://ports.ubuntu.com xenial-updates/main armhf Packages [479 kB]
Get:9 http://ports.ubuntu.com xenial-updates/universe armhf Packages [419 kB]
Get:10 http://ports.ubuntu.com xenial-updates/multiverse armhf Packages [4,864 B]
cubox-i:~$ sudo apt-get install mediacenter22
Reading package lists... Done
Building dependency tree
Reading state information... Done
mediacenter22 is already the newest version (22.0.102-armhf).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
It appears you're only on the beta repo. You need to also add the latest repo alongside it to update to 22.0.106.
#MC
deb http://dist.jriver.com/beta/mediacenter/ wheezy main
deb http://dist.jriver.com/latest/mediacenter/ wheezy main
One thing to be aware of is that many previous odroid models lacked adequate color depth in their graphics driver to correctly display MC (i.e. only 16 or 24 bit color, I can't recall at this remove). I never got MC working correctly on an ODROID C1 or U3. The XU4 may have solved the issue, or may not have. If you install MC and start it, and only see an all white or all black window that's the color depth issue at work.
MC 22.0.111 doesn't 'see' second monitor and there is no resolution choice possible else than 'Desktop resolution'Second monitor on an RPi??