I tried the Alpha 1.15.0.573 and still getting the same issues.
I am still having that problem randomly. Nextpvr records with no errors.
Almost two weeks ago I reported that I installed an older version of Plex server ( 1.13.8.5395) on my test system, then connected my two HDHomerun Extends to it, and was able to flawlessly record all of my primary OTA programming. These are the same Extends and antenna connections I was using when I started getting the failed recording errors. No more failed recordings. I then purchased a HDHomerun Quatro and tested with that and everything work like a dream.
About 5 days later, I upgraded my test server to Alpha 1.15.0.573 and tried running everything again with the Alpha version using the Quatro, and once again, everything recorded without a problem. Even added one of the Extends to the server and tried 6 recordings at one time and everything worked perfectly.
Decided to make the leap, and installed 1.15.0.573 on my QNAP TS-1277 NAS along with the Quatro and one of the Extends. Install and HDHomerun setup went without a problem, and everything has been working great. Plex didn’t have any problems recording using the Quatro or Extend. I tried recording six 1/2 shows with commercial removal right off the bat and everything recorded without so much as a peep. All six recordings showed up in my Plex library about 6 minutes after the recordings ended.
Been running this way for days now and haven’t had any problems with the system and haven’t had any failed recordings. I stand by with what I said two weeks ago, the failed recordings are related to version 1.14.1.5488.
1 Like
I am on Windows 10
The failed recordings stopped over a week or two before version 1.14.1.5488.
I do get some off and on failed recordings still on Version 1.15.0.573
Thanks for the feedback. We are aiming for the 1.15.0 release to go beta soon
What do you mean? Why should it be sufficient?
The HDHomerun API is a simple web-style API. I can’t see any possible way in which the tuner would know nor care that requests are coming from multiple clients, and from the Plex side there is no way it can even tell unless the tuner gives a “no free tuners” error.
So its voodoo in my book. Or you could try an explanation as to how it might matter?
Gotta say that Plex as a media library is amazing. But wow there seem to be a lot of problems with the DVR stuff.
1 Like
I am on 1.14.1.5488 under Ubuntu 18.04 with an HDHomeRun Extend and I am also periodically getting the “Recording failed. Please check your tuner or antenna” error.
For trying to trace down this problem:
While the original patch antenna was initially working perfectly and one would hope seeing I am only 8 miles from the main group of towers in town with a clear line of sight (I can look with my eye directly above the antenna and see the towers), more recently there have been spats of garbled signal and in the midst of these failed recordings. This seemed to be focused on VHF channels and at certain times of day. I switched over to a higher end antenna with VHF enhancer rods and cell phone signal filtering (I live right next to a cell tower), specifically the ANTOP AT-401BV with a Smartpass filter set to its non-amplified mode. (I think 8 miles is too close for amplified mode, but really just after the VHF rods and cell filtration at this point.) Now the picture is always perfect, but I see this error message with the recording abruptly ending. The latest failure (on Feb 1st, 2019) was 49 minutes into the show, so not at the boundary of something else being recorded and to my knowledge only one Plex recording stream was going with no devices using a live stream from the tuner.
As for accounting for external factors:
My Plex server has plenty of disk space and a fast hardware RAID controller at that with no major tasks running at the time, so Plex should not have been tripped up by anything going on in the system. The system also has a plentiful amount of ECC memory and there are no signs whatsoever that the system itself is unstable; it just runs months at a time until planned downtime for maintenance. Pretty much the only services restarted is Plex and Pulseaudio as Plex and Pulseaudio seem to be lower quality than most other software on the box. The box (along with the tuner, networking gear, and some other stuff) is on an industrial grade pure sine UPS with twelve 12v batteries, so plenty of capacity and clean power to ride out the rather frequent power outages in the middle of the city with durations getting into the 15 to 53 minute range multiple times a year with many 1 to 5 minute outages every month. (Hey this is the USA, not some first world country apparently, making the investment in such a large UPS necessary for reliable operation.)
Had another failed recording. I managed to get the logs this time and it looks like what happens is the recording gets rescheduled at the 1 hour mark and soon after the recording is issued a stop command.
Here are logs of interest:
Feb 03, 2019 07:00:02.539 [0x7f9044ff4700] DEBUG - DVR:NewSchedule: Scheduled an operation ‘CBS News Sunday Morning - Episode 02-03’ on channel 2.1 on tuner 0 between 2019-02-03 06:00:00 and 2019-02-03 07:30:00
Feb 03, 2019 07:00:02.539 [0x7f9044ff4700] DEBUG - MediaRecorderVirtual: setting stop time to 2019-02-03 07:30:00
Note that the recording has been going for an hour now and the scheduler is scheduling a ‘new’ operation now. Next how the logs show the recording has stopped:
Feb 03, 2019 07:00:32.895 [0x7f90bb3ff700] DEBUG - Jobs: ‘/usr/lib/plexmediaserver/Plex Transcoder’ exit code for process 17913 is 0 (success)
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - DVR:Recorder: No more consumers, stopping.
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - DVR:Recorder: Asked to stop recording ‘CBS News Sunday Morning - Episode 02-03’ on channel 2.1.
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - DVR:Recorder: Stopping transcode session.
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - Job was already killed, not killing again.
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - Job was already killed, not killing again.
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - DVR:Grabber: Freed a tuner (now 2 available)
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - DVR:Grabber: Recording for ‘CBS News Sunday Morning - Episode 02-03’ on channel 2.1 stopped with status error.
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - DVR:Grabber: Using recording status.
Feb 03, 2019 07:00:32.895 [0x7f905cfff700] DEBUG - Activity: updated activity c466af99-4b5c-4747-bd77-e2967c38a23c - completed 100% - Recording
Feb 03, 2019 07:00:32.896 [0x7f905cfff700] DEBUG - Activity: updated activity c466af99-4b5c-4747-bd77-e2967c38a23c - completed 100% - Recording
Feb 03, 2019 07:00:32.896 [0x7f905cfff700] DEBUG - [MI] Opening input file: “/pub/Videos/Plex/.grab/1a9de215d7d4711346abe2bd75a7767af4468959/CBS News Sunday Morning (1979) - 2019-02-03 06 00 00 - Episode 02-03.ts”
Feb 03, 2019 07:00:32.896 [0x7f905cfff700] DEBUG - [FFMPEG] - Opening ‘/pub/Videos/Plex/.grab/1a9de215d7d4711346abe2bd75a7767af4468959/CBS News Sunday Morning (1979) - 2019-02-03 06 00 00 - Episode 02-03.ts’ for reading
For some extra notes:
The recording duration shows up as 59:56 recorded out of 1:30:00 total.
This is not the first time it has failed this far into a recording (as in almost exactly 1 hour in).
The video quality is perfect all the way up to the ‘failure’.
The channel guide update happens around the same time as the failure, so wondering if it has something to do with the channel guide updating. (Say it scans for shows to record and sets up a ‘new’ recording oblivious to the reality of the recording being progress.)
Is there any update on this? Seriously? There have been plenty of logs provided. This is a massive issue for many people and it’s really frustrating.
Records about 3-7 minutes then quits. I’ll upload my logs tonight.
Suggest you start your own thread and attach your debug (not verbose) logs to get a more focused response.
Since I had cycled through regular, beta, alpha, snap and docker install I decided to take the current beta (1.15.0.659) and purge my system of plex and do a clean install. My gremlins have gone away. During the purge I notice duplicate files/db in /var/lib/plexmediaserver and /usr/lib/plexmediaserver which was probably the source of my problems. YMMV.
I finally got a hit outside of Plex itself. I have talked with SiliconDust and they said at the time of one of these abrupt recording failures the HDHomeRun Extend had a transcoder hang and rebooted at that time. So I went from hours of perfect reception, not a single glitch that I could see when reviewing the video to the device hangs up and reboots real quick and Plex also almost immediately bombs out and does not try to finish recording.
I have asked for an update - This failure which manifests itself in log lines like these below, may turn out to be a windows issue (as was before)
ERROR - [Transcoder] [stream_segment,ssegment @ 05cfbcc0] Failed to open segment list 'http://127.0.0.1:32400/video/:/transcode/session/66771F20-675F-4D89-AED5-00656B60A29E/9a8d4721-bea0-49ec-9bdf-f3b9ebc8b584/seglist'
ERROR - [Transcoder] av_interleaved_write_frame(): Unknown error
ERROR - [Transcoder] Error writing trailer of media-%05d.ts: Invalid argument
I am sorry but i can only investigate issues from full logs and not snippets. For example i need to know when process 17913 started and for what.
Please upload the full logs zip and i will have a look
I was not referring to how HD Homerun API works and how HD Homerun operates.
My statement was purely concerning the design within Plex Media Server and that it was written in a way that assumes full control and management of all tuners and does not allow for any external factors that may impact that
I have been looking at the logs. would like to confirm which recordings you are reporting as failed here. The server logs only covered 23 minutes so if the failures were before that then i would not be able to look into them (if you disable verbose logging and just have debug logging, the logs would cover longer time)
I cannot see any references to errors giving check tuner / antenna message
What the logs show
-
Recoding completing at 23:30 on 22 Jan for E5 on channel 76
How It's Made (2001) - S27E05 - Commercial Drones Aquarium Fish Runway Cleaners and Shuttlecocksand comskip running on it at the end -
Recording starting at 23:30 on 22 Jan for for E6 on channel 76
How It's Made (2001) - S27E06 - Mortars & Pestles Bowling Lane Conditioners Crematories and Wood Playsets -
Recording on Channel 4: 'Naked Attraction - E1 - Episode 1` for 22:35 skipped because it was already airing and partial recordings are not allowed
-
Recording on Channel 13: 'Naked Attraction - E1 - Episode 1` for 23:35 skipped because it was already airing and partial recordings are not allowed
Were these 2 added late or were already in the schedule?
Is the problem you mentioned to do with these ?
It is now beta - at version 1.15.0.659
The windows binary for Plex Media Server, whilst being 32-bit, runs on both 32-bit and 64-bit systems and it has always been that way
OK, I sent the last log dump I was able to get before the error scrolled off via email, however it bounced due to being too large. Do you have another way I can send it?
There have been a couple of developments since coming from talking with SiliconDust:
-
As it was finally clear enough early in the morning for me to visually see the towers again from my place, I made a quick scramble to adjusted the antenna about 3 degrees to be better centered on the towers as opposed to going off of memory. I still can’t make out the actual towers while on the roof where the antenna is mounted due to a tree obscuring the view, but from the ground I can see and the antenna looks pretty close to being dead on with quick eyeballing before rushing off to work. Since this adjustment (less than 24 hours at this writing) 100% of the recordings have succeeded.
-
I have more telemetry from SiliconDust. They said what they are seeing is the signal is strong, then there is an occasional burst of interference at which point they see an encoder hang (the onboard h.264 encoder) and the device reboots. This is happening while tuned to 177 MHz (VHF). The strongest UHF signal is a little over +12 dBmV and the strongest VHF signal is -30 dBmV.
@chalky1982 - further to my earlier reply - concerning the following
- Recording on Channel 4: 'Naked Attraction - E1 - Episode 1` for 22:35 skipped because it was already airing and partial recordings are not allowed
- Recording on Channel 13: 'Naked Attraction - E1 - Episode 1` for 23:35 skipped because it was already airing and partial recordings are not allowed
The problem for this has been found,. Basically it should have scheduled the recording at 23:35 for channel 13 when it realized that the 22:35 recording could not be done .
where exactly is this ? Plex client app ? which client?
For uploading to the forum in a forum post, zipped files can be attached or if too big, upload to dropbox / google drive etc and share link
