Manually assign tunners to recordings?

[Croftie]

Is this possible? When scheduling several recordings they are not always assigned to the same tuner if they are an the same mux, which then causes conflicts that npvr doesn't warn about (by design because it doesn't take padding into account) so recordings get cut off.

The only way I can see to do this is manually edit npvr.db3. Would that work? I'll test it tomorrow when the tunner isn't busy but in the mean time if anyone knows.

If that is the only way I'd love a gui option to manually assign tuners to recording. Overlaying the assigned tunner in the epg would be cool too so you can see at a glance they are assigned as you like.

Recently upgraded to 3.2.9 and it's working perfect, thank you

[steeb]

Is this possible? When scheduling several recordings they are not always assigned to the same tuner if they are an the same mux, which then causes conflicts that npvr doesn't warn about (by design because it doesn't take padding into account) so recordings get cut off.

Surely that is the question?

Why should you have to delve further?

I am fairly stupid but surely this should be what NextPVR does by default and you shouldn't have to dig about editing the db?

Not having a dig at you Croftie, just really trying to get a handle on where we are at with NextPVR at the moment!

Suspect that provided logs may have helped?

[Croftie]

sorry, i'm getting ahead of myself. I presumed this was intended behaviour.

Is it? If not yep logs would be helpful but i'm in bed now so will attatch tomorrow if needed.

Thanks.

[Kiwi]

I had a recent problem too with my recordings which used extra tuners than necessary, which was discussed in another thread.

I basically operate on 2 frequencies. The first one has a lot of SD channels, which is tuned pretty much most of the time. The second one is a single HD channel, which I sometimes record as a form of simul recording in addition to the SD channel. So what I notice is that sometimes manual recurring recordings based on the same SD frequency ended up using more than 1 tuner.

But I figured out a way to resolve the problem. What I did was to move the priority of the manual recuriring recordings based on the second HD frequency to be behind those based on the first SD frequency. And the problem of using more than 1 tuner for the same frequency issue did not come up again.

[smiffypr]

Just edit the "device setup" of each individual device so that any channel only appears against one device and all the channels on the same frequency are on the same device.
If you have enough devices to have each one covering only one transmission frequency, you will never get any conflicts at all.

[Croftie]

sub, is this intended behaviour or should recordings on the same mux always go to the same tunner?

Kiwi, I can't see how to set the priority can you elaborate please.

smiffypr, that's a good idea. but unfortunatly I don't have enough tunners or spare signal on the areal for more feeds. It would be an expensive process to add any more.


Just edited the capture_source_oid feild so all mux's are on the same tunner, will see later tonight if it works or the PC sets on fire haha.

Thanks everyone.

[sub]

sub, is this intended behaviour or should recordings on the same mux always go to the same tunner?

Generally it'll try to make recordings on the same tuner if possible. It's complicated though - sometimes a later overlap, or preference to retain padding on later recording can prompt it to use a different tuner.

Just edited the capture_source_oid feild so all mux's are on the same tunner, will see later tonight if it works or the PC sets on fire haha.

Keep in mind the application will reallocate the tuners each time the EPG is updated. Also, the app only uses that has a recommendation - it can sometimes decide to use a different tuner when it comes time to start the recording.

[Croftie]

Thanks sub, I recognise it's a complicated area.

Nothing caught fire and all recordings were complete, that wouldn't of been the case had I not manually changed the assigned tunners as it's just a dual tunner setup so no spare tunners for it to re-gig recordings.

Is the assigning in this example expected?

Two recordings on different MUXs added to the same tunner, there are no other recordings scheduled so it could of used the spare tunner:



Schedule another recording and they havn't been regigged so unless they get regigged before the first recording starts pre and post padding at 1am will be ignored.



However, if I add the two recordings on MUX2 they are added to the same tunner and if I then add the recording on MUX1 it's added to the spare tunner. So no conflicts.

In this scenario recordings are being assigned differently to tunners depending on the order I schedule them. Is that expected or can the auto-assigning be optimised further?

[sub]

Is the assigning in this example expected?

Two recordings on different MUXs added to the same tunner, there are no other recordings scheduled so it could of used the spare tunner:

What typically happens in this scenario is that it packs the tuners in tightly when they're scheduled, intentionally ignoring padding, but at recording time when it goes to start the second recording it'll reassess to see if it can move a tuner to give both recordings padding.

Schedule another recording and they havn't been regigged so unless they get regigged before the first recording starts pre and post padding at 1am will be ignored.



However, if I add the two recordings on MUX2 they are added to the same tunner and if I then add the recording on MUX1 it's added to the spare tunner. So no conflicts.

In this scenario recordings are being assigned differently to tunners depending on the order I schedule them. Is that expected or can the auto-assigning be optimised further?

Yes, this can happen. It doesn't usually go back and move existing recordings when trying to schedule a new one, so priority of season recordings etc is definitely a factor. These are not necessarily the tuners that'll end up being used for the recording though.

The app does a reasonable both with making sure it records everything. It's not perfect, but it's does an ok job. It complicated to deal with all possible eventualities.

[ttfitz]

Is this possible? When scheduling several recordings they are not always assigned to the same tuner if they are an the same mux, which then causes conflicts that npvr doesn't warn about (by design because it doesn't take padding into account) so recordings get cut off.

The only way I can see to do this is manually edit npvr.db3. Would that work? I'll test it tomorrow when the tunner isn't busy but in the mean time if anyone knows.

If that is the only way I'd love a gui option to manually assign tuners to recording. Overlaying the assigned tunner in the epg would be cool too so you can see at a glance they are assigned as you like.

Recently upgraded to 3.2.9 and it's working perfect, thank you

I don't know if this will help you at all, but it might at least get you thinking differently. I have two different types of tuners in my setup - one that records clear-QAM channels, and two that use a cablecard to record cable channels. While the channels available to the clear-QAM tuner are duplicated in the cablecard ones, the clear-QAM tuner can record two shows at the same time on the same mux, while the cablecard one can't.

Since I wanted to be able to pick the clear-QAM tuner for those cases, even though they are the same channel, I didn't merge the channel list. I gave the clear-QAM ones different names (for example, NBC on channel 4 is "NBC" on the cablecard listing, and "Ch 4" on the clear-QAM). I even named the clear-QAM channels with a mux specification, so I could keep track of which channels were together.

With this setup, I can at least partially manually pick which tuner gets used.

Hope this made sense, and maybe it will help.