Print

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

[bob]

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]

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]

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]

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 .

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]

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]

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]

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]

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]

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]

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]

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]

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

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

[UdoS]

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]

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]

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]

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]

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]

Could it be related?

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

[Mike Noe]

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]

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]

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]

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]

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

[tlcmd]

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]

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]

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]

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]

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

Glad the memory leak is sorted.

[Mark_NL]

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]

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]

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]

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]

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

[UdoS]

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]

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]

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]

Thanks for the report!

[bob]

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

[geier22]

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]

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]

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]

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]

Read two posts above yours for the solution.

[twgehr]

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

[bob]

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

[Awesome Donkey]

Nice!

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]

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]

That would be my guess. Give it a try!

Confirmed, fixed. Thanks Bob!

[NickA]

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]

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