INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Linux => Topic started by: bob on March 05, 2015, 05:56:05 pm
-
http://files.jriver.com/mediacenter/channels/v20/latest/MediaCenter-20.0.101-armhf.deb
20.0.101 Fixed playback of ALAC files.
20.0.99 Added support for Media Keys.
20.0.93 Fixes the issue with crashing on the RPi 1 (arm6l devices).
Changed the /mediaserver mode to startup minimized to try to save on processing power required while doing playback.
20.0.91 Includes the /mediaserver mode switch change that doesn't hide the UI but still prevents blocking. This means you can use it with a dummy X Server but still connect to it remotely to change the settings.
For the list of other changes, see the general debian linux release announcement for linux specific changes and the windows announcement for multiplatform changes.
This is a full version of MediaCenter for Debian Wheezy on ARM for your testing pleasure. It will time out on June 10, 2015.
We may or may not release an end user package for ARM in the future. Much will depend on if it requires any support outside of generic linux support.
This is compiled to run on the RPi 1 as a minimal system (arm6l). It will also run on an arm7 box (i.e. RPi 2, cubox) but is not and will not be optimized for that platform.
Feedback welcome.
-
This is compiled to run on the RPi 2 as a minimal system (arm6l).
Quick question: the RPi 2 is an arm7 platform; the original RPi was arm 6. So is this build still arm 6 optimized? Or did you rebuild on the Pi 2?
Just trying to figure out if I need to redo my benchmarks ;D
-
Quick question: the RPi 2 is an arm7 platform; the original RPi was arm 6. So is this build still arm 6 optimized? Or did you rebuild on the Pi 2?
Still aiming at the 6l.
Just swapped out the pi 1 for the pi 2 in the build system.
They haven't built a arm7k Raspbian system yet, just the kernel.
We aren't going to try to support a bunch of cpu's with this and the JRMarks really aren't that different between the 2.
-
Still aiming at the 6l.
Just swapped out the pi 1 for the pi 2 in the build system.
They haven't built a arm7k Raspbian system yet, just the kernel.
We aren't going to try to support a bunch of cpu's with this and the JRMarks really aren't that different between the 2.
I figured, but I wanted to make sure. I mentioned this in the other thread, but running an RPi 2 on Arch ARM (which is fully arm7h), my JRMark was about 20% higher than on Raspbian (635 on Arch vice 523 on Raspbian). Obviously it doesn't necessarily follow that gains from JRiver optimization for arm7h would be that significant, and it sounds they're not? Regardless, thanks for clarifying.
-
Is this just an update inline with other Linux code base updates or have you added/changed any features for ARM?
-
I think it's the same Linux code, just compiled for ARM.
-
I think it's the same Linux code, just compiled for ARM.
Ok so we should check the most recent Linux change log then.
-
I just did some fairly thorough testing of playback and network features on a raspberry pi 2 (both on Arch and Raspbian). I didn't experience any regressions, FWIW. Let me know if there's anything specific you'd like tested.
-
Ok so we should check the most recent Linux change log then.
yes and for the changes in general, the windows log.
-
I just did some fairly thorough testing of playback and network features on a raspberry pi 2 (both on Arch and Raspbian). I didn't experience any regressions, FWIW. Let me know if there's anything specific you'd like tested.
Thanks, I'm just looking for breakage right now.
-
I just did some fairly thorough testing of playback and network features on a raspberry pi 2 (both on Arch and Raspbian). I didn't experience any regressions, FWIW. Let me know if there's anything specific you'd like tested.
Is there any reason not to use Arch? I'd like to try it out if its stable as I've always liked Arch.
-
Is there any reason not to use Arch? I'd like to try it out if its stable as I've always liked Arch.
In this context, I haven't seen any significant downsides once everything is running.
Arch requires much more manual configuration on the front end, but that's true anytime you use Arch for anything. The Arch ARM base has virtually nothing preconfigured except SSH. You have to setup your locale and timezone in the shell, install X, install your desktop environment, configure wi fi yourself, and repackage the Mediacenter .deb, but once that's all done, it's done. I've done enough Arch installs that I can be done in about 40 minutes, but the first time took a few hours. If you're not used to systemd, there can be a bit of a learning curve with that too.
Pros:
1) Newer software and sound drivers
2) Arm7 optimized so there are mild performance gains
3) Minimal base, so it's only running what you tell it to run.
Cons:
1) More work to setup (the flip side of minimal base)
2) It's a rolling release, so it will occasionally break. I've been running Arch on my main PCs for close to a year, and have only seen one instance where an update broke things in a serious way and required manual intervention. I haven't seen any breakage on the Pis yet, but that day will probably come sooner or later.
Debian Jessie is pretty up to date right now (because it just had a package freeze in november), so if you just want newer packages *and* stability you can install Jessie on the Pis. I installed jessie on several Pi 1's and it worked well (although some of the core packages are still wheezy packages because the pi foundation isn't moving on to Jessie yet).
-
I've having some trouble with this build on the Pi 1. It's segfaulting when I switch to the audio view. Sounds like perhaps a imaging issue.
Anyway backing off to 66 works fine.
-
I gave the Pi2 a pretty thorough stress test today.
I have 3 zones configured:
Pi-Default > HDMI
Pi-E17DAC > USB
Pi-Bluetooth > BT
Playing 320K MP3s to all zones at once and using JRemote playing to "this device" on the iPhone.
(so 4 streams at once)
The Pi was running @ ~15% CPU once all streams are running and peaks @ 80% CPU with a few streams starting together.
When one zone goes to the next track the CPU goes to 40% for a few seconds before dropping back to 10-15%
It didn't stop or stutter until I started all 4 streams at once, then it took 15 seconds to stabilise and was fine even with 2-3 streams overlapping when going to the next track.
Not bad for the little Pi2!
It plays 176K and 192K FLAC from the USB stick ok to a single zone transcoding to 44.1K or 96k, playing the same tracks from the attached USB HDD it would occasionally buffer.
This might me due to brown-outs on the USB bus to the HDD as it's really right on the limit running a HDD without a powered USB hub for the HDD. (the Pi has a soft power down poly fuse which causes brown-outs on the USB bus if you push it too far, this is to protect the processor and kernel from panicking and crashing.
96K and 44K FLACs are fine.
2ch SACD to PCM is close but not quite there, and multi-channel is out of the question for FLAC or SACD.
This is using the Pi2 as a server which is not really what it's designed for. Its nice to know you can use it as a server for MP3s and lower samplerate FLACs though.
Using the Pi as a renderer with transcoding on the server it played everything upto 24bit/96K FLAC from the server.
-
That's surprisingly good. Thanks for taking the time to report what you found.
-
It plays 176K and 192K FLAC from the USB stick ok to a single zone transcoding to 44.1K or 96k, playing the same tracks from the attached USB HDD it would occasionally buffer.
This might me due to brown-outs on the USB bus to the HDD as it's really right on the limit running a HDD without a powered USB hub for the HDD. (the Pi has a soft power down poly fuse which causes brown-outs on the USB bus if you push it too far, this is to protect the processor and kernel from panicking and crashing.
I did some testing on this today myself. I had no problems playing resampled 192K FLAC files (resampled by the pi to 96K or 44K) from an external HDD plugged directly into the Pi today, but plugging in extra peripherals caused buffering issues like you described. With just my external HDD, a wifi dongle and my DAC plugged in, I managed to listen through an entire album resampled from 192K down to 96K with no dropouts or pauses, and CPU utilization remained low. If I plugged in a USB stick or another HDD, I could replicate your buffering issue. Using a powered USB hub with plenty of current allowed me to run two external HDDs at the same time without harming Pi Playback while resampling.
Obviously not all external HDDs have the same power requirements, but I think it's likely to be a brown out/power issue, not a bus speed issue as I had no problems pulling 192K FLACs from an external HDD (provided I kept my power load down). I was doing local playback, not serving, so that may be a distinction (depending on how you tested), but the fact that you got good playback with a USB stick seems like a red flag for a power issue.
In more general notes, I got in about six hours of playback testing today at the office with zero issues; local playback on the pi 2 worked for all file types tested without breaking a sweat. With a 2amp power supply, I managed to power the Pi itself, a wifi dongle for control, and my external DAC (an ODAC). I'll post some pics over in the other thread.
-
Hi Guys,
Have recently moved to JRiver Linux, and with JRemote, there is simply no going back for me. This interface simply the best there is for both sound quality & user interface. I have gone through virtually most there are in the audiophile World. e.g JPlay, Foobar, ....., squeezebox, LMS,...., Volumio, RuneAudio, PiCoreplayer via LMS......., you got the point. :)
Many thanks to Bob & the team for your great efforts with the ongoing development.
Currently, I have also experimenting this build on my Pi2, and is working great! I use ENC-Viewer via iPad to do all the desktop configurations and importing library. JRemote for navigating the library and playing the music.
Here comes my question, has anyone able to get this to work with Banana Pi or BeagleBone Black? Grateful for some technical assistance getting either BPi or BBB to work?
Many thanks,
Chanh
PS: It is sad to see this project terminate at June.
-
Here comes my question, has anyone able to get this to work with Banana Pi or BeagleBone Black?
Just to inform all that I have now able to get JRiver to work with BananaPi under Ulbutun distro. :)
-
PS: It is sad to see this project terminate at June.
Nice work on bananaPi!
I wouldn't worry about the demo expiring in June. Im pretty sure by then Jim will be happy to take our money! :) Its still experimental for now because there are still bugs to be ironed out.
-
Obviously not all external HDDs have the same power requirements, but I think it's likely to be a brown out/power issue, not a bus speed issue as I had no problems pulling 192K FLACs from an external HDD (provided I kept my power load down). I was doing local playback, not serving, so that may be a distinction (depending on how you tested), but the fact that you got good playback with a USB stick seems like a red flag for a power issue.
It is indeed not a bus bandwidth issue, its a brown-out issue. I was getting the rainbow square popping up in the top right corner of the screen which indicates a power issue.
When my HDD was on a powered USB hub in the office today it was fine.
Yesterday I tested USB stick and HDD performance with HDParm and its more than adequate.
I got 400MB/s cached read from USB stick and 250MB/s from HDD with about 28MB/s buffered read from both USB stick and USB HDD.
So no bottleneck there unless your getting USB brown-outs which will cause buffering because the HDD momentarily looses power during the brown-outs.
-
I had a complete lockup this afternoon. Here's the tail of the syslog.
HDD was on the powered hub at the time.
Syslog Errors:
Mar 10 16:02:30 raspberrypi kernel: [11160.363230] usb 1-1.5.1: new full-speed USB device number 42 using dwc_otg
Mar 10 16:02:30 raspberrypi kernel: [11160.511991] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512026] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512046] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512065] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512084] usb 1-1.5.1: config 1 has no interface number 2
Mar 10 16:02:30 raspberrypi kernel: [11160.524235] usb 1-1.5.1: New USB device found, idVendor=1852, idProduct=50d0
Mar 10 16:02:30 raspberrypi kernel: [11160.524264] usb 1-1.5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 10 16:02:30 raspberrypi kernel: [11160.524283] usb 1-1.5.1: Product: FiiO USB DAC-E17
Mar 10 16:02:30 raspberrypi kernel: [11160.524301] usb 1-1.5.1: Manufacturer: FiiO
Mar 10 16:02:30 raspberrypi kernel: [11160.541054] input: FiiO FiiO USB DAC-E17 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:1852:50D0.0012/input/input17
Mar 10 16:02:30 raspberrypi kernel: [11160.541696] hid-generic 0003:1852:50D0.0012: input,hidraw0: USB HID v1.00 Device [FiiO FiiO USB DAC-E17] on usb-bcm2708_usb-1.5.1/input0
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] log.c: Invalid UTF-8 string following below:
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] #004: ▒▒il#006
Mar 10 16:02:35 raspberrypi rsyslogd-2177: imuxsock lost 7948 messages from pid 18986 due to rate-limiting
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
-
We often put a timeout on early builds of something new so that a year later, when someone has a problem, we know there build is less likely to be broken.
-
I had a complete lockup this afternoon. Here's the tail of the syslog.
HDD was on the powered hub at the time.
Syslog Errors:
Mar 10 16:02:30 raspberrypi kernel: [11160.363230] usb 1-1.5.1: new full-speed USB device number 42 using dwc_otg
Mar 10 16:02:30 raspberrypi kernel: [11160.511991] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512026] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512046] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512065] usb 1-1.5.1: config 1 has an invalid interface number: 3 but max is 2
Mar 10 16:02:30 raspberrypi kernel: [11160.512084] usb 1-1.5.1: config 1 has no interface number 2
Mar 10 16:02:30 raspberrypi kernel: [11160.524235] usb 1-1.5.1: New USB device found, idVendor=1852, idProduct=50d0
Mar 10 16:02:30 raspberrypi kernel: [11160.524264] usb 1-1.5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 10 16:02:30 raspberrypi kernel: [11160.524283] usb 1-1.5.1: Product: FiiO USB DAC-E17
Mar 10 16:02:30 raspberrypi kernel: [11160.524301] usb 1-1.5.1: Manufacturer: FiiO
Mar 10 16:02:30 raspberrypi kernel: [11160.541054] input: FiiO FiiO USB DAC-E17 as /devices/platform/bcm2708_usb/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:1852:50D0.0012/input/input17
Mar 10 16:02:30 raspberrypi kernel: [11160.541696] hid-generic 0003:1852:50D0.0012: input,hidraw0: USB HID v1.00 Device [FiiO FiiO USB DAC-E17] on usb-bcm2708_usb-1.5.1/input0
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] log.c: Invalid UTF-8 string following below:
Mar 10 16:02:30 raspberrypi pulseaudio[2656]: [pulseaudio] #004: ▒▒il#006
Mar 10 16:02:35 raspberrypi rsyslogd-2177: imuxsock lost 7948 messages from pid 18986 due to rate-limiting
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread error reading '/Music/B.B. King/Reflections (Sacd_flac)/04-I'll String Along With You.flac' at offset 20316160: 4096 <> -1: Input/output error
Mar 10 16:02:35 raspberrypi ntfs-3g[18986]: ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Well, read errors off of a USB drive.
Still you'd think that MC'd quit trying eventually.
-
Well, read errors off of a USB drive.
Still you'd think that MC'd quit trying eventually.
I think I've found the cause of this and it may indeed be a USB bus issue, not a power issue. As I mentioned this occurred on a powered USB hub and I wasn't getting power warnings from the Pi at the time.
I have been running TOP & vmstat and watching CPU/RAM/HDD and interrupt workload and the CPU, RAM and HDD have not hit any bottlenecks, it appears to be a USB bus problem, which I now find after more research, is well known about.
The USB bus in the Pi is a bit funny when you push the USB bandwidth on it because of the high polling interrupts it uses. There's several threads over in the Pi forum about this.
"The Foundation has discovered that the (USB) controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, lost data, etc.."
As anything plugged in uses the USB bus including the onboard Ethernet port you can get into a bit of a problem with real-time audio applications with USB DACs struggling when your using high bitrate content from a USB HDD. This combined with wifi/Ethernet and other USB peripherals plugged in is what caused the crash. Essentially the USB bus crashed because it got flooded. There were thousands of those entries in my log, I just snipped a section of it.
If my understanding is correct, they tried to slow down the USB bus interrupts with some optional cmd switches but it appears that with a high workload on the bus that it may "miss" interrupt requests.
I've been playing with the optional switches to try stop the buffering and will report back what I find.
These are the /boot/cmdline.txt entries Im going to play with. (if you do, backup your SDcard first!)
dwc_otg.speed=0 -> 1 will limit USB speed to full speed 12Mbps (USB 1.1)
dwc_otg.lpm_enable=0 -> 0 by default, it disalbes LPM support - DONT CHANGE THIS
dwc_otg.fiq_fix_enable=1 -> 1 (default now) give about 10% extra performance to ARM Pi B when USB is not busy by lowering the number of interrupts USB does
dwc_otg.microframe_schedule=1 -> 1 (default now) This should fix the error when too many periodic endpoints are present
dwc_otg.nak_holdoff_enable=1 -> 1 (default now) NAK holdoff scheme, This slows down network traffic and smooths the packet delivery so memory doesn't get flooded.
So far turning this off > dwc_otg.fiq_fix_enable -> 0 has reduced buffering pauses on 192k/24bit transcoding to 96/24 but not quite eliminated it.
There's also some good info in here that I may try out. I had already tried playing with process priorities and not made any progress but there's some ideas in here. http://wiki.linuxaudio.org/wiki/raspberrypi
PS. Im also going to try the latest 3.19 kernel as well.
Someones also compiled a real-time kernel im going to try too.
http://www.emlid.com/raspberry-pi-real-time-kernel/
-
I think I've found the cause of this and it may indeed be a USB bus issue, not a power issue. As I mentioned this occurred on a powered USB hub and I wasn't getting power warnings from the Pi at the time.
I have been running TOP & vmstat and watching CPU/RAM/HDD and interrupt workload and the CPU, RAM and HDD have not hit any bottlenecks, it appears to be a USB bus problem, which I now find after more research, is well known about.
The USB bus in the Pi is a bit funny when you push the USB bandwidth on it because of the high polling interrupts it uses. There's several threads over in the Pi forum about this.
"The Foundation has discovered that the (USB) controller and its driver expect realtime response from the ARM core, and if Linux’s non-realtime scheduling doesn’t respond in 1 ms, a split transaction USB event can be dropped. Not surprisingly, this occurs regularly and produces lost mouse clicks, stuck keyboard keys, lost data, etc.."
As anything plugged in uses the USB bus including the onboard Ethernet port you can get into a bit of a problem with real-time audio applications with USB DACs struggling when your using high bitrate content from a USB HDD. This combined with wifi/Ethernet and other USB peripherals plugged in is what caused the crash. Essentially the USB bus crashed because it got flooded. There were thousands of those entries in my log, I just snipped a section of it.
If my understanding is correct, they tried to slow down the USB bus interrupts with some optional cmd switches but it appears that with a high workload on the bus that it may "miss" interrupt requests.
I've been playing with the optional switches to try stop the buffering and will report back what I find.
These are the /boot/cmdline.txt entries Im going to play with. (if you do, backup your SDcard first!)
dwc_otg.speed -> 1 will limit USB speed to full speed 12Mbps (USB 1.1)
•dwc_otg.lpm_enable -> 0 by default, it disalbes LPM support - DONT CHANGE THIS
dwc_otg.fiq_fix_enable -> 1 (default now) give about 10% extra performance to ARM Pi B when USB is not busy by lowering the number of interrupts USB does
•dwc_otg.microframe_schedule -> 1 (default now) This should fix the error when too many periodic endpoints are present
•dwc_otg.nak_holdoff_enable -> 1 (default now) NAK holdoff schame, don't really know what it does
So far turning this off > dwc_otg.fiq_fix_enable -> 0 has reduced buffering pauses on 192k/24bit transcoding to 96/24 but not quite eliminated it.
There's also some good info in here that I may try out. I had already tried playing with process priorities and not made any progress but there's some ideas in here. http://wiki.linuxaudio.org/wiki/raspberrypi
PS. Im also going to try the latest 3.19 kernel as well.
I haven't been able to reproduce your crash with an external HDD/DAC or with high-bitrate material so far, how many USB peripherals do you have connected? I want to see if I can replicate.
The other potential difference is that I'm mostly working with an Arch ARM system. I'll try and fool around more with my Raspbian image at home and see if I can repro there (if so, then you might be able to side-step the whole issue).
What kernel are you currently running? 3.18.9 or something older?
-
I haven't been able to reproduce your crash with an external HDD/DAC or with high-bitrate material so far, how many USB peripherals do you have connected? I want to see if I can replicate.
The other potential difference is that I'm mostly working with an Arch ARM system. I'll try and fool around more with my Raspbian image at home and see if I can repro there (if so, then you might be able to side-step the whole issue).
What kernel are you currently running? 3.18.9 or something older?
3.18.7-v7+
Yes Arch might side step the issue.
-
Ok, I'm on 3.18.9-1 FWIW. I just checked my logs and dmesg on the Arch system, and saw no i/o or ntfs errors (I'm also using an NTFS formatted drive).
NTFS may be part of the picture too. Linux's NTFS implementation has improved pretty dramatically over the past few years, so it may be that the older NTFS implementation in wheezy (from 2012) may be partly to blame.
I'll see if I can get mine to wig out on Raspbian.
-
Ok, I'm on 3.18.9-1 FWIW. I just checked my logs and dmesg on the Arch system, and saw no i/o or ntfs errors (I'm also using an NTFS formatted drive).
NTFS may be part of the picture too. Linux's NTFS implementation has improved pretty dramatically over the past few years, so it may be that the older NTFS implementation in wheezy (from 2012) may be partly to blame.
I'll see if I can get mine to wig out on Raspbian.
Im updating to 3.18.9 now and see if its any better before I do anything else.
-
Im updating to 3.18.9 now and see if its any better before I do anything else.
On
Linux raspberrypi 3.18.9-v7+ #767 SMP PREEMPT Sat Mar 7 21:52:35 GMT 2015 armv7l GNU/Linux
[ 145.084381] Transfer to device 6 endpoint 0x1 frame 1029 failed - FIQ reported NYET. Data may have been lost.
[ 428.986297] Transfer to device 6 endpoint 0x1 frame 221 failed - FIQ reported NYET. Data may have been lost.
[ 497.515425] Transfer to device 11 endpoint 0x1 frame 1157 failed - FIQ reported NYET. Data may have been lost.
Get these when it buffers now but I haven't changed cmdline.txt back to defaults yet.
PS. Just HDD, Key/mouse, wifi, DAC with Key/mouse on powered Hub.
-
Have you tried looking at iotop and iftop (or similar utilities) to see if the errors correspond to particularly high disk or net traffic periods or if there's some other driver?
It would be good to know exactly how much bandwidth causes the issue.
-
Have you tried looking at iotop and iftop (or similar utilities) to see if the errors correspond to particularly high disk or net traffic periods or if there's some other driver?
It would be good to know exactly how much bandwidth causes the issue.
Just trying something I should have tried earlier... a different USB HDD to see if its the Toshiba Canvio slim II that's the problem. Its new so I wouldn't expect it to have problems but here goes!
-
Just trying something I should have tried earlier... a different USB HDD to see if its the Toshiba Canvio slim II that's the problem. Its new so I wouldn't expect it to have problems but here goes!
Doh. The Toshiba is at fault. An old Seagate 500Mb doesn't buffer at all even at the beginning of tracks with 192/24. edit: or even skipping tracks, no gaps or buffering just straight to the next track.
Must be something to do with Toshiba firmware. Burst buffer must be better on the Seagate too or something, because in hdparm tests they both get identical direct disk read performance.
-
Seagate supports DMA6 Tosh only DMA5.
pi@raspberrypi ~ $ sudo hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: ST9500325AS
Serial Number: 5VE928EE
Firmware Revision: 0002BSM1
Transport: Serial
Standards:
Used: unknown (minor revision code 0x0029)
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 976773168
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 476940 MBytes
device size with M = 1000*1000: 500107 MBytes (500 GB)
cache/buffer size = 8192 KBytes
Nominal Media Rotation Rate: 5400
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* 64-bit World wide name
* IDLE_IMMEDIATE with UNLOAD
Write-Read-Verify feature set
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Long Sector Access (AC1)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
unknown 206[12] (vendor specific)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
136min for SECURITY ERASE UNIT. 136min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c50021719efb
NAA : 5
IEEE OUI : 000c50
Unique ID : 021719efb
Checksum: correct
pi@raspberrypi ~ $ sudo hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: TOSHIBA MQ01UBD100
Serial Number: Z48DTM19T
Firmware Revision: AX101U
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 1953525168
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 953869 MBytes
device size with M = 1000*1000: 1000204 MBytes (1000 GB)
cache/buffer size = 8192 KBytes
Form Factor: 2.5 inch
Nominal Media Rotation Rate: 5400
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 128
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* 64-bit World wide name
* IDLE_IMMEDIATE with UNLOAD
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Native Command Queueing (NCQ)
* Host-initiated interface power management
* Phy event counters
* Idle-Unload when NCQ is active
DMA Setup Auto-Activate optimization
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT LBA Segment Access (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
244min for SECURITY ERASE UNIT. 244min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 0000000000000000
NAA : 0
IEEE OUI : 000000
Unique ID : 000000000
Checksum: correct
-
Is one of the drives USB 3.0 compatible and the other one only USB 2.0? If so, the difference may still be power. The USB 3.0 drive draws a little more power.
-
Is one of the drives USB 3.0 compatible and the other one only USB 2.0? If so, the difference may still be power. The USB 3.0 drive draws a little more power.
They are both USB 3 but the Seagate is only Sata I 1.5G sig spec where as the Tosh is Sata I 1.5 and sata II 3G sig spec, so it's probably got to do with the Toshiba implementation of their Sata II to USB bridge.
-
My USB HDD (which works correctly) is a USB3, Western Digital SATA II. So it looks like something specific to the Toshi implementation.
-
Hello JRiver MC Team,
I use a Synology DS214se (NAS) with the CPU Marvell Armada 370 based on armv7 architecture.
Did you plan to compile the JRiver Media Center demo 20.0.81 as a synology SPK package for the models with armv7 CPU ?
Thanks in advance for your reply.
-
Not any time soon.
-
Thanks for your reply.
-
Hello great MC Team,
I just want to let you know that I'm using MC20 for ARM (Raspian on RPI2) right from the start and I am really enjoying it. I hope you will decide to continue support for ARM/RPI(2) Perhaps even an RPI2 optimised version?
Many thanks,
Hugo
-
I'm getting a strange behavior with gapless playback.
It looks like the new track playback is started before the old track finishes so you have a few seconds overlapping between the two tracks. It is like fading is applied to the transition.
I'm not 100% sure, but it looks specific to the ARM version as I've not been able to recreate the same issue with the x86 Linux version. I'm not 100% sure because the ARM version is 20.0.81 while the x86 version is 20.0.84, so it may be specific to the 20.0.81 version, as well.
I've tried several settings, but nothing changed.
I'm using a Cubox-4i Pro with Wheezy (armhl) and kernel 3.14.14. I usually run MC as a renderer with the /mediaserver switch and the dummy xorg driver, but I also tried to run it interactively on a vncserver (tightvnc).
Did anybody experience the same issue?
Thank you
-
I'm getting a strange behavior with gapless playback.
It looks like the new track playback is started before the old track finishes so you have a few seconds overlapping between the two tracks. It is like fading is applied to the transition.
I'm not 100% sure, but it looks specific to the ARM version as I've not been able to recreate the same issue with the x86 Linux version. I'm not 100% sure because the ARM version is 20.0.81 while the x86 version is 20.0.84, so it may be specific to the 20.0.81 version, as well.
I've tried several settings, but nothing changed.
I'm using a Cubox-4i Pro with Wheezy (armhl) and kernel 3.14.14. I usually run MC as a renderer with the /mediaserver switch and the dummy xorg driver, but I also tried to run it interactively on a vncserver (tightvnc).
Did anybody experience the same issue?
Thank you
Maybe not enough horsepower for the transition.
Try turning it off.
Options->Audio->Track Change.
Make it gapless and turn off the "do not play silence" option.
-
Would someone please try this on the RPi 1?
I'm getting some illegal instructions on mine and I'm thinking it may be my Pi.
Thanks.
-
Would someone please try this on the RPi 1?
I'm getting some illegal instructions on mine and I'm thinking it may be my Pi.
Thanks.
I just tried it on a Pi 1 B+ and after a few clicks got Illegal Instruction (core dumped)
So it's not just your Pi, unfortunately.
-
Would someone please try this on the RPi 1?
I'm getting some illegal instructions on mine and I'm thinking it may be my Pi.
Thanks.
20.0.91 running fine on Pi2B so far for 20mins. Have logging turned on, if I get a crash I'll provide the log.
I'll restart with the new /mediaserver switch.
-
I should add I've also had no problems on my Pi 2's
-
No problems for the last half hour in /mediaserver mode running mixed mp3/FLAC and loading different playlists or searches from JRemote on the Pi2B.
-
I don't have any trouble on the RPi 2 either.
I don't know how any illegal instructions could have entered the equation.
Unfortunately I can't get eclipse to work properly on the RPi 1, probably not enough memory and command line gdb shows the crash in a system lib :-(
-
Still got the same troubles : stutters at the end of a song;
http://yabb.jriver.com/interact/index.php?topic=96616.0
Does anyone of you use a USB2 (uac2) dac?
-
Still got the same troubles : stutters at the end of a song;
http://yabb.jriver.com/interact/index.php?topic=96616.0
Does anyone of you use a USB2 (uac2) dac?
I use a Dragonfly without issue.
-
I've had no problems with a Fiio e7 and a Fiio e17, and an ODAC. Once configured, everything works great.
-
Ok, thanx for the feedback!
I’ll gues this dac is just a bit too exotic; although the driver should be in the kernel
(https://github.com/lintweaker/xmos-native-dsd)
The alsa version could be a problem (Raspbian is still 1.0.25) but Arch arm is at 1.0.29 and that doesn’t help...
Just to be sure, does one of your dacs really use the asynchronous UAC 2 protocol with 125us data packet interval? (quick reed learned that the Dragonfly, E7 and ODAC seem to be audio class 1 devices)
i’m trying to get to the bottom of this: MC-arm and PI2 is the only combination which doesn’t run well with this USB implementation
-
You do know that MC doesn't support direct DSD on Linux, correct?
-
You do know that MC doesn't support direct DSD on Linux, correct?
yes i know JRiver linux does it over PCM but i’m not aiming at DSD playback just FLac;
it would be nice to get it asynchronous out of the USB with every extra bit bitdepth available (32 bit), hence the choice of a UAC 2 device.
-
Hi Guys,
Wonder if anyone has successfully had it is running under Arch-Linux?
I tried but MediaCenter kept on crashing whenever load up. :(
Many thanks,
Chanh
-
Hi Guys,
Wonder if anyone has successfully had it is running under Arch-Linux?
I tried but MediaCenter kept on crashing whenever load up. :(
Many thanks,
Chanh
There are some additional dependencies that have to be installed with Arch but I haven't tried so I cant help you.
If mwillems doesn't respond to the thread drop him a PM as he has it running on Arch and he know what's needed.
Cheers
Hilton
-
There are some additional dependencies that have to be installed with Arch but I haven't tried so I cant help you.
If mwillems doesn't respond to the thread drop him a PM as he has it running on Arch and he know what's needed.
Cheers
Hilton
Many thanks Hilton!
Will wait for mwillems's kind technical assistance.
Regards,
Chanh
-
Many thanks Hilton!
Will wait for mwillems's kind technical assistance.
Regards,
Chanh
Chan, you mention running on Arch Linux; I assume you mean Arch ARM, which is a separate distribution?
Usually a crash is due to unsatisfied dependencies (or having no xserver running). Can you talk about your configuration a little more?
What are you using for a desktop environment/xserver? How did you install MC? What did you use for a PKGBUILD?
Check out this post for a sample PKGBUILD that includes all dependencies: http://yabb.jriver.com/interact/index.php?topic=95459.msg659236#msg659236
You'll need to change the version number and the shasums obviously, but otherwise it should work.
-
I am happy to report that I have MC running quite well on the Raspberry pi2 with the new Cirrus Logic Hi-Def audio card. My compliments. Nice work on this, I certainly hope that a decision is made to continue on this platform. It would be shame not, since it works so well, and it sounds really good with the CL card. It plays all formats fine, including 192x24.
In order to support the cirrus logic audio card it was necessary to download special iso; I then installed JRiver on it, being careful not to let the kernel get updated or replaced. Cirrus Logic states on their website that it will soon be part of the the standard Raspbian distro.
-
Chan, you mention running on Arch Linux; I assume you mean Arch ARM, which is a separate distribution?
......
Hi mwillems,
Apologies for the late reply and thank you for your response!
Yes, I meant to say Arch-Arm. I have previously been more success with the Pi-2 with Arch-Arm. However, Banana Pi remains a challenge.
Here's the ldd output from bananapi for JR
[bananapi@lemaker ~]$ ldd `which mediacenter20' libcryptlib.so => /usr/lib/jriver/Media Center 20/libcryptlib.so (0xb6c93000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6c6b000) librt.so.1 => /usr/lib/librt.so.1 (0xb6c54000) libdl.so.2 => /usr/lib/libdl.so.2 (0xb6c3f000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6b22000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0xb6b15000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6a47000) libm.so.6 => /usr/lib/libm.so.6 (0xb69c9000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb69a3000) libc.so.6 => /usr/lib/libc.so.6 (0xb6864000) /lib/ld-linux-armhf.so.3 (0xb6f8e000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6844000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb683a000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6825000)
And here's the output of the same file in raspberry PI 2...
/usr/local/lib/libasound.so (0x76e6a000) libcryptlib.so => /usr/lib/jriver/Media Center 20/libcryptlib.so (0x76b6f000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76b40000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76b31000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76b26000) libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0x76a12000) libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x76a04000) libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76932000) libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x768c1000) libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76899000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76769000) /lib/ld-linux-armhf.so.3 (0x76f8b000) libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0x76749000) libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0x7673f000) libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0x76733000)
The BananaPi build is missing libasound somehow? I unsure why... the library is there, but it's just not showing up...
I may be wait for the ArmV7 build in the future? :)
Many thanks again, Gents!
Chanh
-
It sounds like you've identified your problem (a missing library), but it's a little confusing how that happened. I've configured Arch ARM on three different RPi2's with no issues whatsoever.
If you still would like some assistance, could you answer some of my other questions above? Specifically, could you please post the PKGBUILD you used to install MC on the RPi2, and some details about what you're using for an xserver?
-
So, pardon my utter n00bness here (I probably did something wrong), but my experience has been thus trying to use Media Center 20.0.99 on a Raspberri Pi 2 running Raspbian:
1. I downloaded http://files.jriver.com/mediacenter/channels/v20/latest/MediaCenter-20.0.99-armhf.deb
2. I installed it with
sudo dpkg -i MediaCenter-20.0.99-armhf.deb3. I run mediacenter20 (either with X running or just in the terminal itself) and after a few seconds I get the error:
segmentation fault
Am I doing it wrong? 8)
-
So, pardon my utter n00bness here (I probably did something wrong), but my experience has been thus trying to use Media Center 20.0.99 on a Raspberri Pi 2 running Raspbian:
1. I downloaded http://files.jriver.com/mediacenter/channels/v20/latest/MediaCenter-20.0.99-armhf.deb
2. I installed it with
sudo dpkg -i MediaCenter-20.0.99-armhf.deb3. I run mediacenter20 (either with X running or just in the terminal itself) and after a few seconds I get the error:
segmentation fault
Am I doing it wrong? 8)
You are probably missing some dependencies.
try
sudo apt-get -f install
Also make sure you are running in X, if you can't run
xterm
you won't be able to run mediacenter20
-
You are probably missing some dependencies.
try
sudo apt-get -f install
Also make sure you are running in X, if you can't run
xterm
you won't be able to run mediacenter20
Thanks. apt-get reported:
0 upgraded, 0 newly installed, 0 to remove and 16 not upgraded.
Running from within X still yields the same segfault. :(
[Update: I'm running updates now... will try afterward and see if having a fully-updated system works better ;-)]
-
Make sure that you follow the advice here:
Quick start guide for installing JRiver Mediacenter ARM for Raspberry Pi 1 and 2 (http://yabb.jriver.com/interact/index.php?topic=95578.0)
It's not stickied, so I overlooked this too and followed in your footsteps.
Once I used mwillems' guide, it all came good. Give it a go. I'm reckon you might get some joy.. ;)
-
Make sure that you follow the advice here:
Quick start guide for installing JRiver Mediacenter ARM for Raspberry Pi 1 and 2 (http://yabb.jriver.com/interact/index.php?topic=95578.0)
It's not stickied, so I overlooked this too and followed in your footsteps.
Once I used mwillems' guide, it all came good. Give it a go. I'm reckon you might get some joy.. ;)
Yeah, I forgot about 24/32 bit video mode. MC will not run in a 16 bit video mode environment.
-
Make sure that you follow the advice here:
Quick start guide for installing JRiver Mediacenter ARM for Raspberry Pi 1 and 2 (http://yabb.jriver.com/interact/index.php?topic=95578.0)
It's not stickied, so I overlooked this too and followed in your footsteps.
Once I used mwillems' guide, it all came good. Give it a go. I'm reckon you might get some joy.. ;)
Thanks! That definitely helped... althought now I get a message that tells me that the version of media center I'm running has timed out and i should go get a new one.
Once that gets dismissed, media center seems to work (at least the window comes up )
-
Glad my guide is helping folks! I initially started it for selfish reasons: there were enough dependencies and just enough configuration twists and turns that I knew I'd forget them myself if I didn't write them down, and then I'd be doing a reinstall in a few months and would forget something important. Once I had it all written down, it was easy enough to work it up into a guide.
Sure enough, I was doing a reinstall a few days ago, and had to pull up the guide because I'd forgotten something (the USB current flag so external drives will work) ;D
-
Thanks! That definitely helped... althought now I get a message that tells me that the version of media center I'm running has timed out and i should go get a new one.
Once that gets dismissed, media center seems to work (at least the window comes up )
Yep, that's exactly what it did for me too. I thought, ignore it, unless it's a real barrier. Seems that's the right plan.
-
Glad my guide is helping folks! I initially started it for selfish reasons: there were enough dependencies and just enough configuration twists and turns that I knew I'd forget them myself if I didn't write them down, and then I'd be doing a reinstall in a few months and would forget something important. Once I had it all written down, it was easy enough to work it up into a guide.
Sure enough, I was doing a reinstall a few days ago, and had to pull up the guide because I'd forgotten something (the USB current flag so external drives will work) ;D
Done this sort of thing myself, so I know what it's like to live the dream. Thanks for your good work.
-
This release fixes the trouble playing ALAC files.
-
Attempted installing on Rev C BeagleBone Black....no install errors, the prog loads, however the windows are all blank. Controls seem to work just can't see them! Thought I would let you know what I found. Will keep an eye on this thread in case you do get around to working on the BBB...Pi2 will be the next attempt...
-
Attempted installing on Rev C BeagleBone Black....no install errors, the prog loads, however the windows are all blank. Controls seem to work just can't see them! Thought I would let you know what I found. Will keep an eye on this thread in case you do get around to working on the BBB...Pi2 will be the next attempt...
That's what happens when the color space on the device is set to 24-bit color depth. MC requires 32-bit color depth, which is unfortunate because many of these ARM boards don't support 32-bit color. I had the same issue on 2 different ODROID boards, and I can reproduce the problem on an RPi by setting the wrong color depth.
If it's any consolation, if you vnc into the box remotely, MC should display correctly (or at least that's what I did with my odroids).
-
Thanks Bob. Bluetooth media remote works now! :)
-
I've just installed MC without any problems on my Cubietruck (Igor Image). But why doesn't play MC 44/16? HiRes-flacs e.g. 192/24 or 176/24 are playing. TIA
Edit: Probably an Alsa problem. The iFi-Dac shows for all sample/bitrates 44...
Edit 2: But Logitech Media Server plays all formats native. Hm...
Edit 3: solved with another sounddevice (aplay -L)
-
I'm playing around al little bit with this nice piece of Software. ;)
Is there a change for future releases consuming less CPU-Power?
E.g. Squeezelite uses much less. And that is not only a question of the GUI.
1. MC20
(http://www.imagenetz.de/thce3c8ad1/BildschirmfotoJR.png) (http://www.imagenetz.de/fce3c8ad1/BildschirmfotoJR.png.html)
2. Squeezelite/LMS
(http://www.imagenetz.de/th8a01da84/BildschirmfotoLMS.png) (http://www.imagenetz.de/f8a01da84/BildschirmfotoLMS.png.html)
3. MC 20 idle
(http://www.imagenetz.de/th35c2cb45/BildschirmfotoJRidle.png) (http://www.imagenetz.de/f35c2cb45/BildschirmfotoJRidle.png.html)
-
This would be best discussed in a new thread, but it's likely that MC is processing the files (audio analysis, cover art, thumbnails, etc.) and CPU usage will eventually drop.
-
I'm playing around al little bit with this nice piece of Software. ;)
Is there a change for future releases consuming less CPU-Power?
E.g. Squeezelite uses much less. And that is not only a question of the GUI.
1. MC20
(http://www.imagenetz.de/thce3c8ad1/BildschirmfotoJR.png) (http://www.imagenetz.de/fce3c8ad1/BildschirmfotoJR.png.html)
2. Squeezelite/LMS
(http://www.imagenetz.de/th8a01da84/BildschirmfotoLMS.png) (http://www.imagenetz.de/f8a01da84/BildschirmfotoLMS.png.html)
3. MC 20 idle
(http://www.imagenetz.de/th35c2cb45/BildschirmfotoJRidle.png) (http://www.imagenetz.de/f35c2cb45/BildschirmfotoJRidle.png.html)
Jim's right a new thread might be best, but a few quick notes:
I'm not sure how familiar you are with Linux load figures, but that top read out doesn't mean you're at 50% total CPU usage during playback: it means you're using 50% of one core. The cubietruck is a dual core system and if you look at the third line from the upper left (CPU%) that's the actual total CPU usage (about 25% total utilization, which is about double the 12% utilization with squeezelite)
That said, I think those cpu figures may be a bit high, Jim's right, JRiver may still be analyzing audio files or performing other tasks in the background. Check under "Services and Plugins" --> "Reporter" in the tree to see what might be running.
For context: Have a look at my measurements for an RPi 1 and RPi 2 over here: http://yabb.jriver.com/interact/index.php?topic=97100.0
The Rpi 2 is a useful comparison point as it's an A7 cortex processor (like the cubietruck), clocked at 900MHz (similar to the 1 GHz clock of the cubietruck). The RPi2 is quad core instead of dual core, but core for core it should work about like the cubietruck.
You can see that on the RPi2 playback of 16 bit/44KHz flac files peaked at about 20% of one core, so you're seeing CPU usage about 2.5 times what I'm seeing. So unless you're playing much higher resolution material, MC is probably running something in the background. Higher res material will use more CPU, necessarily.
-
Jim's right a new thread might be best
Yes, perhaps a moderator should split this thread?
You can see that on the RPi2 playback of 16 bit/44KHz flac files peaked at about 20% of one core, so you're seeing CPU usage about 2.5 times what I'm seeing. So unless you're playing much higher resolution material, MC is probably running something in the background. Higher res material will use more CPU, necessarily.
Yes - your values for 44/16 I've too on the CT. My examples are generated with HiRes 192/24 flac. Much more impressive. ;)
-
I was having USB DAC reliability problems with 3.18.9-v7+ and upgrading to 3.18.12-v7+ along with upgrading my packages and its now stable again.
-
I've just installed MC without any problems on my Cubietruck (Igor Image). But why doesn't play MC 44/16? HiRes-flacs e.g. 192/24 or 176/24 are playing. TIA
Edit: Probably an Alsa problem. The iFi-Dac shows for all sample/bitrates 44...
Edit 2: But Logitech Media Server plays all formats native. Hm...
Edit 3: solved with another sounddevice (aplay -L)
It's important to remember that MC does NOT use ALSA's automatic resampling engine like most everything else does.
We use our own DSP studio instead.
-
I'm new to the forum so I apologise if this is in the wrong place!
Is there any update on the June timeout? Will there be a consumer release? I would happily pay an additional license fee for the Debian ARM version (I already have a windows license for my PC and a Linux license for my Intel NUC).
I have upgraded to 20.0.101 running on a Raspberry Pi 2 and feeding an Arcam USB irDAC. No problems so far
I also have 20.0.93 running well on another Raspberry Pi 2 and feeding via HDMI to a Yamaha RX A3010 amplifier. I'm about to upgrade this too.
Both Raspberry Pi's are using flac files from a Synology NAS (DS213) mounted via cifs. They are also both running headless using vncserver.
I'm new to Linux but with the help of this forum have been able to set up Linux versions. Thanks everyone!
Maybe I have been lucky but I have had no problems at all with the Debian ARM versions.
-
I second the question expiry date for the beta: I'd like to try it and use it on an ARM based device, but if this version does not get proper release or extended time for testing , I won't bother and use another program :(
I already have a PC license, since 5 years ago:)
-
I just compiled ARM 20.0.66 for Arch ARM and this warning came up. Is it anything to worry about?
[pi@raspberrypi jriver-media-center]$ makepkg -s
==> Making package: jriver-media-center 20.0.66-1 (Thu May 14 22:46:30 AEST 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found MediaCenter-20.0.66-armhf.deb
-> Found License.txt
==> Validating source files with sha256sums...
MediaCenter-20.0.66-armhf.deb ... Passed
License.txt ... Passed
==> Extracting sources...
-> Extracting MediaCenter-20.0.66-armhf.deb with bsdtar
==> Removing existing $pkgdir/ directory...
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
-> Purging unwanted files...
-> Removing libtool files...
-> Removing static library files...
-> Compressing man and info pages...
-> Stripping unneeded symbols from binaries and libraries...
strip: Unable to recognise the format of the input file `./usr/lib/jriver/Media Center 20/alsacap'
==> Creating package "jriver-media-center"...
-> Generating .PKGINFO file...
-> Generating .MTREE file...
-> Compressing package...==> Leaving fakeroot environment.
==> Finished making: jriver-media-center 20.0.66-1 (Thu May 14 22:52:00 AEST 2015)
I also tried to make the latest 101 but I don't know how to updated the sha256 to match.
PS. Im up and running on Arch with 20.0.66 and it all seems to be working. Wow Arch is a lot of trouble to setup but its much faster to boot.
-
Do you mean the "strip" line? That happens everytime, it's because ALSACAP isn't compatible, it's nothing to worry about.
To update the SHA just use the method found here: https://wiki.archlinux.org/index.php/PKGBUILD#Integrity
Or if you trust that you got a good download, you can always run makepkg with the flag "--skip-integ"" which will disregard the SHA sums.
PS. Im up and running on Arch with 20.0.66 and it all seems to be working. Wow Arch is a lot of trouble to setup but its much faster to boot.
Lower overhead while running too because all the cruft is gone!
-
The next build which will be released today will no longer have a timeout and will require a license (linux or master license).
-
The next build which will be released today will no longer have a timeout and will require a license (linux or master license).
Excitement!!
-
The next build which will be released today will no longer have a timeout and will require a license (linux or master license).
Great!
-
The next build which will be released today will no longer have a timeout and will require a license (linux or master license).
Take my money! :)