@cayars said:
It’s currently being tested by staff & ninjas. As Charles already said it’s in RC status which is an interactive cycle where we test, they fix, we test, etc until it’s ready for release to the masses.
It’s good you have the ninjas attacking it.
@cayars said:
It’s currently being tested by staff & ninjas. As Charles already said it’s in RC status which is an interactive cycle where we test, they fix, we test, etc until it’s ready for release to the masses.
Thanks for chiming in @cayars! And yes, the fix has been merged with the builds being tested that will make the next release of PMS. Over the past 6 months we’ve upped internal testing with the Ninjas, including them earlier on in alpha builds wherever possible. They have close contact with support, qa, engineering, design, and can file internal issue tickets that get seen and triaged directly by development.
@cayars said:
Not to change topics, but doesn’t it suck when you can spend an hour to build a better antenna then a commercial one?
Not a surprise. Open up one of those store bought antennas and you may think it was homemade. The difference in geometry and mounting position are the two major factors that affect reception. Changing position of an antenna as little as three inches can have dramatic effect. Consider that average wavelength is around 22 inches (539 MHz - US Channel 25,) if you move your antenna one wavelength you may see no change in reception.
“The higher, the better,” is only true if you can get to line of sight with the transmitting antenna. Reflected signals from the ground and other buildings can serve to cancel the primary signal, but they can also be useful for reception. If primary and reflected signals hit your antenna “in phase” they are additive, though this is hard to achieve across multiple sources. It can be useful to find a spot where primary signal is blocked or diminished and use the reflected signal for reception. A roof mounted antenna may perform better at a lower height if it serves to reduce reflected signals. The last time I adjusted my antenna was to try to reduce some signal glitches I was seeing in my recordings. During adjustment I noticed a signal drop when a car would drive by. This helped explain why I had so many glitches in my 5-7pm recordings before adjustment. Many of my neighbors arrive home in the evening at this time.
“The larger, the better,” is not always true. A larger antenna can increase reception of weaker signals but if those weaker signals are reflections that cancel the primary signal, it doesn’t help. A large antenna is useful for pulling in distant weaker signals.
Exterior vs. Interior Mounting. Varies dramatically per use case. Try interior first, if you are getting 90% of what you expected then moving to exterior probably wont help. At least exhaust all possible positions and heights available indoors first.
Obstructions. Television signals are transmitted as a horizontal wave, Radio is vertical, and Satellite is round or oval. The antennas need to match the proper orientation in order to collect the transmitted energy. Anything else in the same orientation that can react to that energy will collect or reflect it. Mostly this means metal objects but moisture is also a factor. Say you have bars on your windows, if the majority of them are vertical they will have little to no effect on a television signal. Metal siding is going to block a lot of signal. Wood and other common building materials are typically considered transparent as long as the moisture content is low. Water and materials with high moisture content will collect some of the signal energy. If you have an attic mounted antenna you may notice when the roof is wet your reception is diminished. To bring this back to our primary topic… Trees can be a source of signal loss due to the moisture content of their leaves. As engineering is efforting to rectify error handling due to signal loss, we in the northern hemisphere are seeing the leaves fall from the trees. This in turn will eliminate the problem for some users as the naked trees and dry air of winter will help with reception. Please don’t consider this case closed until we see what next spring will bring. I am surrounded by trees and without changing anything in my setup, have had no hung recordings in the past few weeks.
Yeah. I really hope all the different bugs I’m seeing are related to this one:
Generally all three errors are only solved by restarting plex, and by one means or another re-initializing the HDHomeRunHD. Sometimes that simply means running the windows software and doing a scan or something. Others it means I actually have to remove the device from plex and add it back in.
I’ve notice no pattern as to whether this is more frequent with or without transcoding enabled. I did notice though when I attempt to run a scan, the error will indicate a transcoder has locked the device, even if I have transcoding disabled… When I look through the processes, it seems the transcoder always runs, what varies is the parameters passed to the transcoder.
Call it wishful thinking on my part, but it would be useful if the the transcoder could also be used to convert *.ts to *.mkv. The main reason is I can point handbrake a directory of mkv’s and select convert all. But for *.ts files I have to do one file at a time… But really it is far more important just to have the DVR working reliably. It sucks to have my favorite shows scheduled to record just to find nothing there.
@docbillnet said:
Yeah. I really hope all the different bugs I’m seeing are related to this one:
- Sometimes recordings are stuck forever at 100%.
- Sometimes I get partial recordings with as little as 6 seconds that are marked as complete.
- Sometimes recording “completes” but then there is simply no video stored.
The patch going out addresses #1. We’ve been able to reproduce #2 and #3 and continue to investigate a fix.
Call it wishful thinking on my part, but it would be useful if the the transcoder could also be used to convert *.ts to *.mkv. The main reason is I can point handbrake a directory of mkv’s and select convert all. But for *.ts files I have to do one file at a time.
We briefly tried wrapping MPEG2 in an MKV container, but we ran into issues around how well it worked on the various platforms we support. in addition, we had issues with subtitles and seeking. If the signal was corrupted at all, it screwed up the file. TS by comparison is designed to be a “broadcast format” that can withstand things like this.
@docbillnet said:
Yeah. I really hope all the different bugs I’m seeing are related to this one:
- Sometimes recordings are stuck forever at 100%.
- Sometimes I get partial recordings with as little as 6 seconds that are marked as complete.
- Sometimes recording “completes” but then there is simply no video stored.
There is a 4th common one, too: back-to-back recordings capture the same content. This is a more recent one we’ve noticed since Friday and engineering is knee deep in investigating that one. In my testing I have found #2 and #3 often happen with back-to-back recordings on the same channel. It’s possible the work being done for #4 might help the others. We’re intensifying our investigation and testing to speed up work on getting the rest of these fixed, including recording back-to-back programs (simultaneous raw curl capture and scheduled through DVR) all day long on multiple channels, across multiple cities and tuner models. The next release of PMS, which includes the fix for #1, is now going through QA.
@docbillnet said:
Yeah. I really hope all the different bugs I’m seeing are related to this one:
- Sometimes recordings are stuck forever at 100%.
- Sometimes I get partial recordings with as little as 6 seconds that are marked as complete.
- Sometimes recording “completes” but then there is simply no video stored.
@docbillnet Can you confirm if #2 and #3 have mostly happened with back-to-back recordings? Or are they happening with gaps where there is no recording scheduled? Thanks!
Just out of curiosity i didn’t read every post in this thread but for the hdhomerun users have you looked at your firmware as I just happened to look at mine and it’s sitting with a firmware from 2015 and there was a firmware that says fixes an issue where the unit would quit responding and hang with heavy internet use which possibly could cause it to happen more if you are using more than one tuner at a time just a thought as I haven’t seen anyone mention this
Morning I am new to this forum but have been following it closely as I have the same problems. I have plex (the latest plex pass download) running on Windows server 2012 r2 foundation with a HD homerun connect.
The last version was useless for DVR as rarely recorded a programme and when it did it only recorded a few seconds. The 100% recording issue was there too (which of course limits in plex the HD connect to one tuner), the only way to clear it was to restart plex, this often released the completed recording. Frustratingly though some times plex wouldn’t restart and I had to restart Windows.
The latest version of plex is definitely better and more complete programmes are recorded, but otherwise the problems still persist. I have had to restart Windows today as plex wouldn’t restart so as to clear a 100% issue.
Does anyone know when this issue will be resolved as plex dvr is no where near reliable which it should be as we are paying for it?
Simon
@kinoCharlino said:
@docbillnet said:
Yeah. I really hope all the different bugs I’m seeing are related to this one:
- Sometimes recordings are stuck forever at 100%.
- Sometimes I get partial recordings with as little as 6 seconds that are marked as complete.
- Sometimes recording “completes” but then there is simply no video stored.
@docbillnet Can you confirm if #2 and #3 have mostly happened with back-to-back recordings? Or are they happening with gaps where there is no recording scheduled? Thanks!
Here is an example of a couple of these in the HDHomeRun log:
20171122-00:00:00 Tuner: tuner0 http stream ended (remote closed)
20171122-00:00:00 Tuner: tuner0 tuning 7.2 LAFF (8vsb:617MHz-4)
20171122-00:00:01 Tuner: tuner1 tuning 7.3 ESCAPE (8vsb:617MHz-5)
20171122-00:00:02 Tuner: tuner0 streaming http to 172.31.253.119:59064
20171122-00:00:02 Tuner: tuner1 streaming http to 172.31.253.119:59066
20171122-00:02:13 Tuner: tuner0 http stream ended (remote closed)
20171122-00:10:34 Tuner: tuner1 http stream ended (remote closed)
20171122-00:30:00 Tuner: tuner0 tuning 7.2 LAFF (8vsb:617MHz-4)
20171122-00:30:01 Tuner: tuner0 streaming http to 172.31.253.119:53032
20171122-00:40:59 Tuner: tuner0 http stream ended (remote closed)
20171122-02:00:00 Tuner: tuner0 tuning 23.2 Bounce (8vsb:581MHz-4)
20171122-02:00:00 Tuner: tuner1 tuning 23.1 WNLO-HD (8vsb:581MHz-3)
20171122-02:00:01 Tuner: tuner0 streaming http to 172.31.253.119:55168
20171122-02:00:02 Tuner: tuner1 streaming http to 172.31.253.119:55170
20171122-02:01:48 Tuner: tuner1 http stream ended (remote closed)
20171122-02:03:08 Tuner: tuner0 http stream ended (remote closed)
As you can see as far as the tuner is concerned plex told the tuner to stop streaming early. Sometimes plex goes to 100% complete at that point, and sometimes it keeps showing progress as if there was a stream still being recorded. I haven’t noticed a particular pattern of it always being back to back. Usually I don’t play these snippets. However, I did notice that sometimes they are all the same snippet. For example I ended up with 8 videos that were all the same 30 second snippet from the Drew Carry show. That particular channel was coming in very badly, so I can understand why the turner might have decided to abort the encoding. I’m not sure though why it considered it complete and then copied the snippet for completely different shows on other channels.
Here is one that just happened with live TV:
20171122-12:41:04 Tuner: tuner0 tuning 26.3 LightTV (8vsb:545MHz-5)
20171122-12:41:04 Tuner: tuner0 streaming http to 172.31.253.119:36342
20171122-12:53:32 Tuner: tuner0 http stream ended (remote closed)
The pop-up message said it was stopped because of a recording conflict. But currently no recordings are in progress, the next one isn’t schedule to start until the top of the hour. So both turners should have been free for watching live tv.
@Toparcticwolf said:
Just out of curiosity i didn’t read every post in this thread but for the hdhomerun users have you looked at your firmware as I just happened to look at mine and it’s sitting with a firmware from 2015 and there was a firmware that says fixes an issue where the unit would quit responding and hang with heavy internet use which possibly could cause it to happen more if you are using more than one tuner at a time just a thought as I haven’t seen anyone mention this
Looks like that isn’t my problem, but thanks for the tip. Please keep those ideas coming.
Model: HDHR4-2US
Device ID: 104B4D8A
Firmware: 20170930
We briefly tried wrapping MPEG2 in an MKV container, but we ran into issues around how well it worked on the various platforms we support. in addition, we had issues with subtitles and seeking. If the signal was corrupted at all, it screwed up the file. TS by comparison is designed to be a “broadcast format” that can withstand things like this.
Good to know. I guess it is better to spend the few extra mouse clicks than to risk additional corruption. I had really interesting effect with with Supernatural recording. It would hit points in the video where suddenly it would loop back and play the same sequence over, and over, and over like a time loop. Normally re-encoding videos in a program like handbrake solves such issues, but even after re-encoding the video had the same glitches. It would be pretty cool if I could figure out a way to make videos do that…
@kinoCharlino said:
@docbillnet Can you confirm if #2 and #3 have mostly happened with back-to-back recordings? Or are they happening with gaps where there is no recording scheduled? Thanks!
I can confirm this happens to me more commonly with back to back recordings. Usually the first of the batch is the one to suffer. But I have also seen it once with a one and done recording that is scheduled by itself.
@kinoCharlino said:
@docbillnet said:
Yeah. I really hope all the different bugs I’m seeing are related to this one:
- Sometimes recordings are stuck forever at 100%.
- Sometimes I get partial recordings with as little as 6 seconds that are marked as complete.
- Sometimes recording “completes” but then there is simply no video stored.
@docbillnet Can you confirm if #2 and #3 have mostly happened with back-to-back recordings? Or are they happening with gaps where there is no recording scheduled? Thanks!
@kinoCharlino - I mostly experience issues #2 and #3 when I have two simultaneous recordings - I have not noticed it happening in back to back recordings.
Also, I posted this except from my log on Oct 12 (https://forums.plex.tv/discussion/comment/1536203#Comment_1536203) where it stopped recording and things went awry - this was while recording two simultaneous recordings. I’m not an expert on logs, but it looks like to me PMS “lost contact” with my HDHOMERUN Extend.
ct 12, 2017 18:33:18.426 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:18.717 [22184] DEBUG - Activity: updated activity fb03b5ea-0153-44e8-9fdc-21ef3c6c51eb - completed 11% - Recording
Oct 12, 2017 18:33:18.718 [22184] DEBUG - Activity: updated activity 589f0b51-bf0f-4470-ad57-5e11e01e978f - completed 11% - Recording
Oct 12, 2017 18:33:19.087 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:19.435 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:20.095 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:20.442 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:21.104 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:21.450 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:22.112 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:22.458 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:23.120 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:23.467 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:24.129 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:24.475 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:25.137 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:25.484 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:26.146 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:26.491 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:27.154 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:27.500 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:27.707 [3744] DEBUG - NetworkServiceBrowser: SSDP departed after not being seen for 29.679165 seconds: 192.168.29.111
Oct 12, 2017 18:33:27.712 [3744] DEBUG - DVR:Device: Discovering and refreshing devices.
Oct 12, 2017 18:33:27.714 [3744] DEBUG - DVR:Grabber: HDHomerun discovered 0 compatible devices.
Oct 12, 2017 18:33:27.714 [3744] DEBUG - DVR:Device: Testing grabber HDHomerun device device://tv.plex.grabbers.hdhomerun/10567791 at http://192.168.29.111:80
Oct 12, 2017 18:33:27.718 [3744] DEBUG - HTTP requesting GET http://192.168.29.111:80/discover.json
Oct 12, 2017 18:33:28.161 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:28.508 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:29.170 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:29.517 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:30.178 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:30.525 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:31.187 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:31.534 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:32.196 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:32.542 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:32.739 [3744] ERROR - Error issuing curl_easy_perform(handle): 28
Oct 12, 2017 18:33:32.739 [3744] DEBUG - HTTP simulating 408 after curl timeout
Oct 12, 2017 18:33:32.794 [3744] ERROR - DVR:Device: Error refreshing existing device device://tv.plex.grabbers.hdhomerun/10567791, marking as dead.
Oct 12, 2017 18:33:32.795 [3744] DEBUG - DVR:Grabber: Mystery discovered 0 compatible devices.
Oct 12, 2017 18:33:32.796 [3744] DEBUG - HTTP requesting POST http://127.0.0.1:32600/devices/discover
Oct 12, 2017 18:33:33.204 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:33.550 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:34.212 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:34.557 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:35.220 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:35.322 [3744] DEBUG - HTTP 200 response from POST http://127.0.0.1:32600/devices/discover
Oct 12, 2017 18:33:35.565 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:36.228 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:36.574 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:36.754 [22189] DEBUG - Activity: updated activity fb03b5ea-0153-44e8-9fdc-21ef3c6c51eb - completed 12% - Recording
Oct 12, 2017 18:33:36.754 [22189] DEBUG - Activity: updated activity 589f0b51-bf0f-4470-ad57-5e11e01e978f - completed 12% - Recording
Oct 12, 2017 18:33:37.237 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:37.581 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:38.246 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:38.589 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:39.254 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:39.597 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:40.263 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:40.606 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:41.271 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:41.614 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:42.279 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:42.622 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:43.287 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:43.630 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:44.296 [22199] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:44.637 [22180] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:45.304 [22177] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:45.646 [21775] DEBUG - buildLiveM3U8: min 0 max 84
Oct 12, 2017 18:33:45.946 [3744] DEBUG - NetworkServiceBrowser: SSDP arrived: 192.168.29.111 (http://192.168.29.111:80/dms/device.xml)
Oct 12, 2017 18:33:45.946 [22182] DEBUG - HTTP requesting GET http://192.168.29.111:80/dms/device.xml
Oct 12, 2017 18:33:45.985 [22182] DEBUG - HTTP 200 response from GET http://192.168.29.111:80/dms/device.xml
Oct 12, 2017 18:33:45.991 [22182] DEBUG - DVR:Device: Discovering and refreshing devices.
Oct 12, 2017 18:33:45.993 [22182] DEBUG - DVR:Grabber: HDHomerun discovered a model HDTC-2US.
Oct 12, 2017 18:33:45.993 [22182] DEBUG - HTTP requesting GET http://192.168.29.111:80/discover.json
Oct 12, 2017 18:33:46.008 [22182] DEBUG - HTTP 200 response from GET http://192.168.29.111:80/discover.json
Thanks guys for your reports and logs. We have been able to reproduce #2 and #3 with single recordings, not back-to-back. The hypothesis engineering is working through right now leads to a different root cause than issue #1 and could have to do with the tuner. We’re digging into it, but know at least issue #1 will be resolved in the next PMS release.
I’ve noticed that for me, the bug occurs when recording something with poor reception. I bought a larger range antenna, and that’s been helping to resolve the issue, but there are a few channels (most notably my local CBS and PBS stations) that can get glitchy. Usually, when this happens, I safely restart my server (an Nvidia SHIELD), and when I come back I find whatever was recorded of the show (usually a few minutes) in my library, with no logs indicating it was recorded in the Recording Schedule.
Regarding recordings that stop early (but don’t present an error message in Plex Web), we have confirmed that in certain situations, HDHR tuners stop sending packets to Plex even when signal quality measures acceptable of better. We’re in touch with SiliconDust and are looking into what we can do on our side to help.
@kinoCharlino the signal quality in HDHR is just a cheap guide. Has anyone confined this tuner issue with a properly so and tested signal like correct signal level and good MER and BER? I have a very good calibrated setup and you need someone with $2k Meter to test this properly and I don’t have issue 2 or 3 HDHR connect Australia.
