Print

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

[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: [Select]

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

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]

1) Does it seem file size dependent?

Not 100% sure here.  It's just randomly died while playing a few times.

2) Is play from memory checked?

I just looked.  Memory playback is disabled, which apparently is the default.  (I wasn't sure)

3) Does doing a bunch of fast seeks or track changes trigger it?

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.

[bob]

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.

That sounds very interesting.
Without a window manager, MC will require a couple of changes (like to DSP studio where you can only exit by using the WM's close box).

[blgentry]

I've only been able to test MC22 in XPRA in loopback mode:  Running XPRA server and client on the same Linux box.  The one I'm typing on right now actually. 

In loopback mode with XPRA, MC acts a little funny.  For the first 20 to 60 seconds it does weird stuff on the display.  But then it settles down and is usable.  As a test I popped up the DSP Studio window.  XPRA wrapped it with the normal window manager controls, so I was able to easily close it.

I'll have to do some more testing if I can get access to a second machine on this network.

Brian.

[blgentry]

Well, the good news is that MC hasn't crashed since I changed the config.txt to include the couple of settings from the setup guide.  I think it was these two that did it:

Code: [Select]

framebuffer_depth=32
framebuffer_ignore_alpha=1

I'll keep monitoring it.  Seems good for now. 

Brian.

[blgentry]

I just had it crash twice more.  I'm not sure what's going on.  But it definitely happened both times today while I was using EOS remote to add albums to Playing Now.

Same error message as before.

Brian.

[mwillems]

I just had it crash twice more.  I'm not sure what's going on.  But it definitely happened both times today while I was using EOS remote to add albums to Playing Now.

Same error message as before.

Brian.

Does it happen with any other remotes or just eos?  I don't use eos anymore, but I can try and see if I can repro it with eos.

[blgentry]

I pretty much only use EOS. So EOS is the "cause".

Brian.

[bob]

Doesn't seem to be a generic linux thing, I can't get it to happen with EOS and my MC22 linux install.

[bob]

How about Thumbnailing?
I tried EOS with a Mac and it had an interesting hesitation while playing back when I scrolled the EOS album cover view screen up and down.
You could look in Options to see what the thumbnailing priority is set to and make it the lowest setting.

Others have dealt with running out of memory while thumbnailing by pre-generating all of the thumbnails in MC while it's not being used for playback.

[blgentry]

I was about to tell you that all my thumbnails were already built.  So I went to check.  Only 10% are built!  I set thumbnail generation to low priority and have clicked the button to generate all thumbnails it's running now.

I'm using the technique of copying my MC library from my normal MC computer, over to the Pi, on an external hard drive.  I'm also shipping over a library backup file with it, then restoring that library backup into MC on the Pi.  Each time I do this, I guess I need to rebuild all thumbnails.

It's probably NOT a coincidence that I just refreshed the library on the Pi using the above method:  I copied the new media onto the external drive with a backup file, then restored that backup into MC.  I apparently did not rebuild thumbnails when I was doing restoring the MC backup.  This might explain it.

It might also explain why EOS has been very sporadic about showing album thumbnails.  They aren't all built!

I'll report back after some period of stability, or upon first crash.

Thanks Bob!

Brian.

[Hendrik]

The relatively low memory on the Pis is really an annoying problem. As little memory as MC in normal operation uses, once you start processing media files there is no real way to tell how much its going to need - especially when a web client spins off a bunch of thumb requests at the same time.

I do hope future small boards like that come with more memory.
There are alternatives to Raspberry Pi of course, but they are often not as well supported and hard to get going.

[blgentry]

A Pi with 2GB or 4GB would be pretty neat.

Honestly, I wasn't even considering using a Pi for this task.  I was shopping for a Mac mini to do this particular audio "server" duty.  But a friend of mine insisted that I borrow his to test it.  I did, it worked pretty well for a few days, and I bought my own.  The price was very hard to pass up, especially considering that it worked pretty well in my few days of testing.

Frankly, I'm pretty amazed that it works as well as it does.  It's pretty incredible that a "computer" the size of a pack of cigarettes boots "real Linux" in about 20 seconds and runs real deal JRiver Media Center and works mostly just like any other MC computer.  I could see myself with 2 or 3 of these in the future, assuming I can get them totally stable and problem free.

Thanks again,

Brian.

[JimH]

Is that an IdPi or a homebrew build?

[mwillems]

I was about to tell you that all my thumbnails were already built.  So I went to check.  Only 10% are built!  I set thumbnail generation to low priority and have clicked the button to generate all thumbnails it's running now.

I'm using the technique of copying my MC library from my normal MC computer, over to the Pi, on an external hard drive.  I'm also shipping over a library backup file with it, then restoring that library backup into MC on the Pi.  Each time I do this, I guess I need to rebuild all thumbnails.

It's probably NOT a coincidence that I just refreshed the library on the Pi using the above method:  I copied the new media onto the external drive with a backup file, then restored that backup into MC.  I apparently did not rebuild thumbnails when I was doing restoring the MC backup.  This might explain it.

It might also explain why EOS has been very sporadic about showing album thumbnails.  They aren't all built!

I'll report back after some period of stability, or upon first crash.

Thanks Bob!

Brian.

Library restores do indeed flush the thumbnails everytime; in my experience the best way to use the pi is as a library client of an existing MC instance (preferably on a beefier machine).  Then the thumbnail generation is one and done, and it can mostly run without interference for days or weeks. 

I'd also advise using my systemd service for MC (stickied on this forum) as it will auto-restart MC if it crashes.

[blgentry]

Is that an IdPi or a homebrew build?

It's just a Pi with Raspbian on it.  I considered buying an IdPi, but I was impatient and had already built a proof of concept myself.  I have no doubt that the IdPi is an easier to install solution.

Brian.

[blgentry]

in my experience the best way to use the pi is as a library client of an existing MC instance (preferably on a beefier machine).

I specifically want a fully stand alone "mini server" for this project.  I'm not a fan of network based sources for home entertainment.  I'm looking for maximum availability and consistency.  In my case I do not have a dedicated MC "master server" that will always be on and not used as a desktop by a human being.  If I had a full powered MC "server" that a human being would never sit in front of, I might revise my opinion.

I'd also advise using my systemd service for MC (stickied on this forum) as it will auto-restart MC if it crashes.

Hmm, that's new to me.  I'll have to go read the sticky.  Thanks!

Brian.

[JimH]

It's just a Pi with Raspbian on it.  I considered buying an IdPi, but I was impatient and had already built a proof of concept myself.  I have no doubt that the IdPi is an easier to install solution.

It might also solve the stability problem you've had.