Print

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

[bob]

http://files.jriver.com/mediacenter/channels/v20/latest/MediaCenter-20.0.31-1.deb

20.0.31-1 (11/1/2014)

1. There was something off about that last upload build (version number was wrong for one). Replaced with 20.0.31-1

20.0.31 (10/31/2014)

1. Happy Halloween   Just changes from the main branch.

20.0.27 (10/24/2014)

1. Fixed: Filesystem character problems in Rename, Move and Copy files.
2. Changed: Added hinting to window creation to try to get the window manager to move and resize windows in larger increments.
3. Fixed: CPU usage, especially during the drawing of the Spectrum Analyzer during playback, bug introduced in 20.0.22

20.0.25 (10/16/2014)

1. Changed: More UI changes. Extra desktop hinting on window, title bar and icon creation. Suspend desktop hinting when moving or resizing the root window. Attempt to fix initial window placement issue. Needs testing.

20.0.23 (10/13/2014)

1. Changed: More UI changes. Needs testing.

20.0.22 (10/9/2014)

1. Fixed: Video Playback crashed on stop when playing from a library server.
2. NEW: If using the system volume control and there is no mixer for the PCM device, we'll fall back to using the Master mixer for the device.
3. Changed: UI fixes. Startup position and position of popup windows should be stable now. This includes the controls in fullscreen video mode.

20.0.20 (10/2/2014)

1. Fixed: https protocol broken in 20.0.18
2. Changed: Switched to gnutls from openssl for https support because of a bug in the openssl static libs that prevented some websites certificates from being verified (i.e. twitter)

20.0.18 (9/26/2014)

1. Fixed: JRWorker segfaulting occasionally prevented some file types from being recognized.
2. Fixed: MediaCenter also occasionally segfaulted on exit.

20.0.17 (9/19/2014)

1. NEW: Implemented the file "locate" function.
2. Fixed: Menu items that open a URL in a browser.
3. Fixed: Disabled menu items unsupported on linux.
4. Fixed: Default for managing links changed to external browser.
5. Changed: possibly more ability to play Internet streams. Needs testing.

20.0.16 (9/16/2014)

1. Fixed: Series and Season cover art downloaded to the wrong folders.
2. NEW: Video playback supports playing from a library server.
3. Fixed: Last.fm scrobbling.

20.0.15 (9/12/2014)

1. Fixed: Fullscreen video playback is functional.
2. Changed: The video renderer uses VSYNC if available in the graphics driver.

20.0.13 (9/8/2014)

1. Fixed: Corrected the latency calculation for the ALSA output.
2. NEW: Video support.

[mwillems]

I'm getting segfaults/coredumps on exit again; rolling back to .29 makes them go away.  I'm on Arch 64 bit using Gnome as my DE.

[cassfras21]

Hello,

My feedback on earlier versions is still true:

-I set a custom view based on "file list" view on my htpc.  From the MC Windows client (connected to MC Linux library), it will display another category view than "File list". I guess this behaviors because of missing 3D cat on Linux version.
-I saved DSP profiles for test and I am unable to delete them.

Thanks.

[imugli]

If I do File > Open Media File, then select multiple files, only first one gets loaded.

[astromo]

I'm getting segfaults/coredumps on exit again; rolling back to .29 makes them go away.  I'm on Arch 64 bit using Gnome as my DE.

I'm getting segfaults/coredumps starting up:

~$ mediacenter20
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
Found 0 devices (devices will be listed below)

Total time: 5 ms
Result: 0
Segmentation fault (core dumped)

Running Ubuntu LTS 14.04 64bit, all up to date.

Thoughts? Is there any way to extract a log?

I'll try rolling back and see whether that helps.

[bob]

I'm getting segfaults/coredumps starting up:
Running Ubuntu LTS 14.04 64bit, all up to date.

Thoughts? Is there any way to extract a log?

I'll try rolling back and see whether that helps.

Well since you are supposedly seeing that there are libs missing you could try installing them.

I find an easy way to do this is:
sudo apt-get install apt-file
sudo apt-file update
apt-file search /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so

install the package it returns.

[astromo]

Well since you are supposedly seeing that there are libs missing you could try installing them.

I find an easy way to do this is:
sudo apt-get install apt-file
sudo apt-file update
apt-file search /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so

install the package it returns.

Thanks for that. Filed this for future reference. In between, I loaded a previous system image and then updated to 31-1. Ran the processes above and a lot of funky stuff happened, so I'm taking that as a good sign. MC's back on track. Cheers.

[mwillems]

Ok I just tracked down a bug that had been making me crazy.  MC for Linux appears to parse the Album Type and Album Artist (auto) tags differently from MC for Windows which leads to strange results in cross-platform library server/client situations.  To summarize, I'm seeing different results in shared views for the same files when viewed on MC Linux.

Steps to repro:

1. Setup a view on a windows library server that sorts by Album Artist (auto)
2. Find a complete compilation album with a different artist for every track. and look at the tags; the Album Type will show "Multiple Artists (complete)" and the Album Artist (auto) tag will read "(Multiple Artists)."  This results in the compilation album being shown as a single album in the view created in 1).
3. Load the windows server's library on a Linux library client
4. Find the same album and look at the tags; the Album Type will show "Single Artist (Incomplete)" and the Album Artist (auto) tag will show whatever is in the Artist tag.  This results in the album getting broken up into a dozen single track albums in the view created in 1).
5. Loading the same library on a windows client shows the correct info (as described in 2.).

So I think the issue is that MC's logic for Album Type field may not be working the same wayin the Linux context, and that results in derived fields (like Album Artist (auto)) not working consistently. 

[LETRA]

I think the problem of high CPU activity is not completely solved. There is an improvement but increases from 6% to 35% (and not 65% since the last 2 updates). It is true that Ubuntu 14.04 LTS is not well optimized resource usage. But there is a significant increase for a single program.

[bob]

Ok I just tracked down a bug that had been making me crazy.  MC for Linux appears to parse the Album Type and Album Artist (auto) tags differently from MC for Windows which leads to strange results in cross-platform library server/client situations.  To summarize, I'm seeing different results in shared views for the same files when viewed on MC Linux.

Steps to repro:

1. Setup a view on a windows library server that sorts by Album Artist (auto)
2. Find a complete compilation album with a different artist for every track. and look at the tags; the Album Type will show "Multiple Artists (complete)" and the Album Artist (auto) tag will read "(Multiple Artists)."  This results in the compilation album being shown as a single album in the view created in 1).
3. Load the windows server's library on a Linux library client
4. Find the same album and look at the tags; the Album Type will show "Single Artist (Incomplete)" and the Album Artist (auto) tag will show whatever is in the Artist tag.  This results in the album getting broken up into a dozen single track albums in the view created in 1).
5. Loading the same library on a windows client shows the correct info (as described in 2.).

So I think the issue is that MC's logic for Album Type field may not be working the same wayin the Linux context, and that results in derived fields (like Album Artist (auto)) not working consistently. 

Are you running the same builds on both?
I seem to recall some changes in that area recently and the linux build isn't quite as new as the windows build.

[mwillems]

Are you running the same builds on both?
I seem to recall some changes in that area recently and the linux build isn't quite as new as the windows build.

I don't think it's related to any super recent changes, this has been an ongoing issue for a couple of months. I noticed the view issue back in September and reported it in my second paragraph here:

http://yabb.jriver.com/interact/index.php?topic=92168.msg634487#msg634487

I just didn't have time to run down why it was happening until now (i.e. I saw compilations getting split up and noticed that the same view got different results in both platforms, I just didn't link it back to Album Type).  

I'm currently running the "latest" on both, so .33 on windows and .31-1 for linux, but rolling back the windows build doesn't change anything (which I'd expect since it's been an issue since at least Linux build .18, and maybe before).  

As I recall the "Album Type" field's logic looks at a few different things, including actual directory contents on the disk right?  The wiki's a little outdated, but here's the description of the logic:

Media Center has some built-in support to automatically determine if an album is complete and incomplete. Two fields are automatically calculated, [Album Type] and [Complete Album], and these can be used to help determine if tracks for an album are missing, or help create views to filter single-tracks. An album is considered complete if the following conditions are met:

    all tracks are of [Media Type]=Audio
    all tracks have exactly the same, non-empty [Album] value
    all tracks are in the same folder - i.e. have the same value for the [Filename (path)] field
    all tracks have sequential [Track #] values starting at 1
    all tracks have the same, or sequentially increasing [Disc #] values (empty and 1 are considered the same)

Just a hunch, but could it be a filesystem interaction issue (i.e. the check for all tracks being in the same folder is auto-failing due to differences in MC Linux's filesystem parsing)?