I am having two problems which may be related. First I had to re-tune NPVR the other day as the BBC has moved one of my favourite channels to a new slot. The retune worked OK, and NPVR pulled down the Schedules Direct data without any obvious problems, but then towards the end of updating the DVB data it crashed with a "NextPVR has stopped working" dialog. NextPVR seemed to restart OK, but I've just tried to update the EPG again and the same thing has happened. (Update, I restarted and did an "Empty EPG" and then another update, and that seems to have worked OK.)
Second, I have had a couple of instances where the recording system has "locked" and missed a scheduled programme. This happened at 9pm last night, where I had to reboot the PC to get recording started again (it started automatically without problems on the reboot), and then possibly again overnight as another scheduled program was missed.
Please could someone have a look at my logs and see if they can see what's wrong, and especially what the problem was last night?
Does this make any sense? Did I clobber something? Is the command correct?
Attached logs show my attempt to watch Fox News Channel(FNCHD) on channel 618, identified in my guide as 618.2. My ".2" suffix is simply notation that the 1512 and STB is needed to view this channel.
First time posting. Be gentle. I read the first post and did all the searching I could with my limited abilities at this.
After upgrading to 4.0.5 I keep getting a very annoying error message every time I use my Windows 10 and Start NextPVR, then click on Live TV. The error message has an OK option, but I keep pressing it over and over to no end. The only way to exit is to force to close all NPVR windows. I tried to stop all services and reinstall a fresh new download, I tried rebooting, I tried removing my USB Tuner (WinTV HVR-950 BDA Tuner) and adding it back on. Nothing so far works. Remote viewing through Kodi still works, I do most of my viewing through the local NPVR client on my Desktop/server. Any help/guidance will be greatly appreciated. Thanks
[ATTACHMENT NOT FOUND]
Hopefully my two attachments will show up (screen capture of error and logs)
I finally managed to stop the wife from deleting on of those troublesome recordings that has problems when skipping ( i.e. video goes into Fast forward.)
Interestingly enough there is a "blip" in the video stream at about the 32 minute mark and this causes the playback to jump into fast forward all of its own accord.
This is consistent and happens every time playback passes the 32 minute mark. You can stop the playback and resume and everything will play normal till the end of the file (as long as the resume is after that 32 minute "blip".)
I've uploaded the file to Dropbox if you want to take a look? (Note: there are no errors in the logs indicating a problem with the playback).
Not sure where the error lies but for the last two overnight downloads, there have been a lot of errors of the form "..."response":"INVALID_USER"..." Logs are attached. I can't say if these errors are causing errors in the guide.
Can you help? Should I open a ticket at the SD site?
Hello,
First I would like to say that I'm new with NExt PVR back-end and client on Kodi.
I would like to know if there is any way fro the Kodi client not to use the NextPVR back-end every time i switch channels. This creates issues for me every now and then by loosing connection to the server and not able to find tuner or something like that.
I would like to use the client to to just send to server what program i want to record and only then to use the back-end server recorder. Not when i just watch live.
Please let me know if I'm making any sense here.
Thank you
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.
