How do recordings get allocated to cards? (1 Viewer)

[riksmith]

Hi Jameson, i am currently working with gibman on the card allocation code. I found some bugs, but i can't figure out your specific problem. It should never have used the DVB-S card for a channel that is not mapped to it and the card not able to tune to it.

We are also going to make unittest and i will try to incorporate this scenario.

 

[jameson_uk]

Hi Jameson, i am currently working with gibman on the card allocation code. I found some bugs, but i can't figure out your specific problem. It should never have used the DVB-S card for a channel that is not mapped to it and the card not able to tune to it.

We are also going to make unittest and i will try to incorporate this scenario.

Must have not been clear enough.... The channel was allocated to the DVB-S tuner. This is not really a problem but rather a feature of MP.

All I was thinking was that in theory the tuners should have supported recording all three channels with no conflicts. The problem arose as the third recording added was for a channel that was only on the DVB-S card but by then MP seemed to have allocated a recording (based on card priority) to the DVB-S tuner (even though the channel was also on a free DVb-T tuner)

It looks like the conflict manager plugin may of sorted this by setting the preferred tuner but that has now been removed from the released code. I am assuming the fact recordings are stored at schedule level and not recording level makes the preferred card not so useful. Probably something for MPII but having one table of schedules and one of upcoming recordings (ie. actual start times etc) would be a lot more flexible (and also remove the need for the cancelled schedule table as you would just delete the records from the recording table instead. This would allow you to set card allocation for an individual recording but I can see that this is something for another day.....

 

[riksmith]

Aaah... i see i misread your post. Are you able to reproduce this and produce logging?

The only thing i do not understand:
rec 1: 21-22 -> T
rec 2: 21-22 -> T, S
rec 3 : 23-?? -> S

Why is it a problem that the second recording is done on the S tuner? It is perfectly able to record the 3 in this scenario or do you have pre / post of 30 minutes?

 

[riksmith]

Btw: There still is a server part for conflicts management, the server does assign the recording to a channel. In logging: AssignSchedulesToCard

This is in the core, so no the conflictmanager plugin needed.

 

[riksmith]

It seems these two look a like, but it is not entirely the same. There is a thing called "RecommendedCard" for a recording.

The conflict manager sets this to a card which has no conflicts, but the code in core does not

Not sure if these are bugs, or if these things are meant to be different.

 

[jameson_uk]

Aaah... i see i misread your post. Are you able to reproduce this and produce logging?

The only thing i do not understand:
rec 1: 21-22 -> T
rec 2: 21-22 -> T, S
rec 3 : 23-?? -> S

Why is it a problem that the second recording is done on the S tuner? It is perfectly able to record the 3 in this scenario or do you have pre / post of 30 minutes?

Sorry I think there may have been a typo there.... pre record is set to 3 mins and post record to 5 mins.
Third recording was 22:00 onwards

Btw: There still is a server part for conflicts management, the server does assign the recording to a channel. In logging: AssignSchedulesToCard

This is in the core, so no the conflictmanager plugin needed.

It seems these two look a like, but it is not entirely the same. There is a thing called "RecommendedCard" for a recording.

The conflict manager sets this to a card which has no conflicts, but the code in core does not

Not sure if these are bugs, or if these things are meant to be different.

But is the order in which the recordings are added important? My thought was that initially recordings were allocated to cards when they are scheduled so when I added recording 1 it picked the highest priority card that the channel was on (a DVB-T card) and the second recording picked the next free card with the channel on (which happened to be the DVB-S card)

Else if card allocation happens at record time then this must not consider what is about to happen and just picks the next available card with the channel on based on priority ??

 

[riksmith]

When investigating the current card allocation algorithm i found that the card allocation for recordings is pretty bugged / unfinished.
The bottom line is that there is no real card allocation for recordings when they are planned (although it looks like it). Perhaps if i have time i will dive deeper in to it to see if it is fixable in TVE3 (1.x), but i first need to finish the normal card allocation.

Currently when a recording is started it is recorded at the first free card it finds (indeed using prioirity). It could be that my changes improve this behaviour a little, but i really doubt it.

 

[jameson_uk]

When investigating the current card allocation algorithm i found that the card allocation for recordings is pretty bugged / unfinished.
The bottom line is that there is no real card allocation for recordings when they are planned (although it looks like it). Perhaps if i have time i will dive deeper in to it to see if it is fixable in TVE3 (1.x), but i first need to finish the normal card allocation.

Currently when a recording is started it is recorded at the first free card it finds (indeed using prioirity). It could be that my changes improve this behaviour a little, but i really doubt it.

so the conflict management is an extra level of unfinished complexity on top of this

If you do happen to notice when looking through the code whether the recommendedCard value in the schedule table is actually used this would at least allow the conflict plugin to be made to work at a later date.

Just a shame this is so embeded within MP. I did have a quick scan through the code and from what I could tell there are a couple of places which turn the schedule table into a list of recordings; it would make a lot more sense to store the individual recordings in a table (this would also make the cancelled schedules much easier to handle as it would be a simple delete) and the schedule rules in another. Card allocation could then be set each time a recording is added to the table and each time a new recording is added any conflicts identified and an attempt to resuffle the card allocations to resolve where possible). Anyway this is far too much work for MP 1.1 and probably not going to happen until the next version of TVE

 

[riksmith]

When investigating the current card allocation algorithm i found that the card allocation for recordings is pretty bugged / unfinished.
The bottom line is that there is no real card allocation for recordings when they are planned (although it looks like it). Perhaps if i have time i will dive deeper in to it to see if it is fixable in TVE3 (1.x), but i first need to finish the normal card allocation.

Currently when a recording is started it is recorded at the first free card it finds (indeed using prioirity). It could be that my changes improve this behaviour a little, but i really doubt it.

so the conflict management is an extra level of unfinished complexity on top of this

If you do happen to notice when looking through the code whether the recommendedCard value in the schedule table is actually used this would at least allow the conflict plugin to be made to work at a later date.

Just a shame this is so embeded within MP. I did have a quick scan through the code and from what I could tell there are a couple of places which turn the schedule table into a list of recordings; it would make a lot more sense to store the individual recordings in a table (this would also make the cancelled schedules much easier to handle as it would be a simple delete) and the schedule rules in another. Card allocation could then be set each time a recording is added to the table and each time a new recording is added any conflicts identified and an attempt to resuffle the card allocations to resolve where possible). Anyway this is far too much work for MP 1.1 and probably not going to happen until the next version of TVE

At least in my changed card allocations code the recommended card is used (when free) not sure about the other one.

I agree with you on the second part.

You should have a table with the schedules for everything but once recordings, a table with the actual (planned) recordings. And if you cancel an episode from a serie, it can just set a flag in the recording table.

And indeed conflict handling should be handled that way. Each recording should have a list of possible cards (calculated from the other recordings) instead of 1 card (which is also not calculated correctly i think).

But we should not do this as you say in the current TVE, this is something for TVE4.