OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Originally Posted by mechling-burgh

Still got the crash after the loading the beta is there a setting in proprieties to increase the length of time to check? Here are the logs but I think they look the same as the last under stable release.

Yes, you can up the value of sagetv.device.global.required_devices_loaded_timeout_ms from 30000 to 60000 and that will give you a minute.

On closer inspection of your logs, it looks like the actual problem is that none of your network interfaces are immediately available. Do you use DHCP or have a static IP address on your server? If you're using DHCP, I highly recommend using a static IP address on anything you consider to be a server. You could change the service to start with a delay. That might help, but this is clearly a timing issue.

[mechling-burgh]

It's DHCP right now because I was building a new server. I never thought about the amount of time it takes to get the IP address assigned I will try those two things tonight after the kids shows are recorded. Thanks again.

Mark

[EnterNoEscape]

No problem. It's exciting for me to see so many people using/trying out this software already.

[Monedeath]

Originally Posted by HelenWeathers

Your setup is unorthodox. Maybe someone else will chime in. I would try to set up a separate OTA guide just to see if you can see what call signs are available and maybe the OTA HiDef version will show a diffeerent call sign from some of the choices in the cable lineup. ie ABCDT in one as opposed to plain ABC in the other. That would allow you to control your favorites by channel if you can avoid the channel grouping by call sign.

Good Luck!!

Due to call signs matching between the HD cable line-up in my area and the OTA stations I gave up on trying to get Sage to differentiate between the two. Might be a plugin or feature add request for the OS version of Sage. However current behaviour is to merge/pool together tuners that are able to tune a station call sign, even if they are from different EPG lineups. (Note: Station ID# may also factor in somehow, but altering that still takes you back to likely ending with no EPG data)

You could make your own entry of course, but you wouldn't have guide data unless you're able to manipulate the EPG feed directly.

The solution I use is the OTA tuners are set at the highest merit so that if Sage is able to record it OTA it should try to do so. But if he is trying to record some OTA and others via Cable off the same station, then another approach would likely need to be created to facilitate it in Sage.

[HelenWeathers]

Originally Posted by Monedeath

Due to call signs matching between the HD cable line-up in my area and the OTA stations I gave up on trying to get Sage to differentiate between the two.......

I overcame that by activating (in channel setup for the cable guide source) the SD channels for locals and not activating the HD channels. I then remapped the activated local cable channels' physical tuner mapping to the HD cable channel number.

If you only get basic SD cable guide this isn't needed as HD OTA locals ie have physical mapping to 5.1 or 10.1 and the local cable channels are physically mapped to 5 or 10. You do have to have two guide sources to do this though. One for the local OTA tuners and one for the cable tuners.

[BobbyDing]

A big "Thank You" to all involved with this project. I've just installed the V3.16 x86 and it appears to be working very well. Question... I have the first two tuners of my single HDHR Prime set up in Sage V9 (Tuners 0 & 1), while leaving the third unassigned is sage, but assigned in nPVR on another machine instead. This is how it was previously set up in sageDCT. Should this work? Or do I need to make changes in the openDCT.properties file? And where do I find that properties file on windows 7? I've looked for it but have not located it yet.

Thanks!

Bobby

[brandypuff]

Originally Posted by Monedeath

The solution I use is the OTA tuners are set at the highest merit so that if Sage is able to record it OTA it should try to do so. But if he is trying to record some OTA and others via Cable off the same station, then another approach would likely need to be created to facilitate it in Sage.

But won't that also record on both OTA and Prime channels if the call signs are similar?

I was able to get guide data on all my prime channels by remapping them to the correct channel names. For some reason, most of them didn't get mapped correctly when adding a new lineup to the Prime.

So now I have both OTA and Prime channel listings showing.
But here's the problem:

Say I want to set up a new Favorite - General Hospital (No, it's only for an example)

In the Web interface I only select record on channel "5 - WCVB - ABC Affiliate". After I click save, both 5 and 5.1 are highlighted instead of only channel 5.
But when I view upcoming recordings, I see it's set to record on 5.1 and 781 but not 5. Why?

[troll5501]

I've been testing the latest beta version for several days, on both XP and Linux and with SageTV 7 and 9, and it's working very well. Every new release is better than the previous! Thanks very much for the continued improvements!

However, I'm still experiencing occasional tuning failures with the Prime...similar to what two of us saw in (I think) 0.4.16. You made a change in the next version to improve that but maybe it still needs more tweaking?

I've included part of my log file from today for your review. The channel tuned but resulted in "No Signal". After a minute or so, SageTV tuned it again and it worked. If you need more information please let me know.

[EnterNoEscape]

Originally Posted by BobbyDing

A big "Thank You" to all involved with this project. I've just installed the V3.16 x86 and it appears to be working very well. Question... I have the first two tuners of my single HDHR Prime set up in Sage V9 (Tuners 0 & 1), while leaving the third unassigned is sage, but assigned in nPVR on another machine instead. This is how it was previously set up in sageDCT. Should this work? Or do I need to make changes in the openDCT.properties file? And where do I find that properties file on windows 7? I've looked for it but have not located it yet.

Thanks!

Bobby

You should be ok with that configuration. OpenDCT will not do anything to manipulate the Prime tuners in a manner that would interfere with another program using it unless SageTV asks it to. The file is located at C:\ProgramData\OpenDCT\config\opendct.properties and there's a shortcut it on the Start Menu.

[EnterNoEscape]

Originally Posted by troll5501

I've been testing the latest beta version for several days, on both XP and Linux and with SageTV 7 and 9, and it's working very well. Every new release is better than the previous! Thanks very much for the continued improvements!

However, I'm still experiencing occasional tuning failures with the Prime...similar to what two of us saw in (I think) 0.4.16. You made a change in the next version to improve that but maybe it still needs more tweaking?

I've included part of my log file from today for your review. The channel tuned but resulted in "No Signal". After a minute or so, SageTV tuned it again and it worked. If you need more information please let me know.

You've run into a problem that I've only seen sometimes on Music Choice channels (but for a slightly different reason). This is actually unrelated to the communications issues fixed in the last beta. Basically FFmpeg consumes the majority of the circular buffer and still has not positively found a video and audio track. The stream it's parsing is actually a rather high bitrate (15Mb/s) and the buffer is completely used up in less than 5 seconds. The second time you tune in it appears to get lucky and returns around 3 seconds. I'll need to see what I can do to improve the handling of this kind of situation. In the mean time, the only thing you can do is increase the buffer and probe sizes.

These values will pretty much double your buffer size, but should also completely get rid of this particular issue until I come up with a less memory intensive way to handle it.
consumer.ffmpeg.circular_buffer_size=12283316
consumer.ffmpeg.max_probe_size=11234740

[troll5501]

Originally Posted by EnterNoEscape

These values will pretty much double your buffer size, but should also completely get rid of this particular issue until I come up with a less memory intensive way to handle it.
consumer.ffmpeg.circular_buffer_size=12283316
consumer.ffmpeg.max_probe_size=11234740

Thanks, I'll make these changes and continue testing.

[troll5501]

There was another tuning failure tonight with the increased buffer settings on tuner 13191941-0. It looks like it tried twice and then SageTV finally rescheduled the recording for a later time when it airs again. Does it look like the same issue as earlier today? Logfile is attached...it occurs around 21:00:02. Thanks for your help.

[Monedeath]

Originally Posted by HelenWeathers

I overcame that by activating (in channel setup for the cable guide source) the SD channels for locals and not activating the HD channels. I then remapped the activated local cable channels' physical tuner mapping to the HD cable channel number.

If you only get basic SD cable guide this isn't needed as HD OTA locals ie have physical mapping to 5.1 or 10.1 and the local cable channels are physically mapped to 5 or 10. You do have to have two guide sources to do this though. One for the local OTA tuners and one for the cable tuners.

In the case for my area, the SD version of channels have a different call sign in the guide so they don't get merged by Sage. So while you could do that, and use a single guide source in the process, your metadata from the program guide would be a little bit off(Showing SD when it is HD), but otherwise workable.

[EnterNoEscape]

Originally Posted by troll5501

There was another tuning failure tonight with the increased buffer settings on tuner 13191941-0. It looks like it tried twice and then SageTV finally rescheduled the recording for a later time when it airs again. Does it look like the same issue as earlier today? Logfile is attached...it occurs around 21:00:02. Thanks for your help.

That's very strange. This isn't the same issue. The log indicates that the stream format was detected in about 3 seconds and that it even starts writing the data to disk (via upload id), but then 2 seconds after that SageTV tells it to re-tune the channel while it's still writing the data out. I can see in the first tuning attempt that 1MB was written before SageTV must have determined the recording was halted.

We should try disabling upload id. Future versions of OpenDCT will have it disabled by default since it appears to overwhelm SageTV in some configurations.

Make the following changes to opendct.properties:
consumer.ffmpeg.upload_id_enabled=false

[troll5501]

Originally Posted by EnterNoEscape

That's very strange. This isn't the same issue. The log indicates that the stream format was detected in about 3 seconds and that it even starts writing the data to disk (via upload id), but then 2 seconds after that SageTV tells it to re-tune the channel while it's still writing the data out. I can see in the first tuning attempt that 1MB was written before SageTV must have determined the recording was halted.

We should try disabling upload id. Future versions of OpenDCT will have it disabled by default since it appears to overwhelm SageTV in some configurations.

I had upload_id disabled in Windows but I had to configure the service to run as the same user as SageTV so it could write to the CIFS share.

But I kept upload_id enabled on Linux because I assumed that OpenDCT (which appears to run as root) would be writing the files as root and my SageTV runs as sagetv. Surprisingly, when I disabled upload_id in Linux, OpenDCT is creating the files as the sagetv user. Where/how is it inheriting the userid of the SageTV process for file creation?

[EnterNoEscape]

It's probably inheriting that from the POSIX or ACL permissions on the folder.

OpenDCT does create it's own account and group when it's installed (opendct), and it can even be configured to use them, but I realized using them can create interesting problems that many people would not be prepared to solve which is why it's running as root. Let me know if you would like directions on how to make it use the opendct account instead.

The first thing that comes to mind is folder permissions. I think this would be one of the biggest hassles for some users to sort out. Also then you have the problem of is it really correct for the opendct account to be added to the sagetv group? If the sagetv group doesn't exist, is it ok for OpenDCT to create it?

Running as root also allows OpenDCT to overcome less obvious obstacles such as running at a higher priority than other programs on the computer.

I have been looking for effective ways to limit permissions of OpenDCT when it comes to writing files since it is running as root and the network encoder protocol is hardly secure; especially when it's not using upload id. When/if we get to that point, there will likely be special directions on how to configure permissions on folders that OpenDCT will be recording into. I do care about security, but as you may have guessed OpenDCT is never going to be making any claims about being impervious to exploits.

[troll5501]

Thanks for the explanation. It sounds like you're not explicitly setting the userid for the writer, so maybe it's happening at the NFS or ZFS layer. I'm writing to an NFS4 volume and it's working fine so far with upload_id disabled, and SageTV is able to access and delete the files created by OpenDCT.

Obviously based on my previous experiences I prefer that OpenDCT can set the thread priorities, so I'm OK with it running as root for now. I hadn't thought about that issue until I started up SageTV on Linux (as non-root) and it complained about "-XX:ThreadPriorityPolicy requires root privilege on Linux". But it's ideal because OpenDCT is running at a higher priority than SageTV and I'm not seeing any issues other than those occasional tuning failures. But I hope they are fixed with the increased buffers and upload_id disabled.

[EnterNoEscape]

That would be correct. You'll notice the log files are owned by root, so it's almost certainly an inheritance thing. ZFS can be particularly good at enforcing that sort of thing, but I suspect it's actually the credentials you have provided to mount your NFS share that are making this happen.

Not completely related, but are you running ZFS on Linux or Unix to get ZFS? Has it generally been a good experience?

[troll5501]

I've been running my ZFS storage on UNIX (OpenIndiana VM on same hardware as SageTV VM) since approximately 2010 and it's been great. I'm using an array of older fiber-channel drives but they perform well and are very reliable. I've been a big fan of ZFS for many years...since the times when it was only available in Solaris.

[nyplayer]

Originally Posted by EnterNoEscape

The discovery and communication abilities are there and have been tested, but I have not created a capture device implementation specifically for the HDHomeRun protocol. I'm currently working on the web interface which involves a few capture device implementation modifications meaning I likely will not add any new devices until the current version is the version with a web interface. It might be a while before I get around to adding that unless several people express interest in having OTA capabilities over a web interface. I have the original HDHomeRun dual tuner device and I've only used it for QAM. In fact I don't think I have ever used SageTV with OTA. I see from my local lineup that SageTV uses a hyphen and the Connect appears to use a period between the channel and sub-channel.


Speaking of the web interface, I'm a little torn between having the latest and having the most compatible. Does anyone have any opinions on a Java 1.8 requirement knowing that this might break some currently in use SageTV plugins? I ask because the latest Jetty as has been discussed already in other threads requires 1.8. In my current implementation, you can choose to not use the web interface and continue to just use 1.7 with all of the latest features.

What I think I'll be doing for simplicity sake on my own setup if I have issues with 1.8 32-bit and SageTV plugins, is install 1.8 64-bit, run the 64-bit version of OpenDCT and retain a 1.7 32-bit version of Java for SageTV. That way I'll know positively what version SageTV is using. If anyone knows a way to tell SageTV exactly what binary to use, I think that would help most people out.

Update: Just to give people an idea of where I'm going with the interface, attached is a screenshot of a nearly complete page. Almost everything you see currently works.

This sure would solve all the problems with the MiniClient being unable to play OTA TS files created by SageTV. You can always map the channels in SageTV to send the period instead of the dash.

Still hoping