More > JRiver Media Center 22 for Linux
MC22 for Linux crashing on Raspberry Pi 3
blgentry:
I've recently installed a Raspberry Pi 3 as a music server. It's running the latest build, 22.0.108 . Music is stored on a local drive plugged in via USB. I'm using an external DAC; a Soundblaster 24 Live, also connected via USB.
I've now had 3 crashes of MC over a 3 day period. This has been on 2 different Pis; I borrowed one from a friend for a few days as a proof of concept, then bought my own. Both have had crashes.
The latest one spit out some error messages in the terminal. I think only the last one is related to the crash:
--- Code: --- JRTools/JRUIMessageLoop.cpp:931:ProcessMessageLoopMessage Unhandled Event KeyRelease -- m_pEvent=0x42bbb20 m_pDisplay=0x2fe6730
type= 3 serial= 1962283 send_event=F Display=0x2fe6730 Window=0x1c00041
JRTools/JRUIMessageLoop.cpp:931:ProcessMessageLoopMessage Unhandled Event KeyRelease -- m_pEvent=0x2f85030 m_pDisplay=0x2fe6730
type= 3 serial= 2080672 send_event=F Display=0x2fe6730 Window=0x1c00041
JRTools/JRUIMessageLoop.cpp:931:ProcessMessageLoopMessage Unhandled Event KeyRelease -- m_pEvent=0x2f85030 m_pDisplay=0x2fe6730
type= 3 serial= 2080672 send_event=F Display=0x2fe6730 Window=0x1c00041
JRTools/JRUIMessageLoop.cpp:931:ProcessMessageLoopMessage Unhandled Event KeyRelease -- m_pEvent=0x3c89018 m_pDisplay=0x2fe6730
type= 3 serial= 2302257 send_event=F Display=0x2fe6730 Window=0x1c00041
*** Error in `mediacenter22': double free or corruption (fasttop): 0x6729a920 ***
[1]+ Aborted mediacenter22
--- End code ---
I sorta remember the "double free or corruption" message from a previous crash, but I wouldn't swear to it.
Any idea what I should do to troubleshoot this?
Thanks,
Brian.
mwillems:
I've never seen that error myself, but my recollection is that this is the error that glibc on the pi throws when it runs into memory pressure while playing media (or maybe from loading multiple files in a hurry).
So my first questions would be:
1) Does it seem file size dependent?
2) Is play from memory checked?
3) Does doing a bunch of fast seeks or track changes trigger it?
The pi has very limited RAM and if you're trying to play from memory or play exceptionally large media files (like .wavs or something) that may be triggering it.
For some context, here are some other folks seeing a similar (or the same) error on pi's while playing media files (not with MC), one of whom saw the issue from lots of fast refreshes:
https://blog.starbyte.co.uk/error-glibc-detected-usrbinpython-double-free-or-corruption-fasttop-on-raspberry-pi-using-python/
https://www.raspberrypi.org/forums/viewtopic.php?t=36878&p=308220
blgentry:
--- Quote from: mwillems on June 12, 2017, 06:51:26 pm ---1) Does it seem file size dependent?
--- End quote ---
Not 100% sure here. It's just randomly died while playing a few times.
--- Quote ---2) Is play from memory checked?
--- End quote ---
I just looked. Memory playback is disabled, which apparently is the default. (I wasn't sure)
--- Quote ---3) Does doing a bunch of fast seeks or track changes trigger it?
--- End quote ---
I don't think so. I don't generally do a lot of seeking; I'm using this with EOS remote controlling it and I rarely change tracks or seek.
I have to admit that I did not follow your guide "to the letter" when setting up the Pi and that bit me several times! I had NOT set the alpha (or ignore alpha?) setting in config.txt until *after* I posted this trouble report. When I went back through your guide, I decided to set all of your config.txt options exactly as you wrote them. I then rebooted and kept using the Pi.
It's only been maybe 5 hours of play time, but so far, no more crashes. We'll see what happens.
Thanks for the input. :)
Brian.
bob:
You could try
cat /proc/meminfo
and
top
to see if there is something else using more memory than you expect.
It is true that memory is tight on the pi running MC, anything you can do to free up memory helps.
The option for allocating memory to the GPU in raspi-config should be set to the lowest possible value which I believe is 16M. At least some of the ones I have seem to have defaulted to 64M.
blgentry:
Regarding memory: I'll do a few top sessions while playing and see what I see.
I've also been investigating using XPRA instead of X11VNC. XPRA, if you're not familiar, is another remote display technology. XPRA is different than VNC in several potentially beneficial ways:
1. XPRA does not use a "desktop". XPRA simply displays one or more windows on the remote display. So, when you fire up an XPRA session on the Pi, it initially has nothing. Then, when you run mediacenter22, the XRPA session has just one window: MC22 . When you connect to it with your XPRA client, you only see this one window. Less programs running should mean lower memory utilization.
2. XPRA includes half a dozen different types of video compression. With "real computers" XPRA's video performance is really good. I don't mean watching moving video. I mean moving windows or resizing them, or things like that. With VNC these operations result in ugly repainting of the window, which is slow and mildly in the way of getting things done. XPRA generally out performs VNC in this regard.
3. XPRA doesn't require a real display to be mirrored like X11VNC does. This reduces complexity in my mind.
The bad new is, I can't get XPRA to install under Raspian. It get a dependency error, which I've been unable to resolve so far. I've considered building it from source, but I haven't yet decided to invest that amount of time and effort.
In case anyone is interested:
https://xpra.org/
XPRA has clients for Windows, Mac, and Linux.
Brian.
Navigation
[0] Message Index
[#] Next page
Go to full version