dvbserver handling of concurrent use

[pastimer]

If two or more clients 'tap' the same transport stream dvbserver needs a mechanism to handle request for channel switches.

 

Let's say i tuned to NED1 and my son in another room starts his client and tunes to NED2. (same transponder, no problem)

 

Now if i change to JETIX, which is on another transponder, dvbserver should first find out if JETIX is available on another device that is not in use or on another existing transport stream. If that is the case, i can be switched accordingly.

 

If that is not the case, it should look for NED2 being available on another device or existing stream. If so, my son can be switched accordingly and then i can be stwiched to the other transponder.

 

If however, both JETIX and NED2 are not available through other sources, my son would have to be kicked from the stream (and receive the a message that the stream has stopped) allowing me to change to JETIX, because my connection to the device is older than his.

 

Complicated stuff, but if you want to exploit the possibilities of dvbserver to the full, it needs to be made.

 

Regards, Eppo

 

EDIT: I realise that probably the most elegant way a conflict can be handled is by a message to the client that the stream is about to die. That client then automatically retunes it's selected channel so there is no need to kick the client of the stream from the server side. As there is a pending channel switch on the original stream, that stream will no longer be available. It will then look for another source for the selected channel.

Edited January 18, 2008 by pastimer

[dgdg]

Hi pastimer,

 

what you describe her is not a technical conflict. It is a family conflict. And I think this can not be solved by technical rules.

I think in most families this will be handled by familiy hierachy. Maybe DVBViewer should check the age of the family member instead of the age of the stream.

 

In earnest: In my opinion DVBViewer should not cancel an existing stream. But it would be comforable, if the clients had readable names. So the name of the client that blocks the stream could be displayed on the client that request the stream.

 

I just think about the situation of the family head watching soccer and the son or wife cancels his stream just bevor a goal is scored.

Edited January 18, 2008 by dgdg

[pastimer]

In earnest: In my opinion DVBViewer should not cancel an existing stream.

 

But it does this in the current release! I can largely agree with with your approach of resolving it within the family, allthough i can think of other communities where that would not work. But right now, the first client that wants a channel switch gets it and thus implicitely kicks all other clients that use that stream!

 

Regards, Eppo

Edited January 18, 2008 by pastimer

[pastimer]

Hi pastimer,

 

what you describe her is not a technical conflict. It is a family conflict. And I think this can not be solved by technical rules.

 

In a configuration where there is a possibility that there exist multiple sources for a requested channel, it wil often be possible to avoid clients being shut off from an existing stream. But that DOES need resolving concurrency conflicts.

It also needs an good logical datamodel of the entities and relations involving channels, transponders, satellites, diseqc configurations and devices.

 

I doubt that it is possible in DVBViewer to select a channel and not getting it through the same device allways - or not at all.

DVBViewer does not know logical channels. It only knows channel mappings: NED1 through Digitenne or NED1 through Astra1.

Not just NED1 and find me a source for that channel.

 

Eppo

[dgdg]

But right now, the first client that wants a channel switch gets it and thus implicitely kicks all other clients that use that stream!

 

I didn't know this. I'm just starting with DVBServer.

 

In my optionen an existing stream should not be affected in any way. Also switching to another transponder or another device will cause a retuning and a dropout of several seconds. Any active recording would become corrupted.

 

Another idea is to fix priorities to the clients. The priority controls which clients can kick other clients.

 

If any client can kick recordings running on my server, than I can quit my thoughs about network streaming instantly. If a recording kicks another client, that's for me ok. Recordings have the highest priority. But that ist the only case where I accept an interruption of an existing stream.

Edited January 18, 2008 by dgdg

[pastimer]

I didn't know this. I'm just starting with DVBServer.

 

In my optionen an existing stream should not be affected in any way. Also switching to another transponder or another device will cause a retuning and a dropout of several seconds. Any active recording would become corrupted.

 

Another idea is to fix priorities to the clients. The priority controls which clients can kick other clients.

 

If any client can kick recordings running on my server, than I can quit my thoughs about network streaming instantly. If a recording kicks another client, that's for me ok. Recordings have the highest priority. But that ist the only case where I accept an interruption of an existing stream.

 

I agree. I thought of that. That is: SCHEDULED recordings. Not the red button.

[dgdg]

That is: SCHEDULED recordings. Not the red button.

 

Yes. I'm talking about scheduled recordings.

[Moses]

If I remember correctly, then it was the way, that no streams would be canceld, but if a tune was not possible, no data would be sended. So an ongoing recording wasn't canceld, but if there was no free DVB Device, it could happen that the recording did not get any data (and there for would be an empty file).

 

I don't know why it was changed this way. This was reported once in a Beta-Test and it sounded as if the change was accidently.. At the moment if there is just one possible device, and two clients use it, both can switch the channel and cancel the stream for the other device (if no other device is free). I think that's not realy optimal.

 

My current approach is to have a DVBViewer and dvbserver running on the same PC, the DVBViewer is only there to carry out recordings, and has direct access to the dvb hardware. DVB Server and DVBViewer do coordinate hardware access between them. So the only problem that can occur is that no device is free for DVBViewer to record, but a recording can't be canceled....

 

For the channel mapping: There is no way for DVBViewer to recognize two channels transmitted through different networks are the same channel. Furthermore you don't want this way of mapping, always... for example DVB-T has much lower bandwith and picture quality in germany than DVB-S or DVB-C and therefore I wouldn't like DVBViewer to record this channels automaticaly.

Edited January 18, 2008 by Moses

[pastimer]

For the channel mapping: There is no way for DVBViewer to recognize two channels transmitted through different networks are the same channel. Furthermore you don't want this way of mapping, always... for example DVB-T has much lower bandwith and picture quality in germany than DVB-S or DVB-C and therefore I wouldn't like DVBViewer to record this channels automaticaly.

 

1. The fact that dvbv is not able to recognize two channels transmitted through different networks are the same means that DVBV needs improvement to acquire that ability. If two mappings are not recognized as being the same (on the basis of the channel name), they can always be assigne to be the same channel by hand of course.

 

2. If it is important in certain situations (recordings) to have it in dvb-s then make it possible to specify that in your schedular.

' I want NED1 at 21.00 and the transport-type must be dvb-s', so that is easely dealt with.

[Moses]

no, it's not. What happens, if your wife watches something via DVB-S at 21.00? is she kicked because NED1 needs to be recorded in dvb-s? And then she needs to tune the same channel again, so it will be recieved via DVB-T... how should anybody understand what's going on? It's much more simple today...

[pastimer]

no, it's not. What happens, if your wife watches something via DVB-S at 21.00? is she kicked because NED1 needs to be recorded in dvb-s? And then she needs to tune the same channel again, so it will be recieved via DVB-T... how should anybody understand what's going on? It's much more simple today...

 

My wife does not want to understand what is going on, she wants to watch television.

 

What do i prefer

IST: " Sorry no television, i'm recording ". Easy to understand and to explain.

SOLL: DVBViewer automatically retunes the channel and the remainder of the program is received in DVB-T.

 

Although she doenst understand what's going on i assure you that my wife will be comfortable with te SOLL and is usually furious with the IST.

Edited January 18, 2008 by pastimer

[dgdg]

My current approach is to have a DVBViewer and dvbserver running on the same PC, the DVBViewer is only there to carry out recordings, and has direct access to the dvb hardware.

 

DVBViewer and DVBServer can both have access to the same DVB-hardware on the same PC ? How is the access coordinated ?

[Moses]

Yes, but not at the same time. Only one application can access a dvbdevice at the same time. But DVBViewer and dvbserver communicate and tell each other which devices they use and so on... so no conflicts will arise.

[dgdg]

Ok, now I understand, why my local DVBViewer that runs beside DVBServer could bypass DVBServer. It was not a bug, it was a feature.

 

I will now try to concentrate all my DVB hardware on the server (2 x Skystar DVB-S, 1 x Pinnacle 400e DVB-S , 1 x Freecom DVB-T) and than make some tests, how this all works together.

[Moses]

instead of DVBViewer you can also use the recording services on the server (which can only access the hardware directly, no network devices in the service!). I did that for some time, but I then missed EPGPlus too much. As far as I understood it, the tvinfo importer can work with the service, too. And the webinterface of the service is quite decent, too. So that is another option to get recordings on the server..

Edited January 19, 2008 by Moses