Recording not ending. Partial or non-existent recordings. Commercials not removed

[dshanks01]

Server Version#: 1.20.2.3402
Player Version#: N/A
Tuner Make/Model: locast2plex 0.5.3
Guide/Lineup name: Broadcast TV Seattle-Tacoma OTA Broadcast
Using XMLTV?: I’m using whatever guide data Plex automatically configured when it noticed I’m in the Seattle/Tacoma area.
Channel number/Name: Problem has been seen on channels 5.1, 7.1, 9.1 and 13.1

plexmediaserver and locast2plex are running on the same system, Mint 19.3 kernel 4.15.0-117-generic. No Docker.

This report is a grab bag of problems I’m occasionally having with the Live TV/DVR function of Plex. Most of the time it works perfectly. And then there are times like last night when the following problems were observed:

This morning,

• two shows recorded last night are still “recording” this morning
• most of one of those two shows has disappeared
• the other of those shows remains in the .grab folder
• a third show, recorded last night, is apparently split between its show folder and the .grab folder
• commercials were not removed from that third show

Most of the time the lowcast2plex/plexmediaserver interface works correctly. When a show is scheduled for recording, Plex gets the video stream from locast2plex, records the show, runs the commercial remover, and copies the show into my TV shows library. On multiple occasions, however, I have checked Plex several hours later and discovered that Plex is still “recording.” The shows it’s “recording” have ended, but Plex appears not to know it. The video file from the recording ends up missing, truncated, or otherwise improperly post-processed.

I’ve attached a screen shot of my Plex DVR screen to show what I’m seeing. The screen shot was taken a ~9AM the morning after.
Notes:

• Two shows are still “recording” even though the last one finished at 3AM.
• I found a ~14 minute partial video from The Late Show episode (which Plex shows still recording) is in my TV shows library, and commercials have been removed. The video segment begins sometime in the middle of the show and ends at a commercial break. There is one deleted commercial break in the middle of the video segment.
• The Nova episode (which Plex shows still recording) is NOT in my TV shows library at all. It remains in Plex’s .grab folder.
• A four minute segment from The Tonight Show remains in Plex’s .grab folder. The rest of the show is in its proper place in the TV shows library. It does not appear that any commercials were removed from the show even though commercials have been correctly removed in the past.

I’m aware that locast2plex is not a supported “tuner.” I’m hoping that the vast Plex user base will be able to help me figure out what’s going on. Also, the problems seem to be on the DVR side of the DVR/tuner interface (e.g. commercials not removed).

Thanks for any suggestions anyone can make for how to solve these problems.

[pshanew]

There was a fairly significant issue with “hung” recordings for many users a few years ago. It was largely mitigated by updates server releases. When I experienced it at the time, it was always accompanied by hung transcoding sessions which never completed. I’m on macOS and it’s very easy to see when these occur (the Plex menu icon shows the active transcoding sessions). You can see something similar on Linux by running the following (assuming PMS is running as user ‘plex’):

sudo ps -u plex

Assuming you have no legitimate recordings ongoing at the time, and the server is otherwise unused, you can assume that any “Plex Transcoder” processes are hung. You can try killing these to see if the recordings then show as complete in the client. Something like:

sudo kill -TERM process_id

Or, if that doesn’t kill it gracefully, end it immediately with:

sudo kill -KILL process_id

As to why this occurs, at the time, it was most often (always?) on channels on which I had marginal signal strength. I think this caused some issues for the transcoder, causing it to hang. I understand locast is streaming service, but it could be that the streams are being interrupted for some reason; that would also explain your partial recordings.

Here’s a good starting point if you’d like to read about some of the previous issues:

Status of "100% complete" recording bug

Since 1.7, I and many others have found DVR recording to be unreliable, occasionally (or frequently) reaching “100% complete” on a recording but then getting stuck, displaying a red “recording” circle in the Recording Schedule rather than a white “play” triangle, and never adding the recording to the library. Instead, a corrupt file remains in the .grab folder. Here’s a review of just some of these reports: Given that the DVR feature is no longe…

There’s a summary of the existing threads at the time discussing the problem.

[dshanks01]

Thanks for this. That’s part of the puzzle.

Before I respond to your suggestions, I want to update the state of the system. At some point between when I initially reported the problems and now, The Tonight Show recording finished without any intervention by me. Why it took over nine hours after the show ended to complete processing the recording, I can’t imagine. But it appears that’s what happened. So now instead of “Why is The Tonight Show still recording?,” we have “Why did it take nine hours to post process the Tonight Show recording.” It’s never done that before, and there was no CPU-consuming process running at the time.

Per your suggestion, there are indeed two plex transcoder processes running. Here’s the ps output:

david@shankscloud:~$ ps -ef |grep -i transcode
david    19232 32718  0 11:13 pts/1    00:00:00 grep --color=auto -i transcode
plex     24631 15443  0 01:30 ?        00:01:40 /usr/lib/plexmediaserver/Plex Transcoder -noaccurate_seek -ignore_unknown -scan_all_pmts -1 -rw_timeout 30000000 -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 30 -fflags +discardcorruptts+fillwallclockdts -probesize 20000000 -i http://127.0.0.1:6077/watch/1572389492146 -map 0:V? -codec:V copy -map 0:a? -codec:a copy -map 0:s? -codec:s copy -break_non_keyframes 1 -segment_format mpegts -f ssegment -individual_header_trailer 0 -segment_time 1 -segment_start_number 0 -segment_time_delta 0.25 -segment_list http://127.0.0.1:32400/video/:/transcode/session/6c7a8748-ea52-4d94-844f-590a32fcae2f/c496c639-3527-4509-aa40-27c8784bc9e5/seglist?X-Plex-Http-Pipeline=infinite -segment_list_type csv -segment_list_size 5 -segment_list_separate_stream_times 1 -segment_list_unfinished 1 -max_delay 5000000 -map_metadata -1 -map_chapters -1 media-%05d.ts -y -nostats -loglevel quiet -loglevel_plex error -xioerror -progressurl http://127.0.0.1:32400/video/:/transcode/session/6c7a8748-ea52-4d94-844f-590a32fcae2f/c496c639-3527-4509-aa40-27c8784bc9e5/progress
plex     24688 15443  6 01:30 ?        00:40:33 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesize 20000000 -i http://127.0.0.1:32400/livetv/sessions/6c7a8748-ea52-4d94-844f-590a32fcae2f/7e62e937-4317-4125-a077-8461acc5c326/index.m3u8?offset=-1.000000&X-Plex-Token=kvnSxEfDqqcMK7rMtLMh -filter_complex [0:0]scale=w=1280:h=720[0];[0]format=pix_fmts=yuv420p|nv12[1] -map [1] -codec:0 libx264 -crf:0 16 -r:0 30 -preset:0 veryfast -x264opts:0 subme=1:me_range=4:rc_lookahead=10:me=hex:8x8dct=0:partitions=none -map 0:1 -codec:1 copy -copypriorss:1 0 -f mpegts -map_metadata -1 -map_chapters -1 /home/plex/tv/.grab/f1e162b691dbdc18e9247fff61ebe43f77c67bcd-b098b33f8a405814a7d2dbd52d7aa6772708be5c/NOVA (1973) - S46E16 - Ice Worlds.ts -y -nostats -loglevel quiet -loglevel_plex error -xioerror -progressurl http://127.0.0.1:32400/video/:/transcode/session/7e62e937-4317-4125-a077-8461acc5c326/31080a8e-1e40-43ad-80ff-53a9800eee94/progress

Both processes appear to be related to Plex continuing to record the NOVA program despite the fact that Plex says the recording is 100% complete (see below). This seems to be exactly the problem people were reporting back in 2017, but it cannot be a signal strength issue for me. Locast2plex is a streaming service, so there’s no signal to fall off. Still, it may be something in the interface between Plex and locast2plex. I’ve reported the problem to them too, to see if they have any ideas.

I tried to gracefully terminate the transcode process with sigterm, sighup, and sigint before resorting to sigkill. Ffmpeg (on which Plex transcode is based) is supposed to clean up and exit upon receiving sigint. It’s behavior seems to indicate that the transcode process was hung. Killing the transcode from locast2plex also terminated the associated transcode to and from the Plex server, which seems to indicate that process was not hung.

After terminating the transcode process, the show being recorded was copied into my TV shows library. So that seems to solve one mystery (though it leaves the mystery of how the Plex transcode process ended up hung). The other thread you referenced (thank you!) doesn’t provide any clues about how to fix the problem, other than to wait for Plex engineering to fix it (assuming they look at it at all; locast2plex is unsupported). I frequently with Plex was open source so I could get some idea of what’s going on inside.

Other remaining mysteries:

• Why did one show recorded last night end up only partially recorded. I got 14 minutes of video from a one hour show.
• Why did another show take over nine hours to post-process after its recording should have ended.

[pshanew]

My assumption from experiencing the problem with an OTA tuner was that it was triggered by the transcoder being starved for data temporarily, such as when the tuner lost its lock on a channel and then regained it (or sometimes didn’t). It’s possible that something similar could happen with a streaming service if the stream temporarily dropped for some reason and then recovered (or didn’t). If this happened, you could end up with either a partial recording, one which hung at 100%, or both.

I don’t recall what fixes/mitigations were added specifically to address this server-side; I only know that it did improve drastically. Over the past year and a half or so I can only recall this occurring once. I didn’t think much about it at the time, I just reflexively killed the ongoing transcoding sessions and the recording was successfully added to my library. Perhaps some edge case still exists where this problem can occur, and locast2plex is good at triggering it.

Your server’s debug logs might show something interesting. If you have those from the timeframe of the problematic recordings upload them and I’ll have a look. Though, again, it’s been a long time since this was a regular occurrence on my system; I’ll have to try to remember what to look for.

[dshanks01]

Appreciate the help and the pointers.

Sounds like the transcoder doesn’t handle bursty video data very gracefully. I’ll see if I can track something more specific down. Or maybe someone on the locast2plex github has some ideas.

Thanks again.

[CraigA57]

This thread seems to be more technical than the one I posted to about this issue

Live TV recordings sometimes don't appear to save

Upgraded to latest Plex Media Server [image] Issue still exists. I tried deleting the record request, then setup record again. Still nothing in the DVR section about the “upcoming” recording: [image] [image]

My setup is an Ubuntu 16.04 LTS x64, 8-core AMD FX-8120 system with 16GB Ram, 60GB SSD (for OS only), 22 TB RAID-5 disk. Horsepower, storage , memory shouldn’t be issues, though the system is used for a lot more development things, i.e. not dedicated only to Plex. This said the load average is usually below 1, but PLEX activity will occasionally push it up past 8.

I am seeing this, which I know isn’t true, it just finished recording a show:

This locast2plex console shows this:

----------------------------------------
frame=54385 fps= 30 q=-1.0 Lsize=  222021kB time=00:30:12.78 bitrate=1003.3kbits/s    
video:156204kB audio:42487kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 11.741563%
Exiting normally, received signal 15.
127.0.0.1 - - [06/Oct/2020 15:21:23] "GET /lineup.json HTTP/1.0" 200 -
127.0.0.1 - - [06/Oct/2020 15:21:46] "GET /lineup.json HTTP/1.0" 200 -

I don’t know how to get Plex’s attention other than to post here.

[dshanks01]

Hi Neighbor

Thanks for the reference. It’s good (sort of) to know that this problem is not unique to my system. Like one commenter, I’d like to see a Plex engineer on the thread asking questions or providing information. But, having been on the engineering side of the conversation, I understand why Plex doesn’t expose their engineers to us. I also understand why they’re unlikely to devote engineering resources to unsupported configurations.

My system is similar to yours. I know it’s not starved for CPU, memory or disk space or I/O, just like yours.

I’ve never seen the “Device not found” error or any other error for the locast2plex device in the DVR setup screen. As far as I can tell, the locast2plex interface for configuration works exactly like the one for h. On the other hand I may have found a smoking gun. I’m not enough of a Python guy to know if this is normal or not.

In the middle of two of the shows last night, one of the locast2plex main.py processes (it apparently forks and runs as two processes) threw two exceptions in a row. They were either caused by or lead to a broken pipe (see below). But the exception did not kill either of the main.py processes. Both have been running since I started them on September 20 and have survived many Python exceptions. I note that the exceptions I observed immediately follow the Exiting normally, received signal 15 that you have also observed.

Oct 06 00:07:46 shankscloud locast2plex[20984]: [366B blob data]
Oct 06 00:07:46 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:07:46] "GET /lineup_status.json HTTP/1.0" 200 -
Oct 06 00:07:46 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:07:46] "GET /discover.json HTTP/1.0" 200 -
Oct 06 00:07:46 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:07:46] "GET /lineup_status.json HTTP/1.0" 200 -
Oct 06 00:07:50 shankscloud locast2plex[20984]: [hls,applehttp @ 0x562dbda30900] Opening 'https://sea.locastnet.org/proxy/sea/kiro_src266994704.ts' for reading
Oct 06 00:07:50 shankscloud locast2plex[20984]: [hls,applehttp @ 0x55a2483e9900] Opening 'https://sea.locastnet.org/proxy/sea/king_src266994686.ts' for reading
Oct 06 00:07:50 shankscloud locast2plex[20984]: [290B blob data]
Oct 06 00:07:50 shankscloud locast2plex[20984]: video:258094kB audio:47907kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 10.669032%
Oct 06 00:07:50 shankscloud locast2plex[20984]: Exiting normally, received signal 15.
Oct 06 00:07:50 shankscloud locast2plex[20984]: Traceback (most recent call last):
Oct 06 00:07:50 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 293, in _handle_request_noblock
Oct 06 00:07:50 shankscloud locast2plex[20984]:     self.process_request(request, client_address)
Oct 06 00:07:50 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 321, in process_request
Oct 06 00:07:50 shankscloud locast2plex[20984]:     self.finish_request(request, client_address)
Oct 06 00:07:50 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
Oct 06 00:07:50 shankscloud locast2plex[20984]:     self.RequestHandlerClass(request, client_address, self)
Oct 06 00:07:50 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 657, in __init__
Oct 06 00:07:50 shankscloud locast2plex[20984]:     self.finish()
Oct 06 00:07:50 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 716, in finish
Oct 06 00:07:50 shankscloud locast2plex[20984]:     self.wfile.close()
Oct 06 00:07:50 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/socket.py", line 283, in close
Oct 06 00:07:50 shankscloud locast2plex[20984]:     self.flush()
Oct 06 00:07:50 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/socket.py", line 307, in flush
Oct 06 00:07:50 shankscloud locast2plex[20984]:     self._sock.sendall(view[write_offset:write_offset+buffer_size])
Oct 06 00:07:50 shankscloud locast2plex[20984]: error: [Errno 32] Broken pipe
Oct 06 00:07:51 shankscloud locast2plex[20984]: [290B blob data]
Oct 06 00:07:51 shankscloud locast2plex[20984]: video:280236kB audio:46545kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 10.523701%
Oct 06 00:07:51 shankscloud locast2plex[20984]: Exiting normally, received signal 15.
Oct 06 00:07:51 shankscloud locast2plex[20984]: Traceback (most recent call last):
Oct 06 00:07:51 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 293, in _handle_request_noblock
Oct 06 00:07:51 shankscloud locast2plex[20984]:     self.process_request(request, client_address)
Oct 06 00:07:51 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 321, in process_request
Oct 06 00:07:51 shankscloud locast2plex[20984]:     self.finish_request(request, client_address)
Oct 06 00:07:51 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 334, in finish_request
Oct 06 00:07:51 shankscloud locast2plex[20984]:     self.RequestHandlerClass(request, client_address, self)
Oct 06 00:07:51 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 657, in __init__
Oct 06 00:07:51 shankscloud locast2plex[20984]:     self.finish()
Oct 06 00:07:51 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/SocketServer.py", line 716, in finish
Oct 06 00:07:51 shankscloud locast2plex[20984]:     self.wfile.close()
Oct 06 00:07:51 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/socket.py", line 283, in close
Oct 06 00:07:51 shankscloud locast2plex[20984]:     self.flush()
Oct 06 00:07:51 shankscloud locast2plex[20984]:   File "/usr/lib/python2.7/socket.py", line 307, in flush
Oct 06 00:07:51 shankscloud locast2plex[20984]:     self._sock.sendall(view[write_offset:write_offset+buffer_size])
Oct 06 00:07:51 shankscloud locast2plex[20984]: error: [Errno 32] Broken pipe
Oct 06 00:08:06 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:06] "GET /discover.json HTTP/1.0" 200 -
Oct 06 00:08:06 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:06] "GET /lineup_status.json HTTP/1.0" 200 -
Oct 06 00:08:11 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:11] "GET /device.xml HTTP/1.1" 200 -
Oct 06 00:08:12 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:12] "GET /lineup.json HTTP/1.0" 200 -
Oct 06 00:08:12 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:12] "GET /discover.json HTTP/1.0" 200 -
Oct 06 00:08:12 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:12] "GET /lineup_status.json HTTP/1.0" 200 -
Oct 06 00:08:12 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:12] "GET /discover.json HTTP/1.0" 200 -
Oct 06 00:08:12 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:12] "GET /lineup.json HTTP/1.0" 200 -
Oct 06 00:08:12 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:12] "GET /lineup_status.json HTTP/1.0" 200 -
Oct 06 00:08:13 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:13] "GET /watch/1572389491672 HTTP/1.1" 200 -
Oct 06 00:08:13 shankscloud locast2plex[20984]: 127.0.0.1 - - [06/Oct/2020 00:08:13] "GET /watch/1572389491219 HTTP/1.1" 200 -

The only error I see that might be associated with the third show is

Oct 06 03:08:18 shankscloud locast2plex[20984]: [hls,applehttp @ 0x55fba9dc6900] Failed to reload playlist 0

But the system was already in a possibly unstable state due to the prior errors. And as I said up thread, the recording completed properly once I killed its hung Plex Transcoder process. So I’m going to ignore that error for now.

Moving forward, I’m turning off the “Convert Video While Recording” feature (see below). I want to see if that improves things. Previously it was set to “Transcode.” Plex says Transcode can improve compatibility (With what? How? and Why? Plex help and documentation truly sucks), but they also say it’s a Beta feature. Maybe turning it off will improve stability.

Now I’m off to dig in the Plex logs to see if I can find any smoking guns over there. I’ll also be reporting the exceptions I see in the locast2plex github project.

I also have to wonder if limiting an instance of locast2plex to a single tuner would work around this problem. I’ve only seen it when two programs are recording at the same time. Maybe I should spawn multiple locast2plex units (I’m using systemd to launch it), each on their own port and advertising a single tuner. Something to think about.

[CraigA57]

I’m also looking into faux-tuner a Node.js app based on locast2plex. So far it looks pretty raw, doesn’t work yet, and is coming up with errors like “can’t find /” in the browser. But promises the ability to tie 4 TV streaming services together including Locast, PlutoTV, IPTV / HLS Streams (coming soon), and Redbox Live TV (coming soon)

It’s possible locast2plex is is tripping up Plex DVR states or throwing weird exceptions. This said, why did it work solidly for several months and a few Plex updates before deciding to tank?

I’m leaning more toward your original statement that this is a Plex DVR problem, likely multiple problems.

I know I didn’t use Plex Live TV & DVR at all until recently when I found locast2plex. I also live in a TV black hole and tried high, low, and medium gain RF antennas. RF reception just isn’t going to happen where I am, behind a hill from all antennas. My impression is Locast started a revolution making a number of applications possible where previously only $100-$150/month cable would work. Before Locast cable prices helped me make the decision I could live without Cable business model no matter what it did to my TV viewing. But HD 4K 45" TV’s make great computer monitors and with a Roku+Plex, a mostly good replacement for $150/month cable.

I’m beginning to wonder how hard it would be to write a C/C++ locast2plex? Or break down and dig deep into Python so I can fix the problems myself. I’m an electrical engineer, embedded systems, so circuit design and certain targeted software are in my realm of experience. I’m overloaded enough with tasks that the most likely outcome is I’ll wait, uh, patiently.

I’m also sitting here watching what plex is doing to my system. Here’s a snapshot:

  1  [|||||||||||||||||||||||||||||||                           46.7%]   5  [|||||||||||||||||||||||||||||||||                         50.3%]
  2  [|||||||||||||||||||||||||||||||||                         49.3%]   6  [|||||||||||||||||||||||||||||||||                         49.4%]
  3  [||||||||||||||||||||||||||||||||                          48.0%]   7  [|||||||||||||||||||||||||||||||                           45.7%]
  4  [|||||||||||||||||||||||||||||||||                         51.0%]   8  [||||||||||||||||||||||||||||                              42.1%]
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||5.11G/15.6G]   Tasks: 252, 1123 thr; 20 running
  Swp[|                                                   23.2M/7.94G]   Load average: 5.12 5.22 4.29 
                                                                         Uptime: 04:39:38

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 1036 plex       20   0 1295M  226M 17844 R 262.  1.4  8:48.58 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1206 plex       20   0 1715M  205M 18080 S 67.8  1.3 13:08.75 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
29430 plex       20   0 1830M  250M 18244 S 17.1  1.6  9:05.62 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 hevc -analyzeduration 20000000 -p
 1068 plex       20   0 1295M  226M 17844 R 16.4  1.4  0:38.67 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1067 plex       20   0 1295M  226M 17844 R 14.5  1.4  0:38.65 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1055 plex       30  10 1295M  226M 17844 R 13.2  1.4  0:23.41 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1061 plex       30  10 1295M  226M 17844 R 13.2  1.4  0:23.84 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1062 plex       30  10 1295M  226M 17844 R 13.2  1.4  0:23.10 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1066 plex       30  10 1295M  226M 17844 S 13.2  1.4  0:23.42 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1059 plex       30  10 1295M  226M 17844 S 12.5  1.4  0:22.83 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1063 plex       30  10 1295M  226M 17844 S 12.5  1.4  0:22.86 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1065 plex       30  10 1295M  226M 17844 R 12.5  1.4  0:24.14 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1060 plex       30  10 1295M  226M 17844 S 11.8  1.4  0:23.38 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1057 plex       30  10 1295M  226M 17844 R 10.5  1.4  0:23.13 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1056 plex       30  10 1295M  226M 17844 R  9.9  1.4  0:22.93 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1058 plex       30  10 1295M  226M 17844 S  9.9  1.4  0:23.14 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1064 plex       30  10 1295M  226M 17844 R  9.9  1.4  0:23.40 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1037 plex       20   0 1295M  226M 17844 S  7.9  1.4  0:15.29 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1038 plex       20   0 1295M  226M 17844 S  7.9  1.4  0:14.47 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1039 plex       20   0 1295M  226M 17844 S  7.9  1.4  0:14.59 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1040 plex       20   0 1295M  226M 17844 S  7.9  1.4  0:15.55 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1041 plex       20   0 1295M  226M 17844 R  7.9  1.4  0:14.38 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1044 plex       20   0 1295M  226M 17844 S  7.9  1.4  0:14.50 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1045 plex       20   0 1295M  226M 17844 S  7.9  1.4  0:14.41 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1244 plex       20   0 1715M  205M 18080 S  7.2  1.3  1:09.50 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1245 plex       20   0 1715M  205M 18080 S  7.2  1.3  1:10.03 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1042 plex       20   0 1295M  226M 17844 R  7.2  1.4  0:14.57 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1043 plex       20   0 1295M  226M 17844 R  7.2  1.4  0:15.46 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
15362 craig      20   0 2154M  133M 30540 S  6.6  0.8  2:03.20 transmission-gtk
15368 craig      20   0 2154M  133M 30540 S  6.6  0.8  1:14.57 transmission-gtk 
24184 plex       20   0 4388M  417M 45168 S  5.9  2.6  3:25.44 /usr/lib/plexmediaserver/Plex Media Server
23649 craig      25   5 3146M  425M  154M R  5.9  2.7  4:22.72 /home/install/linux/firefox/firefox/firefox-bin -contentproc -childID 2 -isForBrows
15521 craig      20   0 2308M  312M  250M S  4.6  2.0 16:42.46 /opt/VirtualBox/VirtualBoxVM --comment hh --startvm 4039c9ae-fe20-4964-8e37-a7c8beb
 1234 plex       30  10 1715M  205M 18080 S  4.6  1.3  0:26.48 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 5325 www-data   20   0  971M 67884 49540 S  4.6  0.4  0:08.24 /usr/sbin/apache2 -k start
15568 craig      20   0 2308M  312M  250M R  3.9  2.0 10:38.45 /opt/VirtualBox/VirtualBoxVM --comment hh --startvm 4039c9ae-fe20-4964-8e37-a7c8beb
 1592 craig      20   0  472M 54976 40784 S  3.3  0.3  0:05.92 SecureCRT
 1207 plex       20   0 1715M  205M 18080 S  3.3  1.3  0:28.15 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1794 craig      20   0 27668  5612  3192 R  3.3  0.0  0:00.38 htop
 1238 plex       30  10 1715M  205M 18080 S  3.3  1.3  0:26.72 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1213 plex       20   0 1715M  205M 18080 S  2.6  1.3  0:28.17 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1211 plex       20   0 1715M  205M 18080 S  2.6  1.3  0:28.41 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1210 plex       20   0 1715M  205M 18080 S  2.6  1.3  0:28.02 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1237 plex       30  10 1715M  205M 18080 S  2.6  1.3  0:26.97 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1232 plex       30  10 1715M  205M 18080 S  2.6  1.3  0:26.41 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1069 plex       20   0 1295M  226M 17844 S  2.6  1.4  0:07.36 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -live_start_index 0 -probesi
 1240 plex       30  10 1715M  205M 18080 S  2.0  1.3  0:25.73 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1235 plex       30  10 1715M  205M 18080 S  2.0  1.3  0:26.17 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio
 1212 plex       20   0 1715M  205M 18080 S  2.0  1.3  0:28.07 /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 ac3 -analyzeduratio

[pshanew]

@dshanks01

Plex says Transcode can improve compatibility (With what? How? and Why? Plex help and documentation truly sucks), but they also say it’s a Beta feature. Maybe turning it off will improve stability.

The docs go into it in a little more detail. Setting this to “Transcode” causes PMS to convert the video to H.264; otherwise, for OTA tuners, it’s generally going to be stored as mpeg2video. This improves compatibility as more devices support H.264 (so transcoding on-the-fly transcoding will be required less frequently). It also saves space, as H.264 is more space-efficient than mpeg2video.

Regardless, I’d certainly recommend setting this to disabled. I’ve used this to convert while recording in the past and I generally ended up with a greater number of failed recordings. I actually considered asking you about this earlier, but didn’t because I just assumed it would left at its default setting (disabled).

[dshanks01]

Faux-tuner sounds interesting, though if I can get locast2plex working properly I don’t see any advantage for my particular application. I really only care about being able to record shows from the major networks. When I lived in Portland, HDHomeRun met my needs. But my location in the Seattle area, like yours, appears to be shadowed by one or more hills. I can’t pull anything in with an antenna.

I’m curious why you think C or C++ would be a better implementation language. As an embedded software engineer, it appears to me that Python is perfectly adequate for the requirements of locast2plex. And it’s much easier to implement in and debug. We’re not trying to run it on resource limited systems, after all (at least I’m not).

After a bit of digging, my best guess is that this is an interface problem. Locast2plex appears to be trying to emulate the API of a particular 2015 firmware version of one model of HDHomeRun. It’s entirely possible that Plex is depending on some undocumented feature (read: bug) in the HDHomeRun firmware. It’s also possible that locast2plex incorrectly implements the API. Without the source code on the Plex side, it’s difficult to know who’s at fault.

All that said, the software engineer in me cringes at seeing unhandled exceptions in the locast2plex application, even if they don’t cause its processes to terminate. I’d never leave something like that in production code even if it’s “harmless.” But I also know that similar things are not uncommon in production web applications, so it’s difficult for me to evaluate the severity of the problem. I need to upgrade my copy of locast2plex to the latest version using Python3 to see if the problem is still there (and maybe send a patch to the project owner if it is).

For now, I"m going to see if the configuration change I mentioned above improves things. If it does, great (though I still need to upgrade). I will continue to report in this thread until I resolve this problem or give up.

[dshanks01]

The docs go into it in a little more detail. Setting this to “Transcode” causes PMS to convert the video to H.264; otherwise, for OTA tuners, it’s generally going to be stored as mpeg2video. This improves compatibility as more devices support H.264 (so transcoding on-the-fly transcoding will be required less frequently). It also saves space, as H.264 is more space-efficient than mpeg2video.

Interesting stuff. And I shouldn’t have taken that shot at Plex documentation. But it seems like every time I go looking for something, either I can’t find it, it’s outdated, or its obfuscated. As an example, I still can’t figure out if an Intel processor is absolutely required for HW transcode, regardless of GPU or if an AMD processor + Nvidia GPU can also be used. The documentation could be read to say either. The only thing I’m sure of is that an AMD GPU won’t help. But I digress.

There are hints in the locast2plex log that it may be sending H.264 video to Plex, negating any need for transcoding by Plex. This needs more research. Thanks for the pointer to the documentation for that feature.

[CraigA57]

@dshanks01

Faux-tuner sounds interesting, though if I can get locast2plex working properly I don’t see any advantage for my particular application. I really only care about being able to record shows from the major networks. When I lived in Portland, HDHomeRun met my needs. But my location in the Seattle area, like yours, appears to be shadowed by one or more hills. I can’t pull anything in with an antenna.

What you ultimately end up running is a matter of personal taste. Then there is that pregnant “if I can get locast2plex working properly…”

I was thinking more of debug. If I have two implementations of tuner then I can question if they experience the same problems, or if problems between the two with Plex being the “constant” might provide more information about which side of the interface boundary to investigate. As you point out, we don’t have code for Plex, nor do we have good documentation about what the interface of a “properly designed” tuner to Plex should look like. Plex is a “Black Box”. There are other ways to debug, this is just the first which occurred to me, not necessarily the “best”. So I tried out what was easy with results as I described.

@dshanks01

I’m curious why you think C or C++ would be a better implementation language. As an embedded software engineer, it appears to me that Python is perfectly adequate for the requirements of locast2plex. And it’s much easier to implement in and debug. We’re not trying to run it on resource limited systems, after all (at least I’m not).

Mostly because I’m a coding demon in C, and pretty good in C++, Design Patterns, etc. Python as a language looks straightforward, but managing Python libraries, Python environment, Python performance monitoring, Python code tuning, running Lint on Python code, and reading all the Python documentation is not. And for performance, Python can use libraries written in C/C++ if Python performance monitoring identifies some performance bottlenecks.

I do want to improve my skills in Python and have good respect for the language for many tasks, including AI+ML/Tensor type programs running in Jupyter Notebooks, which also fascinate me. But like everyone else, I only have 24 hours/day and the question is how to slice it up. I’m pretty fond of getting some sleep at night.

Otherwise, I agree, Python can get the job done on a sufficiently capable server and I don’t need C or C++ for only 4 MPEG streams on a monstrous highly performance optimized (each CPU capable of look-ahead branching and parallel instruction processing) 8-CPU server with NVIDIA GPU support (which Plex recognizes for hardware acceleration) while pulling 100W-300W out of the wall depending on CPU/GPU load. However C or C++ certainly won’t hurt system performance if a solution in this form is made available, as long as you don’t mind Plex activity taking a bigger chunk of server processing overhead on a system doing hundreds of other development related tasks. Look at the “htop” info I posted earlier. I don’t know what that one user was doing, but he, by himself, was consuming 50% to 100% of system resources for his Plex viewing. He was using most of available system resources all by himself, just to watch 1-1080p/5.1aac/h265 show using Plex. This consumption of resources can have a serious impact on separate processing of “TV Tuner” streams and other development activity. As soon as that user was done with his show the other three combined 1080p Plex sessions were only consuming between 5%-20% of system processing resources, meaning overall the system was using considerably less CPU/GPU processing and real wall power, leaving more processing and real power available for other activities. This person was using Chrome and I suspect this person shrank a 1080p H.265 encoded TV program to some non-standard size in the 320x200 size range so he could watch the show in the corner of his screen, PIP style. This might be the cause of captured CPU/GPU hemorrhage.

I followed your lead and turned off “Tuner” transcoding. I don’t expect this to make much difference, but we’ll let data drive that decision and see.

@dshanks01

After a bit of digging, my best guess is that this is an interface problem. Locast2plex appears to be trying to emulate the API of a particular 2015 firmware version of one model of HDHomeRun. It’s entirely possible that Plex is depending on some undocumented feature (read: bug) in the HDHomeRun firmware. It’s also possible that locast2plex incorrectly implements the API. Without the source code on the Plex side, it’s difficult to know who’s at fault.

Sounds reasonable to suspect.

@dshanks01

All that said, the software engineer in me cringes at seeing unhandled exceptions in the locast2plex application, even if they don’t cause its processes to terminate. I’d never leave something like that in production code even if it’s “harmless.” But I also know that similar things are not uncommon in production web applications, so it’s difficult for me to evaluate the severity of the problem. I need to upgrade my copy of locast2plex to the latest version using Python3 to see if the problem is still there (and maybe send a patch to the project owner if it is).

As someone who spent most of his decades long career designing high reliability medical and avionics systems, as opposed to “commercial grade” products which require substantially less engineering effort/skill, I share your concern.

@dshanks01

For now, I"m going to see if the configuration change I mentioned above improves things. If it does, great (though I still need to upgrade). I will continue to report in this thread until I resolve this problem or give up.

I’m there with you.

[pl_5309]

@dshanks01

I still can’t figure out if an Intel processor is absolutely required for HW transcode

It is NOT required, AMD CPU’s work just fine. The onboard GPU of many Intel processors was the first supported due to it’s driver support across Windows, Mac and Linux. It also produces compression results that are closest to cpu transcoding which might have an impact on remote streaming.

Convert Video While Recording only uses software for transcoding, so unless you really want to stress test your system leave it off. All it takes is for one person in a browser using closed captions and timeshifting for 4 cores to be utilized to near 100%. Number of cores is relative to software transcoding, single thread rating is critical when you mix in HW transcoding. STR of 1500 provides a safe cushion for 1080 broadcasts, higher if you have HD audio and non SRT subs in other files.

[dshanks01]

@pl_5309

It is NOT required, AMD CPU’s work just fine

Please don’t take this personally because I’m not really talking about you in particular. I think you probably know what you’re talking about. But I don’t know you, so I don’t know whether you know what you’re talking about or not. And I shouldn’t have to rely on other users to interpret what the documentation says. The documentation should be clear all by itself. That’s the issue, not whether or not an Intel processor is required for HW transcoding.

Also, thanks for pointing out that only some parts of the system are capable of using HW transcoding. One would think that if the capability is available, it’d be used everywhere. But I guess not.

So closed captioning does NOT use HW transcoding, eh? That’s a disappointment, because that’s the most time sensitive, CPU intensive thing my system does. I was hoping to eliminate that bottleneck by offloading the Plex Media Server part of my system to a dedicated Intel CPU. Too bad.

[dshanks01]

@dshanks01

There are hints in the locast2plex log that it may be sending H.264 video to Plex

Locast2plex does not send H.264 to Plex. It’s just streaming what it receives from locast to plex via HTTP. But it doesn’t seem like it would be difficult to insert MPEG to H.264 transcoding into locast2plex’s data path between locast and Plex. I wonder what that would break. Need to talk to the locast2plex developer.

[dshanks01]

@CraigA57

@dshanks01

Faux-tuner sounds interesting

What you ultimately end up running is a matter of personal taste. Then there is that pregnant “if I can get locast2plex working properly…”

I was thinking more of debug. If I have two implementations of tuner then I can question if they experience the same problems, or if problems between the two with Plex being the “constant” might provide more information about which side of the interface boundary to investigate.

But if I understood you correctly, faux-tuner is an aggregator of live stream virtual tuners. Adding it to the mix might possibly hide locast2plex’s problems. But it seems equally likely that adding another layer will introduce new bugs. And it certainly will add complexity to the system for no functional gain (to me). Or am I missing something?

@CraigA57

@dshanks01

I’m curious why you think C or C++ would be a better implementation language.

Mostly because I’m a coding demon in C, and pretty good in C++, Design Patterns, etc. Python as a language looks straightforward, but managing Python libraries, Python environment, Python performance monitoring, Python code tuning, running Lint on Python code, and reading all the Python documentation is not.

Well, I agree with you that Python library management is a pain in the ass. Too often, I have to tweak the Python scripts I’ve written to manage certain other aspects of my Plex infrastructure because the libraries I’m using keep subtly changing the API. “Open source: the code is the documentation. Also open source: the documentation changes without warning.”

@CraigA57

Otherwise, I agree, Python can get the job done on a sufficiently capable server and I don’t need C or C++ for only 4 MPEG streams

If it helps, don’t think of it as “4 MPEG streams.” Think of it as four 1500 Kbps data streams encapsulated in HTTP. The content of those HTTP streams doesn’t affect the CPU cycles required to copy the data from the internet source (locast) to the consumer on your network (Plex). That dinky bit of work could easily be handled by much smaller systems than your server. In fact, if you think that your development processes (or any other processes on your server) are interfering with the data pipeline through locast2plex, you’d probably be better off moving the process to another computer. A Raspberry Pi would be cheap and could easily handle the task of shoveling data between sockets. Locast2plex doesn’t do any transcoding, and it uses ffmpeg to do its data copying (already written in C and highly optimized), so there’s just not a lot of CPU intensive work in there to try to optimize.

@CraigA57

I followed your lead and turned off “Tuner” transcoding. I don’t expect this to make much difference, but we’ll let data drive that decision and see.

I experienced no problems last night after making that change. On the other hand, I had only one show scheduled to record last night. Tonight will be a more real world test. But, at the same time, I’ve had locast2plex running for over a week and only seen the problems above on two occasions. So even if I don’t see problems, it’ll be a while until I’m willing to pin the problem on the Transcode option.

The only change from turning Transcode off, for me, was that DVR recordings in my TV folder are MPEG encoded now instead of H.264. They’re bigger. But I have plenty of disk space. I was concerned that the ability to stream live TV to my Roku would be affected since Roku can’t consume MPEG directly. But when I tried it, Plex automatically transcoded to H.264/AAC and I was still able to pause, rewind, and fast forward live TV. My live football watching habits are safe (for now).

My next step will be to grab the latest version of locast2plex and see what issues that uncovers. The author has moved to Python3, but it’s a recent move so there may be unresolved problems after the change. For now we get to choose between the Python 2.7 version, which I don’t believe is being maintained; and the Python 3 version, which is being maintained but is too new to believe any newly introduced problems have been shaken out.

As before, I’ll continue to report here; especially since it doesn’t look like anyone from Plex will weigh in (for reasons both expected and understood).

[CraigA57]

@dshanks01

But if I understood you correctly, faux-tuner is an aggregator of live stream virtual tuners. Adding it to the mix might possibly hide locast2plex’s problems. But it seems equally likely that adding another layer will introduce new bugs. And it certainly will add complexity to the system for no functional gain (to me). Or am I missing something?

I don’t know, I didn’t think of that. I stopped spending time on faux-tuner when following instructions got it installed and it wouldn’t even bring up the config dialog.

I expected faux-tuner to be a standalone re-implementation of locast2plex, not a towering stack of API cards with Node.js calling a Python script, creating huge multi-language maintenance/support/debug issues. What lead me to think this was the case is the Faux-Tuner web site statement " Largely inspired by (and parts shamelessy stolen from) locast2plex." If all he stole from locast2plex is the Plex API to make his own software shim, then I’m not interested either.

There is no way to tell if faux-tuner is just another layered API without inspecting Node.js code, which if it isn’t working as-is out of the box I’m not inclined to do. It’s too green and I’m not looking for more projects use up my development time, unless they provide some form of compensation. Like Plex falls in the labor of love category.

@dshanks01

Well, I agree with you that Python library management is a pain in the ass. Too often, I have to tweak the Python scripts I’ve written to manage certain other aspects of my Plex infrastructure because the libraries I’m using keep subtly changing the API. “Open source: the code is the documentation. Also open source: the documentation changes without warning.”

Cython may be a way to “freeze” Python library development configuration issues, and might improve performance. I haven’t used Cython, so your mileage may vary. These days desktop hardware is so fast that almost any interpreted software will perform well enough.

This isn’t true for smaller embedded systems yet, but things are improving in the embedded ARM world too. Don’t get me started on DSP programming, that’s yet another intense domain of knowledge of pipeline optimization and numerical methods algorithms. ARM/DSP/FPGA are worlds which desktop programmers -really- don’t understand because they’re spoiled by massive amounts of CPU/GPU/ALU/NPU/Memory support and gigabit or higher speed network interfaces, basically almost unlimited programming resources and nearly unlimited wall power. [I added this paragraph because it helps to understand your open question, “As an embedded programmer…?”]

@dshanks01

If it helps, don’t think of it as “4 MPEG streams.” Think of it as four 1500 Kbps data streams encapsulated in HTTP.

Thanks for explaining. I haven’t looked closely at locast2plex code, just close enough to change it from default 2 streams to 4 streams/channels which Locast supports.

@dshanks01

My next step will be to grab the latest version of locast2plex and see what issues that uncovers. The author has moved to Python3…

Running Ubuntu 16.04 LTS I may not be able to follow this change as it may break other functioning systems. I haven’t bitten the bullet to upgrade to Ubuntu 20.04 because last time I made this kind of change I lost a month of full time work just to get everything running again; Asterisk upgrades, Apache upgrades, PHP upgrades, Perl upgrades, Python upgrades, etc. etc. all which broke existing configurations for phone, web services, email, KiCAD, FreeCAD, Git/SVN, gcc, Visual Code, SliMP3, type services. Last I heard Ubuntu 20.04 seriously broke KiCAD which is written in Python. FreeCAD is also written in Python. My server is a tool, not a development sandbox. As such I have to carefully consider change to a complex and fully functioning integrated system setup. And I’m not sure docker containers (or snap containers) are a “best” solution either, but the jury is still out on these solutions.

% python -V
Python 2.7.12

And other than a few nagging issues, locast2plex and Plex mostly work on the system I currently have/use. Someday I will be forced to upgrade, but it will be a major decision, not made lightly, to do so.

[dshanks01]

@CraigA57

I expected faux-tuner to be a standalone re-implementation of locast2plex

I took another look, and you’re right. It’s another tuner program written in Javascript. My mistake. Maybe there will be something there some day. OTOH, I know even less about developing in Javascript than I do Python.

@CraigA57

Cython may be a way to “freeze” Python library development configuration issues, and might improve performance.

I forgot all about Cython! Interesting thought.

@CraigA57

Running Ubuntu 16.04 LTS I may not be able to follow this change as it may break other functioning systems.

Python3 and Python 2.7 are designed to co-exist and should not interfere with each other. This web page, How To Install Python 3 and Set Up a Local Programming Environment on Ubuntu 16.04 (you don’t need the programming environment, you only need the interpreter), claims that Ubuntu 16.04 shipped with both versions installed, so you probably already have what you need to upgrade. Try this:

david@shankscloud:~$ python -V
Python 2.7.17
david@shankscloud:~$ python3 -V
Python 3.6.9
david@shankscloud:~$ 

Scripts written in Python3 are invoked with the python3 executable. Your existing Python programs will continue to use your existing python executable.

@CraigA57

Someday I will be forced to upgrade, but it will be a major decision, not made lightly, to do so.

That’s prudent. Unless you’re having problems, there’s no reason to upgrade. I only upgraded to try to track and debug the problem I’m having. But, at the same time, you can almost certainly upgrade locast2plex without any affect on the rest of your system.

[CraigA57]

@dshanks01

Python3 and Python 2.7 are designed to co-exist …

Now that you mention it, I knew this at one time. Thanks for the jog.

So I probably can run a Python3 based locast2plex.

% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.7 LTS
Release: 16.04
Codename: xenial

% python3
Python 3.5.2 (default, Jul 17 2020, 14:04:10)
[GCC 5.4.0 20160609] on linux

BTW, I recorded 3 channels of the “VP Debate” tonight with Tuner compression turned off. I think I’m keeping this setting. The system remained very responsive and all 3 programs showed in the library almost immediately after recording. This is the behavior I want.

I wrote a script which will convert to the type of compression I want using ffmpeg. For longer term storage I’ll just run that script on the .ts file. This usually produces a file with same playback characteristics at ⅓-¼ the file size.

Now if I could just figure out why Star Trek: Discovery won’t record.

[dshanks01]

@CraigA57

I recorded 3 channels of the “VP Debate” tonight with Tuner compression turned off. I think I’m keeping this setting. The system remained very responsive and all 3 programs showed in the library almost immediately after recording. This is the behavior I want.

I’m seeing the same thing. Turning Transcode off has improved the overall performance of the locast2plex/Plex subsystem. With any luck, that change alone will resolve the problem I originally brought to the forum. I also did not have problems last night (though the unhandled exception still exists in the python3 version of locast2plex). I won’t really believe my original problem is resolved until a significant amount of time has passed without seeing it.

@CraigA57

I wrote a script which will convert to the type of compression I want using ffmpeg. For longer term storage I’ll just run that script on the .ts file.

I don’t know if you’re aware, but you can have Plex invoke your script on freshly recorded video before moving it to your library. Take a look in DVR settings:

Unfortunately, the Plex documentation (my pet peeve!) gives ZERO information on how the script is invoked, what parameters (if any) or environment variables (if any) will be passed in, or what its inputs and outputs should be. And I’m not interested enough to do the experiments that would be required to determine those things empirically, or risk Plex making changes to their undocumented interface without saying anything.

@CraigA57

Now if I could just figure out why Star Trek: Discovery won’t record.

Isn’t that on CBS All Access? Locast2plex only has access to broadcast channels. Or are you telling me there’s a station in the Seattle area that broadcasts Star Trek: Discovery?

P.S. In an earlier comment I said that, without transcoding, recordings would be MPEG encoded instead of H.264. I took a look at last night’s recordings and all of them are H.264 (AKA AVC) without transcoding. It looks like the stations I’m recording encode their broadcasts in H.264. That’s yet another reason not to have Plex transcode the video it records (at least for me).

If you hadn’t already guessed, I’m still learning about broadcast video in the 2020s.