My NextPVR 3.2.9 installation records TV channels in the same frequency on 2 tuners

[johnsonx42]

post full logs again so we can see exactly what was going on at that time.

Only the 4 sources should be considered. The other 4 refers to my Hauppauge HVR2200 card (2 for DVB-T, 2 for analog), while the remaining one is the IPTV. So total 9 sources.

I was referring to the list of tuners in your signature here in the forum; you've listed a TBS quad DVB, a TBS dual DVB, an HVR2200 (also dual), and a HVR-1300 listed which total 9 discreet capture sources. However now having seen your Device Status screen, I see that you only have the quad DVB card configured for DVB channels.

[Kiwi]

post full logs again so we can see exactly what was going on at that time.


I was referring to the list of tuners in your signature here in the forum; you've listed a TBS quad DVB, a TBS dual DVB, an HVR2200 (also dual), and a HVR-1300 listed which total 9 discreet capture sources. However now having seen your Device Status screen, I see that you only have the quad DVB card configured for DVB channels.

Ok I will try to capture a set of logs together with the matching screenshot of the Device Status at the same time, when it happens.

Oh btw, my signature may list the devices, but that doesn't mean I put every listed card in my system. Just take it that it lists down the TV cards that I have owned or currently owning.

[sub]

For the purposes of the discussion, we can ignore the recordings done by Tuner C and Tuner D as their channel frequency are different from that of Tuners A and B. So let's focus on Tuner A and B. They are actually the same frequency so I do not understand why the program assigned 2 tuners to do the recording.

Is it actually causing any problem? Sometimes the app prefers to use a different tuner to ensure it can get complete pre and post padding on the following recording (caused by a third or later recording allocated to the same tuner). You'd probably find if the tuners were busy it'd pack them in more tightly, and stick to sharing the tuner on the same frequency, but with padding sometimes clipped.

I must say, your recordings look suspiciously like those from a commercial user in the media monitoring business. If were doing something like this, your best bet would be to contact me privately, and we could come to some agreement, and I can give you tools tailored to your exact needs.

[johnsonx42]

I must say, your recordings look suspiciously like those from a commercial user in the media monitoring business.

I was wondering that myself, all those back-to-back and overlapping manual recurring recordings, no epg, seems like a very unlikely way for a 'normal user' to use the program.

[Kiwi]

Is it actually causing any problem? Sometimes the app prefers to use a different tuner to ensure it can get complete pre and post padding on the following recording (caused by a third or later recording allocated to the same tuner). You'd probably find if the tuners were busy it'd pack them in more tightly, and stick to sharing the tuner on the same frequency, but with padding sometimes clipped.

I must say, your recordings look suspiciously like those from a commercial user in the media monitoring business. If were doing something like this, your best bet would be to contact me privately, and we could come to some agreement, and I can give you tools tailored to your exact needs.

For the moment it's not causing any problem, but it might cause a problem if there are more channel at different frequencies. Anyway I'm totally not using pre and post padding, hence the settings for pre and post padding is 0.

As for the suspicion of being a commercial user, I have to assure u that I'm just a normal user. I record a lot, but delete a lot too. Sometimes I find a good programme and I will watch it to spend off free time. I do watch my country's news bulletins though.

[Kiwi]

I was wondering that myself, all those back-to-back and overlapping manual recurring recordings, no epg, seems like a very unlikely way for a 'normal user' to use the program.

I have to admit that I'm somewhat an eccentric person with weird recording habits. But I'm still a normal user, not recording for commercial purposes.

[johnsonx42]

I figured out the likely reason for the result shown in your image:
Tuner A had a recording (not shown) that ended sometime between 1900 and 1959 on a different channel.
The next 3 recordings were all on the same physical channel, and Tuner A was still in use, so they were all scheduled on Tuner B.
Then when the scheduler got to the CHU_2000 recording, it found the highest priority tuner, Tuner A, was now available, so it used it. It doesn't consider whether some other lower-priority tuner was also set to record on the same channel at the same time. The "can the show be multi-recorded on this tuner?" check is only done after the tuner is found to be busy; if the tuner is available, it schedules the recording and moves on. You could probably contrive a scenario where you could get all 4 tuners busy recording shows off the same physical channel, but it's not likely to happen in actual usage. (this description isn't completely accurate, as it implies the scheduling is done in chronological order; it's actually done in recurring priority order, but I can't think of how to word it better; the net result is the same though: CHU_2000 recording could have been scheduled first on Tuner A, but the CH5_2000/CH8_1900/CHU_1900 recordings all needed to start while Tuner A was busy with a previous recording, so they all got pushed to Tuner B)

So you have found not so much a bug but rather a case where the scheduler isn't as smart as it could be; it operates in order first by recurring priority and then by tuner priority so it may not always come up with the most elegant and efficient allocation of tuners. However a reliable scheduler has always been very critical to the operation of NextPVR (and GB-PVR before it), so there may be some desire to keep it simple and reliable.

[Kiwi]

I figured out the likely reason for the result shown in your image:
Tuner A had a recording (not shown) that ended sometime between 1900 and 1959 on a different channel.
The next 3 recordings were all on the same physical channel, and Tuner A was still in use, so they were all scheduled on Tuner B.
Then when the scheduler got to the CHU_2000 recording, it found the highest priority tuner, Tuner A, was now available, so it used it. It doesn't consider whether some other lower-priority tuner was also set to record on the same channel at the same time. The "can the show be multi-recorded on this tuner?" check is only done after the tuner is found to be busy; if the tuner is available, it schedules the recording and moves on. You could probably contrive a scenario where you could get all 4 tuners busy recording shows off the same physical channel, but it's not likely to happen in actual usage. (this description isn't completely accurate, as it implies the scheduling is done in chronological order; it's actually done in recurring priority order, but I can't think of how to word it better; the net result is the same though: CHU_2000 recording could have been scheduled first on Tuner A, but the CH5_2000/CH8_1900/CHU_1900 recordings all needed to start while Tuner A was busy with a previous recording, so they all got pushed to Tuner B)

So you have found not so much a bug but rather a case where the scheduler isn't as smart as it could be; it operates in order first by recurring priority and then by tuner priority so it may not always come up with the most elegant and efficient allocation of tuners. However a reliable scheduler has always been very critical to the operation of NextPVR (and GB-PVR before it), so there may be some desire to keep it simple and reliable.

I see, but I feel that the "can the show be multi-recorded on this tuner?" check should be done at the start of every recording so as to make the recording service more efficient.