[vdr-plugin-satip] this and that

Zitat von fnu

Or here, the user "googles" is missing DiSEqC, as it is part of SAT>IP spec. v1.2: [Announce] vdr-plugin-satip-0.0.1 - Make your VDR to a SAT>IP Receiver., but to test this enhancement, there must be an existing layout somewhere for that

Take a look at the README:

Z  signal source position (1-255)


  Signal source: Specifies the signal source (satellite) position
    (DVB-S/DVB-S2)

Don't get fooled about the 'Z' character as it has a double meaning. First, it's used as a source id for SAT>IP DVB-S, but the same character is used in the parameters string to specify the signal source value, that's mapped to DiSEqC configuration.

Zitat von fnu

E.g. here the user "Niel" tells he faces jerking video, what is a good example for this thread: Offene Runde: SAT>IP

Please, try to disable the PAT filter in the plugin setup, and check whether is has any effect. VDR is doing rather intensive PID circulation while scanning through PMTs all the time, that might cause some trouble in certain SAT>IP implementations.

Hi Rolf,

I have a few remarks about your SAT>IP plugin:

Wouldn't it be better to use the channels.conf entries exactly as they are now, without introducing new sources ('Z' and 'Y')?
I was considering doing some experiements with SAT>IP in the future, but if this means having all of my channels twice in the list, that's a no-go.
AFAICS you need a new parameter called 'Z' for the "satellite position". I don't think it is a good idea to put this into the "transponder parameters". The satellite position is already stored in the "source" parameter of the DVB-S channels (e.g. S19.2E), so wouldn't it be better if your plugin maintained some sort of "map" that translated the orbital positions into the numerical values you need? Something like

S19.2E  1
S13.0E  2
S28.2E  3

If these numbers are just indexes, you might as well use the indexes of the standard DiSEqC entries for these devices. That way you wouldn't even have to maintain an additional map file. Plus, if your device just says "I can receive DVB-S", it will be able to participate in the new DiSEqC menu I am working on (as time permits ;-). For that there will probably be a new virtual function in cDevice through which a device can be queried about the delivery systems it provides (something like the already existing cDvbDevice::ProvidesDeliverySystem()). With your new "sources" this wouldn't be possible.
I suggest your devices should behave just like any other device that can receive DVB-S (or -T, -C, for that matter), and completely hide the fact that it doesn't receive the signal directly by itself, but rather gets it from somewhere else via the network. They should especially not require any changes to channels.conf or introduce new "sources". That way VDR could freely choose which device to use when receiving a particular channel, without having the user to first decide whether it should be a "real" device or a SAT>IP device.

I also have mixed feelings about your duplicating much of the code for handling the transponder parameters.
Is this really necessary? Would it help if we made the necessary parts of the code from dvbdevice.c publicly available?

Klaus

Zitat von fnu

But how to handle mixed environments? Means VDRs equiped with e.g. a twin DVB card and dealing with a SAT>IP server in parallel to have more resources in case the 2 built in tuners are busy due schedules ...

Well, correct me if I'm wrong, but I believe that the way the plugin is implemented now makes exactly this *impossible*!
Let's assume you have two DVB-S timers set, on two different transponders. They will be recorded by your twin DVB card. Now assume you add a third timer, on a third transponder. You will have to explicitly make this a "SAT>IP" timer to make sure it will record on the SAT>IP device. Actually you will always have to carefully maintain which timers you want to work on which devices. Isn't that tedious? After all, they're all DVB-S channels in the end!

Zitat

For me it's still a different source, kind of in house IPTV ...

But it *shouldn't* be!

What I suggest is to just have DVB-S channels and hide all the extra functionality in the plugin's devices. That way you can freely set timers and VDR will manage the recordings according to the available devices.

Why would you want to have all your channels duplicated, just because there is a device that receives them a little differently?
That makes no sense to me!

I have 5 DVB-S devices in my VDR. Now if I add SAT>IP for testing, I would expect this to become just another DVB-S device, on which I can receive any DVB-S channel I can receive on the other DVB-S devices. I wouldn't want to have all my channels be duplicated, and I wouldn't want to always have to plan which device to use for recording a given channel.

Klaus

Zitat von fnu

From my view of point no, one of my VDR is running that way to support Rolf, as you also describe it a sentence later.

Yes, right, that's the way it runs actually, so it's possible to run mixed environments, ok, due manual handling.

But that is normal for all mixed environments, DVB-S/T/C and IPTV. With the latter I also have the same number of public tv channels doubled in channels.conf (ARD/ZDF) and I also need to take care where I record "Tatort" on sunday night, either on "Das Erste HD" thru DVB-S2 or IPTV ...

DVB-S, DVB-T and DVB-C are totally different delivery systems. They can't be easily combined to one "grand unified system".
But SAT>IP is merely a tiny little addition to actual DVB-S! It is basically the exact same channel as with DVB-S (its is actually received via DVB-S), just with a small addition that allows the data to be transferred via a network cable rather than a coaxial cable (simply speaking).
<EDIT>
You wouldn't want to have different channel definitions depending on whether your DVB-S device is connected to the system via the PCI bus or USB, would you? SAT>IP is just another method of bringing DVB-S data to the system. there is absolutely no need to make this a different "source".
</EDIT>

Zitat

So if you want make it easier, you run in open arms from many users, but then don't just do it for DVB-S/S2 & SAT>IP.

It's the plugin that makes something that could already be very simple unnecessarily complex!

Zitat

Well, you ever get the stream thru "http", from that point of view it will technically ever be something different. You could fixed in making VDR more convenient in handling mixed environments ...

I suggest we stop discussing "mixed environments" for the moment, because SAT>IP IMHO has nothing to do with "mixed environments". It's DVB-S with a small addition, nothing else.

Klaus

Zitat von fnu

Sure, but for me it's not more complex than running DVB-S & IPTV in parallel, what I do quite a while.

But hence if you think you can help Rolf to make it easier, I will not complain ...

I made the following addition to my previous posting:

You wouldn't want to have different channel definitions depending on whether your DVB-S device is connected to the system via the PCI bus or USB, would you? SAT>IP is just another method of bringing DVB-S data to the system. there is absolutely no need to make this a different "source".

Maybe this clarifies my point of view.

Klaus

At any rate, let's wait and see what Rolf has to say about all this. After all, it's *his* plugin ;-).

Klaus

kls
Is it possible that one device can provide more than one source (dvb-s, dvb-t)
I can not believe that that is inpossible.

Zitat von fnu

I haven't missunderstood that, I know what you meant.

But due to it's nearness to IPTV, due to it's "http" handling, a plugin close to was logical, hence I can use this Octopus Net first time with VDR ...

That "Octopus Net" is a DVB-S receiver, right?
So it receives DVB-S channels. How it transfers the data from these DVB-S channels to VDR doesn't matter at all to the VDR user! They're just plain old DVB-S channels. There is no need for the VDR user to be bothered with IPTV or stuff like that. It's DVB-S, nothing else!

Please see things from the user's point of view. The user has a system that can receive DVB-S, and wants to try a SAT>IP receiver. If the plugin just used plain DVB-S channels.conf entries and hides anything else, this is just "plug and play". Run the plugin and have the given number of additional DVB-S devices. Remove the plugin and everything is as it was before. The way it is now, you would end up with a lot of garbage in your channels.conf. And you lose a lot of flexibility regarding timer handling.

Klaus

Zitat von googles

kls
Is it possible that one device can provide more than one source (dvb-s, dvb-t)
I can not believe that that is inpossible.

Yes, a device can provide several different delivery systems (only one at a time, of course).
See for instance

virtual cString DeviceType(void) const;
         ///< Returns a string identifying the type of this device (like "DVB-S").
         ///< If this device can receive different delivery systems, the returned
         ///< string shall be that of the currently used system.
         ///< The length of the returned string should not exceed 6 characters.
         ///< The default implementation returns an empty string.

Klaus

Thank you for the answer. That meen in SatIp when both dvb-t and s should be received. 2 Devices should be created.

It doesn't matter who this said. In the other Thrad I only want to make a Sugestion to the Author of the Plugin. This have nothing to do to make work of rofar bad. I don't understand you why you think I make work bad. It isn't so.
Now it is probably possible to make changes because there are not so much Users.
Ask Kls what happen when he change somthing that other peobles don't like.
Regards Thomas

So many posts and so many questions, so Iet's try to clarily a bit the current implemation and the reasons behind it. Surely, I know it has pros and cons as any other software and it's having a strong legacy from the IPTV plugin (due to that it took merely a week to cook it up). Please, keep this 0.0.1 version as a proof-of-concept although it's already fully functioning capable providing a whole transponder per a device. Just drop off the politics whether it's good or bad - it's the only one at the moment and therefore a reference. Now, it's up to Klaus to decide in what direction he wants the SAT>IP support to go.

SAT>IP Speficification 1.2 vs. kernel's DVBAPI

My initial though was that the vTuner solution would be perfect, but in order to make a 100% compliant SAT>IP client, you'll have to update the current kernel API to support missing parameters: Pilot tones, T2 system id, SISO/MISO and what ever will come in 1.3. Now, this isn't something every user requires, but the noisy minority will always harass you until the spec is fully implemented. I didn't want to patch the kernel nor the core VDR (well, I'll be patching the VDR until Klaus accepts the rest of my required features ;)), and therefore the easiest way was to duplicate code from cDvbDevice and assign an unique source identifier for it - two actually due to cMenuEditChannel.

I'd really like to utilize the normal S/T source characters as Z/Y are suboptimal, but before that Klaus should add support for the mentioned missing parameters in it and silently ignore them in the cDvbDevice implementation. NIT parsing for T2 system id and SISO/MISO is already there requiring only minimal code changes.

Retuning

I had to slow down the tuning speed of the plugin (it's now slow at the moment, but could be better) as VDR wants to retune after pid (or even just language code pid remaining the same!) changes and this retuning is done as a hard way: "CloseDVR();OpenDVR();". I'd like to get a signal about retuning, so I don't have to teardown the RTSP connection everytime. It could be a just CloseDVR parameter or even a separate RetuneDVR() method.

Channel Alternatives & Timers

The core VDR is still missing support for alternate channels. You already have a situation that the same channel is broadcasted via DVB-T, DVB-T2, DVB-C, DVB-S, and IGMP (multicast reception in IPTV plugin). Now, adding a couple of more alternatives (SAT>IP DVB-T, SAT>IP DVB-S) doens't make it any messier. VDR really needs a proper solution to mark channel alternatives - there's been a patch for it for ages, but I haven't used it.

Zitat von rofafor

So many posts and so many questions, so Iet's try to clarily a bit the current implemation and the reasons behind it. Surely, I know it has pros and cons as any other software and it's having a strong legacy from the IPTV plugin (due to that it took merely a week to cook it up). Please, keep this 0.0.1 version as a proof-of-concept although it's already fully functioning capable providing a whole transponder per a device. Just drop off the politics whether it's good or bad - it's the only one at the moment and therefore a reference. Now, it's up to Klaus to decide in what direction he wants the SAT>IP support to go.

I hope you didn't get my comments wrong, I do appreciate your work and I am fully aware that this is a first version and proof of concept.
All I wanted is to point out what I consider to be "room for improvement". If you could make it so that the SAT>IP plugin uses the exact same channels.conf entries as real DVB devices, that would be great.

Zitat

SAT>IP Speficification 1.2 vs. kernel's DVBAPI

My initial though was that the vTuner solution would be perfect, but in order to make a 100% compliant SAT>IP client, you'll have to update the current kernel API to support missing parameters: Pilot tones, T2 system id, SISO/MISO and what ever will come in 1.3. Now, this isn't something every user requires, but the noisy minority will always harass you until the spec is fully implemented. I didn't want to patch the kernel nor the core VDR (well, I'll be patching the VDR until Klaus accepts the rest of my required features ;)), and therefore the easiest way was to duplicate code from cDvbDevice and assign an unique source identifier for it - two actually due to cMenuEditChannel.

If those additional parameters are necessary for actual DVB-S/-T reception (i.e. without SAT>IP), then they should be implemented in the core VDR code.
I hope I didn't miss any patches you might have sent earlier for this...

Zitat

I'd really like to utilize the normal S/T source characters as Z/Y are suboptimal, but before that Klaus should add support for the mentioned missing parameters in it and silently ignore them in the cDvbDevice implementation. NIT parsing for T2 system id and SISO/MISO is already there requiring only minimal code changes.

Please send me the necessary patches.

Zitat

Retuning

I had to slow down the tuning speed of the plugin (it's now slow at the moment, but could be better) as VDR wants to retune after pid (or even just language code pid remaining the same!) changes and this retuning is done as a hard way: "CloseDVR();OpenDVR();". I'd like to get a signal about retuning, so I don't have to teardown the RTSP connection everytime. It could be a just CloseDVR parameter or even a separate RetuneDVR() method.

Please suggest a patch and I'll look into it.

Zitat

Channel Alternatives & Timers

The core VDR is still missing support for alternate channels. You already have a situation that the same channel is broadcasted via DVB-T, DVB-T2, DVB-C, DVB-S, and IGMP (multicast reception in IPTV plugin). Now, adding a couple of more alternatives (SAT>IP DVB-T, SAT>IP DVB-S) doens't make it any messier. VDR really needs a proper solution to mark channel alternatives - there's been a patch for it for ages, but I haven't used it.

I am aware of the "alternate channel" problem, but I disagree that this is the same as the one we are talking about here.
As I stated earlier, a channel received via SAT>IP is the *exact same* channel as one received via DVB-S. It is therefore not an "alternate channel" in the sense of the same programme being broadcast via DVB-S, DVB-T, DVB-C or whatever distribution system. There is a DVB-S receiver, and it is connected to VDR via a special mechanism that transports the data via the network. From VDR's point of view it doesn't matter whether the receiver is connected via PCI, PCI-x, USB or SAT>IP. It's always receiving the exact same data, and it needs the exact same parameters to tune to that channel. So please let's keep these two areas apart. I fully agree that "alternate channels" is something that should be implemented in VDR at some point (although I don't have a concept for that, yet), but SAT>IP does not fall into that category.

Klaus