Problems with overlapping recordings

[sub]

Note the following group of lines:

> Recording due to start pre-padding, but tuner not available
> Scheduled Recording about to start maybe a candidate for moving to another tuner (different locator than another recording on same device)
> Existing:
> irc</map><chan>16</chan>
> Required:
> rc</map><chan>16</chan>
> Was allocated to capture source: 25
> Checking possible candidate: 35
> Checking possible candidate: 34
> Checking possible candidate: 33
> Checking possible candidate: 32
> Checking possible candidate: 25
> Checking possible candidate: 26
> Checking if multi-record possible...
> Checking possible candidate: 27
> Checking if multi-record possible...
> Checking possible candidate: 20
> Recording not moved. No other available tuner could be found.

This group of lines appeared hundreds of times within a one minute
period at 8:30 pm and again at 9:59 pm. Apparently this had to do
with trying to accommodate the one-minute pre-padding for Broad City
and, upon failing, kept trying almost 200 times within one minute. I
don't know whether that's a bug or a feature, but my gut reaction is
"that can't be right."

Seeing these messages over and over is actually normal, and the intended behaviour. There is an active thread that is the recording service, responsible for starting/stopping recordings etc, monitoring the status of stuff like device leases etc. One of those things it does is monitor for whether a tuner has become available. It's basically checking once around the loop if a tuner is now available (like a user has cancelled another recording early etc). It's actually a very little work, but it can look scary in the logs because it logs lots of information. I might just remove those messages so users don't have to worry about it

[sub]

HDHomeRun Prime is one of only two types of device I cannot emulate fully in my environment (the other is a Ceton), so there is some level of guess work involved in supporting these devices, and I'm dependent of feed back from users. We don't use cable card devices here in NZ.

It'd be useful if you could run some tests to see if you could reproduce the scenario at it's most basic. Like backing up your npvr.db3, deleting all the HDHR Prime tuners accept for one, to force it to be used for everything, then see if a simple back-to-back recording exhibits the problem. It'd be worth doing that with short programs if you could, so that I could get a copy of the resulting files to take a closer look at the data in each.

[johnsta]

> HDHomeRun Prime is one of only two types of device I cannot
> emulate fully in my environment (the other is a Ceton), so there
> is some level of guess work involved in supporting these devices,
> and I'm dependent of feed back from users. We don't use cable card
> devices here in NZ.

> It'd be useful if you could run some tests to see if you could
> reproduce the scenario at it's most basic. Like backing up your
> npvr.db3, deleting all the HDHR Prime tuners accept for one, to
> force it to be used for everything, then see if a simple
> back-to-back recording exhibits the problem. It'd be worth doing
> that with short programs if you could, so that I could get a copy
> of the resulting files to take a closer look at the data in
> each.

You've asked me to do a number of things, and I'm trying to figure out
how to do it to give you the information you need with the least
amount of effort. With regard to the db3 file, it's really huge, because
it has hundreds of shows scheduled from years ago that are no longer
valid. I keep meaning to clean it up, but it's just one more thing
that never gets done.

However, it's easy enough to get the data from the tuner-related
tables. The following listings contain all the relevant data:

Code:

sqlite> .tables
ANALOG_RECORDER       DECRYPT_QUEUE         HDPVR_RECORDER
CAPTURE_SOURCE        DIGITAL_RECORDER      PLAYBACK_POSITION
CHANNEL               DIGITAL_RECORDER_LNB  RECENTLY_DELETED
CHANNEL_GROUP         DRI_RECORDER          RECURRING_RECORDING
CHANNEL_GROUP_NAME    EPG_EVENT             SCHEDULED_RECORDING
CHANNEL_MAPPING       EPG_GENRE             TEMP_FILE
CHANNEL_STREAM        HDHR_RECORDER
sqlite>

sqlite>
sqlite> select count(*) from analog_recorder ;
0
sqlite> select count(*) from capture_source ;
8
sqlite> select count(*) from channel ;
965
sqlite> select count(*) from channel_group ;
32
sqlite> select count(*) from channel_group_name ;
1
sqlite> select count(*) from channel_mapping ;
2891
sqlite> select count(*) from channel_stream ;
0
sqlite> select count(*) from decrypt_queue ;
0
sqlite> select count(*) from digital_recorder ;
0
sqlite> select count(*) from digital_recorder_lnb ;
0
sqlite> select count(*) from dri_recorder ;
4
sqlite> select count(*) from epg_event ;
154600
sqlite> select count(*) from epg_genre ;
200
sqlite> select count(*) from hdhr_recorder ;
3
sqlite> select count(*) from hdpvr_recorder ;
0
sqlite> select count(*) from playback_position ;
21
sqlite> select count(*) from recently_deleted ;
1009
sqlite> select count(*) from recurring_recording ;
308
sqlite> select count(*) from scheduled_recording ;
1345
sqlite> select count(*) from temp_file ;
0


sqlite>
sqlite> select * from analog_recorder ;
sqlite> select * from capture_source ;
20|IPTV Device|NShared.IPTVRecorder|Y|Y|8
25|HDHomeRun Device 1325E4C2|NShared.HDHomeRunRecorder|Y|Y|5
26|HDHomeRun Device 1325E4C2|NShared.HDHomeRunRecorder|Y|Y|6
27|HDHomeRun Device 1325E4C2|NShared.HDHomeRunRecorder|Y|Y|7
32|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 1|NShared.DRIRecorder|Y|Y|4
33|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 2|NShared.DRIRecorder|Y|Y|3
34|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 3|NShared.DRIRecorder|Y|Y|2
35|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 4|NShared.DRIRecorder|Y|Y|1
sqlite> -- select * from channel ;
sqlite> -- select * from channel_group ;
sqlite> select * from channel_group_name ;
1|Stdx
sqlite> -- select * from channel_mapping ;
sqlite> select * from channel_stream ;
sqlite> select * from decrypt_queue ;
sqlite> select * from digital_recorder ;
sqlite> select * from digital_recorder_lnb ;
sqlite> select * from dri_recorder ;
32|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 1
33|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 2
34|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 3
35|Ceton InfiniTV PCIe (00-80-1b-8a) Tuner 4
sqlite> -- select * from epg_event ;
sqlite> -- select * from epg_genre ;
sqlite> select * from hdhr_recorder ;
25|1325E4C2|0
26|1325E4C2|1
27|1325E4C2|2
sqlite> select * from hdpvr_recorder ;
sqlite> -- select * from playback_position ;
sqlite> -- select * from recently_deleted ;
sqlite> -- select * from recurring_recording ;
sqlite> -- select * from scheduled_recording ;
sqlite> select * from temp_file ;
sqlite>

Turning now to the other tasks, here's what I suggest: I'll use
schedule.exe to schedule 6 recordings, four minutes each:

set opts=-minutes 4 -pre 1 -post 2

Schedule.exe -channel 2 -start "2019-03-23 14:15" %opts% -name "1A"
Schedule.exe -channel 4 -start "2019-03-23 14:15" %opts% -name "1B"
Schedule.exe -channel 5 -start "2019-03-23 14:15" %opts% -name "1C"

Schedule.exe -channel 10 -start "2019-03-23 14:19" %opts% -name "2A"
Schedule.exe -channel 30 -start "2019-03-23 14:19" %opts% -name "2B"
Schedule.exe -channel 61 -start "2019-03-23 14:19" %opts% -name "2C"

I can monitor this test as it's running, and watch what happens. This
will provide 6 short recordings to look at.

Let me know if that makes sense.

[sub]

Did you follow my suggestion of backing up npvr.db3 (so you can restore it later), then deleting all the prime tuners other than one? I really want to see the scenario happening on a single tuner, without the logs filled with other crap happening on other tuners.