Topic: JRiver Media Center 21.0.90 for Debian (Jessie) AMD64 (Read 87182 times)

bob · « **Reply #50 on:** September 24, 2015, 09:07:20 am »

Quote from: InflatableMouse on September 24, 2015, 02:17:54 am

This is the first 64-bit release I try.

When I click anywhere in the dark area on top (around the current file/slider/search box), MediaCenter responds as if I clicked the Max/Restore button.

I think in one of the recent 32-bit release this was (accidently?) solved, unless it was reintroduced?

I realize this may not be high prio, but it is kind of annoying and it's been there from the start .

Sorry I tried this on both 32 and 64 bit debian without being able to reproduce it.

InflatableMouse · « **Reply #51 on:** September 27, 2015, 02:42:26 am »

Quote from: bob on September 24, 2015, 09:07:20 am

Sorry I tried this on both 32 and 64 bit debian without being able to reproduce it.

Weird. Maybe it depends on distro/window manager.

I'm on Arch Linux 64-bit with XFCE4. I thought I read a few others mention this issue but I don't remember which distro/WM they were running.

Mark_NL · « **Reply #52 on:** October 01, 2015, 02:24:50 pm »

Hi,

Just updated to all my systems to MC21, and can confirm the windows buttons are working with Fluxbox as Window Manager (Debian & Arch).
If the /mediaserver switch is used there is some strange behavior: the maximize button must be clicked twice;

What puzzles me are the different looks of the buttons on AMD64 vs ARM using the Noire Skin.
On Arm you get tidy looking windows 10 style buttons on AMD64 not.

It isn't the skin it self, i copied it form ARM to AMD64 after renaming it with no result.

Mark_NL · « **Reply #53 on:** October 01, 2015, 02:37:47 pm »

Quote from: InflatableMouse on September 24, 2015, 02:17:54 am

This is the first 64-bit release I try.

When I click anywhere in the dark area on top (around the current file/slider/search box), MediaCenter responds as if I clicked the Max/Restore button.

I think in one of the recent 32-bit release this was (accidently?) solved, unless it was reintroduced?

I realize this may not be high prio, but it is kind of annoying and it's been there from the start .

Quote from: InflatableMouse on September 27, 2015, 02:42:26 am

Weird. Maybe it depends on distro/window manager.

I'm on Arch Linux 64-bit with XFCE4. I thought I read a few others mention this issue but I don't remember which distro/WM they were running.

Seen this on a arm-board with XFCE4/Debian-Jessie

UdoS · « **Reply #54 on:** October 03, 2015, 09:40:08 am »

HI Bob,

I'm running MC now for a few days non stop and it ends up to eat up my memory. I was wondering, why the playback was stalling, when I worked with my computer.

I checked my resources and found that mc uses a little as 12Gb of memory. (see attached images)
After restarting MC, the memory starts reasonable, but if seems like every new song played increments the used memory by some hundreds of kilobytes.
It looks like every time a new song starts, a new buffer is used, but not flushed after playback stops.

UdoS · « **Reply #55 on:** October 04, 2015, 06:30:49 am »

Quote from: UdoS on October 03, 2015, 09:40:08 am

HI Bob,

I'm running MC now for a few days non stop and it ends up to eat up my memory. I was wondering, why the playback was stalling, when I worked with my computer.

I checked my resources and found that mc uses a little as 12Gb of memory. (see attached images)
After restarting MC, the memory starts reasonable, but if seems like every new song played increments the used memory by some hundreds of kilobytes.
It looks like every time a new song starts, a new buffer is used, but not flushed after playback stops.

Hi Bob,

here some detailed information about memory usage.

bob · « **Reply #56 on:** October 12, 2015, 04:03:26 pm »

Quote from: Mark_NL on October 01, 2015, 02:24:50 pm

Hi,

Just updated to all my systems to MC21, and can confirm the windows buttons are working with Fluxbox as Window Manager (Debian & Arch).
If the /mediaserver switch is used there is some strange behavior: the maximize button must be clicked twice;

What puzzles me are the different looks of the buttons on AMD64 vs ARM using the Noire Skin.
On Arm you get tidy looking windows 10 style buttons on AMD64 not.

It isn't the skin it self, i copied it form ARM to AMD64 after renaming it with no result.

The top level window buttons are provided by the Window Manager.

bob · « **Reply #57 on:** October 12, 2015, 04:06:25 pm »

Quote from: UdoS on October 04, 2015, 06:30:49 am

Hi Bob,

here some detailed information about memory usage.

It could be a memory leak triggered by a misbehaving DLNA device or some issue with thumbnailing or the audio analyzer. It could also be an issue with somewhat incompatible libraries on a non-debian system.

Can you try with Media Network disabled and see if that makes a difference?

UdoS · « **Reply #58 on:** October 13, 2015, 04:15:44 am »

Quote from: bob on October 12, 2015, 04:06:25 pm

It could be a memory leak triggered by a misbehaving DLNA device or some issue with thumbnailing or the audio analyzer. It could also be an issue with somewhat incompatible libraries on a non-debian system.

Can you try with Media Network disabled and see if that makes a difference?

I disabled the server, but it still counting up. The heap gained 108Mb within 17min.

bob · « **Reply #59 on:** October 13, 2015, 11:14:49 am »

Quote from: UdoS on October 13, 2015, 04:15:44 am

I disabled the server, but it still counting up. The heap gained 108Mb within 17min.

Ok, thanks.
Hoping it's not an incompatible library.
Another possibility I though about would be a audio driver bug.
You could try a simpler device like onboard audio if you aren't already.
Also perhaps a certain input plugin has a leak. What filetypes are you playing?

bob · « **Reply #60 on:** October 13, 2015, 05:19:16 pm »

Quote from: UdoS on October 13, 2015, 04:15:44 am

I disabled the server, but it still counting up. The heap gained 108Mb within 17min.

Would you try turning off the spectrum analyzer (right click on it) and see if that changes anything?

Mark_NL · « **Reply #61 on:** October 14, 2015, 01:27:50 pm »

Quote from: bob on October 12, 2015, 04:03:26 pm

The top level window buttons are provided by the Window Manager.

But this is the (undecorated) main window...

UdoS · « **Reply #62 on:** October 15, 2015, 09:23:18 am »

Quote from: bob on October 13, 2015, 05:19:16 pm

Would you try turning off the spectrum analyzer (right click on it) and see if that changes anything?

I turned off the spectrum analyzer and it seems to low down using memory. I run the system now for more than 24h and it build up to 771Mb, far less than before, but still counting up.
The heap increases when you start a new song, sometime more, sometimes less.

bob · « **Reply #63 on:** October 15, 2015, 01:31:24 pm »

Quote from: InflatableMouse on September 24, 2015, 02:17:54 am

This is the first 64-bit release I try.

When I click anywhere in the dark area on top (around the current file/slider/search box), MediaCenter responds as if I clicked the Max/Restore button.

I think in one of the recent 32-bit release this was (accidently?) solved, unless it was reintroduced?

I realize this may not be high prio, but it is kind of annoying and it's been there from the start .

I tried the 64 bit version on ubuntu 15.10 and I can't get this to happen.

bob · « **Reply #64 on:** October 15, 2015, 01:34:48 pm »

Quote from: Mark_NL on October 14, 2015, 01:27:50 pm

But this is the (undecorated) main window...

You're right of course, I don't see how it can be different though unless the wm is mucking with it. It's totally different on my RPI than it is on my debian box.

InflatableMouse · « **Reply #65 on:** October 26, 2015, 01:31:02 pm »

I upgraded from 21.0.7 64-bit. It was pretty stable, rarely crashed and would generally close when I clicked close.

This version often randomly crashes. It no longer closes when I click close. Music will continue to play until the song is done, but the screen doesn't update and when I minimize/maximize it, it will stay white. I need to kill it from the terminal.

The only notable change I made is I installed and configured Pulseaudio. I had to because Spotify >=1.0 requires it. I removed Pulse to test but it doesn't matter for MC.

I can configure MC to output to Pulse or directly to an ALSA device but it makes no difference.

Is anyone else seeing a regression with this version? I can supply logs or more info, just ask what you need.

I am on Arch Linux, XFCE4, 64-bit.

Thanks!

mwillems · « **Reply #66 on:** October 26, 2015, 02:06:10 pm »

Quote from: InflatableMouse on October 26, 2015, 01:31:02 pm

I upgraded from 21.0.7 64-bit. It was pretty stable, rarely crashed and would generally close when I clicked close.

This version often randomly crashes. It no longer closes when I click close. Music will continue to play until the song is done, but the screen doesn't update and when I minimize/maximize it, it will stay white. I need to kill it from the terminal.

The only notable change I made is I installed and configured Pulseaudio. I had to because Spotify >=1.0 requires it. I removed Pulse to test but it doesn't matter for MC.

I can configure MC to output to Pulse or directly to an ALSA device but it makes no difference.

Is anyone else seeing a regression with this version? I can supply logs or more info, just ask what you need.

I am on Arch Linux, XFCE4, 64-bit.

Thanks!

I see something similar. If I've been listening for a while, closing MC will just cause the window to freeze until I kill it from the terminal (I left it for an hour or so to see if it would eventually close, but no dice). It doesn't exhibit the behavior if I just open MC and close it again, I need to have been playing something for a while. I too had no issues with 21.0.07.

No crashes to speak of, but all versions after 21.0.07 have a memory leak for me, so if you listen for very long it may eventually crash due to the leak. I just have 16GB of system memory so I don't hit the OOM state very often. Bob says he can see the memory leak in 21.0.07, but I can't reproduce it on Arch on two different machines, so I'd advise folks running the 64-bit version on Arch to roll back to 21.0.07 until the leak gets fixed.

InflatableMouse · « **Reply #67 on:** October 26, 2015, 02:09:52 pm »

Could it be related?

http://yabb.jriver.com/interact/index.php?topic=100628.0

Mike Noe · « **Reply #68 on:** October 30, 2015, 02:41:05 pm »

Bug in MCWS?

I'm issuing:

Code: [Select]

(mcwsBase::exec(const QUrl&, bool)::<lambda:86) - "Error downloading http://localhost:52199/MCWS/v1/Library/GetStats - server replied: Internal server error"

and getting back:

Code: [Select]

<Response Status="Failure">
<Item Name="Files">27126</Item>
<Item Name="Artists">638</Item>
<Item Name="Albums">1826</Item>
</Response>

Just noticed it because I added some extra error detection to my networkReply....

Happening at least back to .7

fwiw, I'm on .17

bob · « **Reply #69 on:** October 30, 2015, 03:07:23 pm »

Quote from: Mike Noe on October 30, 2015, 02:41:05 pm

Bug in MCWS?

I'm issuing:
Code: [Select]
(mcwsBase::exec(const QUrl&, bool)::<lambda:86) - "Error downloading http://localhost:52199/MCWS/v1/Library/GetStats - server replied: Internal server error"
and getting back:
Code: [Select]
<Response Status="Failure"> <Item Name="Files">27126</Item> <Item Name="Artists">638</Item> <Item Name="Albums">1826</Item> </Response>
Just noticed it because I added some extra error detection to my networkReply....

Happening at least back to .7

fwiw, I'm on .17

Looks like it returns the proper information but indicates failure, correct?

Mike Noe · « **Reply #70 on:** October 30, 2015, 03:56:47 pm »

Quote from: bob on October 30, 2015, 03:07:23 pm

Looks like it returns the proper information but indicates failure, correct?

Yep, I'd say so. Also, along with the "failure" status, it appears to be returning internal server error (401), at least that's what's bubbling up to my app through the QT plumbing.

Matt · « **Reply #71 on:** October 30, 2015, 08:05:02 pm »

We'll try to get the error calling:
http://localhost:52199/MCWS/v1/Library/GetStats

Fixed in one of the next coming builds. Thanks for letting us know.

Matt · « **Reply #72 on:** November 03, 2015, 07:39:43 am »

Just to follow up, the error will be fixed next build. Thanks again for letting us know.

tlcmd · « **Reply #73 on:** November 18, 2015, 07:17:35 am »

After my recent upgrade of MC21 to 21.0.16, my smartlists disappeared. I am running Linux Mint Debian Edition. Is anyone else having this problem, and is there a solution to it in installing future upgrades?

Thanks.
tlcmd

bob · « **Reply #74 on:** November 23, 2015, 11:48:18 am »

The memory leak that was affecting the amd64 build especially bad should be fixed now. It's working properly on my build machine and the 2 test bottles I've tried so far.

Mark_NL · « **Reply #75 on:** November 23, 2015, 12:30:20 pm »

Fired up the VM with JRiver AMD64 for testing.

Report back, if there is something specific you'd like to test let me (us) know.
for reference the graph of a MC21-16 AMD 64 test.

teaser update: looks good after 1h playing!

bob · « **Reply #76 on:** November 23, 2015, 02:26:58 pm »

Quote from: Mark_NL on November 23, 2015, 12:30:20 pm

Fired up the VM with JRiver AMD64 for testing.

Report back, if there is something specific you'd like to test let me (us) know.
for reference the graph of a MC21-16 AMD 64 test.

teaser update: looks good after 1h playing!

Thanks!
I got it to happen most egregiously when MC was displaying a list view and cycling through a long playlist of short files so there were lots of window updates in MC.

Awesome Donkey · « **Reply #77 on:** November 23, 2015, 04:34:06 pm »

New build also seems more snappy to me, especially when opening and closing.

Glad the memory leak is sorted.

Mark_NL · « **Reply #78 on:** November 24, 2015, 11:32:59 am »

the leak is fixed!

It's playing for several hours, in diverend views (about the same as the MC21-16 test before) without a growing mem footprint.

(ditto for MC-arm version, that's fixed too!)

bob · « **Reply #79 on:** November 24, 2015, 01:00:32 pm »

Quote from: Mark_NL on November 24, 2015, 11:32:59 am

the leak is fixed!

It's playing for several hours, in diverend views (about the same as the MC21-16 test before) without a growing mem footprint.

(ditto for MC-arm version, that's fixed too!)

Thanks for testing it!

UdoS · « **Reply #80 on:** November 25, 2015, 03:27:22 am »

Hi Bob,

I'm playing it for 2 days now, without any problems. Memory usage is bouncing around between 150 to 260 MB. No more leak.

bob · « **Reply #81 on:** November 30, 2015, 11:29:32 am »

Quote from: UdoS on November 25, 2015, 03:27:22 am

Hi Bob,

I'm playing it for 2 days now, without any problems. Memory usage is bouncing around between 150 to 260 MB. No more leak.

Great, thanks for reporting.
My test X86_64 box has been running for 6 days with no increase in memory footprint as well.

bob · « **Reply #82 on:** December 17, 2015, 05:02:50 pm »

21.0.28 Should fix the crashes caused by bugs in the socket code. Feedback requested.

UdoS · « **Reply #83 on:** December 18, 2015, 06:56:21 am »

Hi
I'm running SUSE Leap 42.1 with the Plasma 5 desktop for testing purpose and run into a strange bug. Since Plasma 5 is buggy, I don't know, if it is a plasma- or MC bug. When I try to save any file during playback, it's not possible until I stop it. It seems like MC is locking the entire home drive. I can read, but I can't write. Is any one else have this problem using Leaf? When I boot into SUSE 13.2 and KDE, everything runs fine (my home drive is nfs based and used by both OS.) Only MC shows this problem and I tried x.16, x.23 and x.28.

NickA · « **Reply #84 on:** December 20, 2015, 08:40:06 pm »

Quote from: bob on December 17, 2015, 05:02:50 pm

21.0.28 Should fix the crashes caused by bugs in the socket code. Feedback requested.

Hi Bob,

Thanks and Merry Christmas.

I am on Debian 8.2 3.16.0-4-amd64 and upgraded to 21.0.28

I am not sure if it is the new version or installing libgl1-nvidia-glx:i386 (I had just installed the i386 drivers when the upgrade came through) but it is markedly more stable it has been running for more than 24 hours without issue. I will pull the i386 drivers off and report back in a few days.

Nick

NickA · « **Reply #85 on:** January 02, 2016, 02:30:18 am »

Quote from: bob on December 17, 2015, 05:02:50 pm

21.0.28 Should fix the crashes caused by bugs in the socket code. Feedback requested.

I have removed the :i386 drivers and architecture and 21.0.28 remains solid as a rock

Thanks Bob

Nick

bob · « **Reply #86 on:** January 04, 2016, 11:42:12 am »

Thanks for the report!

bob · « **Reply #87 on:** January 08, 2016, 05:15:03 pm »

Some fixes for speed and window placement issues. See the first post.

geier22 · « **Reply #88 on:** January 09, 2016, 07:59:58 am »

I believe it is only since the version MC 21 034: Using the Skins Black on Black and Purity tooltips are no longer readable. The font is too bright (standard settings - no effects) I have no setting found to make the font in the tooltips darker.

Awesome Donkey · « **Reply #89 on:** January 10, 2016, 12:37:32 pm »

Anyone running Ubuntu 14.04.x LTS or Linux Mint 17.x needs to update their GCC libs or else Media Center won't function correctly. You can do so by opening a Terminal and running the following commands;

Code: [Select]

sudo add-apt-repository ppa:ubuntu-toolchain-r/test 
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

If you're running Ubuntu 15.10 this is a non-issue - Media Center will function correctly.

bob · « **Reply #90 on:** January 11, 2016, 10:37:15 am »

Quote from: Awesome Donkey on January 10, 2016, 12:37:32 pm

Anyone running Ubuntu 14.04.x LTS or Linux Mint 17.x needs to update their GCC libs or else Media Center won't function correctly. You can do so by opening a Terminal and running the following commands;

Code: [Select]
sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade
If you're running Ubuntu 15.10 this is a non-issue - Media Center will function correctly.

Thanks for the info.

twgehr · « **Reply #91 on:** January 12, 2016, 05:03:41 pm »

This update seemed to have broke my media center 21 on ubuntu 14.04. Try to start the app, but it never comes up. Please advise.

Awesome Donkey · « **Reply #92 on:** January 12, 2016, 07:37:35 pm »

Read two posts above yours for the solution.

twgehr · « **Reply #93 on:** January 12, 2016, 07:51:35 pm »

Just saw the fix. Many thanks. Need to understand how to navigate this forum better.

bob · « **Reply #94 on:** January 25, 2016, 06:47:06 pm »

Desktop integration changes and removing the lame dependency are in this build.

Awesome Donkey · « **Reply #95 on:** January 25, 2016, 06:58:09 pm »

Nice!

Quote

Fixed: Bug in calculating the offset from UTC.

Does this fix the issue where time was ahead by 6 hours when saving library backups?

bob · « **Reply #96 on:** January 25, 2016, 07:08:59 pm »

Quote from: Awesome Donkey on January 25, 2016, 06:58:09 pm

Nice!

Does this fix the issue where time was ahead by 6 hours when saving library backups?

That would be my guess. Give it a try!

Awesome Donkey · « **Reply #97 on:** January 25, 2016, 07:26:44 pm »

Quote from: bob on January 25, 2016, 07:08:59 pm

That would be my guess. Give it a try!

Confirmed, fixed. Thanks Bob!

NickA · « **Reply #98 on:** January 29, 2016, 07:02:32 am »

Hi Bob,

I have upgraded to 21.0.39 and it is crashing for me. How can I help troubleshoot, what do you need?.

Kind regards,

Nick

NickA · « **Reply #99 on:** January 29, 2016, 07:11:03 am »

Quote from: bob on January 15, 2016, 05:48:43 pm

If you want to follow the linux build changes a bit less on the leading edge, try the stable dist.
Using Awesome Donkeys tutorial, just substitute the word stable where you see latest.

Currently all builds in stable are 21.0.34

Hi Bob I just saw this, will go .34 and see how it goes for me. Let me know if you want any into re .39

Cheers, Nick

INTERACT FORUM

Author Topic: JRiver Media Center 21.0.90 for Debian (Jessie) AMD64 (Read 87182 times)