INTERACT FORUM
More => Old Versions => JRiver Media Center 21 for Linux => Topic started by: bob on August 11, 2015, 05:07:54 pm
-
The latest build is up at:
https://files.jriver.com/mediacenter/channels/v21/latest/MediaCenter-21.0.90-armhf.deb (also in the latest apt repository)
See the linux x86 log for specific linux changes and the windows log for general MC changes.
Only changes that apply specifically to the arm build will be listed here and only issues specific to the arm build should be posted here.
21.0.90 (7/14/2016)
1. See the main linux changelog
21.0.89 (6/16/2016)
1. See the main linux changelog for build 21.0.88
2. Changed: Internal calls to external programs (browser, file manager, encoders, etc) to deal with filesystem specific character quoting. Look for regressions.
21.0.85 (5/27/2016)
See the main linux changelog
21.0.83 (5/20/2016)
1. Fixed: Linux detect cifs filesystems for timer supported auto imports
21.0.76 (4/29/2016)
See the main linux changelog
21.0.70 (4/12/2016)
See the main linux changelog
21.0.63 (3/21/2016)
See the main linux changelog.
21.0.61 (3/18/2016)
See the main linux changelog.
21.0.54 (3/4/2016)
Changes from the main branch. Should be considered for stable repo but is in latest for now.
21.0.51 (2/26/2016)
See the main changelog for linux in this forum. More work on eliminating hard killed threads. Needs testing for stability.
21.0.48 (2/15/2016)
See the main changelog for linux in this forum.
Specifically for arm users on SDCards, disk buffering of files received for rendering can be turned off in the Media Network Advanced Options.
21.0.37-2 (1/18/2016)
1. Fixed: Bug in calculating the offset from UTC.
2. Changed: MC linux will download the mp3 encoder instead of using the system mp3 encoder.
3. Fixed: Allocation of some files failed on linux when the filesystem didn't support fallocate(). Affected Thumbnails at the very least.
4. Fixed: ARM System Identification.
21.0.37 (1/15/2016)
Changes from the main branch.
21.0.28 (12/17/2015)
Fixed crashed due to bugs in the socket code. See the general linux log for more info.
21.0.23 (11/23/2015)
Fixed memory leak. See the general linux log for more info.
21.0.14 (10/13/2015)
1. Fixed: Thumbnail creation for Videos would often crash JRWorker.
2. Fixed: The TVInfo Expression did not work.
3. Fixed: Change in eventing fixes maximize button on arm, possibly other subtle changes.
-
I'm getting a broken dependency issue related to libpangoft on Raspbian wheezy? Any special handling instructions?
The following packages have unmet dependencies:
mediacenter21 : Depends: libpangoft2-1.0-0 (>= 1.36) but 1.32.5-5rpi3 is to be installed
Recommends: musepack-tools (>= 2:0.1) but it is not going to be installed
-
I'm getting a broken dependency issue related to libpangoft on Raspbian wheezy? Any special handling instructions?
The following packages have unmet dependencies:
mediacenter21 : Depends: libpangoft2-1.0-0 (>= 1.36) but 1.32.5-5rpi3 is to be installed
Recommends: musepack-tools (>= 2:0.1) but it is not going to be installed
Sigh, the raspbian version is older. 1.32 is fine. I'll regenerate the .deb.
Done.
-
Bob, what's the link to the ARM APT repository? I'll add it to the APT tutorial.
-
Bob, what's the link to the ARM APT repository? I'll add it to the APT tutorial.
I've been using "native" which (actually) should probably be a one size fits all that works for all versions, right?
sudo wget http://dist.jriver.com/latest/mediacenter/mediacenter21native.list -O /etc/apt/sources.list.d/mediacenter21.list
Sigh, the raspbian version is older. 1.32 is fine. I'll regenerate the .deb.
Done.
Looks good, just installed without issue.
-
Okay, this is the repository for the MC21 ARM builds.
http://dist.jriver.com/latest/mediacenter/mediacenter21native.list
So this should work;
sudo wget http://dist.jriver.com/latest/mediacenter/mediacenter21native.list -O /etc/apt/sources.list.d/mediacenter21.list
-
Okay, this is the repository for the MC21 ARM builds.
http://dist.jriver.com/latest/mediacenter/mediacenter21native.list
So this should work;
sudo wget http://dist.jriver.com/latest/mediacenter/mediacenter21native.list -O /etc/apt/sources.list.d/mediacenter21.list
I can confirm it works (I edited my post as you were posting).
EDIT: That same repo should also probably work for anyone running wheezy regardless of the build they're using (it just doesn't specify an arch so the OS picks the one that fits). So you might be able to reduce the number of code snippets.
-
Will 21 install from APT over the top of 20.
Should I remove the old APT dist?
Do I need to do an extra backup of libraries and then uninstall 20?
-
Will 21 install from APT over the top of 20.
No, it's a different package name.
Should I remove the old APT dist?
Yes.
Do I need to do an extra backup of libraries and then uninstall 20?
I did; 21 will not find your MC 20 settings without a library restore.
-
Thanks up and running. :)
-
I'm getting a lot of crashes with MC for ARM. This is on two separate vanilla Raspbian Wheezy installs on raspberry pi 2's. It seems to be related to thumbnail building.
1) Opening a view with a lot of unbuilt thumbnails will crash to desktop about half the time. This seems to happen both when done in the GUI or through a remote (JRemote and Webgizmo both exhibit the behavior when the view would show a lot of unbuilt thumbs). The "remote" case seems more likely to provoke the crash, though.
2) Running auto-import with build thumbnails enabled will also sometimes crash during the thumbnail building, but only after building for a little while.
After several attempts I managed to get all my thumbs built, and it doesn't crash anymore, so my money is on something goofy in the thumbnailing.
-
21.0.5 (9/1/2015)
1. Changed: Added graphical confirmation of the license installation through the file association.
-
21.0.6 (9/8/2105)
See the 21.0.6 linux log for changes.
-
What's going on here? :D
Smashing my poor little Pi at 100% CPU for 20mins and still going??
Mega disk writes and threads running?
Had it crash once before it finished doing whatever its doing and its still going second time around.
(https://farm1.staticflickr.com/738/21295422675_089d4930ba_h.jpg) (https://flic.kr/p/yrNBeV)mc21-0-6 (https://flic.kr/p/yrNBeV) by Hilton (https://www.flickr.com/photos/133784514@N07/), on Flickr
-
Is it building thumbs or analyzing audio? Importing a library doesn't bring the thumbs over usually, so I typically have to rebuild when I update major versions. Check reporter and see what MC might be doing, but my bet is on thumbs or audio analysis.
FWIW I've had lots of instability with MC 21 and my Pi's when MC was building thumbnails or doing any kind of importing activity, including quite a few crashes. It gets better once all thumbs are built, but adding new media results in thrashing and crashes.
I reported it upthread, and I've rolled back to MC20 on my more "mission critical" Pi's until this is sorted.
-
yep rebuilding thumbnails.
Because its running on an SSD the CPU is the limiting factor instead of the disk. :)
I cant do anything else with it while it's rebuilding. :(
PS. might want to put a limit on the number of threads for pi. :)
Library
Total files: 19978
Audio files: 19978
Image files: 0
Video files: 0
Other files: 0
Processing
Thumbnails built: 2% (414 of 19978)
Audio analyzed: 0% (0 of 19978)
Background Tools Running
No tools currently running
Power
No entries that affect the system power state
Media Center
Version:
Install path: /usr/lib/jriver/Media Center 21/
Interface plug-ins:
JRMark: never run
Memory used:
Handles used:
Advanced System Info
Memory & CPU
CPU features:
Operating System
Unknown OS
-
yep rebuilding thumbnails.
Because its running on an SSD the CPU is the limiting factor instead of the disk. :)
I cant do anything else with it while it's rebuilding. :(
PS. might want to put a limit on the number of threads for pi. :)
Library
Total files: 19978
Audio files: 19978
Image files: 0
Video files: 0
Other files: 0
Processing
Thumbnails built: 2% (414 of 19978)
Audio analyzed: 0% (0 of 19978)
Background Tools Running
No tools currently running
Power
No entries that affect the system power state
Media Center
Version:
Install path: /usr/lib/jriver/Media Center 21/
Interface plug-ins:
JRMark: never run
Memory used:
Handles used:
Advanced System Info
Memory & CPU
CPU features:
Operating System
Unknown OS
How about in Options->Tree and View_>Thumbnails-> setting the Thumbnail creation threading to Low?
-
How about in Options->Tree and View_>Thumbnails-> setting the Thumbnail creation threading to Low?
I tried that recently and it showed slightly improved stability in a library with no thumbs built, but it didn't completely stop the instability (I could still provoke a crash by navigating to a view with very few thumbs built, just less reliably). Additionally, from a usability perspective, MC on the Pi is significantly more responsive and usable if you pre-build all thumbs. Everything works faster and better whether using a remote or the local interface.
So my first order of business whenever I setup a new instance is to manually ask JRiver to build all thumbs (whether as part of import, or through the options menu), and come back the next day to start actually using it. I've successfully done that four or five different times with MC 20. Trying to do that (without any other interaction) is giving me eventual crashes on MC21 regardless of thread priority (usually after a few thousand thumbs built). Thumbnailing does not create any similar instability on MC 20 on the same installs with the same settings, so I think this is a regression.
-
I tried that recently and it showed slightly improved stability in a library with no thumbs built, but it didn't completely stop the instability (I could still provoke a crash by navigating to a view with very few thumbs built, just less reliably). Additionally, from a usability perspective, MC on the Pi is significantly more responsive and usable if you pre-build all thumbs. Everything works faster and better whether using a remote or the local interface.
So my first order of business whenever I setup a new instance is to manually ask JRiver to build all thumbs (whether as part of import, or through the options menu), and come back the next day to start actually using it. I've successfully done that four or five different times with MC 20. Trying to do that (without any other interaction) is giving me eventual crashes on MC21 regardless of thread priority (usually after a few thousand thumbs built). Thumbnailing does not create any similar instability on MC 20 on the same installs with the same settings, so I think this is a regression.
It sounds like an issue with the worker (JRWorker).
Maybe it's running out of memory.
None of my libraries are huge (6k is about the biggest), how big are yours?
-
It sounds like an issue with the worker (JRWorker).
Maybe it's running out of memory.
None of my libraries are huge (6k is about the biggest), how big are yours?
About 60k audio files, so that may be part of the story (when I manually build thumbs it's crashing after several thousand). Looking at my munin logs, memory stress does seem to be part of the picture (memory is near maximum before the crash). Not sure what changed between 20 and 21 to trigger it though as the same size library chugs right through on MC 20.
-
I'd say it's a memory problem. With my 20K files being analysed I can see the memory steadily climbing to 1GB just before it crashes.
I see mostly writes happening and almost no reads, does it keep the thumbs in ram?
-
Hi guys,
Just thought I'd report that setting thumbnail priority to low makes the Pi2 still usable during rebuilds but still get some occasional stutters and I had this crash just happen.
(https://farm6.staticflickr.com/5655/21220479530_65c1f919ae_b.jpg) (https://flic.kr/p/ykbvfJ)pi-crash (https://flic.kr/p/ykbvfJ) by Hilton (https://www.flickr.com/photos/133784514@N07/), on Flickr
-
1 hour 44 mins to rebuild 20k thumbs on 1TB USB SSD disk. (on low priority and no crash)
(https://farm1.staticflickr.com/684/20791921583_068e101820_b.jpg) (https://flic.kr/p/xFj2UB)pi2-mem-thumbs (https://flic.kr/p/xFj2UB) by Hilton (https://www.flickr.com/photos/133784514@N07/), on Flickr
-
I think I may know what's going on here. It's a combination of two things.
One, the fork/exec method of spawning another program we moved to copies the existing program space before forking which is why you see a bunch of mediacenter21's running at the same time.
Two, the low priority is spawning too many threads.
I might see if I can build a beta with the old shell call instead of fork/exec and see if that solves your issue.
1 hour 44 mins to rebuild 20k thumbs on 1TB USB SSD disk. (on low priority and no crash)
(https://farm1.staticflickr.com/684/20791921583_068e101820_b.jpg) (https://flic.kr/p/xFj2UB)pi2-mem-thumbs (https://flic.kr/p/xFj2UB) by Hilton (https://www.flickr.com/photos/133784514@N07/), on Flickr
-
FWIW, the fork+exec model is considered much more lightweight than a shell call through system(), for example.
-
FWIW, the fork+exec model is considered much more lightweight than a shell call through system(), for example.
It could be that the counting of active threads for the aggressiveness of the thumbnailing setting is affected by the way the worker is called.
-
Changes listed at http://yabb.jriver.com/interact/index.php?topic=100183.0
-
Hi,
I can confirm that with Fluxbox the maximize and restore window buttons work for MC21-ARM too it also ‘jumps’ to maximized after startup.
I had no problem installing MC21 (nor MC20) on a minimal (no desktop) to Jessie (packages) upgraded raspbian setup.
-
The maximize works on the default desktop in the 21.0.14 build
-
Confirmed the maximize and minimize buttons now work on default raspbian desktop.
-
The maximize works on the default desktop in the 21.0.14 build
confirmed working for plain openbox
-
Sigh, the raspbian version is older. 1.32 is fine. I'll regenerate the .deb.
Done.
Hi, finding the best suitable setup for the OrangePI, now testing Debian (Old Stable) wheezy armhf.
Wheezy has no (separate) package libpangoft2, MC21 runs fine (I think the lib is included in libpango1).
I am probably the only fool installing Debian old-stable so would not worry about it (removed the dependency manually)
-
See the top post for this build. It's not in the repo yet, some testing would be great.
-
I'm hoping we are about done with the threading changes. Would appreciate some testing before it gets into the repository.
-
I'm hoping we are about done with the threading changes. Would appreciate some testing before it gets into the repository.
Just updated one of my Pi's and put it through the paces (using remotes/MCWS, lots of starts and stops, etc.). So far so good, everything works fine. Any suggestions for specific areas of testing?
-
Just updated one of my Pi's and put it through the paces (using remotes/MCWS, lots of starts and stops, etc.). So far so good, everything works fine. Any suggestions for specific areas of testing?
The testing you've done is just what I'm looking for.
Network activity by other uPnP devices could be interesting too.
It's stability over time that we're most concerned with. There were a few places where hardkilled threads were still being done (which cause a segfault on linux) that have been eliminated.
The expected result of this is that the segfaults simply go away, an undesirable result would be a hang.
Thanks!
-
Hello,
I'm trying to update my pi as usual and get this error messgae:
W: Failed to fetch http://raspberrypi.collabora.com/dists/wheezy/rpi/binary-armhf/Packages 403 Forbidden
E: Some index files failed to download. They have been ignored, or old ones used instead.
What am I missing?
Thank you!
-
For possible addition to the stable repo. Currently in latest.
-
Fixed the cover art crashing bug and reverted a change for DLNA renderer volume getting that caused sluggish GUI performance when used with a slow renderer.
-
The 21.0.70 build has a change to the copy/paste method. Some testing would be good. We are looking to see if we broke other control key functions (we found a few that didn't work before already). Also to make sure it doesn't crash MC under an unusual situation.
-
I've been using MC on my Beaglebone for well over a year without a problem, through several OS changes and eMMC flashes. I just put the latest Debian on an SD card, booted and reinstalled JRMC21 - and when I open it, the entire window (screen, if maximized) is white. I redid everything again, but the result is still the same - a blank white patch. Any ideas would be gratefully accepted!! Thanks.
-
I've been using MC on my Beaglebone for well over a year without a problem, through several OS changes and eMMC flashes. I just put the latest Debian on an SD card, booted and reinstalled JRMC21 - and when I open it, the entire window (screen, if maximized) is white. I redid everything again, but the result is still the same - a blank white patch. Any ideas would be gratefully accepted!! Thanks.
The most likely cause is that you haven't set the framebuffer color depth to 32 bit. I don't have a beaglebone, but on the Raspberry pi, it's as easy to fix as adding twoi lines to the config.txt
framebuffer_depth=32
framebuffer_ignore_alpha=1
If there's a similar option on the beaglebone, I would start investigating there.
-
The most likely cause is that you haven't set the framebuffer color depth to 32 bit. I don't have a beaglebone, but on the Raspberry pi, it's as easy to fix as adding twoi lines to the config.txt
framebuffer_depth=32
framebuffer_ignore_alpha=1
If there's a similar option on the beaglebone, I would start investigating there.
Thanks - I'll do it when I get home from work and report back! FWIW, I haven't had to do this before through several setups of MC on various Ubuntus, Debians etc. I've also flashed and run Rune and Daphile on the 'bone at different times - but stuff happens.
-
Thanks - I'll do it when I get home from work and report back! FWIW, I haven't had to do this before through several setups of MC on various Ubuntus, Debians etc. I've also flashed and run Rune and Daphile on the 'bone at different times - but stuff happens.
I only know that the all white window is a sure fire sign that the framebuffer color depth is wrong. On some of my ODROID SoC's the issue was uncorrectable as their drivers only supported 24 bit output, which ruled them out for MC use. I'm not sure why it would work one day and not the next, but I would suspect a graphics driver/X11 update or change.
-
It's not the entire screen that's white - it's only the MC window. If I maximize it, the entire screen is white but otherwise, only the MC portion is affected. The rest of the display is black with the BB logo and taskbar normal, and all other GUIs display and work fine.
-
It's not the entire screen that's white - it's only the MC window. If I maximize it, the entire screen is white but otherwise, only the MC portion is affected. The rest of the display is black with the BB logo and taskbar normal, and all other GUIs display and work fine.
By "all white window" I meant the MC window. If MC only displays as a solid white window, that's the clear sign that the color depth is wrong. Most programs don't insist on 32 bit color depth, so will display normally when it's not present, but JRiver is not one of them.
-
By "all white window" I meant the MC window. If MC only displays as a solid white window, that's the clear sign that the color depth is wrong. Most programs don't insist on 32 bit color depth, so will display normally when it's not present, but JRiver is not one of them.
Hmmmm - I put several hours into this over the weekend, and there's no relevant config.txt file on my BBB running the latest Debian Jessie per Beagleboard.org . But I did find a relevant file with a different name in X11 defining a default bit depth of 16. I changed that to 32 and thought I'd bricked my 'bone. But I was able to get it going again with the internal boot switch and a reflash. So I went through the whole routine again of downloading and installing MC21 after reinstalling Debian, but now I'm getting "no more room on device" errors at several lines during the MC install. So it appears that so much manipulation over the life of the 'bone has left its little memory choking on useless stuff. I did have MC up and running on it last year, but like an idiot I decided to try Ubuntu. I should have quit while I was ahead.
Reflashing does not remove all previous files from the eMMC, and I cannot find any information at all on how to clear out everything in the eMMC and start fresh. As it appears that I'm not sophisticated enough to know what I can safely delete piecemeal, I'm going to leave MPD on it for now until I learn how to get the 'bone back to its original state (if that's possible). Thanks!!
-
Reflashing does not remove all previous files from the eMMC
It turns out that I was wrong about this - the old files were being cleared. The problem is that the latest Debian images for the BeagleBone Black fill almost all of the eMMC, so there's simply no room for MC there. You have to expand the file system on a uSD card that's large enough to hold everything you want to put on it and run from that. With fast cards, this is not a functional problem (although I did my best to avoid it, thinking it was a compromise).
So the bottom line is that running MC on a Beaglebone Black seems best done by booting and running entirely from the uSD card rather than flashing the eMMC with the latest OS images. I suppose I could also expand the file system on the card, boot from the eMMC and run MC from the card. But at this point, I'm tired of playing with it and just want to listen to music. Of course, I also want to try Void Linux...............
-
.
.
.
Of course, I also want to try Void Linux...............
Glutton for punishment? ;)
-
Glutton for punishment? ;)
Well........perhaps I was a bit too optimistic. If I am a glutton for punishment (and you appear to be more correct about that than I was willing to consider), my current device seems more than up to the task. Last night, I put a fresh Jessie image on a 64G card, booted the 'bone right up, expanded the file system on the card to its full size, and installed JRMC21. The MC window still opens as a white patch, although it does have the blue strip across the top now. So I went into /etc/X11/xorg.conf and changed the default depth from 16 to 24 in the "screen" section, resulting in brick city once again. A web search reveals many such posts, so it's not just me or my device. It appears that changing that value really messes something up.
Yet another fresh image on a fully reformatted card brought everything back to life with a white MC window once again. I haven't yet left it open and looked on my main MC PC or JRemote to see if the 'bone's instance is working. If it is, I'm fine running headless and will leave it alone. That's tonight's entertainment. ;)
-
Well........perhaps I was a bit too optimistic. If I am a glutton for punishment (and you appear to be more correct about that than I was willing to consider), my current device seems more than up to the task. Last night, I put a fresh Jessie image on a 64G card, booted the 'bone right up, expanded the file system on the card to its full size, and installed JRMC21. The MC window still opens as a white patch, although it does have the blue strip across the top now. So I went into /etc/X11/xorg.conf and changed the default depth from 16 to 24 in the "screen" section, resulting in brick city once again. A web search reveals many such posts, so it's not just me or my device. It appears that changing that value really messes something up.
Yet another fresh image on a fully reformatted card brought everything back to life with a white MC window once again. I haven't yet left it open and looked on my main MC PC or JRemote to see if the 'bone's instance is working. If it is, I'm fine running headless and will leave it alone. That's tonight's entertainment. ;)
There has to be somewhere other than the X11 conf file where you set the depth. The hardware has to boot with 24 bit support or the conf file won't be able to make it work.
That's the point of the parameters in the Rpi's boot.txt file.
-
As expected, it shows up as a zone in MC on my primary PC, and it's controllable both from there are from JRemote. So I'm not even going to bother trying to find the configuration file that will allow me to change the default bit depth for the display to 24. If anyone lets me know what it is and where it is, I'll go in and give it a shot - but I run the 'bone headless anyway, so this isn't a problem. In fact, it may have been happening all along - the HDMI output didn't work when I first got it, so I never put it on a display. There were apparently a lot of early problems with the video drivers that have been fixed in recent software updates.
Thanks for the input!!
David
-
From Robert Nelson on the Beaglebone Black forum and one of the most experienced authorities on the 'bone in the universe: "This is a hardware limitation of the beaglebone black in it's default state... The HDMI framer chip used is only wired to the am335x in 16bit mode" - 'nuf said! That's why it won't boot when the X11 conf file is changed to 24 from 16.
So I'll set MC on the Beaglebone Black with TightVNC and run it headless (which I did without difficulty last year). We live and learn. :D
-
Bob, is there an .88 build coming for arm? I only ask because my pi's are still back at .83 due to the library server bug in .85.
-
Bob, is there an .88 build coming for arm? I only ask because my pi's are still back at .83 due to the library server bug in .85.
Yes, it just takes longer to build and we found one more thing we want to change first. I'm thinking later today...
-
Bob, is there an .88 build coming for arm? I only ask because my pi's are still back at .83 due to the library server bug in .85.
Ready to DL.
See the comment in the top build about the calling of external programs...