I just recently reinstalled windows 10, and all my software, including Nextpvr. Everything in Next worked great before and I have all the same stuff installed on my pc this time (actually this is the third go, on my first windows reinstall Next gave me an error saying it couldn't start my 955q every time i started a scan so I reinstalled windows again and that was fixed). The only thread I've found on this was pretty old and I have tried reinstalling next, including deleting the public folder and the registry key. Any help would be appreciated, thank you.[ATTACHMENT NOT FOUND][ATTACHMENT NOT FOUND]
So I can't quite isolate what is causing this issue with (some) recordings.
About 2-3 recordings / day seem to have this issue when I load in other players (Kodi, Plex, emby), that I cannot fast forward. It is almost like the player is playing the recording live, and that any fast forwarding requires a load of buffering (1+ min). All other recordings is immediate.
If I play the recording in nPVR itself, it plays just fine.
I am not quite sure what could cause this, whether or not it is an issue with:
1) my HDHR tuner?
2) How nPVR is recording this? (It seems to be happening mostly on FS1 or ESPN recordings).
3) other?
What would be most useful to diagnose this? Would logs of the time from recording help?
And frankly on my old system under Windows XP I solved this issue by mapping a drive letter under the system account. Now, the new system is a running Windows 10 and I wanted to keep it as clean as possible, so I created a share on the NAS that the guest account can access without password. This was suggested previously.
Well, that doesn't work. Below is an excerpt from my NRecord.log, first trying to record to the NAS, then to a local directory:
Code:
2016-12-14 17:14:46.269 [DEBUG][10] Requesting wake up for 'RecordingOID851-backup' at 12/14/2016 5:18 PM
2016-12-14 17:14:46.269 [DEBUG][10] Requesting wake up for 'RecordingOID851' at 12/14/2016 5:17 PM
2016-12-14 17:15:09.601 [DEBUG][48] ReloadSettings()
2016-12-14 17:15:09.601 [DEBUG][48] Checking for new capture devices
2016-12-14 17:15:09.601 [DEBUG][48] CaptureSource.LoadAll()
2016-12-14 17:15:09.664 [DEBUG][48] ReloadSettings()
2016-12-14 17:15:09.665 [DEBUG][48] Checking for new capture devices
2016-12-14 17:15:09.665 [DEBUG][48] CaptureSource.LoadAll()
2016-12-14 17:19:00.124 [DEBUG][10] DefaultDirectoryChoice: first
2016-12-14 17:19:00.362 [DEBUG][10] allocating recording target filename: \\GUPPY\mc_rec\rec_tv\Manual Recordings\Default_20161214_17201730.ts
2016-12-14 17:19:00.362 [DEBUG][10] About to start recording (851 on 20): \\GUPPY\mc_rec\rec_tv\Manual Recordings\Default_20161214_17201730.ts...
2016-12-14 17:19:00.362 [DEBUG][10] Asking NDigitalHost to start: \\GUPPY\mc_rec\rec_tv\Manual Recordings\Default_20161214_17201730.ts
2016-12-14 17:19:01.743 [DEBUG][10] Temp at 12/14/2016 5:19:11 PM
2016-12-14 17:19:01.743 [DEBUG][10] Started recording (851:25:\\GUPPY\mc_rec\rec_tv\Manual Recordings\Default_20161214_17201730.ts)
2016-12-14 17:19:01.803 [DEBUG][10] Invalid file passed to StartParallelProcessing(): '\\GUPPY\mc_rec\rec_tv\Manual Recordings\Default_20161214_17201730.ts'
2016-12-14 17:32:00.239 [DEBUG][10] Stopping recording (851 on 20). Past end time of recording. 25
2016-12-14 17:32:00.311 [DEBUG][10] StopStream(19)
Code:
2016-12-14 17:39:58.627 [DEBUG][10] Requesting wake up for 'RecordingOID852' at 12/14/2016 5:38 PM
2016-12-14 17:40:00.179 [DEBUG][10] DefaultDirectoryChoice: first
2016-12-14 17:40:00.180 [DEBUG][10] allocating recording target filename: C:\temp\Manual Recordings\Default_20161214_17401750.ts
2016-12-14 17:40:00.180 [DEBUG][10] About to start recording (852 on 20): C:\temp\Manual Recordings\Default_20161214_17401750.ts...
2016-12-14 17:40:00.180 [DEBUG][10] Free space 285377081344 (C:\)
2016-12-14 17:40:00.180 [DEBUG][10] Asking NDigitalHost to start: C:\temp\Manual Recordings\Default_20161214_17401750.ts
2016-12-14 17:40:01.446 [DEBUG][10] Temp at 12/14/2016 5:40:11 PM
2016-12-14 17:40:01.446 [DEBUG][10] Started recording (852:26:C:\temp\Manual Recordings\Default_20161214_17401750.ts)
2016-12-14 17:40:01.456 [DEBUG][10] No C:\Users\Public\NPVR\Scripts\ParallelProcessing.bat
I checked as a different user that the guest access to my NAS actually allows to RW and create files.
If I try accessing the share from a cmd.exe running as system user (PsExec) I get:
Code:
C:\Windows\system32>dir \\guppy\mc_rec
The specified server cannot perform the requested operation.
For other users the dir command works.
Seems like system on Windows 10 is a little different.
Normally when starting a show in progress, while being recorded, I would get prompted to either start at the beginning of the show, or where it is in the progress of the show.
I just moved all of the recordings to a NAS share. Since then, if I start a recording while in progress, it just starts where the show is currently at in the recording process. I know that I while was trying to get the NAS share to work, I had made some changes and tweaks here and there, but I don't remember everything that I might have changed. Is there a setting somewhere that I might have changed that prompts me to start the recording from the beginning while in progress? I use a RPi2,Kodi 16.1.
A suggestion I'll make for NextPVR and VLC:
One suggestion I'd make for an enhancement: skipping to a point in a video that is not accurately known is a nuisance (an example is advertisement skipping). If you take small jumps there have to be many; if large jumps, they go too far. So you set up jumps of various sizes; if you remember the keys you start with big ones, and make them smaller as you home in; you would typically have 6 keys, small, medium, and large jumps forwards and backwards. Alternatively, you could use fast-forwards/backwards, which is slow and a nuisance.
A much more convenient and faster method is to use a binary chop: you start with a large jump, and the size progressively and automatically gets smaller (halved) as you approach, until you reach the right spot. I have a hardware video recorder with a software plugin supporting this; it is extremely useful. Your first jump is fixed size, and can be repeated in the same direction; once you change direction, you halve the length of each successive jump. So, if your first jump is 4 minutes (240 seconds) and your destination (which you don't know) is 5'23" (323") ahead, you quickly press r (right arrow; takes you 240" ahead) r (jump +240", position 480") l (-120", 360") l (-60", 300") r (+30", 330"), l (-15", 315", close enough, or we can go +7.5" to 322.5"). You obviously don't have to do these sums, just watch the result as you quickly do r r l l r l. You never require more than 7 jumps after the first reversal to get within 7.5", with just 2 keys, and no need to change from bigger to smaller jumps. If you make a mistake and find you're making small steps from too far away, wait 5" and start again - this shouldn't happen often.
The algorithm has 3 parameters, which should be user-configurable, and uses two keys (left and right keyboard or remote controller arrows are the obvious allocations). The parameters are: initial jump, could default to 4 minutes; smallest jump (so we don't end up with millisecond jumps), which could be 5"; and timeout, say 5 seconds. The binary chop continues until no key is pressed during the timeout period, then reinitialises.
On pressing an arrow key, we initially jump 4'. Every press of the same key is 4' in the same direction. When we press the opposite key, the binary chop starts; the jump is halved at every keypress in either direction, until it reaches the configured smallest value of 5" or whatever. Subsequent jumps are all by this smallest value. When we're near enough we stop; there's no need to get closer than a few seconds before.
This technique was implemented by Simon Capewell in the QuickJump 1.7 TAP (software add-on) for the discontinued Topfield TF5800 PVR, and very useful it is.
When I watch live or recorded TV the sound doesn't synchronise with the vision. The longer you watch it, the further out it gets. In addition sometimes the sound repeats / stutters while the vision continues. If you stop the player and start again it improves but it all happens again eventually.
When I view the nextpver video with another player it works fine. Any suggestions anybody?
I have a twin tuner dvb-s2 card and am trying with some success to get it working with acamd.
What I have done so far is put acamd.dll and the card client.conf which contains the same n line in both files newcamderver:port:0/0000/0000:bilbopvr:password123:0102030405060708091011121314 in each of the tuner folders in mdplugins. Oscam server.
On the devices, multidec is enabled with one instance, have also tried 0 instances on both tuners.
What happens is I can watch a channel and additional files are created in the tuner A folder. What I cannot do is record on and watch one, from what I can tell the acamd in the tuner B folder is not invoked at all, no files created and I get a black screen. When running acamd monitor only one tab is made for tuner a.
I also tried putting a different line in tuner b but acamd still did not seem to get invoked.
Is there something I have missed in the setup? or a way to see if acamd is getting called a second time or even a more preferred plugin.
I am running windows10 64 bit, tuner tbs 6981. Watching and recording works fine on all of the fta channels.
Hi folks,
NextPVR was working very well for me until recently. I've started getting an unhandled exception error when I perform a particular sequence of actions : open the UI, watch one channel, close the channel, click on another one in TVGuide, an unhandled exception is thrown with the details as below. I've attached the logs to this post as well.
Some extra pieces of info: I installed TV Listings recently, and tried removing that to eliminate it causing the issue. I think I've managed to clean it up and it doesn't show up anywhere. I upgraded to 3.9.2 recently as well and tried going back to earlier version to see if that was the issue, but of no help.
Any suggestions/pointers will be helpful !
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at NextPVR.TV.TVGuide.OnClick(PointF location)
at NextPVR.ControllerForm.ControllerForm_MouseClick(Object sender, MouseEventArgs e)
at System.Windows.Forms.Control.OnMouseClick(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at NextPVR.ControllerForm.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
I updated to 3.9.2, and while everything looks in order, the web interface shows no data. The web interface loads, but it does not show EPG or recordings.
erver:port:0/0000/0000:bilbopvr:password123:0102030405060708091011121314 in each of the tuner folders in mdplugins. Oscam server.
![[Image: 2016-12-12-login.png]](http://www.ashleygriffin.ca/temp/npvr/2016-12-12-login.png)
