Emby still doesn't show the CD02 files, but it does list all the CD01 files. and Filename_CD02 - (then re-indexing/scanning) makes no difference. I did some quick tests this past hour with a small sample library like the one I gave earlier. I find this very weird indeed.Īny idea why this is happening? Why would it not be indexing half of the files in a folder? And hence, not showing them in the remote apps? I have tried all the sorting and filtering options, but it doesn't change the listed movie files. Yet, when I look at the Emby app (Win or Android or IoS) and look through my library (connected successfully to my Emby server, etc.) and navigate to the folder that contains my movies, it only shows the files with the "_CD1_" filename in them and doesn't show the 2nd-half files. I just want to index my movies on my hard-drive so I can see them away from the PC. I haven't chosen any advanced Library options like get metadata, or make frame captures, or find trailers, etc. SHA1 (patch-src_common_locale.I have a bunch of movie files on my hard-drive that are split into two parts, so the first half of the movie is file-named as "FilenameABC_CD1_MP4.mp4" and the second half is called "FilenameABC_CD2_MP4.mp4".Īll these pairs of files are in one folder, which is in the folder path that Emby is indexing for my library. Multimedia/mkvtoolnix/distinfo | 10 +++++-Ģ files changed, 7 insertions(+), 7 deletions(-)ĭiff -r 109041b07572 -r d9679f5cea9b multimedia/mkvtoolnix/Makefile * Qt 5.4.0 or newer has required (up from 5.3.0) since version 30.0.0 I just * MKVToolNix GUI: multiplexer: the GUI did not clean up temporary files
* MKVToolNix GUI: multiplexer, chapter editor: fixed drag & drop handling with The difference between the current and the following entry. * mkvmerge: text subtitles: entries with an explicit duration of 0ms will nowīe handled correctly: the 0ms duration will be stored in Matroska instead of * mkvmerge: MP4 reader: edit lists consisting solely of elements that mkvmergeĭoesn't support (such as dwells) are simply ignored. To the height of the full frame instead of the height of a single interlaced * mkvmerge: HEVC: the height of interlaced streams will now be set correctly * mkvmerge: AVI reader: using DV type 1 AVIs will now result in an unsupportedįile type being reported (as the underlying AVI library doesn't support * MKVToolNix GUI: multiplexer: the dialog previewing different character setsįor text subtitles will now keep the position of the displayed text when Just an intermediate result to be processed further. Queues when the output by mkvmerge/mkvextract isn't the final product but
The reason is that automatic flushing causes long delays in processing Programs (-flush-on-close) that re-enables flushing for people who areĪffected by data loss such as described in 2469. Reverts the workaround implemented for 2469. * mkvmerge, mkvextract: when closing files that were opened for writing,Ĭached data will not be flushed to storage automatically anymore. Program to abort after it has emitted the first warning, similar to how it * all programs: added a new option -abort-on-warnings that will cause the
0 kommentar(er)
