SageTV Community  

Go Back   SageTV Community > Hardware Support > Hardware Support
Reload this Page OpenDCT: An open source digital cable tuner.
Forum Rules FAQs Community Downloads Today's Posts Search

Notices

Hardware Support Discussions related to using various hardware setups with SageTV products. Anything relating to capture cards, remotes, infrared receivers/transmitters, system compatibility or other hardware related problems or suggestions should be posted here.

Reply
Page 34 of 148 « First 243233 34 35364484134 Last »
 
Thread Tools Search this Thread Display Modes
  #661  
Old 03-27-2016, 06:34 AM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
Quote:
Originally Posted by Greg2dot0 View Post
Installed RC3 and deleted my existing opendct.properties file and came across some issues

First off, at 06:00:

06:00:03.562 [FFmpegSageTVConsumerImpl-98CT-HDHomeRun Prime Tuner 13142E5A-0] WARN FFmpegSageTVConsumerImpl - Consumer created an IO exception => java.nio.channels.ClosedByInterruptException
at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:216)
at opendct.consumer.FFmpegSageTVConsumerImpl.writeBuffer(FFmpegSageTVConsumerImpl.java:766)
at opendct.consumer.FFmpegSageTVConsumerImpl.access$900(FFmpegSageTVConsumerImpl.java:49)
at opendct.consumer.FFmpegSageTVConsumerImpl$WriteCallback.call(FFmpegSageTVConsumerImpl.java:559)
at org.bytedeco.javacpp.avformat.av_interleaved_write_frame(Native Method)
at opendct.consumer.FFmpegSageTVConsumerImpl.remuxRtpPackets(FFmpegSageTVConsumerImpl.java:1217)
at opendct.consumer.FFmpegSageTVConsumerImpl.run(FFmpegSageTVConsumerImpl.java:269)
at java.lang.Thread.run(Thread.java:745)

06:00:03.563 [FFmpegSageTVConsumerImpl-98CT-HDHomeRun Prime Tuner 13142E5A-0] ERROR FFmpegSageTVConsumerImpl - Error -541478725 while writing packet at input stream offset 1225060640.

This doesn't seem to be related to the issue I was having but may be related to the change in shows.

But, at 6:47, it looks like the old issue is still here:

06:47:49.348 [FFmpegSageTVConsumerImpl-562CT-HDHomeRun Prime Tuner 13142E5A-1] WARN ffmpeg - [mpegts @ 0x7f9bd0057ea0] PES packet size mismatch
06:47:55.617 [FFmpegSageTVConsumerImpl-562CT-HDHomeRun Prime Tuner 13142E5A-1] WARN ffmpeg - [mpegts @ 0x7f9bd0057ea0] Invalid timestamps stream=1379733664, pts=(null), dts=(null), size=0
06:47:55.701 [FFmpegSageTVConsumerImpl-562CT-HDHomeRun Prime Tuner 13142E5A-1] WARN ffmpeg - [mpegts @ 0x7f9bd0057ea0] DTS 140309371359392 < 0 out of order
06:47:55.701 [FFmpegSageTVConsumerImpl-562CT-HDHomeRun Prime Tuner 13142E5A-1] ERROR ffmpeg - [mpegts @ 0x7f9bd005b860] Application provided invalid, non monotonically increasing dts to muxer in stream 1379733664: (null) >= (null)
06:47:55.701 [FFmpegSageTVConsumerImpl-562CT-HDHomeRun Prime Tuner 13142E5A-1] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset 2924624068.
06:47:55.732 [FFmpegSageTVConsumerImpl-562CT-HDHomeRun Prime Tuner 13142E5A-1] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset 2924636476.

The log is attached.
Your issue is only fixed in the transcoding consumer. I did not apply the fixes to the other one because it is being deprecated.

If you've been having the kinds of issues described by Greg2dot0 and troll5501, try changing the values of sagetv.device.<unique_id>.consumer to opendct.consumer.FFmpegTransSageTVConsumerImpl with this release.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Reply With Quote
  #662  
Old 03-27-2016, 06:45 AM
Greg2dot0's Avatar
Greg2dot0 Greg2dot0 is offline
Sage Advanced User
  
Join Date: Dec 2008
Posts: 82
I verified in the consumer config before I started since I had configured them for Raw to capture that bad video:

Here's what my consumers are set for:

sagetv.new.default_consumer_impl=opendct.consumer.FFmpegSageTVConsumerImpl

But, what I realized is that I forgot to run ./console-only so am deleting the properties and starting over. Guess that's what I get for doing this before coffee.
__________________
Production SageTV Server: ASUS P8P67-Pro, 16gb RAM, Crucial m4 256GB SSD, Unbunto 16.4.04 LTS (Server x64), WDC Red 4TB
Capture: 1x HDHR Prime, 1x HDHomeRun (ClearQAM)
Clients: 1x HD300, 2x HD200, 2x Placeshifters
Reply With Quote
  #663  
Old 03-27-2016, 06:57 AM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
Quote:
Originally Posted by Greg2dot0 View Post
I verified in the consumer config before I started since I had configured them for Raw to capture that bad video:

Here's what my consumers are set for:

sagetv.new.default_consumer_impl=opendct.consumer.FFmpegSageTVConsumerImpl

But, what I realized is that I forgot to run ./console-only so am deleting the properties and starting over. Guess that's what I get for doing this before coffee.
That's correct. That's the current default because most people are ok on that one. I will change it in the next release if opendct.consumer.FFmpegTransSageTVConsumerImpl works out for you. Please use opendct.consumer.FFmpegTransSageTVConsumerImpl since that's the only one that actually addresses the issues you're having. opendct.consumer.FFmpegSageTVConsumerImpl will not fix anything.

Don't worry about the ./console-only thing. You can get the same effect by starting the service and then stopping it after 30 seconds.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Last edited by EnterNoEscape; 03-27-2016 at 07:00 AM.
Reply With Quote
  #664  
Old 03-27-2016, 10:24 AM
troll5501 troll5501 is offline
Sage Advanced User
  
Join Date: Jun 2006
Posts: 136
I will install the new build today. As I was reviewing the log from today's recordings--using 0.4.37 (I've had live TV running since last night on two extenders), I noticed that 5 times the FFmpegTransSageTVConsumerImpl reported a "write failed" at exactly the time of a SWITCH, for the recording that is scheduled to end at that time. This left the open files as expected with 0.4.37, but I'm wondering why these write failures are happening at these times? There is plenty of disk space 150GB+. Is there something in the SWITCH logic that is closing or deleting the file while it is still being written to by another thread?

Also, a side effect of the open file handles issue is that the space associated with those files (even if they have been deleted) is not released back to the filesystem until the file handles are closed.

Code:
02:35:00.292 [SageTVRequestHandler-6171:null] DEBUG SageTVRequestHandler - SageTV sent: 'SWITCH DCT-HDHomeRun Prime Tuner 13191941-1 Digital TV Tuner|1456289802|803|/sagedata/ThisOldHouse-NewtonCentreProject-38147811-0.ts'
02:35:00.292 [SageTVRequestHandler-6171:null] DEBUG SageTVRequestHandler - Renaming the thread 'SageTVRequestHandler-6171:null' to 'SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1'...
02:35:00.292 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  HDHRNativeCaptureDevice - Capture device is was already locked.
02:35:00.293 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG SageTVRequestHandler - Switching network encoder to filename '/sagedata/ThisOldHouse-NewtonCentreProject-38147811-0.ts'.
02:35:00.296 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - SWITCH started.
02:35:01.206 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegTranscoder - Video key frame flag: 1
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - avcodec_close
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - avio_closep
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - avformat_free_context
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - Initializing FFmpeg transcoder stream output.
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - Calling avformat_alloc_output_context2
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegContext - DO
Output #0, mpegts, to '/sagedata/ThisOldHouse-NewtonCentreProject-38147811-0.ts':
    Stream #0:0, 0, 1/90000: Video: mpeg2video, yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, max. 18000 kb/s, 90k tbn, 59.94 tbc
    Stream #0:1(eng), 0, 1/90000: Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2(spa), 0, 1/90000: Audio: ac3, 48000 Hz, mono, fltp, 96 kb/s

02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegTranscoder - Writing header
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG ffmpeg - [mpegts @ 0x7fc8080bf640] muxrate VBR,
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG ffmpeg - [mpegts @ 0x7fc8080bf640] pcr every 1714569376 pkts, sdt every 0, pat/pmt every 0 pkts
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - Initialized FFmpeg transcoder stream output.
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - SWITCH successful: 912ms.
02:35:01.209 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG SageTVRequestHandler - Replied: 'OK'
02:35:01.210 [Thread-4808] ERROR FFmpegTransSageTVConsumerImpl - File '/sagedata/EyewitnessNewsat11pmSaturday-38097062-0.ts' write failed => java.nio.channels.AsynchronousCloseException
        at sun.nio.ch.SimpleAsynchronousFileChannelImpl$3.run(SimpleAsynchronousFileChannelImpl.java:380)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
__________________
Server: HP DL380 G6, VMware ESXi 5.0 with HW passthrough for USB and Firewire, 4 x HD-PVR, ZFS storage
SageTV: Production: 7.1.9+Java 1.6.0_32 on XP, Test: 9.0.4.291+Java 1.8.0_72 on Linux 64-bit
Clients: 2 x Sage HD200 Extender, 1 x Sage HD100 Extender
Sources: 4 x Motorola DCH-3200 (firewire channel changing), HD Homerun Prime, OpenDCT 0.5.7
Last edited by troll5501; 03-27-2016 at 10:48 AM. Reason: Added more log entries
Reply With Quote
  #665  
Old 03-27-2016, 01:10 PM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
Quote:
Originally Posted by troll5501 View Post
I will install the new build today. As I was reviewing the log from today's recordings--using 0.4.37 (I've had live TV running since last night on two extenders), I noticed that 5 times the FFmpegTransSageTVConsumerImpl reported a "write failed" at exactly the time of a SWITCH, for the recording that is scheduled to end at that time. This left the open files as expected with 0.4.37, but I'm wondering why these write failures are happening at these times? There is plenty of disk space 150GB+. Is there something in the SWITCH logic that is closing or deleting the file while it is still being written to by another thread?

Also, a side effect of the open file handles issue is that the space associated with those files (even if they have been deleted) is not released back to the filesystem until the file handles are closed.

Code:
02:35:00.292 [SageTVRequestHandler-6171:null] DEBUG SageTVRequestHandler - SageTV sent: 'SWITCH DCT-HDHomeRun Prime Tuner 13191941-1 Digital TV Tuner|1456289802|803|/sagedata/ThisOldHouse-NewtonCentreProject-38147811-0.ts'
02:35:00.292 [SageTVRequestHandler-6171:null] DEBUG SageTVRequestHandler - Renaming the thread 'SageTVRequestHandler-6171:null' to 'SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1'...
02:35:00.292 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  HDHRNativeCaptureDevice - Capture device is was already locked.
02:35:00.293 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG SageTVRequestHandler - Switching network encoder to filename '/sagedata/ThisOldHouse-NewtonCentreProject-38147811-0.ts'.
02:35:00.296 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - SWITCH started.
02:35:01.206 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegTranscoder - Video key frame flag: 1
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - avcodec_close
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - avio_closep
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - avformat_free_context
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - Initializing FFmpeg transcoder stream output.
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegContext - Calling avformat_alloc_output_context2
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegContext - DO
Output #0, mpegts, to '/sagedata/ThisOldHouse-NewtonCentreProject-38147811-0.ts':
    Stream #0:0, 0, 1/90000: Video: mpeg2video, yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, max. 18000 kb/s, 90k tbn, 59.94 tbc
    Stream #0:1(eng), 0, 1/90000: Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s
    Stream #0:2(spa), 0, 1/90000: Audio: ac3, 48000 Hz, mono, fltp, 96 kb/s

02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegTranscoder - Writing header
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG ffmpeg - [mpegts @ 0x7fc8080bf640] muxrate VBR,
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG ffmpeg - [mpegts @ 0x7fc8080bf640] pcr every 1714569376 pkts, sdt every 0, pat/pmt every 0 pkts
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - Initialized FFmpeg transcoder stream output.
02:35:01.208 [FFmpegTransSageTVConsumerImpl-3782:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegTranscoder - SWITCH successful: 912ms.
02:35:01.209 [SageTVRequestHandler-6171:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG SageTVRequestHandler - Replied: 'OK'
02:35:01.210 [Thread-4808] ERROR FFmpegTransSageTVConsumerImpl - File '/sagedata/EyewitnessNewsat11pmSaturday-38097062-0.ts' write failed => java.nio.channels.AsynchronousCloseException
        at sun.nio.ch.SimpleAsynchronousFileChannelImpl$3.run(SimpleAsynchronousFileChannelImpl.java:380)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
This is a known possibility with the async file channel provided by the Java framework. That's one reason why I used a blocking queue to keep it from getting too far ahead. I thought I had sufficiently addressed it, but clearly it's happening to you. I suspect it's a timing issue as in the write is still in progress when the channel is told to close. I think I'll just write my own implementation in the next RC to avoid this problem.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Reply With Quote
  #666  
Old 03-27-2016, 01:59 PM
troll5501 troll5501 is offline
Sage Advanced User
  
Join Date: Jun 2006
Posts: 136
Quote:
Originally Posted by EnterNoEscape View Post
This is a known possibility with the async file channel provided by the Java framework. That's one reason why I used a blocking queue to keep it from getting too far ahead. I thought I had sufficiently addressed it, but clearly it's happening to you. I suspect it's a timing issue as in the write is still in progress when the channel is told to close. I think I'll just write my own implementation in the next RC to avoid this problem.
Thanks for the explanation. I'm going to install 0.4.38 now and test the disk full scenario and I'll also watch for any of these SWITCH issues to see if OpenDCT closes the file handles when it happens.
__________________
Server: HP DL380 G6, VMware ESXi 5.0 with HW passthrough for USB and Firewire, 4 x HD-PVR, ZFS storage
SageTV: Production: 7.1.9+Java 1.6.0_32 on XP, Test: 9.0.4.291+Java 1.8.0_72 on Linux 64-bit
Clients: 2 x Sage HD200 Extender, 1 x Sage HD100 Extender
Sources: 4 x Motorola DCH-3200 (firewire channel changing), HD Homerun Prime, OpenDCT 0.5.7
Reply With Quote
  #667  
Old 03-27-2016, 03:41 PM
troll5501 troll5501 is offline
Sage Advanced User
  
Join Date: Jun 2006
Posts: 136
With 0.4.38, I've seen several of the java.nio.channels.AsynchronousCloseException errors again, most recently when I stopped an active recording a few minutes ago. When this happened, it left the file open in OpenDCT (see file descriptor list below):

Code:
17:31:26.461 [SageTVRequestHandler-178:null] DEBUG SageTVRequestHandler - SageTV sent: 'STOP DCT-HDHomeRun Prime Tuner 13191941-2 Digital TV Tuner'
17:31:26.461 [SageTVRequestHandler-178:null] DEBUG SageTVRequestHandler - Renaming the thread 'SageTVRequestHandler-178:null' to 'SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2'...
17:31:26.461 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HDHRNativeCaptureDevice - Stopping encoding...
17:31:26.461 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HTTPCaptureDeviceServices - Stopping producer thread...
17:31:26.461 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HTTPCaptureDeviceServices - Waiting for producer thread to stop...
17:31:26.461 [HTTPProducerImpl-95:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HTTPProducerImpl - The socket has been closed.
17:31:26.461 [HTTPProducerImpl-95:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  HTTPProducerImpl - Producer thread has stopped.
17:31:26.461 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG BasicCaptureDevice - Stopping consumer thread...
17:31:26.461 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG BasicCaptureDevice - Waiting for consumer thread to stop...
17:31:26.461 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG FFmpegContext - FFmpeg consumer was interrupted while reading.
17:31:26.461 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
17:31:26.461 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  ffmpeg - Last message repeated 1 time.
17:31:26.461 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  ffmpeg - [mpegts @ 0x7f20d400d1c0] PES packet size mismatch
17:31:26.477 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  FFmpegTranscoder - FFmpeg transcoder ended with code -541478725
17:31:26.478 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG FFmpegContext - avcodec_close
17:31:26.478 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG FFmpegContext - avio_closep
17:31:26.478 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG FFmpegContext - avformat_free_context
17:31:26.478 [FFmpegTransSageTVConsumerImpl-97:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  FFmpegTransSageTVConsumerImpl - FFmpeg Transcoder consumer thread stopped.
17:31:26.478 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HDHomeRunControl - key: '/tuner2/lockkey' value: 'force' lockKey: '-1' sendLength: 40
17:31:26.480 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HDHomeRunControl - key: '/tuner2/lockkey' value: 'null' lockKey: '0' sendLength: 26
17:31:26.482 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HDHomeRunControl - key: '/tuner2/channel' value: 'none' lockKey: '0' sendLength: 33
17:31:26.483 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HDHomeRunControl - key: '/tuner2/target' value: 'none' lockKey: '0' sendLength: 32
17:31:26.485 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG HDHomeRunControl - key: '/tuner2/lockkey' value: 'null' lockKey: '0' sendLength: 26
17:31:26.487 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  HDHRNativeCaptureDevice - HDHomeRun is now unlocked.
17:31:26.487 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  HDHRNativeCaptureDevice - Capture device is now unlocked.
17:31:26.487 [SageTVRequestHandler-178:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG SageTVRequestHandler - Replied: 'OK'
17:31:26.478 [Thread-53] ERROR FFmpegTransSageTVConsumerImpl - File '/sagedata/NCAATipOff-38100032-0.ts' write failed => java.nio.channels.AsynchronousCloseException
        at sun.nio.ch.SimpleAsynchronousFileChannelImpl$3.run(SimpleAsynchronousFileChannelImpl.java:380)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
See fd #47:

Code:
[root@sagelinux sagedata]# ls -al /proc/13337/fd
total 0
dr-x------. 2 root root  0 Mar 27 17:23 .
dr-xr-xr-x. 9 root root  0 Mar 27 17:23 ..
lrwx------. 1 root root 64 Mar 27 17:23 0 -> /dev/null
l-wx------. 1 root root 64 Mar 27 17:23 1 -> pipe:[55692929]
lr-x------. 1 root root 64 Mar 27 17:23 10 -> /opt/opendct/lib/seamless-http-1.1.0.jar
lr-x------. 1 root root 64 Mar 27 17:23 11 -> /opt/opendct/lib/seamless-util-1.1.0.jar
lr-x------. 1 root root 64 Mar 27 17:23 12 -> /opt/opendct/lib/seamless-xml-1.1.0.jar
lr-x------. 1 root root 64 Mar 27 17:23 13 -> /opt/opendct/lib/log4j-api-2.5.jar
lr-x------. 1 root root 64 Mar 27 17:23 14 -> /opt/opendct/lib/log4j-core-2.5.jar
lr-x------. 1 root root 64 Mar 27 17:23 15 -> /opt/opendct/lib/commons-cli-1.3.jar
lr-x------. 1 root root 64 Mar 27 17:23 16 -> /opt/opendct/lib/jna-4.2.1.jar
lr-x------. 1 root root 64 Mar 27 17:23 17 -> /opt/opendct/lib/jna-platform-4.2.1.jar
lr-x------. 1 root root 64 Mar 27 17:23 18 -> /opt/opendct/lib/ffmpeg-2.8.1-1.1.jar
lr-x------. 1 root root 64 Mar 27 17:23 19 -> /opt/opendct/lib/javacpp-1.1.jar
l-wx------. 1 root root 64 Mar 27 17:23 2 -> pipe:[55692929]
lr-x------. 1 root root 64 Mar 27 17:23 20 -> /opt/opendct/lib/ffmpeg-2.8.1-1.1-linux-x86_64.jar
lr-x------. 1 root root 64 Mar 27 17:23 21 -> /opt/java/jre1.8.0_72/lib/ext/nashorn.jar
l-wx------. 1 root root 64 Mar 27 17:23 22 -> /var/log/opendct/opendct.log
lrwx------. 1 root root 64 Mar 27 17:23 23 -> socket:[55693772]
lrwx------. 1 root root 64 Mar 27 17:23 24 -> socket:[55693774]
lrwx------. 1 root root 64 Mar 27 17:23 25 -> socket:[55693894]
lrwx------. 1 root root 64 Mar 27 17:23 26 -> socket:[55693915]
lrwx------. 1 root root 64 Mar 27 17:23 27 -> socket:[55693963]
l-wx------. 1 root root 64 Mar 27 17:23 28 -> /var/log/opendct/opendct_cling.log.lck
lrwx------. 1 root root 64 Mar 27 17:23 29 -> socket:[55693880]
lr-x------. 1 root root 64 Mar 27 17:23 3 -> /opt/java/jre1.8.0_72/lib/rt.jar
l-wx------. 1 root root 64 Mar 27 17:23 30 -> /var/log/opendct/opendct_cling.log
lrwx------. 1 root root 64 Mar 27 17:23 31 -> socket:[55693964]
lrwx------. 1 root root 64 Mar 27 17:23 32 -> socket:[55693895]
lr-x------. 1 root root 64 Mar 27 17:23 33 -> pipe:[55693896]
l-wx------. 1 root root 64 Mar 27 17:23 34 -> pipe:[55693896]
lrwx------. 1 root root 64 Mar 27 17:23 35 -> anon_inode:[eventpoll]
lrwx------. 1 root root 64 Mar 27 17:23 36 -> socket:[55693897]
lrwx------. 1 root root 64 Mar 27 17:23 37 -> socket:[55693905]
lrwx------. 1 root root 64 Mar 27 17:23 38 -> socket:[55693916]
lrwx------. 1 root root 64 Mar 27 17:23 39 -> socket:[55693918]
lrwx------. 1 root root 64 Mar 27 17:23 4 -> socket:[55692782]
lrwx------. 1 root root 64 Mar 27 17:23 40 -> socket:[55693917]
lrwx------. 1 root root 64 Mar 27 17:23 41 -> socket:[55693095]
lr-x------. 1 root root 64 Mar 27 17:23 42 -> /opt/java/jre1.8.0_72/lib/ext/localedata.jar
lr-x------. 1 root root 64 Mar 27 17:23 43 -> /opt/java/jre1.8.0_72/lib/ext/cldrdata.jar
lrwx------. 1 root root 64 Mar 27 17:23 44 -> socket:[55693953]
lrwx------. 1 root root 64 Mar 27 17:23 45 -> socket:[55693965]
lrwx------. 1 root root 64 Mar 27 17:23 46 -> socket:[55739320]
l-wx------. 1 root root 64 Mar 27 17:23 47 -> /sagedata/NCAATipOff-38100032-0.ts
lrwx------. 1 root root 64 Mar 27 17:23 48 -> socket:[55739318]
lrwx------. 1 root root 64 Mar 27 17:23 49 -> socket:[55741569]
lr-x------. 1 root root 64 Mar 27 17:23 5 -> pipe:[55692929]
l-wx------. 1 root root 64 Mar 27 17:23 6 -> pipe:[55692929]
lr-x------. 1 root root 64 Mar 27 17:23 7 -> /opt/opendct/jsw/lib/wrapper.jar
lr-x------. 1 root root 64 Mar 27 17:23 8 -> /opt/opendct/lib/opendct-0.4.38.jar
lr-x------. 1 root root 64 Mar 27 17:23 9 -> /opt/opendct/lib/cling-core-2.1.0-S
__________________
Server: HP DL380 G6, VMware ESXi 5.0 with HW passthrough for USB and Firewire, 4 x HD-PVR, ZFS storage
SageTV: Production: 7.1.9+Java 1.6.0_32 on XP, Test: 9.0.4.291+Java 1.8.0_72 on Linux 64-bit
Clients: 2 x Sage HD200 Extender, 1 x Sage HD100 Extender
Sources: 4 x Motorola DCH-3200 (firewire channel changing), HD Homerun Prime, OpenDCT 0.5.7
Reply With Quote
  #668  
Old 03-27-2016, 07:27 PM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
Quote:
Originally Posted by troll5501 View Post
With 0.4.38, I've seen several of the java.nio.channels.AsynchronousCloseException errors again, most recently when I stopped an active recording a few minutes ago. When this happened, it left the file open in OpenDCT (see file descriptor list below):
I wrote my own async writer that cannot have this potential race condition when closing the file, since the close request is queued up with the writes queue being read by the writer thread. That basically guarantees that the last write will always happen and not have the potential to be interrupted before it completes. This is probably what I should have done the first time around since the design is marginally more efficient too. This will be in the next RC.

I also plan on making the transcoding consumer the default if everything Greg2dot0 has been experiencing short of this issue appears to be have been fixed. Were you seeing something like that too on occasion? Are you able to confirm things are any better as far as the dts errors?
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Reply With Quote
  #669  
Old 03-27-2016, 09:28 PM
troll5501 troll5501 is offline
Sage Advanced User
  
Join Date: Jun 2006
Posts: 136
Quote:
Originally Posted by EnterNoEscape View Post
I wrote my own async writer that cannot have this potential race condition when closing the file, since the close request is queued up with the writes queue being read by the writer thread. That basically guarantees that the last write will always happen and not have the potential to be interrupted before it completes. This is probably what I should have done the first time around since the design is marginally more efficient too. This will be in the next RC.
Sounds good, thanks for addressing this issue!

Quote:
I also plan on making the transcoding consumer the default if everything Greg2dot0 has been experiencing short of this issue appears to be have been fixed. Were you seeing something like that too on occasion? Are you able to confirm things are any better as far as the dts errors?
I was about to respond and say everything looked good because I had not seen any of those "looping" dts error messages recently. But then tonight (unfortunately during the NCAA Tournament) something went wrong and OpenDCT suddenly got into a non-stop loop fixing dts values which corrupted the entire rest of the recording. From the viewing perspective, the audio stopped and the video started playing at what seemed like twice the normal rate. Eventually I could hear audio again but it was 5-10 seconds ahead of the video (which was still jerky and going faster than normal). When I was using FF and REW, it was sometimes jumping around as if the timestamps in the recording were corrupted.

I checked the logs and from 22:10 on, OpenDCT was constantly making corrections - "DEBUG FFmpegTranscoder - fixing stream ...". I'm attaching the first logfile (there are several because of the volume of log entries) so you can look at the start of the issue. If you need subsequent logs or want the resulting recording file let me know. For the attached log, take a look at timestamp 22:10:32.530 which is when the issue started. As of 23:17 the dts corrections are still happening and it's generated over 100MB of logs so far.
Attached Files
File Type: zip opendct-log.zip (614.2 KB, 104 views)
__________________
Server: HP DL380 G6, VMware ESXi 5.0 with HW passthrough for USB and Firewire, 4 x HD-PVR, ZFS storage
SageTV: Production: 7.1.9+Java 1.6.0_32 on XP, Test: 9.0.4.291+Java 1.8.0_72 on Linux 64-bit
Clients: 2 x Sage HD200 Extender, 1 x Sage HD100 Extender
Sources: 4 x Motorola DCH-3200 (firewire channel changing), HD Homerun Prime, OpenDCT 0.5.7
Reply With Quote
  #670  
Old 03-27-2016, 10:35 PM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
Quote:
Originally Posted by troll5501 View Post
I was about to respond and say everything looked good because I had not seen any of those "looping" dts error messages recently. But then tonight (unfortunately during the NCAA Tournament) something went wrong and OpenDCT suddenly got into a non-stop loop fixing dts values which corrupted the entire rest of the recording. From the viewing perspective, the audio stopped and the video started playing at what seemed like twice the normal rate. Eventually I could hear audio again but it was 5-10 seconds ahead of the video (which was still jerky and going faster than normal). When I was using FF and REW, it was sometimes jumping around as if the timestamps in the recording were corrupted.

I checked the logs and from 22:10 on, OpenDCT was constantly making corrections - "DEBUG FFmpegTranscoder - fixing stream ...". I'm attaching the first logfile (there are several because of the volume of log entries) so you can look at the start of the issue. If you need subsequent logs or want the resulting recording file let me know. For the attached log, take a look at timestamp 22:10:32.530 which is when the issue started. As of 23:17 the dts corrections are still happening and it's generated over 100MB of logs so far.
The AV sync can potentially be thrown off because I'm just using the time stamps instead of a rational, but the "corrective" state is supposed to be temporary, so you should see at most around 50 corrections at one time, then all should be well again. The offset is constant for all streams, so as long as they are in sync, once the right offset has been determined, everything will sync back up. In your logs, what I see happening is the corrective offset is being set to aggressively. I was setting the threshold dynamically, but I have a feeling that might have been a bad idea. I'll try something new for the next RC. The problem is that without the same recording in a raw (unprocessed) format, there isn't much I can learn from the resultant recording.

Update: Actually after looking at this a little more closely, the discontinuity actually started because a dts matched the last dts and that's not allowed, so the program tried to fix it. It looks like some code I put in place to determine if a dts <= last dts, but the pts > last pts, to just increment the dts so it's sequential was a bad idea. The dts values cannot be the same or less than the last value, so I'm going to change it to just discard the frame if dts == last dts which is what we would have done before.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Last edited by EnterNoEscape; 03-27-2016 at 11:19 PM.
Reply With Quote
  #671  
Old 03-28-2016, 06:01 AM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
OpenDCT 0.4.39-RC4


I wanted to address these issues sooner than later and get all new installs switched over to the newer FFmpeg implementation. The old one is still available and will remain available in the foreseeable future, but I have no intentions of continuing to update it along side this one.
  • Reworked FFmpeg transcoder dts correction logic so it will be less aggressive.
  • Changed writer for FFmpeg consumer to ensure that files don't accidentally get re-opened when closing while a write is still in progress.
  • Changed default consumer to the FFmpeg transcoding consumer (opendct.consumer.FFmpegTransSageTVConsumerImpl).
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Reply With Quote
  #672  
Old 03-28-2016, 09:22 AM
Greg2dot0's Avatar
Greg2dot0 Greg2dot0 is offline
Sage Advanced User
  
Join Date: Dec 2008
Posts: 82
Downloaded and installed RC4 and for the most part everything is working great. I do see some hiccups in the logs where I'll get:

10:33:55.483 [FFmpegTransSageTVConsumerImpl-885CT-HDHomeRun Prime Tuner 13142E5A-2] DEBUG FFmpegTranscoder - fixing stream 2 timestamp discontinuity diff = 8369361152, new offset = -8369358272, dts = 8590146770, new dts 220788498, last dts = 220785618, new pts = 8590146770, pts = 220788498, last pts = 220785618

but going back and checking the video, it seems to correlate with some pixelation and some frame jumps if the problem lasts longer, but that's it. This resembles the same behavior that I notice when recording using PrimeNetEncoder on my Windows box.

I'll keep testing throughout the day.
__________________
Production SageTV Server: ASUS P8P67-Pro, 16gb RAM, Crucial m4 256GB SSD, Unbunto 16.4.04 LTS (Server x64), WDC Red 4TB
Capture: 1x HDHR Prime, 1x HDHomeRun (ClearQAM)
Clients: 1x HD300, 2x HD200, 2x Placeshifters
Reply With Quote
  #673  
Old 03-28-2016, 09:44 AM
troll5501 troll5501 is offline
Sage Advanced User
  
Join Date: Jun 2006
Posts: 136
Thanks again for the quick fixes. I installed 0.4.39 and I'm testing it now.

Out of curiosity, what is the significance of the 8707216918 value here (from FFmpegTranscoder.java)?:

Code:
if (dts <= lastDtsByStreamIndex[inputStreamIndex] || dts > 8707216918L) {
I'm asking because last night I was seeing values in the logs much higher than this. And something actually caused the dts corrections to continue all night until this morning and the values were up to 10107630772, for example:

*NOTE: this was with 0.4.38
Code:
10:26:05.944 [FFmpegTransSageTVConsumerImpl-294:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG FFmpegTranscoder - fixing stream 0 dts increment = 4504, dts = 10107630772, new dts = 10107626268, last dts = 10107626268, pts = 10107641282, last pts = 10107626267
__________________
Server: HP DL380 G6, VMware ESXi 5.0 with HW passthrough for USB and Firewire, 4 x HD-PVR, ZFS storage
SageTV: Production: 7.1.9+Java 1.6.0_32 on XP, Test: 9.0.4.291+Java 1.8.0_72 on Linux 64-bit
Clients: 2 x Sage HD200 Extender, 1 x Sage HD100 Extender
Sources: 4 x Motorola DCH-3200 (firewire channel changing), HD Homerun Prime, OpenDCT 0.5.7
Reply With Quote
  #674  
Old 03-28-2016, 11:13 AM
Cooper Cooper is offline
Sage User
  
Join Date: Oct 2008
Location: Washington
Posts: 35
Quote:
Originally Posted by EnterNoEscape View Post
That's odd. That's one of the things I test constantly. There will be a move to the transcoding consumer when I move on to 0.5 because I have improved so much and it doesn't make sense to keep them synced up when they effectively do the same thing when remuxing. Try changing all of the values for sagetv.device.<unique_id>.consumer to opendct.consumer.FFmpegTransSageTVConsumerImpl and see if the situation improves. The difference is that it performs SWITCH more accurately on the key frames.

The reason why you would have never seen this in SageDCT is because it didn't support SWITCH which is why you get that brief interruption between recordings when watching live.
Thanks I changed this and a few times when fast forwarding over the weekend on a paused show I would receive the never ending circle. I noticed you put up RC4 and from a few other posts this may have been addressed? I installed latest and will test out more later today.
Reply With Quote
  #675  
Old 03-28-2016, 12:44 PM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
Quote:
Originally Posted by Greg2dot0 View Post
Downloaded and installed RC4 and for the most part everything is working great. I do see some hiccups in the logs where I'll get:

10:33:55.483 [FFmpegTransSageTVConsumerImpl-885CT-HDHomeRun Prime Tuner 13142E5A-2] DEBUG FFmpegTranscoder - fixing stream 2 timestamp discontinuity diff = 8369361152, new offset = -8369358272, dts = 8590146770, new dts 220788498, last dts = 220785618, new pts = 8590146770, pts = 220788498, last pts = 220785618

but going back and checking the video, it seems to correlate with some pixelation and some frame jumps if the problem lasts longer, but that's it. This resembles the same behavior that I notice when recording using PrimeNetEncoder on my Windows box.

I'll keep testing throughout the day.
If you're only seeing a handful of those in under a second, the dts fix is doing it's job. If you end up seeing hundreds of them in a second, something has gone wrong. Your situation is abnormal and I don't really have anything to compare it to other than the sample you gave me.

Quote:
Originally Posted by troll5501 View Post
Thanks again for the quick fixes. I installed 0.4.39 and I'm testing it now.

Out of curiosity, what is the significance of the 8707216918 value here (from FFmpegTranscoder.java)?:

Code:
if (dts <= lastDtsByStreamIndex[inputStreamIndex] || dts > 8707216918L) {
I'm asking because last night I was seeing values in the logs much higher than this. And something actually caused the dts corrections to continue all night until this morning and the values were up to 10107630772, for example:

*NOTE: this was with 0.4.38
Code:
10:26:05.944 [FFmpegTransSageTVConsumerImpl-294:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG FFmpegTranscoder - fixing stream 0 dts increment = 4504, dts = 10107630772, new dts = 10107626268, last dts = 10107626268, pts = 10107641282, last pts = 10107626267
8707216918L is 2 ^ 33. The decode and presentation timestamps should not be going above that value because only 33 bits are allocated for each timestamp. I have not been able to go back to 0 without the FFmpeg muxer throwing a fit. I had not considered that some people might leave the tv running live well past the limit. One of the challenges that I'm facing here is that I have almost no conveniences that you get from running the executable. It's really hard to work out what the best thing to do is for each situation especially since I'm hardly an expert and I'm trying to keep corrective measures to a minimum because the more I tweak, the more unexpected situations could arise.

Quote:
Originally Posted by Cooper View Post
Thanks I changed this and a few times when fast forwarding over the weekend on a paused show I would receive the never ending circle. I noticed you put up RC4 and from a few other posts this may have been addressed? I installed latest and will test out more later today.
How long are you leaving your live tv paused? I've been watching live tv continuously trying to see what you're getting all day on an HD300 and HD200. Are you talking about the client? It could matter. I noticed that the client given the right conditions will hang on switch which really just means you'll want to turn the feature off.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Last edited by EnterNoEscape; 03-28-2016 at 01:35 PM.
Reply With Quote
  #676  
Old 03-28-2016, 01:44 PM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
I just noticed that 8589934592 is 2 ^ 33. Now I don't know how I came up with that incorrect number. I'm fixing it right now. These issues coming up now are really making this not feel like a release candidate.

I also just found something else saying to just let it overflow and FFmpeg will take care of it. I'll do that in the next release.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Last edited by EnterNoEscape; 03-28-2016 at 02:26 PM.
Reply With Quote
  #677  
Old 03-28-2016, 04:00 PM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
OpenDCT 0.4.40-RC5

  • Duplicate log entries are now reported at the same log level as the duplicates so that you don't see the duplicate entry, yet no previous logging associated.
  • Dts corrective code will now transparently restart the muxer if more than 30 errors are encountered in under a second. Most players can handle this, the FFmpeg remuxer cannot deal with timestamps that are not monotonic.
  • Removed 33-bit dts limit checking since it appears that FFmpeg will take care of that automatically.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Reply With Quote
  #678  
Old 03-28-2016, 07:06 PM
troll5501 troll5501 is offline
Sage Advanced User
  
Join Date: Jun 2006
Posts: 136
I've been running 0.4.40 for a few hours. It has also gotten into a dts correction loop like the earlier version. See attached logfile starting at 20:32:06.706.
Attached Files
File Type: zip opendct-log-20160328.zip (603.3 KB, 108 views)
__________________
Server: HP DL380 G6, VMware ESXi 5.0 with HW passthrough for USB and Firewire, 4 x HD-PVR, ZFS storage
SageTV: Production: 7.1.9+Java 1.6.0_32 on XP, Test: 9.0.4.291+Java 1.8.0_72 on Linux 64-bit
Clients: 2 x Sage HD200 Extender, 1 x Sage HD100 Extender
Sources: 4 x Motorola DCH-3200 (firewire channel changing), HD Homerun Prime, OpenDCT 0.5.7
Reply With Quote
  #679  
Old 03-28-2016, 08:56 PM
EnterNoEscape's Avatar
EnterNoEscape EnterNoEscape is offline
SageTVaholic
  
Join Date: Jun 2010
Location: Harrisburg, PA
Posts: 2,657
Quote:
Originally Posted by troll5501 View Post
I've been running 0.4.40 for a few hours. It has also gotten into a dts correction loop like the earlier version. See attached logfile starting at 20:32:06.706.
I can see you're just over the threshold for discontinuity correction which was set to +/- 2 seconds. The constant movement between the different timestamps is the part causing the constant adjustments. I need to make it smart enough to know when it's just being fiddly with an insignificant difference. The easiest way is to increase the threshold, but there has to be a better way.

By the way, thank you for your aggressive persistence in testing these builds.
__________________
SageTV v9 Server: ASRock Z97 Extreme4, Intel i7-4790K @ 4.4Ghz, 32GB RAM, 6x 3TB 7200rpm HD, 2x 5TB 7200rpm HD, 2x 6TB 7200rpm HD, 4x 256GB SSD, 4x 500GB SSD, unRAID Pro 6.7.2 (Dual Parity + SSD Cache).
Capture: 1x Ceton InfiniTV 4 (ClearQAM), 2x Ceton InfiniTV 6, 1x BM1000-HDMI, 1x BM3500-HDMI.
Clients: 1x HD300 (Living Room), 1x HD200 (Master Bedroom).
Software: OpenDCT :: WMC Live TV Tuner :: Schedules Direct EPG
Last edited by EnterNoEscape; 03-28-2016 at 09:03 PM.
Reply With Quote
  #680  
Old 03-28-2016, 09:38 PM
troll5501 troll5501 is offline
Sage Advanced User
  
Join Date: Jun 2006
Posts: 136
Quote:
Originally Posted by EnterNoEscape View Post
I can see you're just over the threshold for discontinuity correction which was set to +/- 2 seconds. The constant movement between the different timestamps is the part causing the constant adjustments. I need to make it smart enough to know when it's just being fiddly with an insignificant difference. The easiest way is to increase the threshold, but there has to be a better way.
Makes sense. If you can't find a better way or if an increased value may cause other issues for some users, maybe the dts tolerance could become a tunable property (with the ability to either change the value or to disable the feature entirely if it causes issues). For me, the non-transcoder consumer was working very well--I was running 0.4.27 for several weeks without any significant issues. So I'm not sure that everyone needs these corrective actions or maybe just not such aggressive ones. It seems to depend on the cable/signal provider and the quality of their data streams.

Quote:
By the way, thank you for your aggressive persistence in testing these builds.
No problem...apparently I'm good at triggering bugs.

Now for some better news... it looks like the open file issue has been resolved. I didn't see any leftover file handles with 0.4.39 or 0.4.40 during switch/close operations and I even ran the disk out of space (with 0.4.39) to test that scenario.
__________________
Server: HP DL380 G6, VMware ESXi 5.0 with HW passthrough for USB and Firewire, 4 x HD-PVR, ZFS storage
SageTV: Production: 7.1.9+Java 1.6.0_32 on XP, Test: 9.0.4.291+Java 1.8.0_72 on Linux 64-bit
Clients: 2 x Sage HD200 Extender, 1 x Sage HD100 Extender
Sources: 4 x Motorola DCH-3200 (firewire channel changing), HD Homerun Prime, OpenDCT 0.5.7
Reply With Quote
Reply
Page 34 of 148 « First 243233 34 35364484134 Last »

« Previous Thread | Next Thread »

Currently Active Users Viewing This Thread: 5 (0 members and 5 guests)
 

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
ATI TV Wonder Digital Cable Tuner & SageTV nyle Hardware Support 4 02-17-2009 10:12 PM
ATI TV Wonder Digital Cable Tuner rajczi Hardware Support 4 01-14-2008 08:24 PM
ATI TV Wonder™ Digital Cable Tuner dadams Hardware Support 4 01-09-2007 10:55 AM
Digital Cable - one guide - need HD on one tuner reg tv on other Kimper SageTV Beta Test Software 14 11-27-2006 08:15 PM
Multi-tuner Digital Cable mlbdude SageTV Software 0 06-26-2003 01:08 PM


All times are GMT -6. The time now is 05:29 AM.

Contact Us - SageTV, LLC - Archive - Privacy Statement - Top

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, vBulletin Solutions Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.