OpenDCT: An open source digital cable tuner.

[SHS]

Originally Posted by jeffoffline

I think the android app works quite well actually, the only drawback is it doesn't support 5.1 audio for MPEG-2 playback.

Or you could just build a full PC like ASRock J5005-ITX or pick Intel NUC NUC7PJYH toss windows 10 and SageTV Client and cover you all way to H265 decoding

[jeffoffline]

Originally Posted by SHS

Or you could just build a full PC like ASRock J5005-ITX or pick Intel NUC NUC7PJYH toss windows 10 and SageTV Client and cover you all way to H265 decoding

Yep, i went with a refurb dell pc to use as an htpc and run the windows version of SageTV in my living room, works great and only set me back like $225.

[KryptoNyte]

Originally Posted by Deacon Crusher

...
Following up on the HVEC statement and associated question. This feels like a biggy. If Silicondust moves to HVEC does that mean our Sage Extenders will no longer work, even if Sage itself does work? And will we have to find some playback device that is good for OTA channels and HVEC channels? And isn't it true that the android devices don't do OTA channel/show playback very well right now? I don't really want to give up on Extenders, they are great.

Thanks

Yikes. I did not pick up on that originally, but yeah, that's a big one for those of us that love our SageTV brand extenders - HVEC/H.265 is a no go. I suppose there are two options;

1) Upgrade extenders to Android boxes and run the miniclient. Does the miniclient on a Shield pass 5.1 channel audio?
2) Have OpenDCT re-encode video to a playable format, on the fly. Is that an option?

[waylo]

Originally Posted by jeffoffline

I think the android app works quite well actually, the only drawback is it doesn't support 5.1 audio for MPEG-2 playback.

I've had issues with the speed of it for some reason. These are on wireless connections (but 802.11N and AC connections), but for whatever reason, on my tablet and last 2 modern phones, the UI is so sluggish. Not sure if there is a way to improve this.

Sorry for the off topic.

[EnterNoEscape]

Originally Posted by KryptoNyte

Yikes. I did not pick up on that originally, but yeah, that's a big one for those of us that love our SageTV brand extenders - HVEC/H.265 is a no go. I suppose there are two options;

1) Upgrade extenders to Android boxes and run the miniclient. Does the miniclient on a Shield pass 5.1 channel audio?
2) Have OpenDCT re-encode video to a playable format, on the fly. Is that an option?

H.265 can be very CPU heavy just to decode without hardware acceleration. OpenDCT should be able to transcode it to H.264, but that scenario has not been tested. I suspect the CPU load for decoding and encoding might be too much for most computers.

[SHS]

Originally Posted by EnterNoEscape

H.265 can be very CPU heavy just to decode without hardware acceleration. OpenDCT should be able to transcode it to H.264, but that scenario has not been tested. I suspect the CPU load for decoding and encoding might be too much for most computers.

Not only that but SageTV doesn't make use of hardware acceleration encoding

[nyplayer]

Originally Posted by SHS

Not only that but SageTV doesn't make use of hardware acceleration encoding

OpenDCT uses FFMPEG it should be able to use hardware encoding on the fly... I hope it gets updated to FFMPEG 4.

http://ffmpeg.org/index.html#pr4.0

[KryptoNyte]

I contacted Silicondust about the decision to use HEVC and their support echoed that they're still on the fence about the final video format. I suppose they are still in the testing phases for a while yet.

I also asked them if the Extend device could be used to re-encode back to h.264. They replied that the extend will only pass whatever encoding it receives via Premium TV.

[tmiranda]

I just installed the latest opendct on a brand new Ubuntu system and I am seeing a lot of stuttering and bad recordings. I'm not sure where to start? Logfile is attached.

Edit: I tried all of the different consumers and the result is the same. After a few seconds playback stutters.

[tmiranda]

Originally Posted by tmiranda

I just installed the latest opendct on a brand new Ubuntu system and I am seeing a lot of stuttering and bad recordings. I'm not sure where to start? Logfile is attached.

Edit: I tried all of the different consumers and the result is the same. After a few seconds playback stutters.

Everything on my new server is working except this. I read through large portions of this thread and tried several things including the various consumers and nothing has helped. Video plays smoothly for a second of two and then it stutters very badly.

Anybody have any suggestions?

[NetworkGuy]

Originally Posted by tmiranda

Everything on my new server is working except this. I read through large portions of this thread and tried several things including the various consumers and nothing has helped. Video plays smoothly for a second of two and then it stutters very badly.

Anybody have any suggestions?

If you copy the video file to another machine and play it back locally (i.e. no network) does it stutter?

If there is no stutter it is a playback issue and typically points the hardware involved during the playback. Typical choke points are:

• Network Congestion
• CPU Performance
• Disk Contention

Use resource monitor to monitor the hardware components before and during the playback. See what changes.

[tmiranda]

Originally Posted by NetworkGuy

If you copy the video file to another machine and play it back locally (i.e. no network) does it stutter?

If there is no stutter it is a playback issue and typically points the hardware involved during the playback. Typical choke points are:

• Network Congestion
• CPU Performance
• Disk Contention

Use resource monitor to monitor the hardware components before and during the playback. See what changes.

The videos play the same no matter where I play them back. The issue seems to be with the recordings themselves.

The machine is a brand new 3.6 GHz quad core i5. I don't think CPU performance is an issue. I will double check to make sure.

I thought about disk issues since the recording drives are NTFS formatted drives from my old Windows server. I did some basic performance testing and they seem to be fast enough. I even installed a new drive and formatted it ext4. Recordings made to that drive have the exact same issues.

I can watch TV using the Silicondust web based software so the Prime is probably functioning OK.

The fact that the recordings start out good then quickly go downhill tells me that something isn't keeping up, but I don't know what. And I know just enough about Linux to be dangerous, but not enough to be an expert.

My plan is to go back and retest CPU and disk performance to see if I missed something.

Edit: CPU load is not an issue, it never gets over 15%. I don't think drive speed is an issue either. I used the "benchmark" tool and it's telling me the read speeds are 170MB/s with 11 ms access times. These seem like reasonable numbers to me.

[NetworkGuy]

Originally Posted by tmiranda

The videos play the same no matter where I play them back. The issue seems to be with the recordings themselves.

Did you copy the video to a different machine and try to play it back?

If you did and it still stutters, that means it is not recording correctly.

If the drive is not able to write the video stream fast enough to keep up, it would introduce stuttering in the recording.

Are you recording to a Network Drive or a NAS? I have had problems in the past trying to record to anything but a locally attached drive.

[tmiranda]

Originally Posted by NetworkGuy

Did you copy the video to a different machine and try to play it back?

If you did and it still stutters, that means it is not recording correctly.

If the drive is not able to write the video stream fast enough to keep up, it would introduce stuttering in the recording.

Are you recording to a Network Drive or a NAS? I have had problems in the past trying to record to anything but a locally attached drive.

Problem solved!

It turns out that the disk IO speed was the issue. The disk speed tests I ran measured the raw read/write speed of the disk, not the effective speed through the filesystem. After some googling I found out that the ntfs-3g file system driver is notoriously slow. I reformatted the recording drives to ext4 and the stuttering problems have gone away.

Lesson learned. Don't use NTFS partitions in Ubuntu.

[NetworkGuy]

Glad you found it.

[EnterNoEscape]

Originally Posted by tmiranda

Problem solved!

It turns out that the disk IO speed was the issue. The disk speed tests I ran measured the raw read/write speed of the disk, not the effective speed through the filesystem. After some googling I found out that the ntfs-3g file system driver is notoriously slow. I reformatted the recording drives to ext4 and the stuttering problems have gone away.

Lesson learned. Don't use NTFS partitions in Ubuntu.

Sorry I'm a little late to the party here, but I think we've run into this problem before. I forget if I made of note of it somewhere easier to find.

Edit: Oh, now I remember. It was a different thread and I suggested that the discovery should be a sticky because people converting from Windows will likely have this problem if they don't convert their disks to a native Linux filesystem. https://forums.sagetv.com/forums/sho...9&postcount=34

[tmiranda]

Originally Posted by EnterNoEscape

Sorry I'm a little late to the party here, but I think we've run into this problem before. I forget if I made of note of it somewhere easier to find.

Edit: Oh, now I remember. It was a different thread and I suggested that the discovery should be a sticky because people converting from Windows will likely have this problem if they don't convert their disks to a native Linux filesystem. https://forums.sagetv.com/forums/sho...9&postcount=34

No problem. It gave me the chance to learn how to manage disks in Ubuntu
Which, by the way, is a lot easier now. In the past I always had to use command line tools. Now it's all automated in the "Disks" configuration program.

At one point the kernel wouldn't boot and I even got to reuse my old "vi" (now vim) skills. I haven't used that since 1991

The issue did take me by surprise. I didn't expect the ntfs driver to be so bad given how mature Ubuntu and linux is.

[KryptoNyte]

Originally Posted by Deacon Crusher

Working on this.

So, stopped all sage services.
Stopped opendtc
deleted opendtc properties (not actually using it right now, so didn't need the history)
ran opendtc console, let sit for a while
Ctrl-c to stop
reviewed properties, looked fine.
started service
started sage service. waited a bit
started sage client.
deleted one of my sage controlled hdhr video sources
chose to add a video source
scrolled down and found the opendtc version of the hdhr tuner I'd removed from sage.
chose it
selected it as a digital tv tuner. waited a bit
selected Continue - Device input ...
selected use tuner on capture card ...
seleced use schedules direct ...
said yes to using existing schedules direct account.
Chose add a new lineup
Found a lineup call HDHomerun Premium TV West National (that was exciting)
Chose extended
said yes do a channel scan
It found all the OTA channels, and listed all the Premium channels but said they failed scan.
I then tried again with Basic and again the premium channels failed scan

BUT, this time I tested one of the Premium channels in PREVIEW and it WORKED.

Just signed up for HD Homerun premium and am going to integrate into Sage.

Will update.

Trying to get HDHomeRun premium TV into Sage ...

I must be missing something here. I ran a clean install of SageTV and OpenDCT after installing the HDHomerun software (for Windows 7). I was not able to get the HDHomerun View application to display any video on Windows 7 (it did however work on the HDHR Android app on a Galaxy Note 4), so I tried to dial up a stream using VLC and was successful on channel 1111 using the stream path below (the IP address is the HDHR Connect Quatro);

http://192.168.254.213:5004/auto/v1111

I then started OpenDCT and let it find (4) HDHR tuners (Connect Quatro), per your instructions. When I selected and setup one of these tuners in SageTV (in the SageTV UI the tuner is listed as "HDHomeRun HDHR5-4US Tuner 10757234-1 on 127.0.0.1:9000") it doesn't render the stream, it just says "no signal." I studied the OpenDCT properties file and it seemed to be listening on port 9000, so I changed that to 5004 for each tuner thinking that was a good correction based on the VLC stream path test. That did not fix the problem, still no signal.

I'm now thinking that OpenDCT has found the (4) antenna tuners in the Quatro, which is why it can't tune the Premium TV streams - it even mentioned "atsc_10757234" in the OpenDCT encoder_pool. Can someone please take a look at the attached OpenDCT properties file and let me know your thoughts on this? Somehow I need to get OpenDCT to recognize the (4) virtual tuners in the Quatro if they are in fact separate from the antenna tuners. If my thoughts that the Quatro has 4 antenna tuners and 4 virtual tuners is incorrect, I need to figure out how to get these tuners streaming the Premium TV service somehow.

Maybe Deacon could even report in on what his OpenDCT properties file looks like as a comparison. If I can play a stream in VLC, I'm sure this can work great in Sage.

[KryptoNyte]

The OpenDCT log seems to suggest that when it discovered the tuner, it would treat it as a qam tuner, so it looks to the lineup for tuning the channel. The lineup, however, looks just like an HDHR Prime lineup, where the tuning path is via HTTP. OpenDCT then throws an error that it can't find the channel frequency during tuning, as if it were trying to tune qam.

There is something that I'm missing here ... any ideas are welcome.

[waylo]

One thing that might help you on your way. (Or maybe not at all):

To view video on Windows 7 through the native HDHR View app, install VLC 32-bit. I've never gotten the right answers on why this works, their forum is really skimpy on it and they actively discourage talking about it.

Probably won't affect your tuning issues though.