OpenDCT: An open source digital cable tuner.

[smak]

I need a push in the right direction. I am trying to test out the transcoding options and not having success. Using a HDHomeRun Prime with a cable card.

I can successfully record using the openDCT tuners in sagetv.

[QUOTE=EnterNoEscape;581743][*] Transcoding.

Set the software transcoding profile by changing sagetv.device.<unique_id>.transcode_profile to one of the available profiles are stored under C:\ProgramData\OpenDCT\config\transcode on Windows and /etc/opendct/conf/transcode on Linux. See profile_example.properties for help on how you can create your own. Do not include the .properties extension when setting the profile.

I found the the correct sagetv.device.<unique_id>.transcode_profile line in the configuration file. Set it to the ultrafast720p example file.

When I record shows in 1080i nothing seems to be happening on the transcoding side. I searched the log file and see nothing regarding transcoding

For testing I only have one tuner configured in SageTV xxxxxx-0.

I think I am missing a configuration option and/or the example file (ultrafast720p) is filter out too much.

Does anyone that uses the transcoding have any insight.

If it matters I am using the crazifuzzy docker container.

Thanks

[Fuzzy]

For simplicity in getting up and running, the docker container, sets the default consumer for the Dynamic Consumer selection to MediaServerConsumerImpl, which doesn't support transcoding. Instead, you'll have to change the specific device to use the FFmpegTransSageTVConsumerImpl, instead of using the dynamic selection:

sagetv.device.<unique_id>.consumer=opendct.consumer.FFmpegTransSageTVConsumerImpl

[sflamm]

install openDCT only, and use the batch file I posted called from openDCT, and you'd have a completely working network encoder for your BM3000-HDMIs, complete with tuning, all located next to the boxes they are tuning. This is what I was trying to get at. You are trying making the entire setup more complicated than it needs to be. This is the proper configuration for it.

Current:

Room 1:

STBs

BM3000-HDMIs
IR Blasters

Computer 1 (SageTV Server as Network Encoder)

USB-UIRT
SageTV (usb-uirt tuning plug-in)
OpenDCT

Room 2:

Computer 2 (Main SageTV Server)

SageTV
OpenDCT (acting as Network Encoder for HDHRs)

Room 3:

HDHRs

Alternate:

Room 1:

STBs

BM3000-HDMIs
IR Blasters

Computer 1

USB-UIRT
OpenDCT
USB-UIRT tuning script

Room 2:

Computer 2 (Main SageTV Server)

SageTV
OpenDCT (acting as Network Encoder for HDHRs)

Room 3:

HDHRs

There are disadvantages to the alternative:

1. The tuning plugin as an executable is much slower (process needs to load/unload)
2. OpenDCT does not support multiple Video Capture types (e.g. HDPVR)
3. There is no SageTV server - so no convenient SageTV for backup (or experimentation)
4. That's a fantastic waste of an entire computer just to run OpenDCT/tuning executable

[Fuzzy]

Again, you're just trying to make this more of an issue than it is for some reason.

Originally Posted by sflamm

There are disadvantages to the alternative:

1. The tuning plugin as an executable is much slower (process needs to load/unload)

Have you tried it? I posted actual times up above. Any faster than that and the box is likely to not keep up, making changing less reliable.

Originally Posted by sflamm

2. OpenDCT does not support multiple Video Capture types (e.g. HDPVR)

You said you only had 3 BM3000's there. You can still run sagetv on that machine if you so choose, to add additional sources at that location. As you are already aware from your main server, openDCT and SageTV can coexist perfectly fine on the same machine.

Originally Posted by sflamm

3. There is no SageTV server - so no convenient SageTV for backup (or experimentation)

Again, nothing is preventing running SageTV on that system as well as openDCT.

Originally Posted by sflamm

4. That's a fantastic waste of an entire computer just to run OpenDCT/tuning executable

It's already there being a 'waste of an entire computer' just to be a sagetv encoding server, isn't it? I mean, if you really cared about computer resources, you'd relocate the stb's to be near the main server, or run a USB extender from the main server to the STB location to serve the USB-UIRT.

[sflamm]

The point architecturally is that SageTV Server should be able to be configured into a Network Encoder and to use whatever resources are necessary to: a) capture video (any type) b) tune (any means).

There should be no reason not to follow this model.

The fact that that video capture is implemented against OpenDCT or an HDPVR or even the BM3000-HDMI directly should not matter. A video capture source should be chosen.

Same for the tuning mechanism.

You could argue that SageTV should be split into two - a Network Encoder and a central Media engine... but there is no harm to giving the Network Encoder more capabilities like to schedule its own recording or to post-process its own recordings independent of the central Media engine.

On your points:

Any faster than that and the box is likely to not keep up, making changing less reliable.

Sounds good - did not look at your times... the REST API is also very fast... much faster than necessary for the actual channel change.

You said you only had 3 BM3000's there.

True - but what if I wanted to add another type of capture in that location. Then I'd have to add SageTV anyway...

Nothing is preventing running SageTV on that system as well as openDCT.

Indeed - that is what I have done... and my script leverages the SageTV REST API which makes it more flexible than an executable that can only handle USB-UIRT.

It's already there being a 'waste of an entire computer' just to be a sagetv encoding server

Agreed - but the idea was to use that machine for more than just the single purpose. And the main server provides a single point of failure.

[Fuzzy]

I just think you really aren't going to get any traction on the need for a network encoder to share another network encoder. There really is absolutely NO reason for the added conflict resolution required to prevent repeated connections.

[smak]

Originally Posted by Fuzzy

For simplicity in getting up and running, the docker container, sets the default consumer for the Dynamic Consumer selection to MediaServerConsumerImpl, which doesn't support transcoding. Instead, you'll have to change the specific device to use the FFmpegTransSageTVConsumerImpl, instead of using the dynamic selection:

sagetv.device.<unique_id>.consumer=opendct.consumer.FFmpegTransSageTVConsumerImpl

Thanks... I will try this out.

I'll have to wait until my [wife's] shows finish on the production system so I can use the tuners.

[peternm22]

I just ordered one of the BM3000 devices and I am reading up on how to configure it while I await for it to arrive from China.

I see that OpenDCT has a transcoder option. Is there any reason to use this option when I can just set the bitrate/resolution settings on the BM3000 device itself?

It seems like the transcoder option is designed more for devices like the HDHR. Correct?

[Fuzzy]

Originally Posted by peternm22

I just ordered one of the BM3000 devices and I am reading up on how to configure it while I await for it to arrive from China.

I see that OpenDCT has a transcoder option. Is there any reason to use this option when I can just set the bitrate/resolution settings on the BM3000 device itself?

It seems like the transcoder option is designed more for devices like the HDHR. Correct?

Correct. The real point of transcoding in opendct is for mpeg-2 sources.

[Monedeath]

Originally Posted by Fuzzy

Ideally, the tuning plugins would move to the encoder piece anyway, so sage just has to send a channel to the encoder in the START command, so they can stay 32-bit just fine. Also, yes, the recorder was still at least partially java based. (min requirements list Java 1.4) I'm guessing it was actually still using Sage.jar, just with a different launch point (similar to how standalone, service, and client are today. I think the current launcher code on github still has the launch points in it for the recorder.

Realistically, a "Slaved SageTV Server" in 32 bit can play the role of SageTVRecorder9 right now(and probably why it was discontinued).

So in that respect, the "inelegant" solution for an ambitious outside party would be to

Step 1) Fork the code base and go ahead and start on a 32/64-bit Windows/Linux build that has no native tuning capabilities.

Step 2) Direct people to install a slaved server from the "main branch" in the interim if Native Tuning is needed and participating in testing. (If all it is doing is network encoding and they need more than a 32-bit memory space, they're probably not using it for "a consumer purpose," or something has gone very wrong). (Fork is considered to be in Alpha/Beta stage. Main repo remains fully functional)

Step 3) Migrate the "Slaved Server" over towards becoming "SageTV9 Native Recorder" or some other name. (Server Fork remains "Beta"/"RC" until completed)

Step 4) Merge the builds w/native tuning broken apart from "SageTV Core" back into the main repo.

But I guess EnterNoEscape's bigger consideration in this is the revamp to the Network Tuner Protocol used by SageTV. As it is, he only has to worry about one code base(Sage.jar) as his main concern. If someone splits it apart before that happened, he's then having to make sure the protocol gets changed in both parts(Server + Native Recorder) which makes code management more challenging. So someone else starting in on it first may make things more difficult if they're not careful in how they do it.

[EnterNoEscape]

Originally Posted by Monedeath

Realistically, a "Slaved SageTV Server" in 32 bit can play the role of SageTVRecorder9 right now(and probably why it was discontinued).

So in that respect, the "inelegant" solution for an ambitious outside party would be to

Step 1) Fork the code base and go ahead and start on a 32/64-bit Windows/Linux build that has no native tuning capabilities.

Step 2) Direct people to install a slaved server from the "main branch" in the interim if Native Tuning is needed and participating in testing. (If all it is doing is network encoding and they need more than a 32-bit memory space, they're probably not using it for "a consumer purpose," or something has gone very wrong). (Fork is considered to be in Alpha/Beta stage. Main repo remains fully functional)

Step 3) Migrate the "Slaved Server" over towards becoming "SageTV9 Native Recorder" or some other name. (Server Fork remains "Beta"/"RC" until completed)

Step 4) Merge the builds w/native tuning broken apart from "SageTV Core" back into the main repo.

But I guess EnterNoEscape's bigger consideration in this is the revamp to the Network Tuner Protocol used by SageTV. As it is, he only has to worry about one code base(Sage.jar) as his main concern. If someone splits it apart before that happened, he's then having to make sure the protocol gets changed in both parts(Server + Native Recorder) which makes code management more challenging. So someone else starting in on it first may make things more difficult if they're not careful in how they do it.

Your plan isn't too far from the ideas that I've had. I am planning on updating the network encoder protocol, but I'm holding off until I know everything that I would want it to be able to do to support the exact kind of architecture you're describing. Things like the tuning plugins need special consideration in the proposed scenario. Also I am trying to add some really nice advanced recording abilities to Seeker at the moment and one of them will require pretty much a complete replacement of the way SageTV natively interacts with digital encoders to support correctly.

Edit: You should know the protocols are versioned, so if the derivative network encoder says it's 3.0, SageTV will not try to talk to it like it's 4.0. Believe it or not we would only have a problem if the network encoder somehow was ahead of the main SageTV project.

[AlphaCrew]

I know you're focused on other things at the moment EnterNoEscape, but I thought I would post up my latest recording failure for some reference..

[EnterNoEscape]

Originally Posted by AlphaCrew

I know you're focused on other things at the moment EnterNoEscape, but I thought I would post up my latest recording failure for some reference..

I'm actually reaching a point where I think that once I get all of the changes I want in, I might be able to move the capabilities of OpenDCT right into SageTV. I never thought I'd be overhauling the way we interact with capture devices, but this has the potential for some very desirable new features and since I would need to overhaul OpenDCT a little to correctly support these new features I figure I might as well port the most interesting parts into SageTV so everyone benefits.

Anyway, I can clearly see Windows misbehaving in that log. I says I'm going into standby and then 5 minutes later it says it just came out of standby, then without actually waiting for OpenDCT to tell it that it's done, it clearly goes back into standby because we have an almost 8 hour gap before everything resumes. OpenDCT sees the discrepancy that it's being told that the computer resumed, but it never got a signal to go back into standby and it tries to fix everything by effectively doing a full cycle like it would if we went into standby and came out immediately in an effort to ensure we are in a stable state. Interestingly enough that doesn't seem to be causing any problems so that latest workaround is working correctly, but I'm still not happy with how Windows is not waiting for OpenDCT to return that's ok to go into standby before it just does it.

What is causing problems is this line:

ERROR InfiniTVTuning - Unable to read reply. Capture device may not be available => Server returned HTTP response code: 500 for URL: http://192.168.200.1/channel_request.cgi

If we get that kind of response there isn't much we can do other than just wait for it to start talking again. OpenDCT only tries twice because if we get too forceful, it might never come back to us. If you have an InfiniTV 4, it's even more problematic. 500 means at least it probably didn't just reboot on you since that's a real HTTP code and not just a connection timeout.

[AlphaCrew]

Thanks ENE, It is indeed a Infinity4..

[smak]

Originally Posted by Fuzzy

For simplicity in getting up and running, the docker container, sets the default consumer for the Dynamic Consumer selection to MediaServerConsumerImpl, which doesn't support transcoding. Instead, you'll have to change the specific device to use the FFmpegTransSageTVConsumerImpl, instead of using the dynamic selection:

sagetv.device.<unique_id>.consumer=opendct.consumer.FFmpegTransSageTVConsumerImpl

I finally set aside a little time to look into this more. After changing to the FFmpegTransSageTVConsumerImpl, the videos stopped working. Looking through the logs it appeared that opendct could not open the file. After a long reading session through this thread I tried changing the upload_id_enabled setting:

consumer.ffmpeg.upload_id_enabled=true

That seems to have gotten things working for me.

[lezouave@earthu]

Sorry, after reading a portion of this thread I still have this question:

I currently run SageTV 7 with an HDHomeRun HDHR-US, the older 2 tuner white box, connected to a Windows 10 machine and record OTA, and everything works fine.

I would like to buy an HDHomerun Prime, and get a cablecard from Comcast and watch/record HBO and other protected channels.

Is that the purpose of OpenDCT, and if so, can I do this with Sagetv 7, or must I use Sagetv 9?

Thanks to any who read...

[KarylFStein]

Originally Posted by lezouave@earthu

Sorry, after reading a portion of this thread I still have this question:

I currently run SageTV 7 with an HDHomeRun HDHR-US, the older 2 tuner white box, connected to a Windows 10 machine and record OTA, and everything works fine.

I would like to buy an HDHomerun Prime, and get a cablecard from Comcast and watch/record HBO and other protected channels.

Is that the purpose of OpenDCT, and if so, can I do this with Sagetv 7, or must I use Sagetv 9?

Thanks to any who read...

A CableCard will not work with copy once channels like HBO. I don't have any premium channels and CableCard + OpenDCT works fine for me, but I fear the day Comcast decides for some reason to mark other channels copy once, (not saying that they have threatened to do so, but I have little faith in Comcast doing anything but making my life harder and charging me more ).

[nkd]

Hello folks

I had a OpenDCT fail this AM after a system reboot. After a bit of debugging i realized that the 32bit installation of OpenDCT is using the 64bit Java even though 32bit Java is also installed. I fixed this by uninstalling the 64bit Java.

Is there a way to force OenDCT to use 32bit Java if 32bit OpenDCT is installed (and in turn use 64bit Java if the 64bit OpenDCT is installed)

I use Ninite to keep my favorite apps up to date and it automatically installs both 32bit and 64bit of Java

Regards,
Neel

[EnterNoEscape]

Originally Posted by nkd

Hello folks

I had a OpenDCT fail this AM after a system reboot. After a bit of debugging i realized that the 32bit installation of OpenDCT is using the 64bit Java even though 32bit Java is also installed. I fixed this by uninstalling the 64bit Java.

Is there a way to force OenDCT to use 32bit Java if 32bit OpenDCT is installed (and in turn use 64bit Java if the 64bit OpenDCT is installed)

I use Ninite to keep my favorite apps up to date and it automatically installs both 32bit and 64bit of Java

Regards,
Neel

This is one of the nuisances of how Java handles installations. There isn't a path that's definitely 32-bit and a path that's definitely 64-bit. The symlink that it creates just goes to whatever was installed last. You can edit wrapper.conf and point it to specific binary, but as soon as it's upgraded, the path will be invalid. SageTV finds the right binary by searching the registry for known 32-bit Java paths. To do this in OpenDCT, I would basically need to write my own service wrapper which I really was going to do initially, but JSW kind of keeps everything united between Windows and Linux. It's nice to not need to maintain a custom piece of software, but I know this could cause issues for those that choose to have 32-bit and 64-bit Java installed. I might circle back to this one day, but don't hold your breath.

[nkd]

Originally Posted by EnterNoEscape

This is one of the nuisances of how Java handles installations. There isn't a path that's definitely 32-bit and a path that's definitely 64-bit. The symlink that it creates just goes to whatever was installed last. You can edit wrapper.conf and point it to specific binary, but as soon as it's upgraded, the path will be invalid. SageTV finds the right binary by searching the registry for known 32-bit Java paths. To do this in OpenDCT, I would basically need to write my own service wrapper which I really was going to do initially, but JSW kind of keeps everything united between Windows and Linux. It's nice to not need to maintain a custom piece of software, but I know this could cause issues for those that choose to have 32-bit and 64-bit Java installed. I might circle back to this one day, but don't hold your breath.

Fair Enough ... Thanks for creating OpenDCT ...