Print

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

[bob]

This is a BETA version of MC24 for Linux.  Please post bugs here.  Please start a new thread for anything requiring discussion.  Non-bug posts will be deleted.

Download:
amd64      https://files.jriver.com/mediacenter/test/MediaCenter-24.0.65-amd64.deb

Also in the BETA repo.

24.0.65 (11/27/2018)

1. Changed: Updated FFmpeg to version 4.1, used for file analysis, transcoding and video playback.
2. NEW: Support for hardware accelerated video decoding on x86/amd64 on NVIDIA GPUs using NVDEC (MPEG2, VC-1, H.264, H.265/HEVC, VP8/9), and on Intel/AMD using VA-API (MPEG2, VC1, H.264 only).
3. Changed: Internal change to the way files are moved.
4. Changed: plughw: and dmix: audio devices are now allowed to change the audio output at the ALSA level. If you use those devices we assume you know what you are doing.
5. Fixed: Editing Custom Website Entries in the Streaming section did not work.
6. NEW: Media Center can now read video tags written in Apple Quicktime's extensible tagging format.
7. Changed: Adjusted the quality score of MetaCritic movie information lookup to reflect its cover art and information quality.
8. Changed: Made the MCC_PLAY_PLAYLIST command reset the search cache so running it on a random smartlist will get new information each instance.
9. NEW: Added a toolbar button to add selected files to Playing Now.
10. Fixed: Radio Paradise could play duplicates in some cases.
11. Changed: Made the Playing Now Overview lists no longer ignore the selection.  Instead the selection will be used to populate the Tag Action Window and the like.
12. NEW: Added the option to suppress the duplicate track warning in a playlist (Options > General > Advanced > Show duplicate file warnings for playlists).
13. Fixed: The seed parameter of the play doctor MCWS command would not load properly.

24.0.64-3 (11/20/2018)

1. Fixed: Two of the plugin libraries were being registered to the wrong directory.

24.0.64-2 (11/20/2018)

1. Fixed: Build number was wrong.
2. Fixed: Editing Custom Website Entries in the Streaming section did not work.

24.0.64 (11/19/2018)

1. Changed: Updated package dependencies.
2. NEW: Support for FLAC-in-Ogg files and streams.
3. Changed: Room Correction DSP allows setting a distance of up to 100 ft instead of 50 ft (or meters if you're metric).
4. Fixed: Made Rotten Tomatoes movie lookup work for a few more titles.
5. Changed: Updated to Monkey's Audio 4.40.
6. Fixed: Removing a column from the sorting in a list with no sorting (or external sorting) would crash.
7. NEW: Radio Paradise toolbar channel buttons added.
8. Fixed: A occasional mismatch with Radio Parasdise metadata for the current playing track.
9. NEW: Added the MCC MCC_LIST_SEND_TO_PLAYING_NOW (26031) to add selected files to Playing Now using any of the modes available (play shuffled, add albums to end, etc.).
10. Fixed: The option to advance to the next track didn't work nicely when also picking stop after each item when it played the second to last track in the playlist.
11. Fixed: Playing Ogg Vorbis Internet Radio streams did not work.
12. NEW: Added the website MetaCritic to the online movie information lookup (http://www.metacritic.com).
13. Changed: Brought Rotten Tomatoes back to the online movie lookup.
14. Fixed: Theater View Background color did not work properly since 24.0.59.
15. Changed: The memory playback model "Load decoded file into memory" no longer engages when playing a URL.
16. Fixed: The option to "Advance to the next track when stopping after the current track" could loop to the second file in the playlist instead of the first after the last track.
17. NEW: There's a "Web Media" playlist that shows under the "Streaming" tree item and files from the Open URL dialog get added to it when added to the library.
18. Changed: German translation updated (thanks ByteStar).
19. Fixed: Open Weather Map configuration for Theater View was not working.
20. NEW: Pressing Ctrl+Q+Enter in a search box adds the files to Playing Now (Ctrl+Enter plays).

24.0.61 (11/2/2018)

1. Fixed: MC could deadlock when loading a large DLNA server library.
2. NEW: Non-standard file associations for various DSD mimetypes added so that we can see those files from DLNA server libraries that are using those mimetypes.
3. Changed: Some DLNA servers (like on the QNAP) don't properly provide the total number of files matches in a search which limited us to seeing the first 1000 files in a library.
4. Changed: All other multi-platform applicable changes from the windows build.

24.0.55 (10/8/2018)

1. NEW: Buttons added for re-ordering a track in a playlist.
2. Changed: Range for detecting an external DLNA controller while a playlist is playing is changed from 0 - End-5 seconds to 0 - End-6 seconds

24.0.52 (9/20/2018)

1. Changed: Only the 64 bit version uses Chromium now, the i386 and arm builds use webkit libraries from the users OS.
2. Changes from the main build.

24.0.46 (8/10/2018)

1. Fixed: Crash under some DM's (Cinnamon, perhaps others) when the file select dialog is closed.
2. Fixed: MC would leave around some files in /run/shm which could cause unexplained behavior and crashes when they accumulated and the process numbers recycled and MC reused them.
3. Fixed: Changes to make the running of the Chromium browser more stable.
4. Fixed: The wavepack plugin was missing from some builds which resulted in unexplained crashes.
5. Changed: Added the libnss3 dependency and removed the webkit dependency for the Chromium builds.

24.0.45 (7/27/2018)

1. NEW: The web browser uses chromium now (except for ARM). A chromium plugin is downloaded and installed on first run (MC will take a while to come up depending on your connection speed, it's 45 megs to DL).

24.0.42 (7/10/2018)

1. Changed: Improved internal web browser operation.

24.0.39 (6/29/2018)

1. Changes from the main branch mainly dealing with JRiver Radio.

24.0.37 (6/26/2018)

1. NEW: Linux implement key release handling. Detect whether a key is being held down (key repeat).
2. Fixed: Crash on right-click release in some context menus.
3. Fixed: A key sending function in MC was sending 2 keypresses instead of a press/release.

24.0.36 (6/22/2018)

1. Fixed: In some cases, converting an audio file would leave the file type set to the old file's type.
2. Fixed: OpenGL Theater View could use more CPU then expected since 24.0.34.
3. Fixed: SRT subtitles with non-breaking spaces did not render properly.
4. Changed: DLNA, change SetNext controller option disabling so that device errors don't disable SetNext only disable it if the renderer reports that it's not implemented.
5. Changed: DLNA. Want to make sure that if a resubscribe fails we clear and do a subscribe. Have seen http error codes of 412 on resubscribe.
6. Changed: DLNA, Add a code that will do a manual transport state update if we look frozen at the end of a track (missed an event..)
7. Changed: Radio JRiver playlists will end after playing for two hours without any Media Center user interaction.

24.0.35 (6/15/2018)

1. Fixed: Licensing on i386/amd64 builds. Hopefully for the last time, will require re-entering your registration code.
2. Changed: Implemented some missing low level windowing functions.

24.0.34 (6/12/2018)

1. Fixed: A couple of memory leaks in ALSA and in the Windowing code.
2. Changed: Removed the Register function from the desktop entry because it was preventing mime type associations from working.
3. Changed: The internal web browser is more resiliant and should work better with some desktops.

24.0.32-4 (6/5/2018)

1. Fixed: On some systems we couldn't open the ALSA hardware devices.

24.0.32-2 (6/3/2018)

1. Fixed: Covert art thumbnails were not working on some platforms.

24.0.32 (6/1/2018)

1. Changed: Licensing on InteThis is the latest version of MC24 for Linux.  Please post bugs here.  Please start a new thread for anything requiring discussion.  Non-bug posts will be deleted.

24.0.31 (5/29/2018)

1. NEW: Implemented the startup options for linux. Works with any desktop manager.
2. Fixed: A memory leak in the ALSA driver.
3. NEW: Implemented the internal browser. Needs testing.

24.0.28 ( 5/14/2018)

1. NEW: Added info to the Reporter Advanced Information showing the system memory and free memory.
2. Changed: For Linux ARM, disable multithreaded drawfast code (used in resizing) until neon is fully implemented.
3. Changed: For Linux ARM, cap maximum threads and weight for thumbnailing until neon is fully implemented.
4. Fixed: Linux ALSA output device, wasn't configuring local zones other than the default zone properly.
5. Changed: Updated the gtk dependencies from libgtk2.0 to libgtk-3-0

[Rizlaw]

Ubuntu 18.04LTS 64bit has a problem upgrading from 24.0.64-3 to 24.0.65. See attached screenshot using gdebi to inst

[Zhillsguy]

Ubuntu 18.04LTS 64bit has a problem upgrading from 24.0.64-3 to 24.0.65. See attached screenshot using gdebi to inst

I'm getting the same error using Mint 19 Xfce.

[Scobie]

Works ok on Debian

[Hendrik]

Newer Ubuntu versions apparently switched to libva2, and don't have libva1 at all anymore, while thats not present in Debian until Buster.
Unfortunately we cannot really support both at the same time. Thats annoying. Like I said in another thread just yesterday, absolutely no consideration for software that they don't ship themselves.

I suppose we could ship the two libva libraries we use, but it still would only work on a subset of systems that use a matching one (ie. either libva1 or libva2).

[Awesome Donkey]

Fortunately, libva1 is available in Arch Linux, so just adding it as a dependency in the PKGBUILD and building the package and installing it worked fine.

[Hendrik]

Chances are that only one of those is actually compatible with your graphics driver though, probably libva2 at this point if you update regularly.
We're currently evaluating our options. Its really unfortunate that there is a break in the version basically right now, for Debian Jessie/Stretch still use libva1, only Buster moves to libva2, while many other popular distributions already did the switch, since newer Intel drivers probably required it.

[Awesome Donkey]

Yeah, in my case my graphics driver would be the open-source one, since I'm using an AMD GPU (and Mesa/AMDGPU). Now sure if HW accelerated video decoding would work there though, I guess I'd have to try it.

[Hendrik]

AMD supports VA-API in some of its drivers, the Mesa one at least. How well it works however, I cannot tell you.
Hardware Acceleration on Linux is unfortunately a real mess. Don't even get me started on ARM.

[Awesome Donkey]

Gotta love Linux... sometimes... other times it's a pain (due to the fragmentation of the different distros and the libraries they use or don't use).

VA-API *should* work for me with Mesa/AMDGPU since I manually enabled it and set it up in Arch Linux some time ago. Pretty sure VA-API worked in VLC when I tested it after enabling it. I guess it depends, like you said, if libva1 works with Mesa/AMDGPU and VA-API.

I can imagine ARM, especially on a Raspberry Pi, is a total nightmare and not even viable for at least another few years, if not more.

[Hendrik]

RPi is the worst. Its really sad how such bad hardware could become so popular. The Broadcom GPU and video chip is all sorts of non-standard and terrible. And unfortunately I don't see them switching vendor for a future RPi at all.
Something like an ODROID-C2 with a ARM Mali GPU is so much better to work with (and faster to boot), but it doesn't have that huge ecosystem around it.

[Awesome Donkey]

Yeah, I have an ODROID-XU4 I use for a RetroPie and it works pretty well for that. From what I read in regards to video on it (through Kodi), it has a Mali-T628 MP6 and it can handle 1080p just fine but I've read conflicting reports about 4K content on it - very interesting read indeed. I suppose I could test that by using Kodi that the RetroPie includes and using some of the 4K sample videos I have. And it looks like you can run full Ubuntu 18.04 LTS with MATE on it too, which is also kinda interesting. Hmmm, if I flash a microSD card with Ubuntu 18.04 LTS, I wonder if I can get MC24 installed and working on it?

But yeah, ODROIDs haven't caught on like the Pis, even though they're much more powerful than a Pi (the XU4 is 3 to 4 times more powerful than a Raspberry Pi 3 Model B+).

[Hendrik]

Bob has been testing a ARM64 build of MC24 which he runs on a similar device. It runs Theater View pretty nicely (unlike the RPi). Maybe we'll release it some day.

[mwillems]

Yeah, I have an ODROID-XU4 I use for a RetroPie and it works pretty well for that. From what I read in regards to video on it (through Kodi), it has a Mali-T628 MP6 and it can handle 1080p just fine but I've read conflicting reports about 4K content on it - very interesting read indeed. I suppose I could test that by using Kodi that the RetroPie includes and using some of the 4K sample videos I have. And it looks like you can run full Ubuntu 18.04 LTS with MATE on it too, which is also kinda interesting. Hmmm, if I flash a microSD card with Ubuntu 18.04 LTS, I wonder if I can get MC24 installed and working on it?

But yeah, ODROIDs haven't caught on like the Pis, even though they're much more powerful than a Pi (the XU4 is 3 to 4 times more powerful than a Raspberry Pi 3 Model B+).

I've posted before on the ODROIDs; I'd be interested in your results, the previous generation boards were completely unsuitable for use with MC (for a variety of reasons), so I'd be curious to see if its doable now. 

Part of the reason the ODROIDs haven't caught on like the Pis is that they were (and stilla re to my knowledge) missing mainline kernel support for several subsystems, so you're entirely reliant on the vendor images, especially if you want graphics acceleration.  With ODROIDs I used the only software that had working hardware acceleration were pieces of software that the devs or other enterprising people had specifically recompiled to target the platform (general arm builds never had working hardware accel).  The other hiccup was that the drivers lacked the necessary color space to display MC at all so you just got a white or black window on local video connections. 

It would be nice if they fixed those issues (or had mainline kernel support that was worth a c**p).  By contrast, the Pi's hardware sucks, but it works for everything (albeit slowly), so I've been very hesitant about new arm platforms that don't have mainline kernel support.

Something like an ODROID-C2 with a ARM Mali GPU is so much better to work with (and faster to boot), but it doesn't have that huge ecosystem around it.

Hendrik, when you say "better to work with" do you mean "easier to work with as a dev (i.e. easier to implement hardware acceleration on)" or do you mean "easier to use as an end user"?  I've only ever heard dev horror stories about trying to work with Mali, so if they've gotten better to develop for that would indeed be good news.

[Awesome Donkey]

I wonder if the new x86_64-based ODROID-H2 might be something worth looking into too. From what I read it's capable of emulating the GameCube and Wii at full speed with Vulkan so I wonder what its video capabilities would be since it's Intel-based.

[mwillems]

I wonder if the new x86_64-based ODROID-H2 might be something worth looking into too. From what I read it's capable of emulating the GameCube and Wii at full speed so I wonder what its video capabilities would be since it's Intel-based.

If its x86/intel it's probably got close to 100% open source drivers which would be the bee's knees.  I'll definitely check that out, although it looks like it's sold out through next March (other people clearly had the same thought  )

[Awesome Donkey]

If its x86/intel

It is. It has a Intel Celeron J4105 Gemini Lake CPU so it probably can run mainline... depending on the level of support the current kernel release has, of course.

[geier22]

Violated dependencies in MC 24.0.65

apt says:

Code: [Select]

Die folgenden Pakete haben verletzte Abhängigkeiten:
 mediacenter24 : Hängt ab von: libva1 (>= 1.4.1) which is a virtual package and is not provided by any available package

                 Hängt ab von: libva-drm1 (>= 1.4.1) which is a virtual package and is not provided by any available package

Die folgenden Aktionen werden diese Abhängigkeiten auflösen:

     Beibehalten der folgenden Pakete in ihrer aktuellen Version:
1)     mediacenter24 [24.0.64-3 (now)]           
available in Debian Buster:

Code: [Select]

~$ dpkg -l lbva*
||/ Name                     Version      Architektur  Beschreibung
+++-========================-============-============-=========================
ii  libva-drm2:amd64         2.3.0-2      amd64        Video Acceleration (VA) A
ii  libva-glx2:amd64         2.3.0-2      amd64        Video Acceleration (VA) A
ii  libva-wayland2:amd64     2.3.0-2      amd64        Video Acceleration (VA) A
ii  libva-x11-2:amd64        2.3.0-2      amd64        Video Acceleration (VA) A
ii  libva2:amd64             2.3.0-2      amd64        Video Acceleration (VA) A

libav1 is not available in Buster. can you correct that?

[Awesome Donkey]

They're evaluating their options.

[bob]

I've posted before on the ODROIDs; I'd be interested in your results, the previous generation boards were completely unsuitable for use with MC (for a variety of reasons), so I'd be curious to see if its doable now. 

Part of the reason the ODROIDs haven't caught on like the Pis is that they were (and stilla re to my knowledge) missing mainline kernel support for several subsystems, so you're entirely reliant on the vendor images, especially if you want graphics acceleration.  With ODROIDs I used the only software that had working hardware acceleration were pieces of software that the devs or other enterprising people had specifically recompiled to target the platform (general arm builds never had working hardware accel).  The other hiccup was that the drivers lacked the necessary color space to display MC at all so you just got a white or black window on local video connections. 

It would be nice if they fixed those issues (or had mainline kernel support that was worth a c**p).  By contrast, the Pi's hardware sucks, but it works for everything (albeit slowly), so I've been very hesitant about new arm platforms that don't have mainline kernel support.

Hendrik, when you say "better to work with" do you mean "easier to work with as a dev (i.e. easier to implement hardware acceleration on)" or do you mean "easier to use as an end user"?  I've only ever heard dev horror stories about trying to work with Mali, so if they've gotten better to develop for that would indeed be good news.

It's really unfortunate that they aren't better supported but from the testing I've done with a native build the C2 works well. It's not really that much quicker than a Pi3 in general but that OGL support Hendrik was talking about with the Mali chip is at least 300% faster than the Pi3. Also it's got twice the ram which is nice too.

With such a limited market share though it's not going to make sense for us to spend resources putting out builds for it.

Best hope is that stuff like this spurs the RPi foundation to up their game.

[mwillems]

It's really unfortunate that they aren't better supported but from the testing I've done with a native build the C2 works well. It's not really that much quicker than a Pi3 in general but that OGL support Hendrik was talking about with the Mali chip is at least 300% faster than the Pi3. Also it's got twice the ram which is nice too.

Yeah there are a lot of pretty attractive things about their platforms from a specs perspective.

Best hope is that stuff like this spurs the RPi foundation to up their game.

Either that, or hope that the continued success of the RPI in the face of vastly technically superior competing hardware makes it clear to the ODROIDs of the world that what's choking their market share isn't specs, but rather compatibility and mainline support.

[BryanC]

In Fedora, when trying to play video I'm getting:

0014095: 3010915328: Playback: CJRVideoEngine::Open: FFmpeg DLLs are not available.

Works normally on 24.0.64.

Any ideas? Do I need to link something during install?

[bob]

In Fedora, when trying to play video I'm getting:

0014095: 3010915328: Playback: CJRVideoEngine::Open: FFmpeg DLLs are not available.

Works normally on 24.0.64.

Any ideas? Do I need to link something during install?

I'm guessing they are there but they don't work since your system doesn't have libva1?

[BryanC]

I'm guessing they are there but they don't work since your system doesn't have libva1?

Yes, F28 moved to libva2. I didn't realize that this would prevent playback even without hardware decoding enabled. I suppose add me to the list of the "move to Stretch" proponents.

[Awesome Donkey]

Moving to Stretch wouldn't help, it still uses libva1 too. They'll have to move to Buster once it's released to stable to gain libva2 support.

[BryanC]

Moving to Stretch wouldn't help, it still uses libva1 too. They'll have to move to Buster once it's released to stable to gain libva2 support.

Yikes! I didn't realize Stretch was so far behind the curve. But non-hardware accelerated video playback shouldn't depend on libva (as it currently appears to be), right? I could manage without HW decoding but without any video playback ability, I'd have to stick to 24.0.64 or possibly downgrade to F27.

Maybe the best solution to accommodate the greatest number of users would be to migrate the dev environment to Ubuntu 18.04 LTS.

[Hendrik]

The problem is that those libraries are directly linked to the ffmpeg libraries, so if they are not present, they won't load at all, even if hardware decoding is not used. We're working on a solution to that.
In the meantime we've turned VA-API hardware decoding off for the next build.

[Awesome Donkey]

Maybe the best solution to accommodate the greatest number of users would be to migrate the dev environment to Ubuntu 18.04 LTS.

At this point, it's probably too late since I believe the Id runs Debian (custom version of it?) as its OS. They'd have to either redo all Ids out in the wild (which would require users to mail it in, then somebody would have to reinstall/reflash it, send it back, etc.) which would be very costly AND time consuming. That, and I believe JRiver wants a "stable" platform, which Debian provides. Another problem is Ubuntu for the Raspberry Pi. Unless I'm mistaken, only a version of Ubuntu (using MATE?) is available. They would literally have to create a new Id (something like an Id 2 or something like that) if they wanted to make that change. It's all very costly no matter how you look at it.

It seems to me, it's "damned if you do, damned if you don't". Will be interested to see how it progresses though. Maybe there's a way around it, e.g. use libva2 only for "newer" distros while libva1-only distros have some sort of fallback. But this might be a problem too, as it might requiring cutting a build for a libva1 distro like Debian Jessie and another one for a libva2 distro like Ubuntu 18.04. Which adds more time to build, likely requires separate repositories, etc.

How do players like VLC and SMPlayer pull it off on different distros?