Re-init CI-module & rebuild graph

[Gandalf_der_Graue]

hello DVBViewer-team, first let me state that your software is simply awesome !

 

actually i'm building myself an htpc (winxp based), with raw dual-core cpu power & ATI X1900GT. furthermore (for the tv-part) i got a SkyStar HD with genuine technisat CI interface (where Vcc is tied, by the manufacturer, to +5V).

at this CI-interface, i use an actual version of a CI-cam, which is able to deal with more than one crypt system.

 

now i've the following problems:

 

1. when i change channel from an ordinary mpeg2 station to an h264 channel, and vice versa, it happens (very often) that the playback fails. when this happens, only a restart of DVBViewer brings back a picture.

2. when i change to a channel using a different crypt system than the previous one, decoding fails.

 

at all, when i close DVBViewer (the channel selection remains stored then) and start it immediately again, playback works fine at the desired channel.

 

now my questions / feature requests :

 

is it possible to implement two options :

 

1. rebuild/reinit the filter graph, when changing from an h264 to an mpeg2 channel, and vice versa. Or simply reinit the filter graph, when the resolution changes (got some problems too, when changing from/to unusual resolutions like 544x576 and/or 352x576).

 

2. reinit the ci-cam on: 2.1 every channel change, 2.2 change of caid, 2.3 change of uncrypted channel to crypted channel.

 

at the acutal beta, i've noticed that you've implemented already an option not to send uncrypted streams to the cam. i checked this out, but encountered still problems after decoding failures when i try to switch back to an fta-channel.

 

best,

Gandalf_der_Graue

 

 

ps. related to the first described problem, i already messed around with different mpeg2 & h264 decoders, but without success.

[Lars_MQ]

1. Use detect videoformat and disable fast channelchange in the options.

2. Sounds like a problem of your Card/Driver/CAM.

2.1 Not wanted, would mess up recordings. the CI gets informed of every channelchange. It's the job of the driver/CAM to handle it correctly.

2.2 This IS the job of a CAM. That's why it gets informed of every channelchange.

2.3 see 2.1

Test the current Pro beta, the CI handling has been a little bit improved there. Don't use any beta drivers.

[Gandalf_der_Graue]

1. Use detect videoformat and disable fast channelchange in the options.

2. Sounds like a problem of your Card/Driver/CAM.

2.1 Not wanted, would mess up recordings. the CI gets informed of every channelchange. It's the job of the driver/CAM to handle it correctly.

2.2 This IS the job of a CAM. That's why it gets informed of every channelchange.

2.3 see 2.1

Test the current Pro beta, the CI handling has been a little bit improved there. Don't use any beta drivers.

thank's for the quick reply

 

first: i've already checked "detect video format" (Videoformat automatisch erkennen) and disabled the fast channel changes.

second: the cam works without any problems in other (stand alone) receivers, like topfield or DR 11 CI. but i admit, that i couldn't test it with these receivers in combination with h264 channels .

 

to 2.1: why should this mess up recordings ? a channel change should happens before, or after ... never during a recording.

you're right, it is a job of the driver/cam to handle the channel changes correctly, but why does the cam then works with the topfield like a charm ?

whom should i aks to fix the problem ? technisat (or technotrend), for a better bda driver for the SkyStarHD/CI module ?

 

i expect that an option like in 2.1 mentioned would really help me with my problem, and shouldn't be too hard to implement. the use of such an option might slow down channel changes, but actually it takes several seconds anyhow.... so 2 or 3 seconds more wouldn't really do any harm.

as i bought DVBViewer (in 2004), i did it with the hope for support through this community.

 

and by the way, i'm using no beta drivers. the SkyStarHD drivers came along with the card and seem to be the actual ones (4.4.10.18, from 26th of october 2006). the ati drivers are the actual ones too (8.282.0.0 from the 2nd of august '06).

and furthermore, i'm already using the DVBViewer Pro 3.6.3.0 Beta, but the slight improvements in CI handling seem to have no effect to my problem.

[uglyrooster]

There is also a german thread about this.

 

I reported exactly the same behaviour already some weeks ago.

[Lars_MQ]

i expect that an option like in 2.1 mentioned would really help me with my problem, and shouldn't be too hard to implement.

I exspect such an option will be a lot of trouble for all, but since it seems you have a vast knowlegde on CI and driver specific implementations in BDA, it shouldn't be too hard to implement it yourself.

[Gandalf_der_Graue]

@Lars_MQ

sorry, but i guess Bernd would have posted a more polite and more helpful answer to one of his customers.

 

I exspect such an option will be a lot of trouble for all, ...

i still don't think so, because nobody would be urged to check that option without a need. only users like uglyrooster and me would do so...

 

...but since it seems you have a vast knowlegde on CI and driver specific implementations in BDA...

no, i don't have any clue about that stuff. my assumption, that it shouldn't be too hard to implement, refers to the fact, that the ci is already going to be initialized at every startup of the DVBViewer.

and exactly this fact is my actual workaround for the problem. i close DVBViewer and start it up immediately again.

 

@uglyrooster:

i will have a look into the german thread about this.

[uglyrooster]

There is an easy workaround for the issue:

 

Just change the "Channel +" and "Channel -" settings in "Eingabe" with "Stop graph" before. You have to use the "Lernen" feature and to assign a new command.

 

The result is perfect, but channel switching is >3 seconds in FTA-channels and >6 seconds in encrypted channels.

 

With more than one card the issue can be solved by the programmers, just the behaviour of "Bevorzugt" has to be used again after switching back to a FTA-channel.

 

Unfortunately Lars don't like this feature (it is just 100% what the function describes) when switching from encryption to FTA due to the longer switching time (around 4 seconds).

 

Maybe you find a better workaround or Lars can at least change the "Bevorzugt" behaviour for users with more than one card .

 

PS: Or you use the separate key for "Stop graph" on your remote (you have to tell your family about this if there is no picture...).

Edited June 10, 2007 by uglyrooster

[Lars_MQ]

Lars can at least change the "Bevorzugt" behaviour for users with more than one card .

I am a user with more than one card and I like the handling just the way it is, thank you.

[uglyrooster]

... so after switching from encrypted to FTA this feature is useless?

 

We have to accept it this way, but sometimes a short explanation is helpful.

[Moses]

I, too, like the feature as it is now...

 

If preffered would always change to the tuner which is preffered if possible the time to switch a channel will be much longer in some occasions. That would effect all users... of course it would solve your problem, but cause problems or at least unecessary long channel switch times to all other users which use that feature...

 

Then it's better to implement such an rebuild complete graph as special feature..

Edited June 10, 2007 by Moses