More > JRiver Media Center 21 for Linux
Memory Leak in AMD64 and RPi builds
PrinterPrinter:
--- Quote from: mwillems on October 19, 2015, 07:48:41 am ---Have you built all your thumbnails? I've had similar crashes while my library was building thumbnails, but once all thumbs are built I have very stable memory usage. If you could try pre-building all your thumbs as a diagnostic that could help (the option is under library & folders-->build missing thumbnails)
Even if that's not the issue, you'll see improved responsiveness of the interface (and gizmo/jremote) with all the thumbs pre-built so it won't be a waste of time either way. When you change major versions (i.e. from 20 to 21) the thumbs don't get brought across so you're starting fresh with 21.
--- End quote ---
Thanks I'll do it.
I don't have any local media on the Pi - it's all streaming from a bigger windows machine running MC20 - so I still need to build the thumbs on the Pi? Or on teh windows machine? Or both?
Thank you!
Update - I don't have option like that - I can see one on my local Pi (under configure auto import) but it complains I have no media folders checked - because I'm playing a library from another server...
mwillems:
Do it on the Pi instance. When a JRiver instance displays a view it has to create thumbnails to display from teh album cover art. Creating a thumbnail to display requires CPU, memory, and disk access, and in the case of a remote client it requires network bandwidth too. For this reason, JRiver caches the thumbnails on disk locally once they're built so the display stays responsive (which is one of the ways that JRiver is able to handle such large libraries while every other player chokes).
On a full spec PC with a fast network connection the resource load is pretty trivial (thumbs are created as needed pretty quickly), but on the pi, you'll notice that if you open a view you haven't looked at before you'll see a lot of those blue musical notes and then all the cover art will gradually fill in over several seconds (sometimes several tens of seconds). The time it takes to fill in is the Pi struggling to pull the cover art into memory across the network downscale it to thumbnail size and then display it. If you build them all in advance on the pi, they'll just be "there" already so the only bottleneck is disk access. Gizmo and JRemote pull from the same thumbnail cache, so pre-creating them will help there too.
In my experience pre-building thumbs drastically improves view responsiveness on the Pi so it's a good investment of time no matter what. Set thumbnailing priority to "low" (to minimize memory usage) and leave it to run overnight; it may crash (due to the memory leak) but progress won't be lost, just run it again if that happens and it will pick up where it let off. You can check under services/reporter to see how many thumbs are currently built.
And report back about whether that resolves the memory leak once it's done.
bob:
I think you non-debian users are running into library incompatibilities (since I can't reproduce the memory issue on either i386 or AMD64 debian) and I'm not sure how much farther we can go down the path to try and make this work for you.
The AMD64 build has about every library it can have to make it work on other distros linked into MC's private library path.
mwillems:
--- Quote from: bob on October 19, 2015, 10:45:15 am ---I think you non-debian users are running into library incompatibilities (since I can't reproduce the memory issue on either i386 or AMD64 debian) and I'm not sure how much farther we can go down the path to try and make this work for you.
The AMD64 build has about every library it can have to make it work on other distros linked into MC's private library path.
--- End quote ---
FWIW I run the AMD64 build on Arch and see no memory leak.
Bob, just a wild thought, but someone reported a memory leak over on ARM as well this morning on raspbian. Do you think the two might be connected? I speculated in that thread that it might be related to the thumbnailing memory leak on ARM (which is improved but not fixed). Do you think the leak in this thread could be connected to thumbnailing? My amd64 instance where I see no memory leak already has all of its thumbnails built so that's one differential. That would also explain why you might see it on newer installs, but not longstanding ones.
Anybody else running the 64 bit version on Arch? Anyone seeing the memory leak?
mwillems:
--- Quote from: PrinterPrinter on October 19, 2015, 08:06:37 am ---Update - I don't have option like that - I can see one on my local Pi (under configure auto import) but it complains I have no media folders checked - because I'm playing a library from another server...
--- End quote ---
Sorry I mentioned the wrong menu location. It's under Options-->Tree and View-->Thumbnails-->Build missing thumbnails
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version