Recording in Wrong Folder

[KNet]

The problem is that occasionally a program is recorded on the default folder rather the the folder selected during program record setup.

The two examples here are "Great Barrier Reef" (2/11/2016 8:00PM-9:00PM) and "MayDay" (2/12/2016 11:00PM-12:00AM) both intended to be recorded at "E:\MediaStore\Video\Arts, Science, and Information" but placed instead in the default "D:\MediaStore\Video".

This has happened over the past couple of years through several NPVR versions. However it only happens maybe once or twice every couple of weeks.

I have the feeling this may occur when the unit has a heavy processing load and be due to a hard drive not spinning up in time to satisfy NPVR but this may be entirely off base.

The setup has a fast quad processor, an SSD drive for the O/S, programs and program data (including NPVR version 3.6.6), as well as eight hard disk drives for A/V storage. NPVR is used to record about 130 hours per week from two tuner devices.

The logs are at https://onedrive.live.com/redir?resid=5E...file%2czip

[sub]

The two examples here are "Great Barrier Reef" (2/11/2016 8:00PM-9:00PM) and "MayDay" (2/12/2016 11:00PM-12:00AM) both intended to be recorded at "E:\MediaStore\Video\Arts, Science, and Information" but placed instead in the default "D:\MediaStore\Video".

Your nrecord.log doesn't go back as far as these recordings. Do you have the older logs?

[KNet]

I have added the rest to the zip file.

[sub]

Do you still have a recording directory with the logical name of exactly "Arts_Science_and_Information" in your Settings->Recording screen? If it can't find an exact match, it'll default to the first directory in the lost.

[KNet]

The directory name is "E:\MediaStore\Video\Arts, Science, and Information". The "virtual folder name" assigned in "Settings -> Recording" is "Arts_Science_and_Information". This is done because the Kodi plug-in trips up on names with spaces. This works fine on 99% of the recordings to this folder. Also note that the problem also occasionally occurs with folders where the directory name exactly matches the "virtual folder name" (no spaces). The attached file example shows a program recorded in this folder 5 days per week with no problems.

[sub]

You'd probably need to supply me your npvr.db3 and config.xml for me to check. It is something like names not exactly matching though.

[KNet]

They have been added to the zip file.
Please bear in mind a couple of things. The wrong folder thing rarely occurs. The exact same programs with the exact same folders and names usually have no problem whatsoever. Also this problem predates my use of Kodi when I had to change the "virtual names" to eliminate spaces.

https://onedrive.live.com/redir?resid=5E...file%2czip

[KNet]

Complete logs and database as well as conflict errors and wrong folder errors are at:

https://onedrive.live.com/redir?resid=B0...file%2czip

"Conflict errors" refers to: http://forums.nextpvr.com/showthread.php...=conflicts

The default folder is at present: D:\MediaStore\Video\VideoEdit

I have been experimenting with this problem and have noticed that it seems to get worse as more recordings are added to a folder and the <i>rate</i> of disk space use increases.

Does NPVR look at disk space before recording? If so can this be an option?

Researching Windows disk space alarms, I have discovered the current opinion is that they were designed for much smaller storage sizes and the present day usage of up to 6TB disk drives render the algorithms used obsolete.

Microsoft's algorithm for disk space alarms is hard coded and non-adjustable. They are in three steps but seem to be based on 10% remaining disk size adjusted by the frequency and average size of files written to the disk.

The trouble is 10% of a 4TB disk is 400GB, enough for about 100 hours of HD recording, - hardly an urgent matter. Add to this the unknown effect of junction points crossing disk boundaries and reliability problems can arise.

Also now with the advent of the "storage spaces" concept it would seem that Microsoft is not developing new algorithms for terabyte sized disk drives.

I realize there are a few assumptions in the above but could this be where the problem lies, - premature indication of low disk space?

ref: https://msdn.microsoft.com/en-us/library...s.85).aspx