More > JRiver Media Center 21 for Linux
JRiver Media Center 21.0.88 for Debian
bob:
The latest build is up at:
http://files.jriver.com/mediacenter/channels/v21/latest/MediaCenter-21.0.88.deb (also in the latest apt repository)
21.0.88 (6/10/2016)
1. Fixed: Folder watching broken in builds >21.0.83
2. Fixed: Network reads, broken in the 21.0.85 fix for segfaults.
3. NEW: Handle data files using xdg-open
21.0.85 (5/27/2016)
1. Fixed: The cifs detect in 21.0.83 was incomplete in that it couldn't handle spaces and ' in filepaths.
2. Fixed: A longstanding bug causing segfaults during network reads that mainly manifested itself when DLNA devices that disappeared during the tree update.
21.0.83 (5/20/2016)
1. Fixed: Linux detect cifs filesystems for timer supported auto imports
21.0.76 (4/29/2016)
1. Changed: Timing on DLNA M-SEARCH and NOTIFY to make the finding of DLNA devices quicker.
21.0.70 (4/12/2017)
1. Changed: Use the clipboard for copy/paste instead of the cut buffers. Works better with other apps. Only implemented for text so far. Working on images...
21.0.63 (3/21/2016)
1. Fixed: Revert change from 21.0.54 that resulted in extra calls to get the volume of DLNA devices which could make the GUI sluggish on renderers that respond slowly.
2. Fixed: Cover art bug that caused crashes.
21.0.61 (3/18/2016)
1. Changed: The Media Center window class name had spaces which are changed to underscores to try and fix bugs with some desktop managers (i.e. Unity).
2. NEW: If a browsercmd file exists in the users .jriver/Media Center 21/ directory, it will be executed (with one arg) in place of xdg-open when a browser is needed.
3. Changed: Implemented the email function in the send-to menu.
4. NEW: Use the XDG designated directories for media and documents (if they exist).
5. NEW: Upload to web gallery (pix01) implemented.
6. Fixed: The Help->About box.
7. NEW: If a .emailcmd file exists in the users .jriver/Media Center 21/ directory, it will be executed (with one arg) in place of xdg-email when a MC is used to send an email.
21.0.54 (3/4/2016)
Changes from the main branch. Should be considered for stable repo but is in latest for now.
21.0.51 (2/26/2016)
1) More work on eliminating hard killed threads. Needs testing for stability.
2) More complete deletion of dynamic servers and zones when those functions are executed.
21.0.48 (2/15/2016)
1. NEW: Software Deinterlacing using the YADIF algorithm during video playback and transcoding.
2. Changed: Many internal changes to remove thread killing on stuck threads. Should eliminate segfaults, might cause hangs. Need feedback.
3. NEW: Added switches under Media Network to disable disk buffering of audio and video files when the content is being received for rendering. This is intended for low power/sdcard based machines.
21.0.39 (1/25/2016)
1. Fixed: Bug in calculating the offset from UTC.
2. Changed: MC linux will download the mp3 encoder instead of using the system mp3 encoder.
3. Fixed: Allocation of some files failed on linux when the filesystem didn't support fallocate(). Affected Thumbnails at the very least.
4. Fixed: ARM System Identification.
5. Changed: deb packaging and post-install to integrate MC more into Unity (and probably other desktops).
See the windows 21 log for general non-linux related changes.
21.0.37 (1/15/2016)
Changes from the main branch
21.0.28 (12/17/2015)
1. Fixed: Potential worker thread hang in CListener class, also a potential memory leak.
2. Fixed: Fixed potential hangs/crashes and memory leaks in networking code.
21.0.23 (11/23/2015)
1. Fixed: Memory leak bug introduced in 20.0.123. More apparent if there are lots of windows (from any application) open at once.
2. New: The internal function that provides the OS information to MC is now functional. This fixed a bug in Noire where the window action buttons could have been windows 10 lookalikes.
3. Changed: Internal event handling.
21.0.16 (10/16/2015)
1. Fixed: Thumbnail creation for Videos would often crash JRWorker.
2. Fixed: The TVInfo Expression did not work.
3. Fixed: Change in eventing fixes maximize button on ARM, possibly other subtle changes.
21.0.7 (9/15/2015)
1. NEW: Support for external sidecar subtitles.
2. NEW: Automatic stream selection based on the preferred languages configured in Video -> Subtitles & Languages.
3. Changed: Improved font metrics handling of descents on letters like "g" or "j".
4. Fixed: Leaving fullscreen mode (ie when playing video fullscreen) returns MC to the state is was in before entering fullscreen mode.
5. Fixed: MC behavior with multiple monitors (xrandr) and fullscreen mode. Still needs a bit more work to fully support multiple monitors.
6: Changed: MC will print an error message (to stderr) when unable to open the X display instead of segfaulting.
7. Fixed: The cursor will be hidden in fullscreen mode.
8. Changed: The custom Data is used from the users MC resource area instead of from MC's app library area.
21.0.6 (9/4/2015)
1. Fixed: Issue with crashes when closing the tree during playback when the cover art is displaying in the action window. This could possibly help with other sizing issues.
2. Changed: Skins are copied into the users MC resource area from MC's app library area upon updating to this build and are used from there going forward so they can be modified without requiring root permissions.
21.0.5 (9/1/2015)
1. Changed: Added graphical confirmation of the license installation through the file association.
21.0.4 (8/14/2015)
1. Fixed: The "View Current Log" button on the logging dialog wasn't working.
2. Fixed: Exporting a playlist to HTML didn't open a browser to view the playlist properly.
3. Fixed: Viewing the html of a gallery in preview mode didn't open a browser properly to view the preview.
4. Changed: Internal, method of running an external command.
5. Fixed: Can purchase an upgrade via the usual method (install MC 20 license on MC 21 and follow the instructions).
21.0.3 (8/10/2015)
1. NEW: Improved font support.
2. Fixed: Trial period was broken.
21.0.2 (8/7/2015)
1. NEW: Subtitle Support during Video Playback.
2. Changed: Windows redraw better.
3. NEW: Image support. 2D viewing effects only at this time.
mwillems:
xdg-open is working like a champ! Thanks bob!
mwillems:
So I'm seeing some weird behavior with auto-import (it's been going on for a few builds, but I hadn't noticed it because folder watch was broken).
When JRiver for Linux auto-imports an .mp4 file, it is labelling it as data instead of video, which means it gets misfiled under data files instead of video, and MC doesn't get movie and TV info, etc. If I run the auto-import manually instead the exact same files import correctly as video files. Attempts to apply tags on import based on directory don't change the behavior, and .mp4 is not listed as a data file type for auto-import.
This only seems to apply to .mp4's and no other files. I've observed with both the 64 bit and 32 bit builds on Debian Jessie.
A potentially related issue: if I open an .mp4 file from within JRiver (i.e. an .mp4 that's in the library), it plays perfectly. I have JRiver set as my file association for video files in Linux. If I go to my file manager (nautilus or thunar) and double click on an .mp4 file that hasn't been imported into JRiver, a JRiver window opens up, adds the .mp4 file to the now playing playlist, shows a "busy" circle for a bit, but never plays the file. If I then try to start playback from within JRiver, it works, so there's nothing wrong with the file. This used to work a few months ago, although I'm not sure when the last time it worked was. Again, other video files (e.g. .mkv) appear to work normally (opening from file manager plays them).
I've observed this with 32-bit and 64-bit builds on both Debian and Arch.
bob:
--- Quote from: mwillems on June 19, 2016, 05:02:24 pm ---So I'm seeing some weird behavior with auto-import (it's been going on for a few builds, but I hadn't noticed it because folder watch was broken).
When JRiver for Linux auto-imports an .mp4 file, it is labelling it as data instead of video, which means it gets misfiled under data files instead of video, and MC doesn't get movie and TV info, etc. If I run the auto-import manually instead the exact same files import correctly as video files. Attempts to apply tags on import based on directory don't change the behavior, and .mp4 is not listed as a data file type for auto-import.
This only seems to apply to .mp4's and no other files. I've observed with both the 64 bit and 32 bit builds on Debian Jessie.
A potentially related issue: if I open an .mp4 file from within JRiver (i.e. an .mp4 that's in the library), it plays perfectly. I have JRiver set as my file association for video files in Linux. If I go to my file manager (nautilus or thunar) and double click on an .mp4 file that hasn't been imported into JRiver, a JRiver window opens up, adds the .mp4 file to the now playing playlist, shows a "busy" circle for a bit, but never plays the file. If I then try to start playback from within JRiver, it works, so there's nothing wrong with the file. This used to work a few months ago, although I'm not sure when the last time it worked was. Again, other video files (e.g. .mkv) appear to work normally (opening from file manager plays them).
I've observed this with 32-bit and 64-bit builds on both Debian and Arch.
--- End quote ---
Do you have a windows or Mac latest build you could try the same file on? I know there was some work in that area but it might be generic. The log should show info about the import as well.
As for playing from the file association, can you test playing the same file from the command line with MC?
mwillems:
--- Quote from: bob on June 20, 2016, 02:13:13 pm ---Do you have a windows or Mac latest build you could try the same file on? I know there was some work in that area but it might be generic. The log should show info about the import as well.
--- End quote ---
So I tested on Windows and .mp4's correctly import as video with auto-import, so it appears to be either linux-specific or at least non-windows. I have no macs to test, but there have been one or two threads on the mac board recently about .mp4 issues.
--- Quote ---As for playing from the file association, can you test playing the same file from the command line with MC?
--- End quote ---
.mp4's appear to exhibit the same behavior when played from the command line (I only tested a couple though).
Navigation
[0] Message Index
[#] Next page
Go to full version