This has been happening for me since 4.x, but it seems that 4.0.5 is having the most issues for me with skipping on recordings (.ts files). If I skip forward, it will skip but then the video will start off in fast motion and then go to slow motion and then eventually back to normal playback speed. During that fast motion, slow motion period, the timeline will not advance. Meanwhile, the audio will skip just fine and will be out of sync with the video until the video settles down. I've tried different decoders along with trying the legacy TS reader with not much luck. When I looked at the log files, it seems that all is fine. Another issue that will happen is if I just let the recording play the full length, the timeline will have a tendency to be longer than the actual video length. An example is an hour show (1:02:00 length) will have the timeline show as 1:06:00 right before it completes.
I guess I'm stumped and not quite sure where to check next. So, any ideas would be appreciated.
Hi, I haven't paid attention to how much memory NDigitalHost would normally use, but in the last week I see its Private Working Set rising to about 1.5GB within 10 minutes or so. This happens whether I am just watching Live TV with NextPVR, or just recording a broadcast program.
I have captured a set of events, seen in the attached logs, where I start watching Live TV, stop it, and then restart Live TV and leave it going until the Working Set peaks out at about 1.5GB. At this point NDigitalHost and NextPVR hang if you try and stop and restart Live TV. There is a PerfMon graph of the NDigitalHost Working Set in the attachment.
I can't be sure but I think the problem appeared when I installed all the latest Windows 10 Pro upgrades which have appeared since about last October. I am using the latest release of NextPVR.
I have tried re-installing elements such as LAV codecs, repair-installing .NET, uninstalling and re-installing NextPVR, upgrading video device drivers, and re-installing TV card drivers. Because this happens even when simply recording I am wondering if the TV card drivers are a problem, the card is a BlackGold 3620, and I see the latest device driver is quite old dating from 2011.
If anyone has any suggestions on this I would be grateful, if this behaviour isn't a NextPVR configuration problem maybe I should approach BlackGold for help.
That thread described replacing the Ceton card with an HD HomeRun box.
It also described some problems that I was having with defective TS
files recorded with both the Ceton and HDHomeRun configurations.
During the last week I've been doing a lot of research on this
problem, and I've identified what appear to be issues in NRecord. The
purpose of this thread is to document the results.
***
*** Introduction
***
As I described in the last thread, NRecord has produced some defective
TS files, and it's getting worse, to the point where it's becoming a
nightmare. The defective files display zero recording length in VLC:
- Partially defective TS files can be played in VLC because the
progress bar works (even though the hotkeys don't)
- Totally defective TS files can't be played at all in VLC.
As I described in the last thread, NPVR has been occasionally
producing partially defective TS files for months, but I blamed them
on the Ceton card. However, when I switched to an HDHR box in early
December and the same thing happened, it appeared that the problem was
in NPVR itself. It's hard to believe that both the Ceton card and the
HDHR box are producing the same problem, since one is electrically
connected to the I/O bus, but while the other transmits data through
the router over a network connection. Still, they have a common
component (the Comcast Cablecard), so that possibility has to be
considered.
Starting on December 26, there was a new development. Every recording
of the "WBZ News at 11" (at 11pm) was totally defective. Although
initially this was a really depressing discovery, it was actually a
gift from heaven, because it provided a platform where repeatable
tests could be performed.
In the last two weeks, I've been playing around with different tests,
and all these tests point to a bug in NRecord that's creating bad
TS files during the first few seconds that recording starts.
***
*** Test #1: Duplicate Recording Test
***
In this test, which I've tried several times, I create a manual
recording that records exactly the same show, "WBZ News at 11," as
a manual recording. Result:
- The recurring recording is totally defective, as usual.
- The manual record is not defective at all.
Both of these recordings are made by NRecord from the same tuner on
the same HDHR box, so they should produce the same results, but they
don't, indicating that NRecord is handling them differently.
Here are the ffprobe listings for the two TS files:
Code:
--- ffprobe -hide_banner "d:\tv\shows\WBZ News at 11_20180125_23002335.ts"
[mpeg2video @ 000000000046f100] Invalid frame dimensions 0x0.
Last message repeated 13 times
[mpegts @ 00000000004655a0] PES packet size mismatch
Last message repeated 1 times
[mpegts @ 00000000004655a0] Could not find codec parameters
for stream 3 (Unknown: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from 'd:\tv\shows\WBZ News at 11_20180125_23002335.ts':
Duration: 00:37:00.10, start: 21792.896522, bitrate: 3161 kb/s
Program 4
Program 3
Stream #0:0[0x1823]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002),
yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3],
Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1824](eng): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x1825](spa): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, stereo, fltp, 192 kb/s
No Program
Stream #0:3[0x17e9]: Unknown: none
Unsupported codec with id 0 for input stream 3
--- ffprobe -hide_banner "d:\tv\shows\WBZNews-11_20180125_23002340.ts"
[mpeg2video @ 00000000002ddfe0] Invalid frame dimensions 0x0.
Last message repeated 13 times
[mpegts @ 00000000002d55a0] PES packet size mismatch
Last message repeated 1 times
Input #0, mpegts, from 'd:\tv\shows\WBZNews-11_20180125_23002340.ts':
Duration: 00:42:00.40, start: 21792.896522, bitrate: 3118 kb/s
Program 3
Stream #0:0[0x1823]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002),
yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3],
Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x1824](eng): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, 5.1(side), fltp, 384 kb/s
Stream #0:2[0x1825](spa): Audio: ac3 (AC-3 / 0x332D4341),
48000 Hz, stereo, fltp, 192 kb/s
These two dumps should be virtually identical, but they aren't.
The first of these two dumps illustrates something that I've seen in
all the defective TS files: There are almost always additional
"Program N" sections, in addition to "Program 3".
Here's another piece of information: I've tested these TS files
immediately after they've started recording, as little as 15 seconds
later. It's clear that whether or not they're defective is determined
immediately when the the TS file is initialized by NRecord.
In the past, I assumed that some error was occurring at the end of the
recording session, that perhaps NRecord wasn't closing the file
properly. But these observations make it clear that whatever error is
occurring is occurring at the beginning of the session, at file
creation time, before data recording even begins.
***
*** Test #2: NRecord restart test
***
In this test, which I've also tried several times, I kill NRecord and
restart the service about around 10:45 pm.
Restarting NRecord should not have any effect on a recording beginning
at 11 pm, but it does. Result: The recording of "WBZ News at 11" is
not defective at all under these cirdumstances.
What this indicates to me is that NRecord is in some error state
that gets cleared when NRecord is restarted at 10:45 pm.
***
*** An unrelated bug: NRecord stops recording anything
***
This is a completely separate bug which, as far as I know: NRecord
simply stops recording. Several months ago, I set up a script that
wakes up every 60 seconds and checks the recording directory to see if
the TS file time stamps are being updated. If not, then it pops up an
alert telling me that NRecord has stopped recording, and I just kill
NRecord and restart the service.
While I was working on the defective file bug, I was "fortunate"
enough to see this other bug occur as it happened, and was able to see
what was happening.
The Comcast network went down for a few minutes, both cable tv and
internet. When Comcast came back up, NRecord didn't recover properly,
and simply stopped recording.
I don't know if there are any other reasons why NRecord would stop
recording, but this certainly seems to be one of them.
If I could make a suggestion, start up a background thread in NRecord
that sleeps but wakes up every 30-60 seconds to see if NRecord has
stopped recording and, if so, do something to start it up again.
***
*** Summary
***
I have some other test variations that I want to try in the next few
days, and I'll post additional information as I have it.
I realize that you probably don't support Windows 7 much any more, and
this may be a Windows 7 problem, for all I know.
But producing defective TS files is an absolute nightmare, and
anything you can tell me as workarounds either to prevent the problem
or to repair the files would be greatly appreciated.
For example, if you look at the ffprobe dump of the defective TS
files, all of them have a "Program 3" that looks correct, including
the correct duration, but the defective ones have one or more of
"Program N" that I assume are confusing VLC.
Is there some simple way, either using direct binary editing, or using
ffprobe or ffmpeg, set some internal pointer so that VLC will only see
Program 3?
Any workarounds of this kind would be appreciated. Thanks.
Hi all,
I am bringing my collection of WMC recordings into the NPVR recordings list by manually creating XML files and importing them. I have just noticed that the recording time is showing up two hours later than specified in the file. For example, under the <recording> tag I have:
<startTime>2014-02-12T20:58:00.0000000Z</startTime>
<endTime>2014-02-12T22:02:00.0000000Z</endTime>
but when this is imported it shows as 22:58-00:02.
Under the event tag I have the actual program times:
<StartTime>2014-02-12T21:00:00.0000000Z</StartTime>
<EndTime>2014-02-12T22:00:00.0000000Z</EndTime>
and these show up correctly in the recording detail.
It's no big deal but I am intrigued as to what is happening. Any ideas??
Thanks,
Stanno
Wondering if there is a list of the XMLTV elements that are supported (ie, drive functionality) within NextPVR. I figured that would be on the forum somewhere, but I haven't been able to find it. Obviously, elements like title and desc work, but was hoping to find a comprehensive list without resorting to trial and error.
In the last few days, I have been getting troubling results trying to record. Of particular note is an attempt on Monday night, 2018-01-29 19:59:00.121, to simultaneously record Lucifer and Supergirl, both scheduled for 8:00pm and, later on, Scorpion at 10:00pm. All three recordings created entries in the recordings folder but all were of virtually no duration. I looked through the logs and discovered a lot of entries regarding ignoring recordings: "1208-01-29 20:59:00.410 [DEBUG][9] (ignoring [39498] 'Arrow' since it starts after this recording finishes)". There's a bunch like this. Never seen this before.
I have both Freesat & Freeview (Terrestrial) dual tuners and a number of the UK channels appear on both sources (i.e. the same channel appears on 4 different tuners).
I have combined those channels in the channel setup such that the two satellite channels appear first followed by the terrestrial ones.
E.g. BBC4 HD satellite
BBC4 HD satellite
BBC4 HD Terrestrial
BBC4 HD Terrestrial
The EPG source is set as "Freesat UK".
My expectancy, given that setting, was that it would scan the Freesat EPG frequency and populate the EPG ignoring the Terrestrial EPG source.
The reason I ask is that the BBC4 HD channel on Terrestrial has just moved frequency and I started seeing EPG entries saying "This channel has moved" instead of normal TV listings.
This implies the EPG data was being drawn from the Terrestrial channel and not Freesat.
What is the logic behind selecting the source for EPG data for this mix of tuners?
I ask because we are about to go through months of terrestrial channel frequency changes in the UK (:mad and I'm sure lots of fun with it.
I know this subject was covered, but it was never really solved in previous posts, other then to rescan and possibly lose other channels.
If you've scanned for channels and for some reason, it did not pick up a station, or if your connected to an antenna, and the antenna is pointed in the wrong direction, you won't be able to receive the station in your channel lineup.
I was frustrated and did not want to lose my station list of stations from other town, I have aim my antenna in a completely different direction.
Here is how to solve this problem...
1. First you'll need to find your country's (Real Channel) to frequency list. Not the virtual channel, but the actual frequency that it transmits on.
If you live in the USA then this link will show you the real frequency listing. https://en.wikipedia.org/wiki/North_Amer...requencies
2. Goto to settings in the NPVR program and select Devices,
3. Pick a ATSC tuner, Right mouse click and select Setup Device
4. In Channels.. select drop down to Manual Scan
5. You should notice a frequency that is a 6 digit number... From the link look at the chart, for the real channel.
If you can't find the real channel number, do a google search for (Station Call Sign) WINK real TV channel or use this link https://nocable.org/browse-stations
6. Enter the station call sign, and it will tell you a wealth of information... Look down the list for RF Channel.
in this example it is Virtual channel 11, but RF channel 51.
7. From the previous link, RF Channel 51 show the following data
Channel 51 Low Frequency 692 Video Carrier 693.25 [B]
Audio Frequency 697.75 and Upper Frequency 689
[B][COLOR="#FF0000"]8, Notice the Video Frequency is 693.25 MHZ[/COLOR], you'll need to change this to KHz , simply enter the number and add a 0 to the end, making the number 693250 to the frequency input value for the channel scan, and enter the Scan button.
9. Hit OK and the station will be added to the station list, if one is found.
This is great for those who have stations in different directions and a general scan will erase the previous channel scans.
Hope this helps out
Because NBC has changed it's greater Boston station and I was having trouble getting them included in NPVR, I recently posted "NPVR won't pick up "Hauppauge WinTV-dualHD ATSC Tuner channels" - which was solved when I did a another SCAN at SUB's direction (first recent SCAN didn't get the new channels). That day I was able to watch the new (8.1, 15.1, 60.5) channels. Next 2 days spent trying to get their program schedules to show; this morning I realized that the new channels (and only the new channels) were set to "DVB/ATSC EPG" so I switched them over to Schedules Direct (which provides my scheduling info for all channels). That's when I tried to watch these three channels and instead of appearing I got: "Unable to find available capture device." All my previously scanned channels are working. I did a search for this topic and read through the dozen plus posts but wasn't able to ascertain a solution to this problem (if it's there, I'm missing it) - so I'm posting this new thread.
I have attached the logs.
thanks
bob "bickertn"
and I'm sure lots of fun with it. 
