recording gaps - tuner lost

[cat6man]

i'm having regular loss of tuner/signal, about 1 per hour on average since setting up a linux v9 server to replace my old v7/XP machine.

the baseball game tonight had 4 occurrences and i've captured the logs for sage and opendct. i've uploaded partial logs that capture before and after an anomalous event.

config:
hdhr-prime tuners with latest opendct load
latest sage v9 on ubuntu

if i can help with any other tests/logs, please let me know.

sage-debug-log-1.txt

opendct-debuglog-1.txt

[trallyus]

Seems like me and others are not the only one experiencing this problem. I did not know it affected linux as I thought it was only windows users having problems.

[m1k3g]

I was puzzling over this last night. About half of our channels (OTA) have no data and no signal. Very strange.

I also have TVHeadend running on another system and it's working fine.

[EnterNoEscape]

Originally Posted by cat6man

i'm having regular loss of tuner/signal, about 1 per hour on average since setting up a linux v9 server to replace my old v7/XP machine.

the baseball game tonight had 4 occurrences and i've captured the logs for sage and opendct. i've uploaded partial logs that capture before and after an anomalous event.

config:
hdhr-prime tuners with latest opendct load
latest sage v9 on ubuntu

if i can help with any other tests/logs, please let me know.

Attachment 15427

Attachment 15428

You're using the old consumer I will be removing that soon. Make sure you stop OpenDCT before making changes to opendct.properties. Change all entries for sagetv.device.<unique_id>.consumer to FFmpegTransSageTVConsumerImpl in opendct.properties. That should fix this problem you're seeing. The old consumer was unable to deal with anomalies in the stream.

[cat6man]

it looks like the consumer is already changed (see attached).

however, i see the file opendct.properties.backup in /opt/opendct/conf.moved so i'm wondering where the real opendct.properties file went? if i remember correctly, opendct.properties used to be in subdir conf, not conf.moved

[cat6man]

just saw that opendct.properties is now in /etc/opendct/conf

adding upload of correct file

[cat6man]

Originally Posted by EnterNoEscape

You're using the old consumer I will be removing that soon. Make sure you stop OpenDCT before making changes to opendct.properties. Change all entries for sagetv.device.<unique_id>.consumer to FFmpegTransSageTVConsumerImpl in opendct.properties. That should fix this problem you're seeing. The old consumer was unable to deal with anomalies in the stream.

i'm getting blind.............i see now the difference is the "Trans" between "mpeg" and "Sage" so let me go correct that now

will test for gaps in next couple of hours.

just ran one test of liveTV and hd300 hung up again after a minute of two.
these logs capture it.

[EnterNoEscape]

Originally Posted by cat6man

just saw that opendct.properties is now in /etc/opendct/conf

adding upload of correct file

Somehow the last configuration upgrade missed some things in your configuration.

You'll want to change hdhr.enabled to true, remove HDHR3-CC from hdhr.exp_ignore_models and remove schemas-dkeystone-com from upnp.new.device.search_strings_csv and upnp.new.device.schema_filter_strings_csv.

Originally Posted by cat6man

i'm getting blind.............i see now the difference is the "Trans" between "mpeg" and "Sage" so let me go correct that now

will test for gaps in next couple of hours.

just ran one test of liveTV and hd300 hung up again after a minute of two.
these logs capture it.

Also change consumer.ffmpeg.upload_id_enabled to false, maybe the media server is hanging up on you only when you are watching live.

Unfortunately the log isn't revealing anything that should be significant. All that's happening at least according to what's being logged is the content is being remuxed.

[cat6man]

Originally Posted by cat6man

i'm getting blind.............i see now the difference is the "Trans" between "mpeg" and "Sage" so let me go correct that now

will test for gaps in next couple of hours.

just ran one test of liveTV and hd300 hung up again after a minute of two.
these logs capture it.

update: i made 15 recordings today and not a single gap or warning.
outstanding!!!!

by the way, it seems this was also the cause of problems i was having playing back recordings with skip forward/back acting weird.....family is very pleased now that we can skip ahead/around commercials again

i'll look into updating the properties file next and retest the liveTV.

thanks for the great support

[EnterNoEscape]

Originally Posted by cat6man

update: i made 15 recordings today and not a single gap or warning.
outstanding!!!!

by the way, it seems this was also the cause of problems i was having playing back recordings with skip forward/back acting weird.....family is very pleased now that we can skip ahead/around commercials again

i'll look into updating the properties file next and retest the liveTV.

thanks for the great support

You're welcome!

OpenDCT can completely rebuild the opendct.properties file if it's missing, so if you ever want to be sure you're on the current defaults, you can just stop the service, rename opendct.properties, then start it again. I wouldn't delete it completely in case somehow things are worse than before you renamed it.

In the future once we finally get to that elusive web interface, there will be a little more work if you do that because I will have it set up to detect everything, but not enable any devices by default similar to how SageTV does it.

[cat6man]

i've made all the suggested changes, and loss of tuner/gaps are a thing of the past.

i still crash the hd300 in less than a minute with live tv.

here is a log from this morning

[EnterNoEscape]

Originally Posted by cat6man

i've made all the suggested changes, and loss of tuner/gaps are a thing of the past.

i still crash the hd300 in less than a minute with live tv.

here is a log from this morning

I can't find anything of interest in either one of those logs. The fact that live TV was crashing the HD300 on both the old and new consumer makes me think this is not an OpenDCT issue. I own an HD300 and haven't have seen them crash before on certain types of content. After getting to know the Android miniclient a little bit, I am aware that when you are watching something live TV, SageTV is sending the data to the player as opposed to when you're watching something already recorded, in which case the player pulls from the server. I don't suppose you have more than one HD300 to test with?

You could also try going back to the last 0.3 stable. If you do that, you will need to uninstall the version of 0.4 you have installed, then I would rename opendct.properties to something else. Then install 0.3 stable and see if the problem goes away. I really think the upgrade might have just been a coincidence.

[Narflex]

Originally Posted by EnterNoEscape

After getting to know the Android miniclient a little bit, I am aware that when you are watching something live TV, SageTV is sending the data to the player as opposed to when you're watching something already recorded, in which case the player pulls from the server.

This isn't true for the HD300 (and shouldn't be true for the Android Miniclient either). Push mode is always used for any content that is in MPEG-PS or MPEG-TS containers (whether live or recorded). Pull mode is used for everything else. Push mode is also always used for remote placeshifting when it transcodes (since the result is MPEG2-PS).

[EnterNoEscape]

Originally Posted by Narflex

This isn't true for the HD300 (and shouldn't be true for the Android Miniclient either). Push mode is always used for any content that is in MPEG-PS or MPEG-TS containers (whether live or recorded). Pull mode is used for everything else. Push mode is also always used for remote placeshifting when it transcodes (since the result is MPEG2-PS).

Thanks for correcting me there. I clearly misunderstood what was happening.

The Android miniclient at least does exhibit different playback behavior based on if the content is live or not.

[cat6man]

could be a buffering or smoothing that the live tv/hd300 case is more sensitive to?

i'm going to do two tests, one where i record a show, then start watching it 30 or 60 seconds later and another with live tv

Q: no else seeing this problem?

edit:
tests show that recording, then watching after 30s works fine.
watching directly give hd300 blank screen within a couple of minutes......perhaps buffer underflow to hd300?
going to check sage.properties and see if there are any parameters to play with

[KryptoNyte]

I have never experienced this on my Prime SageTV server or my Infinitv4 SageTV server. Both systems use HD300's with recorded and/or live television.

[Narflex]

Originally Posted by cat6man

could be a buffering or smoothing that the live tv/hd300 case is more sensitive to?

i'm going to do two tests, one where i record a show, then start watching it 30 or 60 seconds later and another with live tv

Q: no else seeing this problem?

edit:
tests show that recording, then watching after 30s works fine.
watching directly give hd300 blank screen within a couple of minutes......perhaps buffer underflow to hd300?
going to check sage.properties and see if there are any parameters to play with

Buffer underflow won't be the problem...when that happens playback just stalls temporarily and then starts up again. If you post SageTV server logs from when it works and then also from when it doesn't work that may help identify what the actual problem is.

[cat6man]

Originally Posted by Narflex

Buffer underflow won't be the problem...when that happens playback just stalls temporarily and then starts up again. If you post SageTV server logs from when it works and then also from when it doesn't work that may help identify what the actual problem is.

here are a few cases with log files for Sage and Opendct (not working live tv cases)

there are no working live tv cases.
case that works is to record, then begin watching.........will log that next

thanks

[cat6man]

logs for 'good' case (record, wait ~20s, watch)

[Narflex]

This is very interesting...here's the failure:

Wed 4/20 10:45:40.776 [Pusher@3ffcb577] Error with MiniPlayer, closing UI: java.io.EOFException
Wed 4/20 10:45:40.776 [Pusher@3ffcb577] java.io.EOFException
Wed 4/20 10:45:40.777 [Pusher@3ffcb577] 	at sage.BufferedFileChannel.read(BufferedFileChannel.java:183)
Wed 4/20 10:45:40.777 [Pusher@3ffcb577] 	at sage.FastMpeg2Reader.read(FastMpeg2Reader.java:987)
Wed 4/20 10:45:40.777 [Pusher@3ffcb577] 	at sage.FastMpeg2Reader.transfer(FastMpeg2Reader.java:880)
Wed 4/20 10:45:40.777 [Pusher@3ffcb577] 	at sage.MiniPlayer.pushBuffer0(MiniPlayer.java:3339)
Wed 4/20 10:45:40.777 [Pusher@3ffcb577] 	at sage.MiniPlayer$1.run(MiniPlayer.java:2076)
Wed 4/20 10:45:40.777 [Pusher@3ffcb577] 	at java.lang.Thread.run(Thread.java:745)

That exception occurs when it's trying to read from the file...but then the file is shorter than is expected. This should NOT be happening, because it checks the length of the file before it does this read. It also isn't relying on any other information (such as asking OpenDCT how many bytes it's recorded)...so this check should be very solid.

The reason it works if you wait 20 seconds is that then there's enough data in the file so it can never get to the end of it....although I would assume that if you waited 20 seconds to start playback, and then skipped forward until you hit live...that you would encounter the same problem. Please verify that's the case, because if not, that's a very important data point.

The only reason I can think this would happen is if OpenDCT is shortening the file length at certain points in time. SageTV assumes that recording files always grow in size and will never be smaller than any size they have had before (during playback only, if you stop and transcode it later, that's fine).

Can the OpenDCT dev weigh in on that point? If you don't think OpenDCT is doing this, then I'll create a JAR file that has more debugging to verify my theory is correct...because I'm wrong sometimes of course.