Jump to content

How to identify more than one dvbs card in a plugin ?


Bernd Wessels

Recommended Posts

Hello,

 

I wrote my own DVBViewer plugin and it is working well. That means that all the function (I know about) are called from the DVBViewer.

 

But now I have a problem. I have two TT S2-3200 DVBS cards in my computer. Now there are sheduled recordings and I am zapping around.

 

Each time DVBViewer is changing from one channel to another, my plugin is called. This is great, but now the plugin must know which card is changing the channel.

 

How can my plugin get the information which card is changing the channel ???

 

Thanks in advance and best regards,

 

Bernd

Link to comment
It's always the card used for the (LiveTV) playback. the plugin is tied to the main (LiveTV) playback.

 

I don't think so.

1. Open DVBViewer - Default channel starts (for example ARD) - Plugin function "Execute" is called

2. Manually start recording this channel

3. Now change the channel - The next channel starts (for example ZDF) - it is on the tuner of the free card, because the first tuner is recording ARD

The Plugin function "Execute" is called - BUT HOW CAN MY PLUGIN KNOW THAT IT IS THE OTHER CARD FOR THIS "Execute" CALL ???

 

Best regards,

 

Bernd

Link to comment

It doesn't. It always gets the card tied to the main playback. if the viewer needs to change cards, because one can't be used, it does it transparent for the plugins.

Link to comment
It doesn't. It always gets the card tied to the main playback. if the viewer needs to change cards, because one can't be used, it does it transparent for the plugins.

 

OK.

 

Is there a chance to have an instance of my plugin running for each card ?

Can the visible (Live playback) and the recording card use my plugin (maybe one instance for each) at the same time ?

 

If not, is there a chance to plug in a directshow filter (processing raw ts) behind each card before the rest of the DVBViewer chain ?

 

Best regards,

 

Bernd

Link to comment

Well, no not exactly.

 

You could use the same technique like here.

 

The rules are simple.

- The main playback always uses the main pluginhandler (\Plugins\) and each recording gets a own pluginhandler (\plugins\plugins1\ .. \plugins\plugins32\) dynamically assigned. The Preview gets also one.

They only get a subset of the plugin functions (menu handling and graph handling makes no sense for them) but everything you need to interact with the streamdeliverer (card) should work (see here).

 

Remember:

- Even if you press record on the current channel, the recording will get an own plugin assigned, which stays with it till it ends.

- The viewer tracks which pluginhandlers are present, you don't need to do 32 folders. but if you want to use them always start at 1 and leave no out. If the viewer runs out of pluginhandlers the recording (or preview) doesn't get one.

- ALWAYS clean up after yourself (callbacks etc).

- ALWAYS follow the events as fast as possible (unloading/terminating etc).

- NEVER try to interact with the user (windows, msgbox etc can easyly destroy the recording). You also have no way to get into the plugns menu.

- Save your settings into the apropriate userdatafolder (\plugins\plugins1 and so on). the userdatafolder can easyly be calculated from the usermode.ini or from the COM interface.

 

If you want to test it, try the netstreaming plugin, it does work with these structures. But you have to configure it by editing the correct ini files, which are created after the first start (don't ask, it was not meant to be published as a feature ;) ).

 

I hope this helps.

 

BTW: only 3.9.4+ or the current recordingservice support this.

Link to comment
Well, no not exactly.

 

You could use the same technique like here.

 

The rules are simple.

- The main playback always uses the main pluginhandler (\Plugins\) and each recording gets a own pluginhandler (\plugins\plugins1\ .. \plugins\plugins32\) dynamically assigned. The Preview gets also one.

They only get a subset of the plugin functions (menu handling and graph handling makes no sense for them) but everything you need to interact with the streamdeliverer (card) should work (see here).

 

Remember:

- Even if you press record on the current channel, the recording will get an own plugin assigned, which stays with it till it ends.

- The viewer tracks which pluginhandlers are present, you don't need to do 32 folders. but if you want to use them always start at 1 and leave no out. If the viewer runs out of pluginhandlers the recording (or preview) doesn't get one.

- ALWAYS clean up after yourself (callbacks etc).

- ALWAYS follow the events as fast as possible (unloading/terminating etc).

- NEVER try to interact with the user (windows, msgbox etc can easyly destroy the recording). You also have no way to get into the plugns menu.

- Save your settings into the apropriate userdatafolder (\plugins\plugins1 and so on). the userdatafolder can easyly be calculated from the usermode.ini or from the COM interface.

 

If you want to test it, try the netstreaming plugin, it does work with these structures. But you have to configure it by editing the correct ini files, which are created after the first start (don't ask, it was not meant to be published as a feature ;) ).

 

I hope this helps.

 

BTW: only 3.9.4+ or the current recordingservice support this.

 

Thank you so much. I think this is the answer I need for the design of my plugins.

 

Is there a detailed documentation about all the features around the plugin api ?

 

I only found the downloadable plugin sdk 0.2 which is very poor. There must be a better one with more detailed informations about all the messages and the parameter stuctures and so on.

 

Thanks again, I will try tonight and give some feedback here.

 

Bernd

Link to comment

read in the second link of my post. remember, there is only a (very) small subset because most of the functions are not needed or do not make sense with a recording. If you have further questions, just ask here or (in this case with my permission ;) ) per PM.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...