More > JRiver Media Center 21 for Linux
JRiver Media Center 21.0.88 for Debian
bob:
--- Quote from: mwillems on June 20, 2016, 09:44:41 pm ---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).
--- End quote ---
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:
--- Quote from: bob on June 21, 2016, 12:20:48 pm ---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?
--- End quote ---
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:
--- Quote from: mwillems on June 21, 2016, 05:38:33 pm ---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.
--- End quote ---
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:
--- Quote from: bob on June 23, 2016, 01:08:01 pm ---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?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version