SiliconDust DVR Compatibility

#1
Since another program is now advertising compatibility with SiliconDust DVR files (i.e. can process the files to remove commercials and rename the files based on the embedded metadata all the while preserving this metadata and compatibility with the SD DVR software in the output) I was wondering if it would be possible to get an update as to if (and hopefully when) similar features will be added to VideoRedo. Thank you.
 

Dan203

Senior Developer
Staff member
#2
What other program? Open source or commercial?

We talked to SD about this a while back but never got any definitive info from them about the format they're using. In fact as far as I know the DVR isn't even available to the public yet, only people who backed the kickstarter.
 
#3
What other program? Open source or commercial?

We talked to SD about this a while back but never got any definitive info from them about the format they're using. In fact as far as I know the DVR isn't even available to the public yet, only people who backed the kickstarter.
The program is MCEBuddy. I don't know whether it is open source or commercial. In fact, I wouldn't know anything about it if it wasn't for all the press that it's now getting on the SD forum because of its new ability to successfully strip out commercials from SD DVR files without losing the metadata necessary to maintain compatibility with SD DVR clients.

I have access the the SD DVR as a Kickstarter supporter. The recording engine component has proven to be stable and works well on my system. Client software is still a work in progress. None of the clients are currently capable of playing back DRM content. The Kodi client works well on my system for non-DRM material. They released a preliminary Windows 10 Universal app client last month and are currently resolving issues with this client. They have stated that their initial Android/Android TV client will be released this month. Like the Windows 10 Client, I expect their will be many issues with this client that will need to be resolved over the next several months. I don't know the current status of the Mac of Plex clients. It seems that they release something to the Kickstarter supports; get a flurry of issues/bugs reported; work on resolving these issues; and then move onto the next item in the chain that will ultimately comprise their DVR system.

What is not well known is that, with development of the SD DVR running behind schedule, several months ago they began selling access to the SD DVR on their website for the same $60 that was initially required as part of the Kickstarter. So anyone who is willing to pay for it can not get access to the "pre-release" software and subsequent progress builds.

More important from the standpoint of VideoRedo, in response to questions, SD provided information about the format of the DVR files in their forum. I assume this is how the person/people who developed MCEBuddy figured out how to successfully process the files.

In any event, the files are in a TS container with an (?erroneous) mpg file extension. There is an initial header in the file that contains all the metadata and this header needs to be preserved for the processed file to be recognized by the recording engine (so that it doesn't rerecord the file) and the SD DVR clients.

Based on the messages from Nick on the SD forum, I can confirm that the following does work:
1) Extract the metadata from the original SD DVR file using the following batch command:
P:\HDHomeRun\MetaExtract\dd.exe if=%1 of="%~dpn1.meta" bs=12032 count=1
where %1 is the name of the original SD DVR recording
2) Process the original SD DVR file in VideoRedo to remove commercials. Save the file as an mpeg2 file with the same name as the original recording and a TS extension (this is how VideoRedo recognizes my original-recording file and the TS extension prevents overwriting the original recording file). I could probably also process this in VideoRedo to output an H.264 file since one of the DVR-supported SD recorders can output H.264 but I haven't tried this.
3) Concatenate the meta and TS files and rename back to mpg extension (at least the current version of the SD DVR software will not recognize files without the mpg extension). For this I use the following batch commands:

set "fileext=%~x1"
set "metafile=%~dpn1.meta"
set "procfile=%~dpn1%fileext%"
set "outfile=%~dpn1.cut.mpg
if exist "%metafile%" (
if exist "%procfile%" (
type "%metafile%" "%procfile%" > "%outfile%"
)
)

I can then delete the original file from the SD DVR folder and the processed file (in that same folder) is recognized and works fine by the SD DVR system.

Hopefully, VideoRedo will be able to accomplish the same things automatically at some point so that I can eliminate several steps and the 2 batch files that I'm currently using.

Edit: If you look at the extracted meta file in a text editor you can see the metadata fields that the SD DVR is using. I suspect this is how MCEBuddy is able to add the SxxExx information to the output filename (at least as reported on the SD forum, I've never used MCEBuddy).
 
Last edited:
#5
I would change
type "%metafile%" "%procfile%" > "%outfile%"
to
copy /b "%metafile%" + "%procfile%" "%outfile%"
A good suggestion and I've implemented it in my batch file. Thank you. However, my goal is to ultimately have these files processed by VideoRedo so that I can eliminate the need for the batch files.
 
#6
I've done some more testing and here are the results:

1)It doesn't matter in VideoRedo whether I output the processed file using the MPEG-2 TS profile or the H.264 TS profile. As long as I concatenate the SD DVR metadata to the beginning of the file, change the extension to mpg, and make sure that the file is located in the SD DVR folder, the SD software (recording engine and clients) will recognize and correctly handle the file. Converting the file to H.264 when processing it in VideoRedo, therefore allows me to save disk space.

2)The actual filename is irrelevant. I even tried renaming the file to test.mpg and it worked. As long as the file has an mpg extension and is located in the appropriate SD DVR directory, the SD DVR software will look for the metadata header and, if it finds it, will load the metadata into the DVR software and appropriately handle the file. This means that I can rename the processed file using a more conventional Title-SxxExx format that other programs (e.g. Kodi, Plex, etc.) prefer and these programs will then also appropriately recognize, categorize, and play the file, independent of the SD DVR software as long as editing/playback of the file are not DRM restricted.
 
#8
Can you upload a recording with the metadata attached for us? Is the metadata chunk always 12032 bytes? Or is there a header bit somewhere that tells it's size?
The metadata chunk is a constant 12032 bytes. It appears they left a lot of extra space in defining their file format since I haven't recorded anything yet whose metadata comes close to 12032 bytes. The rest of chunk is just left empty.

I'd be happy to upload a file for you but the smallest file I have is about 2 GB in size and I don't want to process it to trim most of the video for fear that my trimming will somehow change the file. If you want the full file, let me know how to send it to you since the link in your instructions won't accept a file of this size. Alternately, I could send you just the extracted metadata or the extracted first x amount of bytes of the file while will not be playable on your end but will show you the initial structure. Let me know what you want and I'll send it.
 
#9
I uploaded the first 24062 bytes of one of the files. It should be in a folder with this thread number. This is the complete metadata chunk plus the initial part of the actual video file. Let me know if you need something longer.
 
#11
Has there been any progress on retaining the metadata when editing HDHomeRun DVR recordings? I ran across some notes that I saved from the Silicondust forum a while back. Maybe this will help.

"Recordings are standard MPEG TS files. Metadata is stored on the first 64 TS packets on PID 0x1ffa, which should not cause problems for anything that can handle a TS, as software should just seek through the file until it finds a PAT on 0x0000 then proceed from there. If you preserve that data and transcode and mux into a TS, it should remain accessible to the DVR."
 

Dan203

Senior Developer
Staff member
#13
Did they ever even get their DVR out of beta? It's been years since the Kickstarter campaign and last I checked they still didn't have protected channel recording working. I assumed the project was dead.
 
#14
The project is not dead and has been out of beta for some time. Anyone living in a country that they support can purchase an annual subscription to their DVR service on their website:

https://shop.silicondust.com/shop/product-category/software/

The one item that has proven to be a problem is support for protected channel recordings. They have support for live viewing of protected channels on some platforms but are still working on being able to support protected channel recordings. Their DVR software fully supports OTA and all non-protected channel cablecard recordings. My cable provider only flags channels that I don't subscribe to, like HBO, as copy once, so I have been successfully using their DVR for many years and would still like VideoReDo to support their recordings.

The lack of support for protected channel recordings should have no bearing on the ability of VideoRedo to support SiliconDust DVR recordings since, at its best, VideoRedo can only edit the OTA and non-protected channel recordings that are already fully supported by the released, commercially available SiliconDust DVR software. Even if/when SiliconDust is able to implement protected channel recording support, VideoRedo would not be able to edit these recordings due to the requirements inherent in this protection.
 

Dan203

Senior Developer
Staff member
#15
I realize we wont be able to edit the protected recordings, but I took the fact that it still hadn't been implemented as a sign development on the project had stopped and it was dead. At the very least lack of protected channel support has to hurt popularity.

I'll put this on the list for v6. If we can make it work easily I'll add it in.
 
#16
In a SD forum post on April 10th, Nick Kelsey (co-founder of Silicondust) said:
"Firm company statement, recording of protected content is in the works and will be supported."

He was asked what year that was expected to happen and he replied:
"It will be released in conjunction with the HDHR5-6CC this year (2018)."
 
Top