Print

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

[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]

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.

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]

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.

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.

As for playing from the file association, can you test playing the same file from the command line with MC?

.mp4's appear to exhibit the same behavior when played from the command line (I only tested a couple though).

[bob]

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.

.mp4's appear to exhibit the same behavior when played from the command line (I only tested a couple though).

Thanks for checking.
Is there anything interesting about the path name? Spaces, quotes (single or double)? I'm wondering if JRWorker is parsing them properly.
Can you tell me what's in MC's compression field on one of the files on a windows PC?

[mwillems]

Thanks for checking.
Is there anything interesting about the path name? Spaces, quotes (single or double)? I'm wondering if JRWorker is parsing them properly.
Can you tell me what's in MC's compression field on one of the files on a windows PC?

All of the paths have spaces, but no other special characters.  The compression is .mp4 video (video: h264, audio: aac)

I think I might have a datapoint; as noted above, the issue only seems to occur when the file is scooped up by a in-the-background auto-import.  If I disable auto-import in the background and manually run an import, they come in as video files correctly, etc.  I just managed to reproduce the same behavior with an .mkv file, here's how:

I use makemkv to rip some things; previously, when I ripped something targeting a "watched" directory, MC's auto-import wouldn't "see" the file until makemkv had finished writing the file.  This time, MC picked up the partially written .mkv and imported it before it was done, but imported it with media type "Data." 

In the case of the .mp4's, though, they're recorded in an unwatched directory, and I'm just copying them over to the watched directories, but MC is still potentially grabbing them "midstream."  So I can't just "work around" it except by disabling background auto-import altogether.

So the desktop integration issue (which is local to .mp4s) is potentially unrelated.

[bob]

All of the paths have spaces, but no other special characters.  The compression is .mp4 video (video: h264, audio: aac)

I think I might have a datapoint; as noted above, the issue only seems to occur when the file is scooped up by a in-the-background auto-import.  If I disable auto-import in the background and manually run an import, they come in as video files correctly, etc.  I just managed to reproduce the same behavior with an .mkv file, here's how:

I use makemkv to rip some things; previously, when I ripped something targeting a "watched" directory, MC's auto-import wouldn't "see" the file until makemkv had finished writing the file.  This time, MC picked up the partially written .mkv and imported it before it was done, but imported it with media type "Data." 

In the case of the .mp4's, though, they're recorded in an unwatched directory, and I'm just copying them over to the watched directories, but MC is still potentially grabbing them "midstream."  So I can't just "work around" it except by disabling background auto-import altogether.

So the desktop integration issue (which is local to .mp4s) is potentially unrelated.

The code looks good there from what we can see so far however if the file is being added to a CIFS filesystem or it's taking longer than 5 minutes to copy to the drive there may be an issue.
Are either of these the case?

[mwillems]

The code looks good there from what we can see so far however if the file is being added to a CIFS filesystem or it's taking longer than 5 minutes to copy to the drive there may be an issue.
Are either of these the case?

Neither one should be the case; the files are large (multiple GB each), but the move shouldn't take more than five minutes (in fact with the filesystem I'm using a pure copy with the right options is effectively instantaneous).  The copying is being done from one directory on a local drive to another directory on a local drive.  The filesystem in question is a btrfs filesystem, but btrfs supports inotify and the auto-import process seems to work fine for audio and for other video file types.  The only difference (apart from the file type) is that I'm (usually) moving these files via script rather than by hand.  

The script just moves files and changes permissions, so should be harmless, but let me look at my script and see if there's something in there that's breaking things.

[captainkurt]

I'm trying to enter my new recently purchased within 5 days Linux reg code for a QNAP NAS running 21.0.83 and it shows invalid. Also shows 9 left because I tried it on my Windows PC.
Shouldn't it auto register when purchased from wthin MC?
Please help.

[JimH]

It should.  There is a QNAP thread here.

[mwillems]

The code looks good there from what we can see so far however if the file is being added to a CIFS filesystem or it's taking longer than 5 minutes to copy to the drive there may be an issue.
Are either of these the case?

So I did some more testing on this, and it seems pretty unpredictable.  Some nights the files get imported correctly as video files; some nights they get imported as data files.  The only predictable factor is that on nights when they import correctly, they all import correctly; on nights when they come in as data files, they all come in as data files.  Other than that there seems to be no predictable pattern to when they come in one way versus the other (they're all .mp4s generated in the same way, they all get moved into the same watched directory, etc.).  I managed to reproduce it with a few other video file types, so it doesn't seem limited to .mp4 files, but it does seem limited to video files (I've imported quite a lot of audio files and none of them have exhibited this behavior).

With respect to the "taking longer than 5 minutes to copy," what's the exact trigger that would cause that?  Most of the files exhibiting the behavior are just a few GB, and the behavior doesn't seem linked to time to transfer in my case (I've seen files moved into the watched directories in 3 seconds come in as data files).  

It looks like some other folks are seeing something similar on the Mac build, so this may be a broader issue:
https://yabb.jriver.com/interact/index.php?topic=105819.0
https://yabb.jriver.com/interact/index.php?topic=105760.msg735986#msg735986

In any case, manually running import seems to work, so I guess I can just turn off auto-import until this gets sorted.  Let me know if I can do any additional testing.

[bob]

So I did some more testing on this, and it seems pretty unpredictable.  Some nights the files get imported correctly as video files; some nights they get imported as data files.  The only predictable factor is that on nights when they import correctly, they all import correctly; on nights when they come in as data files, they all come in as data files.  Other than that there seems to be no predictable pattern to when they come in one way versus the other (they're all .mp4s generated in the same way, they all get moved into the same watched directory, etc.).  I managed to reproduce it with a few other video file types, so it doesn't seem limited to .mp4 files, but it does seem limited to video files (I've imported quite a lot of audio files and none of them have exhibited this behavior).

With respect to the "taking longer than 5 minutes to copy," what's the exact trigger that would cause that?  Most of the files exhibiting the behavior are just a few GB, and the behavior doesn't seem linked to time to transfer in my case (I've seen files moved into the watched directories in 3 seconds come in as data files).  

It looks like some other folks are seeing something similar on the Mac build, so this may be a broader issue:
https://yabb.jriver.com/interact/index.php?topic=105819.0
https://yabb.jriver.com/interact/index.php?topic=105760.msg735986#msg735986

In any case, manually running import seems to work, so I guess I can just turn off auto-import until this gets sorted.  Let me know if I can do any additional testing.

It looks like we have tracked this one down. New build later today...

[mwillems]

It looks like we have tracked this one down. New build later today...

Just a gentle nudge; would love to have a build to resolve the video files importing as data files issue.

[JimH]

Bob went to Canada for a few days.  I think he will be back tomorrow.

[mwillems]

Bob went to Canada for a few days.  I think he will be back tomorrow.

Got it.  Hopefully he's there for some well deserved vacation