MCEBuddy Version and Type (32bit or 64bit):
MCEBuddy 64bit; 2.4 beta May 25 & previous May beta)
Operating System and Type (32bit or 64bit):
Windows 10 64bit; version 1803
Summary of the problem or suggestion:
Files generated using the MKV Unprocessed profile will not open, thumbnails do not show in File Explorer.
The exported files generated from MCEBuddy (beta version(s) before May worked fine) will not open/transcode in Aâs Video Converter and result in a crash of AâsVC.
Taking the exported MCEBuddy video(s) and re-wrapping them in MKV using XMedia Recode produces output that processes fine in Aâs Video Converter.
Reverting to April build fixes the issue.
Steps to replicate the bug:
WTV files - SDi, HDi/p (720p and 1080i) âconvertedâ by MCEBuddy (last 2 beta versions) using the MKV Unprocessed profile will can not be properly read/processed by Aâs Video Converter, and thumbnails do not show in explorer.
Screenshots:
The mkv files generated by MCEBuddy and the re-wrapped mkv file created by Xmedia Recode have been uplpaded to your ftp server in the john_freiman folder
I am including exported Media Info for one file in both the original MCEB and XMedia file(s). as well as the logs I have since the update to the May 28 beta build (I was going to send the previous May logs, but they deleted after I uninstalled the software and reinstalled the previous build).mceduddy 2.4 May 25 Logs & MediaInfo export.zip (1.2 MB)
PS. I was going to report this issue with the first May beta build, but to determine if this was an MCB issue or a config issue, I went back to the April beta and then discovered that all my log files were deleted with the uninstall/re-install.
Before reverting back to as April build again, I replaced the included MKVTools (Merge & Extract) (v17) with the latest v23 build to see if that âfixesâ the above problem â Iâll report back after I record a new program/show.
update: switching the MKVmerge (C:\Program Files\MCEBuddy2x\mkvmerge) file(s) to the latest MKVTools version did not fix/resolve the problem.
Files created using the May beta builds of MCEBuddy still can not be opened by Aâs Video Converter.
Iâm switching back to MCEBuddy 2.4.9 64bit - 20180421 until some solution, fix, workaround or âtryâ is available.
** One of the things that I think is new with the May builds are changes that benefit Ceton ETH users (like me).
I noticed the change to order ffmpeg / copy and viceversa, made that change and still had the same issue â I deleted the âcopyâ option.
I did not however I did not notice the ffmpeg-ext=.ts / remuxto=âŚ. changes.
I will make that change and see if it fixes my the issue.
Thanks.
This is whatâs working (Arpril 21 build)
[MKV Unprocessed]
Description=Very fast but limited functionality. Use this profile if you want to copy the original audio and video tracks, remove the commercials and convert the file format to MKV (e.g. WTV to MKV) without any additional processing (deinterlacing, resizing, volume, cropping etc). The original video can be in any format, MPEG1, MPEG2 or MPEG4/H.264, it will be retained unaltered.
order=ffmpeg,copy
copy-ext=.ts
copy-remuxto=.mkv
copy-audiodelay=skip
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec copy -map 0:v -sn
ffmpeg-audio=-acodec copy -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a
ffmpeg-ext=.mkv
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
FixedResolution=true
SkipCropping=true
AutoDeinterlace=false
DisableEncoderReordering=true
instead of uninstalling the April build, and then installing the May build(s), can I just replace the profiles.conf file?
Also I have a âcustomâ header for two unique profiles to pass through video and only mux the audio â Is there a way to preserve this heading through re-installs? or is cutting and pasting them back into each new build the only way to keep them?
The only way to keep the custom profiles is to setup a separtely profiles.conf and point MCEBuddy to it from the system settings page. This way it will always use the custom file.
For getting to the bottom of this would be good to isolate the real issue.
Does your above profile work with the latest build?
re: custom profiles: got it, but then I will never see the updated profiles.conf you update with newer settings/options. (but then I also wonât have compatibility issues either.)
Iâve just installed the May 25 build clean. Iâm backing up both the profiles.conf and mcebuddy.conf and will try your suggestions â including using the April .conf files.
Same issue after making the above changes to the MKV Unprocessed profile
[MKV Unprocessed]
Description=Very fast but limited functionality. Use this profile if you want to copy the original audio and video tracks, remove the commercials and convert the file format to MKV (e.g. WTV to MKV) without any additional processing (deinterlacing, resizing, volume, cropping etc). The original video can be in any format, MPEG1, MPEG2 or MPEG4/H.264, it will be retained unaltered. order=ffmpeg,copy
copy-ext=.ts
copy-remuxto=.mkv
copy-audiodelay=skip
ffmpeg-general=-threads 0
ffmpeg-video=-ss 0 -vcodec copy -map 0:v -sn
ffmpeg-audio=-acodec copy -map 0:a
ffmpeg-audioac3=-acodec copy -map 0:a ffmpeg-ext=.ts ffmpeg-remuxto=.mkv
ffmpeg-audiodelay=skip
PreConversionCommercialRemover=true
FixedResolution=true
SkipCropping=true
AutoDeinterlace=false
DisableEncoderReordering=true
Thumbnail is no longer visible (only shows format icon) and Aâs Video Converter can not process the file.
The issue from the profile is that MKVMerge is creating files that your setup doesnât like where as ffmpeg is working.
This change was done since Samsung TVâs werenât playing back files created by ffmpeg but were able to play files created by MKVMerge.
As you can see no one solution fits all needs, but we will likely revert this change back since there are other apps which also have an issue with MKVMerge and weâll make a FAQ for the Samsung TV issue.
So this problem remained through the 2.4.9 beta builds and continues with .10 as well.
The âwork aroundâ I found was to change the conversion task to .TS Unprocessed.
That was fine, but 2.4.9 builds using MKV Unprocessed for the final output to my TV Collection folder(s) containing HEVC/.265 video would not seek, scan or resume playback in Plex and werenât able to OPEN using VLC (on Windows) â Microsoft Movies & TV player would play, but also shared playback the issues with Plex - no seeking, ff, etc.
So I âupgradedâ to the latest .10 beta and Aâs still can not read/convert MKV created with MCEBuddy, it can work with the same files in TS format (MCEBuddy MKV (any version) re-muxed with MKVToolNix are ok).
The mkv files created by MCEBuddy play, scan, resume perfectly in Plex and play in VLC too!
However, the .10 version of Plex WILL NOT correctly match my TV files to TheTVdb, IMDB, etc. For files with âtitle sXXeXX episode titleâ they will be placed into the correct folder, but files such as âtitle sXXeXXâ NEVER are looked up and updated with episode title or placed in the proper folder. Instead they placed in their own separate folders.
title sXXeX1\Season 0\s00e00 -.mkv
title sXXeX2\Season 0\s00e00 -.mkv
title sXXeX3\Season 0\s00e00 -.mkv
etcâŚ
Itâs more than a little maddening and makes it impossible to reprocess all my HEVC seasons already stored by MCEBuddy.
Is there a change I can make to MCEBuddy 2.4.9 to have it generate playable x265 MKV videos?
I am getting tired of new issues with each update and would be happy to STOP the cycle and, once again, have a reliable system to organize my files.
Before upgrading from âMCEBuddy 2.4.9 64bit - 20180920â (later versions had the same or similar issues) I did backup the Program Files folder, so I do have access to the old log files and new log files.
I would also recommend using todayâs 2.4.10 BETA build. We have a new version of ffmpeg. Possibly may have fixed your ffmpeg profile issues and also a few fixes related to metadata matching.
If youâre still facing an issue please attach your conversion log with the 2.4.10 BETA run so I can see whatâs going on. Also if you can upload the original file to the MCEBuddy server which has an issue with the MKV Unprocessed profile to our server then I can replicate the issue and deep dive into it otherwise itâll be harder to pin down whatâs going on.