Missing info in recorded file when converting from WMC recordings to HdHomeRun format

I am using the HDHomeRun Unprocessed profile to convert windows WTV files to MPG files for use in the HDHomeRun viewer (HDHRV). There appears to be data missing in the MPG file

  • The WTV Description Tag field is not transferred to the converted MPG file. I can see the description tag in the WTV file but not in the converted mpg file. Using Jriver, I am able to copy the WTV description tag and paste it into the MPG description (so I have a workaround) but it is slowing my conversion process down. After doing this manual step I can see the description in HDHRV and JRiver.

  • When I view a converted file in the HDHRV, the progress bar at the bottom of the viewer does not show any progress as I play the program, even when I skip ahead using the right arrow or up arrow. When I exit the program in the middle of viewing, the shows listing page (list by channel, episode name, episode, and recorded columns), does not show any progress meaning I have to manually skip ahead to get back to the place where I exited the viewer when I re-select the program. I can see progress bar changes in other viewers (JRiver, PowerDVD and Windows Media Player) but not in the HDHRV. I’m sure that SiliconDust will say this is an MCEBuddy issue and I’m hoping that MCEBuddy can offer a fix so I’m not caught in the middle…

Are there some settings I am missing? the following are my profiles:

[Smash In]
SearchPath=E:\Smash\In
SearchPattern=*.wtv
SearchPathExclude=
DeleteMonitorOriginal=False
ArchiveMonitorOriginal=True
ArchiveMonitorPath=E:\Smash\In\Archive
MonitorSubdirectories=True
MonitorConvertedFiles=False
ReMonitorRecordedFiles=False
MinimumAge=1
DomainName=
UserName=

[Smash]
Profile=HDHomeRun Unprocessed
DestinationPath=E:\Smash\Out
WorkingPath=
FallbackDestination=False
CheckReprocessingHistory=False
AddToiTunesLibrary=False
AddToWMPLibrary=False
AutoIncrementFilename=False
SkipReprocessing=False
MaxWidth=1920
FPS=
VolumeMultiplier=0
QualityMultiplier=1
RenameBySeries=True
AltRenameBySeries=False
CustomRenameBySeries=%showname% S%season%E%episode% %airyear%%airmonth%%airday% %recordyear%%recordmonth%%recordday%-%recordhour%%recordminute%
RenameOnly=False
DownloadSeriesDetails=True
DownloadBanner=True
ForceFilenameMetadata=False
OverwriteMetadataInternet=Default
FileSelection=*smash*
MetaSelection=
MetaChannelSelection=
MonitorTaskNames=Smash In
DRC=False
AudioLanguage=
AudioOffset=0
InsertQueueTop=False
ExtractXML=True
WriteMetadata=True
AutoDeInterlace=True
PreferHardwareEncoding=True
StereoAudio=True
EncoderSelectBestAudioTrack=True
DisableCropping=True
StartTrim=0
EndTrim=0
ExtractCC=default
CCOffset=0
EmbedSubtitles=False
EmbedChapters=False
ExtractAdsFromChapters=True
TaskCommercialSkipCut=False
KeepAdvertisements=False
PrioritizeOriginalBroadcastDateMatch=False
SkipCopyBackup=False
SkipRemux=False
IgnoreCopyProtection=False
TiVOMAKKey=
Enabled=True
ForceShowType=Default
MetaShowTypeSelection=Default
MetaCodecSelection=Any
MetaDRMTypeSelection=All
FileSizeCompareType=LessThan
FileSizeThreshold=0
VideoBitrateCompareType=LessThan
VideoBitrateThreshold=0
CommercialRemoval=Comskip
ComskipINI=
DomainName=
UserName=
MetaCorrectionsCount=0

Can you attach your conversion log that will show what’s going on. HDHR has a proprietary metadata format that it uses. We’ve worked with them to incorporate as much of it as possible into MCEBuddy. However certain features in the format are unique to HDHR so if you’re using a HDHR recording to being with, all the metadata features are preserved. However when moving a non HDHR format to HDHR format some of that metadata is mocked up since it doesn’t exist and it’s assigned by HDHR when it’s recorded. However description isn’t one of those.

Your conversion log will shed more light on it.

Description field is apparently not used by HDHR viewer. Other converted recordings showed up fine even without description tag. I’ll experiment more but description tag missing is not the main problem. Sorry for the false alarm on that. :frowning:

Unfortunately that still leaves the matter of the recording progress not present while viewing (or preserved when exiting). I’m assuming that there is some sort of “marker” in the HDHR proprietary recording format that is not mocked up in the converted file. Would log files help for this issue? Should I close this issue as solved and open another thread for the recording progress?

Are you trying to convert a file file it’s being recorded? You’re converting WTV to MPG so I’m trying to understand what exactly you’re referring to here.

No… Sorry for the confusion. I’m trying to describe the progress bar during playback of a converted file in the HDHR viewer.

The first screen snippet shows the HDHR viewer with the progress bar (outlined in orange) for a Smash episode I recorded in 2012 on WMC and converted to mpg using MCEBuddy. Note that there is no progress indicated even though half way through playback.

This next snip shows a progress bar from a Signed, Sealed, Delivered episode recorded last year via HDHR. Note the progress bar outlined in orange contains a green portion which shows how much playback has occurred (about 25%).

If you exit the “Signed, Sealed, Delivered” playback at this point to go back to the episodes screen, you see the playback progress has been preserved (outlined in orange). If you would re-enter playback (via clicking on the episode), the viewer would jump 25% into the program so you’d continue from where you left off.

However, the episodes screen for the above Smash recording (the converted file) shows no progress even though the playback was stopped mid-way through. This means when you re-enter the program, you always start at the beginning and must skip forward to find where you left off.

I hope the above clarifies. I get interrupted frequently and would like the ability to resume playback if at all possible.

Can you upload a sample of the WTV to MPG converted file AND the copy of the file which has the playback marker to our server to analysis.

Instructions here:

Should I use splitter on both?

Do you need entire “good” file or should I use splitter?

Just the first 50MB of each file

ok - file chunks are uploaded. Sent private message with details.

1 Like

@Goose I determined that SeriesID and ProgramID metadata dictionary keys have meanings in some scenarios and therefore should not be set to static values (as coded in MCEBuddy 2.5.1 64bit - 20190717 and as we had discussed in private messages). The values set in version 2.4.11 code work fine (I think they are extracted from the source WTV file). All the following examples were created using version 2.4.11 for conversions together with some code I wrote to make metadata changes after the conversions were complete.

To make the resume function work correctly (which was the original intent of this thread), it is only necessary set the following metadata values (where seconds is a value for the length of the recorded program in seconds). In all the metadata I looked at, StartTime and RecordStartTime were already set correctly in the metadata…

  • EndTime = (StartTime + seconds)
  • RecordEndTime = (RecordStartTime + seconds)
  • Resume = 0

With the above, the resume functionality works perfectly and persists across views. The following shows converted WMC files with resume persistence (version of viewer changed and so it looks a bit different than earlier posts).

  • The Nominations episode shows a few seconds have been watched
  • The Transfer episode shows viewing stopped half way through
  • The Producers episode was completely viewed
  • All other episodes have not been watched.

Attaching images to recordings is also possible but tricky. I had previously posted (via private email) that a Smash episode was not appearing after a 2.5.1 BETA conversion. In addition, I subsequently discovered all the episodes of “Inside the Actors Studio” converted with 2.5.1 had disappeared. These random issues plagued me for a week until I stumbled on the underlying reason by accident.

Turns out that the ImageURL and PosterURL metadata inserted by the 2.5.1 Beta version pointed to large jpg images. For example some I checked were 680 x 1000 pixels or larger. I cannot be sure but suspect that internally the HDHR code (viewer or recorder - not sure which) was running out of buffer space, throwing exceptions, and thus “poisoning” episodes so it appeared they were not there. All these episodes reappeared when the following steps were taken.

  1. ImageURL and PosterURL metadata were updated to point to smaller jpg files
  2. HDHomeRun RECORDER service was stopped and restarted

With this discovery, and the ability to make metadata changes, the power of the viewer became apparent and I was able to do some very cool things. For example, “The Capitol Fourth” is a once per year special of the concert and fireworks in DC on July 4th. It is marked as “Category”: “special” in the metadata. With appropriate metadata changes, these yearly programs now look like a series rather than many separate specials (ignoring the contrived Season/Episode values which for example consist of the year 2019 converted to S20E19). Incidentally, the 2017-2019 were recorded with HDHR recorder. 2016 and earlier recordings were converted WTV files using MCEBuddy 2.4.1 but you can’t tell by looking at the following…

I’d like to see the following in the next release

  1. Incorporate the resume functionality as outline above. It seems simple and should be easy to implement.
  2. Provide capability to attach images to the converted files. If a suitable URL cannot be found programmatically at conversion time, place appropriate notations in the log file (perhaps with instructions on running a utility with a reference to an appropriate jpg file) and leave the ImageURL and PosterURL metadata set to null. The following sizes are used by the HDHR engine so I’m assuming these are the “recommended” sizes
  • ImageURL jpg reference to file 360 x 270 pixels or less
  • PosterURL jpg reference to file 240 x 360 pixels or less.

Contact me if you need additional information.

1 Like

I would suggest reporting this to HDHR also (we have also reported it since it’s a potential security issue). The firmware should just ignore oversized images. Will see how to handle this in MCEBuddy for now since the images are coming from the internet and we don’t always have a smaller image URL. For now we won’t populate that information. FYR, a simple fix is to uncheck the option to download the poster in the Conversion Task -> Expert Settings -> Metadata correction page. Once HDHR fixes the firmware, we’ll resume adding the image URL’s to the metadata.

You can try the latest 2.5.1 BETA version with these changes.

I’m using MCEBuddy 2.5.1 64bit - 20190723 and it preserves the metadata identically when removing commercials from a HDHR recording . However, in order to not break the progress indicator functionality, at least the RecordEndTime should change.

In a recent conversion, 33 minutes of commercials were removed from a 2 hour movie. Consequently, the playback progress indicator was showing only 3/4 progress when the converted movie only had seconds left to play. Experimented and determined that if RecordEndTime metadata is set to RecordStartTime + secondsOfConvertedMpg, then the playback progress indicator moves as expected from far left (at start of movie) to far right (as movie is ending). No other changes were made to metadata.

1 Like

Whats the best way to report these types of bugs? Is there a “bugs” reporting forum like the MCEBuddy bug forum?

Fixed in the next beta build