Weird Encoder Halt Detected and Recovery Issue

[kpbrwn]

Before I get into the details of my problem, I want to give a big thanks to SageTV community for keeping SageTV going strong; been a happy Sage user since 2008'ish

My setup

• Server - SageTV V9.0.14.567
  • using stuckless-sagetv-server-java8 Docker in Unraid 6.3.2
• Encoding Server - SageTV for Windows V9.0.14.568
  • Window 7 (32bit) VM in Unraid with two Hauppauge 2250 cards and 2 HDPVR for a total of 6 tuners.
  • The 2250 cards are stubbed to VM.
  • The USB controller that the HDPVR devices are attached to the VM. These work reliably without any issues to date in both v7 and v9.

Every now and then a "Halt Detected in Recording" happens on one of the 2250 OTA inputs.
Usually Sage has no problem recovering but every now and then it starts recording again but it's recording the wrong channel. Tonight it actually went through various channels before returning back to the correct channel.

Recording was NCIS at 8 PM on CIIIDT via OTA (41-41-1).
Recording filenames:

1. NCIS-S14E19-TheWall-38500904-0.mpg
2. NCIS-S14E19-TheWall-38500904-1.mpg - this recording has various channels in it.
3. NCIS-S14E19-TheWall-38500904-2.mpg

First halt happens at 3/28 20:01:29.184 in "sageserver_sagetv_2.txt log" file. This one recovers for about 10 seconds and then switches to another channel.
Second halt happens at 3/28 20:29:45.205 in "sageserver_sagetv_1.txt" log file. This one was on the correct channel.

There are other halts in the log file for two other recordings but they recovered correctly.

Log files attached. They're a 7-Zip inside of a zip so I could upload the file. The raw log files were too large to upload to the forum post hence why I 7-zipped them and then zipped that.
Their internal files are:

• encodingserver_sagetv_0.txt
• sageserver_sagetv_1.txt
• sageserver_sagetv_2.txt

Any help appreciated.
If there is something else I can do to help track the issue down I'm more than willing.

Thanks in advance.

[wnjj]

The Seeker is confused about something. I found this in the encoding server log:

Tue 3/28 20:00:03.556 [EncodingServerConn@7abf7d] EncodingServer Recvd:START Hauppauge WinTV-7164 Analog Capture #4 Digital TV Tuner|995652163|41-41-1|2981491206822|/var/media/tv/NCIS-S14E19-TheWall-38500904-0.mpg|HDPVRMax
Tue 3/28 20:00:15.081 [Seeker@16bc266] MARK 1 currRecord=null enc=Hauppauge WinTV-7164 Analog Capture #4 clients=[] ir=false
Tue 3/28 20:00:15.082 [Seeker@16bc266] Enabling data scanning for input Hauppauge WinTV-7164 Analog Capture #4 Digital TV Tuner
Tue 3/28 20:00:17.003 [EPG@37ccb4] EPGDS Hauppauge WinTV-7164 Analog Capture Digital TV Tuner found a capture device to start data scanning with:Hauppauge WinTV-7164 Analog Capture #4 Digital TV Tuner

It thinks the tuner isn't recording, and then enables if for scanning and kicks the EPG to start scanning. The question is, why does Seeker think the tuner is not in use?

[wnjj]

I think you can avoid this behavior by disabling data scanning on the tuner in the properties file. Look for or add settings like this:

epg_data_sources/*/disable_data_scanning=true

[kpbrwn]

I'll test it out tonight.


Thanks!

[EnterNoEscape]

I don't want to derail this too much, but I feel like this might be relevant. As far as I can tell Seeker on the encoding server doesn't have any way to know that it's not actually in control of a capture device. When you set up SageTV as an encoding server do you actually need to enable the capture devices on the encoding server that you want to make visible to the SageTV server that will be using the encoding server?

The reason I ask is because when you add a capture device, it hits the Scheduler and then Seeker starts to use them. This data scanning situation being seen in the logs wouldn't happen if the capture devices were not enabled on the encoding server.

[wayner]

@kpbrwn - I have a similar problem although not exactly the same and it seems to occur around the top of the hour for some reason. Check out this post I made in another thread:
https://forums.sagetv.com/forums/sho...42&postcount=8

[kpbrwn]

Originally Posted by wayner

@kpbrwn - I have a similar problem although not exactly the same and it seems to occur around the top of the hour for some reason. Check out this post I made in another thread:
https://forums.sagetv.com/forums/sho...42&postcount=8

I left my 2 HDPVRs in a Win7 VM cause I'm using a multi-zone USB-UIRT setup. I've had no issues at all with them.

My OTA issues usually happened at the top of the hour also; when the signal recovered it was usually recording another channel.

wnjj suggestion of setting the following seems to have made things work last night. I'll see what the rest of the week holds.

epg_data_sources/*/disable_data_scanning=true

Thanks for the reply.

[kpbrwn]

Originally Posted by wnjj

I think you can avoid this behavior by disabling data scanning on the tuner in the properties file. Look for or add settings like this:

epg_data_sources/*/disable_data_scanning=true

Thanks wnjj!!
Seems to have made things work last night. I'll see what the rest of the week holds.

Thanks again!

[kpbrwn]

Originally Posted by EnterNoEscape

I don't want to derail this too much, but I feel like this might be relevant. As far as I can tell Seeker on the encoding server doesn't have any way to know that it's not actually in control of a capture device. When you set up SageTV as an encoding server do you actually need to enable the capture devices on the encoding server that you want to make visible to the SageTV server that will be using the encoding server?

The reason I ask is because when you add a capture device, it hits the Scheduler and then Seeker starts to use them. This data scanning situation being seen in the logs wouldn't happen if the capture devices were not enabled on the encoding server.

So if I'm understanding you correctly, I don't have to add the tuner to encoding server. The main Sage server would still see it???

It never even dawned on me to do it that way.
I guess I would only have to add tuners that needs some special tuning functionality (ie. multi-zone USB-UIRT that I could only get to work in Windows).

Thanks!

[EnterNoEscape]

Originally Posted by kpbrwn

So if I'm understanding you correctly, I don't have to add the tuner to encoding server. The main Sage server would still see it???

It never even dawned on me to do it that way.
I guess I would only have to add tuners that needs some special tuning functionality (ie. multi-zone USB-UIRT that I could only get to work in Windows).

Thanks!

I'm not exactly saying it so much as asking if it's true, but if it's still possible to use the tuner on the encoding server without enabling it on the encoding server, that would likely help you out.

[Narflex]

Originally Posted by EnterNoEscape

I'm not exactly saying it so much as asking if it's true, but if it's still possible to use the tuner on the encoding server without enabling it on the encoding server, that would likely help you out.

I'm fairly sure you're right about this where you don't want to have the devices enabled for real on the encoding server since the encoding server bypasses all of the Seeker logic to do recording. When you do need to setup tuning, you should still be able to do that, but then just remove the source after the setup process because the tuning settings should still stick around for that device (it just won't be linked to any kind of EPG lineup which means Seeker won't try to use it).

[wayner]

Originally Posted by kpbrwn

I left my 2 HDPVRs in a Win7 VM cause I'm using a multi-zone USB-UIRT setup. I've had no issues at all with them.

My OTA issues usually happened at the top of the hour also; when the signal recovered it was usually recording another channel.

Just to be clear - I was having temporary halts with both my HD-PVR and with my OTA tuner(s) which are Hauppauge 1850 and HDHR. The HD-PVR halts are upon starting a recording, the OTA halts are at the top of the hour and the recording generally will recover within a few minutes. Unlike you my tuner does return to the correct channel when the recording resumes.