recordings interrupt with "http_streamer_t: http write error", works with WinTV app [WinTV-DualHD]

apologies for this duplicate, mistakenly posted outside the ‘plex pass member area’ the first time at https://forums.plex.tv/discussion/298751/recordings-interrupt-with-http-streamer-t-http-write-error-works-with-wintv-app-wintv-dualhd/p1

I’m recording a 1-hour show at the same time (3pm local) on the same channel each day. Sometimes (2 out of about 10 recordings so far) it’ll record the entire show, but it most of the time it stops prematurely after a seemingly random amount of time into the show. Sometimes it’s 48 minutes, sometimes 30 seconds, etc. There’s no issue with disk space filling.

As a sanity check on the tuner hardware and device drivers, I installed the WinTV 8.5 app that the tuner comes with a license for and had it record the same program. It records the entire hour every time. Since it’s dual-tuner, I’ve even tried having them both record the show at the same time, and the WinTV 8.5 app records the entire hour and Plex will have it interrupted even when they’re both recording at the same time, so AFAICT it has nothing to do with source signal / tuner hardware / device driver.

Each time it happens, the tuner service log shows the same pattern - lots of log entries as the stream starts recording, then a warn-level log entry of “http_streamer_t: http write error” at which point the stream stops recording (the partial recording shows up in plex fine, but I’d rather have the full show recorded :slight_smile:

Here’s an example from when it stopped after 1 minute and 25 seconds:

Dec 07, 2017 15:00:03.761 [5864] INFO - * tvs_program_streamer::tuning_thread. Finished tuning thread for program triplet://0:1817:3
Dec 07, 2017 15:00:03.816 [15772] INFO - * CTSStreamWaiter::GetPidToCheck. PID to check 49
Dec 07, 2017 15:00:03.816 [15772] INFO - * CTSStreamWaiter::GetVideoPid. Video PID 49
Dec 07, 2017 15:00:03.816 [15772] INFO - * CTSStreamWaiter::ProcessStream. Found first not encrypted packet. Start streaming
Dec 07, 2017 15:01:28.084 [6148] WARN - [E] http_streamer_t: http write error
Dec 07, 2017 15:01:28.084 [4948] INFO - * http_streamer_t::send_thread_func: removing http client
Dec 07, 2017 15:01:28.125 [4948] INFO - * http_streamer_t::send_thread_func: all clients are deleted. Setting exit flag

Each time the stream stops recording with that same ‘http_streamer_t: http write error’ message. Searching across Plex Tuner Service*.log shows the seemingly random amount of time into each recording where it stops:

Nov 16, 2017 15:14:18.204 [10588] WARN - [E] http_streamer_t: http write error
Nov 20, 2017 15:50:44.950 [10384] WARN - [E] http_streamer_t: http write error
Nov 21, 2017 15:04:50.265 [2500] WARN - [E] http_streamer_t: http write error
Nov 22, 2017 15:57:08.747 [13372] WARN - [E] http_streamer_t: http write error
Nov 23, 2017 15:30:01.326 [13372] WARN - [E] http_streamer_t: http write error
Nov 26, 2017 15:44:44.776 [12796] WARN - [E] http_streamer_t: http write error
Nov 27, 2017 15:06:09.580 [0588] WARN - [E] http_streamer_t: http write error
Nov 28, 2017 15:07:58.586 [10360] WARN - [E] http_streamer_t: http write error
Nov 29, 2017 15:14:36.591 [12796] WARN - [E] http_streamer_t: http write error
Nov 30, 2017 15:03:42.600 [10360] WARN - [E] http_streamer_t: http write error
Dec 01, 2017 15:31:11.586 [12796] WARN - [E] http_streamer_t: http write error
Dec 07, 2017 15:01:28.084 [6148] WARN - [E] http_streamer_t: http write error

The tuner service log entries when the recording stops all say the same thing after the http write error happens, but here’s one full instance of it in case it helps:

Dec 07, 2017 15:01:28.084 [6148] WARN - [E] http_streamer_t: http write error
Dec 07, 2017 15:01:28.084 [4948] INFO - * http_streamer_t::send_thread_func: removing http client
Dec 07, 2017 15:01:28.125 [4948] INFO - * http_streamer_t::send_thread_func: all clients are deleted. Setting exit flag
Dec 07, 2017 15:01:28.135 [3700] INFO - * streamer_container_t::control_thread. Removed disconnected streamer a88fd0b8-139b-4aed-84f4-a725e9c8f3a5
Dec 07, 2017 15:01:28.136 [3700] INFO - * streamer_container_t::delete_streamer. Last streamer was deleted. Stop program streamer
Dec 07, 2017 15:01:28.136 [3700] INFO - * dvb_program_streamer_t::stop. Stoping program streamer for channel triplet://0:1817:3
Dec 07, 2017 15:01:28.136 [3700] INFO - * transponder_streamer::stop_channel. Stop request for channel triplet://0:1817:3
Dec 07, 2017 15:01:28.142 [15772] INFO - * CTVSStreamSource::RemoveAllPids. Removing PIDs for client triplet://0:1817:3
Dec 07, 2017 15:01:28.142 [3700] INFO - * transponder_streamer::start_idle_timer
Dec 07, 2017 15:01:28.411 [10156] INFO - * device_manager_t::idle_timer_func. Stream container for channel triplet://0:1817:3 on device dvb#bda#0#@device:pnp:\?\usb#vid_2040&pid_826d#0013955564#{71985f48-1ca1-11d3-9cc8-00c04f7971e0}{510162d9-2f7e-49e7-907b-dbd3a5a15eb9} is idle. Deleting it.
Dec 07, 2017 15:01:37.817 [14196] INFO - * Stopping graph
Dec 07, 2017 15:01:37.822 [15772] INFO - * StopDevice()
Dec 07, 2017 15:01:38.086 [15772] INFO - * stop_graph: hr=0, state=0
Dec 07, 2017 15:01:38.433 [10156] INFO - * device_manager_t::idle_timer_func. Device dvb#bda#0#@device:pnp:\?\usb#vid_2040&pid_826d#0013955564#{71985f48-1ca1-11d3-9cc8-00c04f7971e0}{510162d9-2f7e-49e7-907b-dbd3a5a15eb9} is idle. Unloading it.
Dec 07, 2017 15:01:38.433 [10156] INFO - * transponder_streamer::stop_idle_timer
Dec 07, 2017 15:01:38.433 [10156] INFO - * CTVSStreamSource::Term. Waiting for streaming thread to stop
Dec 07, 2017 15:01:38.445 [10156] INFO - * CTVSStreamSource::Term. Streaming is stopped
Dec 07, 2017 15:01:38.446 [10156] INFO - * CTVSStreamSource::Term. Stream source is stopped
Dec 07, 2017 15:01:39.090 [14196] INFO - * transponder_streamer::idle_thread_func finished

I’ve checked the Application and System windows event logs but nothing shows up anywhere near that timestamp

NOTE: the same issue does happen with other shows being recorded on other channels, but I have more data points about this particular show so using it for this post.