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.
Request Type:
