I downloaded the source via the hyper-linked mcebuddy2x-35814.zip file. Installed VS2010. Applied the VS SP1. Searched the unzipped MCEBuddy source folders for the .sln file, opened it, set the build configuration to x64 release build. Attempted a build. 2 component build targets succeeded and 24 failed.
The first trouble was this one: error MSB3325: Cannot import the following key file: MCEBuddy2-HP.pfx. The key file may be password protected.
When I do a search among the source folders for that file, I get a list of a whole bunch of these, each in a separate sub folder. I checked the Windows Explorer file properties of one such file and the information there indicated I had full permissions and that I was the file's owner.
Q. Are there any steps or prerequisite tools or configuration items missing in your guide to developers for building the code on a clean install of Windows 7 SP1 that is not connected to the internet, but having various versions of the .NET framework installed and updated to early January 2014 levels?
When I copy and pasted the resulting build / compiler diagnostic messages into NotePad and saved them to builderrors.txt the file was 82 kbytes and 799 lines in size.
I had been using MCEBuddy 2.3 release 13 x64, but was having troubles with 4 hour long .mts mpeg-2 Dolby 5.1 AC3 1920x1080i files. There was no newer link to download release 14 in x64 to try it, so I thought that I could build a new version from the latest source code, trace the troubles and determine the remedy?
I had dragged and dropped a group of these 1080i HD files into the MCEBuddy client user interface window and the files were in the queue for quite a while. I went to bed, came back and the queue was empty, but no resulting output files were available.
I could not determine what happened during the processing by examining the MS Windows Application's log in the Event Viewer, and used Windows to search for MCEBuddy*.log off of the start menu, but it found nothing.
Also I had tried Comskip and it was working nicely on 720x480 SD .ts mpeg-2 files, but when processing HD, it didn't find any commercials to cut out and kept practically the entire video, so this time I repeatedly adjusted the MCEBuddy advanced settings (until they saved properly) so that the pixel dimensions max for the width were 720, mp4 conversion speed set to high, quality set to 90%, remove original files=yes.
My reasons for removal of the original files: The original files for each of the 4 hour capture files were 33,565,780,800 bytes in size. Two of those plus two 2 hour files plus one 2.5 hour files added up to a large amount of daily recordings that need to be down sized via processing to permit further shows to record.
The MCEBuddy client software should never reject configuration setting updates from the user so that the user must re-enter them 10+ times before they get saved. If this is an artificial barrier that was manifested by using some other organization's settings API, that choice has to be abandoned for practical, operational reasons.
Some mechanism should be invented to queue the settings updates if they are not accepted right away, instead, the client software, itself, wipes out all of the user-meticulously entered update information by closing up the open dialog screens instead of offering to retry saving (or whatever--automated retry for "30 minutes" or 48 hours or whatever until settings are accepted).
I tried at one point to extract video file closed captioning via check box, but this produced empty text files per each .mp4 file conversion. It seems that 2 English text streams are labeled in the source video files but the text data is interleaved into the one video stream. When closed captions are played back on the source OTA PVR, a Mediasonic Homeworx HW150pvr ATSC HD converter box, the closed captions come out fine.
The first trouble was this one: error MSB3325: Cannot import the following key file: MCEBuddy2-HP.pfx. The key file may be password protected.
When I do a search among the source folders for that file, I get a list of a whole bunch of these, each in a separate sub folder. I checked the Windows Explorer file properties of one such file and the information there indicated I had full permissions and that I was the file's owner.
Q. Are there any steps or prerequisite tools or configuration items missing in your guide to developers for building the code on a clean install of Windows 7 SP1 that is not connected to the internet, but having various versions of the .NET framework installed and updated to early January 2014 levels?
When I copy and pasted the resulting build / compiler diagnostic messages into NotePad and saved them to builderrors.txt the file was 82 kbytes and 799 lines in size.
I had been using MCEBuddy 2.3 release 13 x64, but was having troubles with 4 hour long .mts mpeg-2 Dolby 5.1 AC3 1920x1080i files. There was no newer link to download release 14 in x64 to try it, so I thought that I could build a new version from the latest source code, trace the troubles and determine the remedy?
I had dragged and dropped a group of these 1080i HD files into the MCEBuddy client user interface window and the files were in the queue for quite a while. I went to bed, came back and the queue was empty, but no resulting output files were available.
I could not determine what happened during the processing by examining the MS Windows Application's log in the Event Viewer, and used Windows to search for MCEBuddy*.log off of the start menu, but it found nothing.
Also I had tried Comskip and it was working nicely on 720x480 SD .ts mpeg-2 files, but when processing HD, it didn't find any commercials to cut out and kept practically the entire video, so this time I repeatedly adjusted the MCEBuddy advanced settings (until they saved properly) so that the pixel dimensions max for the width were 720, mp4 conversion speed set to high, quality set to 90%, remove original files=yes.
My reasons for removal of the original files: The original files for each of the 4 hour capture files were 33,565,780,800 bytes in size. Two of those plus two 2 hour files plus one 2.5 hour files added up to a large amount of daily recordings that need to be down sized via processing to permit further shows to record.
The MCEBuddy client software should never reject configuration setting updates from the user so that the user must re-enter them 10+ times before they get saved. If this is an artificial barrier that was manifested by using some other organization's settings API, that choice has to be abandoned for practical, operational reasons.
Some mechanism should be invented to queue the settings updates if they are not accepted right away, instead, the client software, itself, wipes out all of the user-meticulously entered update information by closing up the open dialog screens instead of offering to retry saving (or whatever--automated retry for "30 minutes" or 48 hours or whatever until settings are accepted).
I tried at one point to extract video file closed captioning via check box, but this produced empty text files per each .mp4 file conversion. It seems that 2 English text streams are labeled in the source video files but the text data is interleaved into the one video stream. When closed captions are played back on the source OTA PVR, a Mediasonic Homeworx HW150pvr ATSC HD converter box, the closed captions come out fine.