Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bob]

The latest build is up at:
https://files.jriver.com/mediacenter/channels/v22/latest/MediaCenter-22.0.111-5-armhf.deb (Also in the latest apt repository)

22.0.111-5 (7/11/2017)

See the main linux changelog

22.0.111 (6/23/2017)

See the main linux changelog

22.0.108 (5/18/2017)

1. Fixed: Keyboard searches/navigation within report controls did not support space characters because of a conflict with the space-bar accelerator key Play/Pause functionality.  Now a space is supported as long as it's not the first character in the search string.

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.

22.0.93 (3/28/2017)

See the main linux changelog

22.0.88 (3/24/2017)

See the main linux changelog

22.0.81 (3/17/2017)

See the main linux changelog

22.0.75 (2/17/2017)

1. NEW: Playback of unprotected wma files on ARM.

For other changes, see the main linux changelog.

22.0.73 (2/13/2017)

See the main linux changelog

22.0.71 (2/7/2017)

See the main linux changelog

22.0.63 (1/13/2017)

See the main linux changelog.

22.0.56 (1/5/2017)

See the main linux changelog.

22.0.48-2 (12/13/2016)

1. NEW: OpenGL 2.1 support. Needs testing. RPi 3 works in theater view with the optional OpenGL support but it's glacial for me.
2. Changed: The Audio Device Selection gives verbose device information about each device connected.
3. Changed: The Audio Device Selection no longer shows input devices.

[bob]

Watch for issues with the eventing re-write.

[mwillems]

Mediacenter is crashing on several of my pis immediately on launch with the following error (just recently upgraded them from an older version)

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.

[bob]

Mediacenter is crashing on several of my pis immediately on launch with the following error (just recently upgraded them from an older version)

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).

[mwillems]

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:
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).

[bob]

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:
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.

[mwillems]

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.

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.

[bob]

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.

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.

Yup, just regular old X forwarding.
It's pretty slow through ssh but decent enough for me when I do it directly and on a Lan.

[PAPETOURNE]

What file extention is to be taken to update MC22 in my NAS QNAP 251hs. taking the doawload as is does not work.

[mk9pa]

Brand new user, evaluating MediaCenter22.  Hope I'm posting in the right place for a bug report.

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.

[bob]

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.
You might want to check the docker thread if you want to try getting MC to run on ARM based QNAP boxes.

[bob]

Brand new user, evaluating MediaCenter22.  Hope I'm posting in the right place for a bug report.

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.

[mk9pa]

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.

The intent is that getting MC running can be done entirely by the headless RPi during boot, running with a virtual frame buffer.  Then, if access to the screen by a client is needed for configuration, etc., that can occur without any action on the RPi, just on the client.

The RANDR problem causes immediate MC22 crash on startup when running with tightvncserver with the RANDR extension missing message as others have reported.  Running with vnc4server causes an immediate crash but without the RANDR message.  Running with the current default Raspbian RealVNC server seems to work on the RPi side, but is not compatible with MacOS' screen sharing client. Thus the attempt to use Xvfb and x11vnc. With this combination, MC22 starts and runs fine, at least overnight, without JRemote communicating with it, and on the shared screen's desktop I can resize the MC22 window without any issue. Desktop performance is not great, but not terrible either.

Here's more detail on my setup.  Let me know if you would like something more.

RPi 3 running Raspbian Jessie fully updated as of 1/14/17.  MC22 Linux/Debian ARM build 22.0.63, installed following instruction at https://yabb.jriver.com/interact/index.php?topic=106027.0 up to (and including) the section "Installing MC", i.e. modifications to /boot/config.txt.

My notes on how to set it up once installed are:

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).

Now, start JRemote (3.23, iOS 10.2) and browse artists or albums.  When album art is missing on JRemote, it appears to produce a crash of MC22 pretty much every time, or at least a large fraction of the time. The x11vnc options are verbatim from one of the references I found along the way, and I can't find it at the moment.  I'll keep looking in case it's significant.

[bob]

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.

Update: the dummy X display works fine with remote desktop and xtightvncviewer.

[mk9pa]

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.

Thanks, Bob.  I'll try the dummy X server and xpra, which sounds like it should do what I want also.

[mwillems]

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?

[bob]

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?

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

[mk9pa]

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

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.

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     

[bob]

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.

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     

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

Code: [Select]

ii  xserver-xorg-video-dummy              1:0.3.7-1                        armhf        X.Org X server -- dummy display driver

[mk9pa]

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

Code: [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 

[bob]

It's there all right, but it won't install. Any hints on how you got it to install would be greatly appreciated 

Sorry 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).
Here is what all of my installed xserver packages look like (you'll need to look to see which version are the same and which aren't).

Code: [Select]

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


[mwillems]

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.

The answer appears to be to
1) modify the pi's config so that it loads its native display even when the HDMI is unplugged by modifying the config.txt as shown:

Code: [Select]

framebuffer_width=1920
framebuffer_height=1080
hdmi_group=2
hdmi_mode=82
hdmi_drive=2

and
2) Run x11vnc and MC on top of the actual display as follows

Code: [Select]

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. 

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 

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.

[bob]

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.

[mk9pa]

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 

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?" 

However, I start up JRemote on iOS, start scrolling through Albums, and after a few seconds of filling in missing artwork, MC crashes.

[mwillems]

Mwillems, nice solution and it works all right. That goes on the list of "Why didn't I think of that?" 

However, I start up JRemote on iOS, start scrolling through Albums, and after a few seconds of filling in missing artwork, MC crashes.

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).

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.

I honestly hadn't thought about memory usage; I just wanted a solution that was:
1) Guaranteed to support xrandr (and generally could be counted on to act like a normal x environment)
2) Didn't require meaningful package fiddling. 

I was already doing a variation on the x11vnc method with one of my pi's hooked up to a touch screen so it was just a matter of finding time to test.

[mk9pa]

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.

For anyone else who might be reading this, the Mac's VNC client (Screen Sharing...) requires a password on the x11vnc invocation, and it can't be put in the background before popping up the dialog box that asks for it.  So the "-bg" option to x11vnc can't be used, and the "-usepw" must be used.

Bottom line, for light testing so far, I now seem to have a working combination, fully scriptable startup of MC on RPi boot, with a persistent display connection to a virtual frame buffer that can be connected over VNC to a Mac and, I presume, other systems as well. The bug appears to be caused by possibly over-aggressive thumbnail building when large numbers of thumbnails are requested by JRemote (or, I imagine, other clients).

Thanks Mwillem.

Next: room correction.

[mwillems]

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!)

One down 

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.

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.

[mk9pa]

One down 

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.

Again, 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.

[mk9pa]

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.

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.

[bob]

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.

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.
Tools->Options->Audio->Settings-> Use SoX ....

[mk9pa]

I don't know what is going on here but you could try the alternate resampler.
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.

[bob]

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?

[mk9pa]

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.

[bob]

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.
I'm wondering if it's a power issue.

[mk9pa]

Try the headphone jack or 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.

[bob]

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.
Can you try a beefier PS on the RPi or perhaps separate power for the USB DAC (like with a powered hub).

[mk9pa]

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?

[bob]

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.
I have played a bit with a more cpu specific build for the Pi (2 and above) but I didn't see a very significant benchmark difference so I let it slide for now.

[mk9pa]

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.

[bob]

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.

[mk9pa]

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%).

[bob]

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.

[madbrain]

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.
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 ?

[bob]

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.
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 ?

Ubuntu is just debian with some bells and whistles (in my abbreviated definition).
There are lots of people running MC on Ubuntu and the architecture shouldn't make any difference. You would just run the Pi build and you should be able to install it with apt.

[mwillems]

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.

[bob]

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.

[astromo]

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.

This is what I get in response to an update ...

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]

but no update to Build 106, however I am on Build 102 that doesn't appear to feature in the list:

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.

Have I set up the repo on my system incorrectly or is there something adrift elsewhere?

[Awesome Donkey]

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.

[astromo]

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.

Yep .. you're onto it.

I've gone into /etc/apt/sources.list.d/mediacenter22.list
  and updated it to read:

Code: [Select]

#MC
deb http://dist.jriver.com/beta/mediacenter/ wheezy main
deb http://dist.jriver.com/latest/mediacenter/ wheezy main
I'm assuming that this will mean that an update will get the latest of either "beta" or "latest"?

[madbrain]

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.

Thanks. I'm running my Pi headless currently, and would be running the ODROID XU4 headless too if I purchased it. I think I had to enable 24 bits on the Pi also, even for the remote X server, in order to get Media Center to work.

I think I will give the ODROID XU4 a try in a couple weeks when I come back from vacation.