Spectrum Inversion SAT>IP DVB-C in DVBViewer Pro?

[retrofan1979]

Hello,

 

I tried the Linux minisatip server (https://github.com/catalinii/minisatip) with the latest build of DVBViewer Pro and initially it didn't work, but with a workaround of the programmer of minisatip it does right now. However, this is a workaround and should be fixed someway.

 

What's the problem? My cable operator uses spectrum inversion with setting "on" or "1" (page 68 of http://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf).

According to the programmer of minisatip it seems that DVBViewer Pro has hardcoded this setting to 0, so it doesn't work for me. When this setting is hardcoded, minisatip obeys this setting and DVBViewer doesn't find any channel. However, it should be better to use the auto setting or to have the possibility to manually change this setting to 1 ("on").

 

I searched how to change this setting within DVBViewer Pro, but until now without luck. Who can help?

It's told this setting could be done in the transponder list, but as far as I can see this is only the case for the DVB-S(2) protocol, not for DVB-C. Or do I miss something?

How can this be done in the DVB-C transponderlist?

 

Thanks for your help!

[Griga]

On 12.7.2017 at 1:53 PM, retrofan1979 said:

What's the problem?

 

Up to now we never needed a spectrum inversion setting in DVBViewer because all DVB devices are able to detect it automatically. So the internal DVBViewer default is BDA_SPECTRAL_INVERSION_NOT_SET (in BDA terms), telling the device driver to look after it.

 

Unfortunately the Sat>IP specifications don't allow to specify parameters as "not set" or "unknown". This is a bad design fault that causes a lot of trouble. So in reception data transmitted to a Sat>IP server spectral inversion must be either on or off. I think the best thing a Sat>IP server can do is to simply ignore this setting and let the DVB hardware auto-detect it, in order to avoid configuration trouble for users.

 

However, if spectral inversion must be specified and there is no way around it, the transponder list editor and scanner/analyzer tool TransEdit (see download area) provides a tweak for it. You can add %n to the description line of DVB-C Transponders, where n is a number 0...3 with the following meaning:

 

%0: BDA_SPECTRAL_INVERSION_NOT_SET

%1: BDA_SPECTRAL_INVERSION_AUTOMATIC

%2: BDA_SPECTRAL_INVERSION_NORMAL

%3: BDA_SPECTRAL_INVERSION_INVERTED

 

This is for talking to BDA drivers. If it comes to Sat>IP, %0..%2 are translated to specinv=0 and %3 to specinv=1. So you would need to add %3 in every transponder description for switching spectral inversion on. This only works if scanning is done with TransEdit and the scan results are exported to DVBViewer. For achieving it without TransEdit you can try the following:

1. Export your channel list as INI file in the DVBViewer channel editor.
2. Open the file with a text editor and, by using search and replace, change the SatModulation=0 entries for all DVB-C channels to SatModulation=96 (or more general to the value 0..3 given above times 32, here 3 x 32 = 96 for spectral inversion on).
3. Save the file. Delete you channel list in DVBViewer and re-import the INI file by dragging it with the mouse into the channel editor.
4. Check if it works - nobody tested it up to now. You are the first one. Good luck

[retrofan1979]

Hi,

 

Thanks for your reply. So, how should the transponderlist look like this? (%3 added for each line)

 

[SATTYPE]
1=4000
2=Ziggo

 

[DVB]
0=4
1=132000,5,6900,%3
2=690750,5,6900,%3
3=698750,5,6900,%3
4=706750,5,6900,%3

[retrofan1979]

Another question: I did a channelscan for SAT>IP DVB-C and I want to export to M3U file with rtsp/SATIP URLs, but this doesn't work. Do I miss something?

[Griga]

33 minutes ago, retrofan1979 said:

So, how should the transponderlist look like this?

 

No, that's wrong. You should use TransEdit for editing transponder list files:

 

 

37 minutes ago, retrofan1979 said:

I did a channelscan for SAT>IP DVB-C and I want to export to M3U file with rtsp/SATIP URLs, but this doesn't work.

 

Not possible in DVBViewer as Sat>IP client. M3U channel lists are usually provided by Sat>IP servers.

[retrofan1979]

Thanks about TransEdit. I will try.

 

Could you please add support for exporting to M3U for SAT>IP url in Transedit and DVBViewer even if it's a client? All information like PIDS freq. etc. is already available by the channelscan. Thanks!

[Griga]

11 hours ago, retrofan1979 said:

Could you please add support for exporting to M3U for SAT>IP url in Transedit and DVBViewer even if it's a client?

 

No, sorry, that won't happen.

 

But you may use the Recording Service 1.33.2 beta that is still available in the "Older Versions" download section. As a Sat>IP server that is associated with DVBViewer it is able to export the DVBViewer channel list as M3U file containing RTSP URLs. However, you will need to replace the Recording Service IP:Port addresses in the file by the minisatip IP:Port address.

 

The Recording Service is free for owners of a DVBViewer licence (the DVBViewer Media Server as successor requires an extra licence). Please read more about the Recording Service in the wiki.

[retrofan1979]

Hi Griga,

 

Just to let you know your trick with TransEdit works :-) Thanks! Didn't try the other solution as this one is very easy.

However, without TransEdit the transponderlist looks like this, so then we can do this even without TransEdit right away?

Apart from the pipeline sign, it looks the same as I suggested the first time.

 

[SATTYPE]
1=4000
2=Ziggo - Network-ID 43140 - specinv=1

 

[DVB]
0=40
1=124000,5,6900,|%3
2=132000,5,6900,|%3
3=140000,5,6900,|%3
4=148000,5,6900,|%3
5=156000,5,6900,|%3
6=164000,3,6900,|%3
7=298750,5,6900,|%3
8=482750,5,6900,|%3
9=490750,5,6900,|%3
10=498750,5,6900,|%3
11=506750,5,6900,|%3
12=514750,5,6900,|%3
13=522750,5,6900,|%3
14=530750,5,6900,|%3
15=554750,5,6900,|%3
16=562750,5,6900,|%3
17=578750,5,6900,|%3
18=586750,5,6900,|%3
19=594750,5,6900,|%3
20=602750,5,6900,|%3
21=610750,5,6900,|%3
22=626750,5,6900,|%3
23=634750,5,6900,|%3
24=642750,5,6900,|%3
25=650750,5,6900,|%3
26=658750,5,6900,|%3
27=682750,5,6900,|%3
28=690750,5,6900,|%3
29=698750,5,6900,|%3
30=706750,5,6900,|%3
31=714750,5,6900,|%3
32=746750,5,6900,|%3
33=762750,5,6900,|%3
34=778750,5,6900,|%3
35=810750,5,6900,|%3
36=826750,5,6900,|%3
37=834750,5,6900,|%3
38=842750,5,6900,|%3
39=850750,5,6900,|%3
40=858750,5,6900,|%3
 

About export to M3U, I will try. You're very helpful, thanks!

 

According the logfile of minisatip I see specinv=0 without the %3 trick in the transponderfile which DVBViewer is sending to minisatip. Still a bug?

Maybe DVBViewer should not send specinv at all so minisatip will auto-detect?

 

[28/06 19:20:03.074 main]: read RTSP (from handle 7 sock_id 7, len: 0, sid 0):
[28/06 19:20:03.074 main]: PLAY rtsp://192.168.0.4:554/stream=1?freq=490.75&msys=dvbc&sr=6900&specinv=0&mtype=256qam&pids=0 RTSP/1.0
CSeq: 30
Session: 0846930886

 

Edited July 13, 2017 by retrofan1979

[Griga]

14 minutes ago, retrofan1979 said:

According the logfile of minisatip I see specinv=0 without the %3 trick in the transponderfile which DVBViewer is sending to minisatip.

 

Please describe what you did in DVBViewer.

 

The transponder list changes in TransEdit have no effect on DVBViewer. It only takes effect if you transfer the TransEdit scan results to the DVBViewer channel list.

 

18 minutes ago, retrofan1979 said:

Maybe DVBViewer should not send specinv at all so minisatip will auto-detect?

 

Not that easy. According to the Sat>IP specs this parameter is mandatory for DVB-C. I've already seen servers responding with an error if certain parameters are missing, though they don't matter at all. Sending random fake parameters made it work

[retrofan1979]

I just played around with Recording Service 1.33.2 beta, but no luck with exporting to M3U with RTSP URLs.

What's the exact procedure?

 

About specinv: the first time I used the normal transponderlist without %3, then minisatip reports specinv=0 in it's logfile when receiving incoming data from DVBViewer.

 

Edited July 13, 2017 by retrofan1979

[retrofan1979]

Also, I noticed the signal strength with satip isn't displayed as 100%, but as 41%. With Enigma2 URLs I got 100% signal strength. Is it a bug?

Edited July 13, 2017 by retrofan1979

[retrofan1979]

My M3U files remain empty when attemping to export DVB-C channels to M3U SATIP file with RTSP URLs with the Recording Service installed. Why?

 

Maybe you also could add the %3 trick to the WIKI? Maybe more people could use it in the future :-) Thanks!

Edited July 14, 2017 by retrofan1979

[retrofan1979]

On 12-7-2017 at 5:58 PM, Griga said:

 

For achieving it without TransEdit you can try the following:

1. Export your channel list as INI file in the DVBViewer channel editor.
2. Open the file with a text editor and, by using search and replace, change the SatModulation=0 entries for all DVB-C channels to SatModulation=96 (or more general to the value 0..3 given above times 32, here 3 x 32 = 96 for spectral inversion on).
3. Save the file. Delete you channel list in DVBViewer and re-import the INI file by dragging it with the mouse into the channel editor.
4. Check if it works - nobody tested it up to now. You are the first one. Good luck

 

Just to report: yes, changing to SatModulation=96 in INI file also works!

[retrofan1979]

Maybe it's also possible you create a converter for DVBViewer .INI file to .M3U file? All information neccessary for SAT>IP stream is available in the .INI file, but ofcourse the wrong format.

[retrofan1979]

I discovered the displayed signal strength is incorrect when using tuner type DVB-C and the channelscan is done with RTSP (SAT>IP) Network Device.

When importing an M3U file directly without channelscan, the displayed signal strength is correct, but this way the tuner type is set to TS Stream.

 

Additionally, how can I use a transponder list when tuner type is set to TS Stream?

 

[Griga]

18 hours ago, retrofan1979 said:

I just played around with Recording Service 1.33.2 beta, but no luck with exporting to M3U with RTSP URLs.

What's the exact procedure?

 

Tray Menu -> Web Interface and then trigger TV playback in the browser somewhere, e.g. by clicking a channel on the timeline page, in order to open the stream configuration window. Then click the RTSP Channel List button.

 

18 hours ago, retrofan1979 said:

then minisatip reports specinv=0 in it's logfile when receiving incoming data from DVBViewer.

 

Why did you expect a change?

 

3 hours ago, retrofan1979 said:

Maybe you also could add the %3 trick to the WIKI?

 

You can do it. Everybody can log in and write something in the wiki.

 

3 hours ago, retrofan1979 said:

My M3U files remain empty when attemping to export DVB-C channels to M3U SATIP file

 

How and where did you try to do it? In DVBViewer and TransEdit you can't.

 

2 hours ago, retrofan1979 said:

Maybe it's also possible you create a converter for DVBViewer .INI file to .M3U file? 

 

No time for this. You have to do it yourself or find someone else, maybe some script expert.

 

1 hour ago, retrofan1979 said:

Additionally, how can I use a transponder list when tuner type is set to TS Stream?

 

Don't know what you mean.

 

[retrofan1979]

8 hours ago, Griga said:

 

Tray Menu -> Web Interface and then trigger TV playback in the browser somewhere, e.g. by clicking a channel on the timeline page, in order to open the stream configuration window. Then click the RTSP Channel List button.

 

Thanks, now it's clear to me! I thought I had to do something in DVBViewer... Much more options I see in the stream URL. 

 

Quote

 

Why did you expect a change?

 

No, I did not expect a change, but at default DVBViewer sends specinv=0 to minisatip which obey this setting which causes to fail tuning as my cable operator uses specinv=1. I asked the programmer of minisatip to check the specinv=0 parameter and if it doesn't get a signal, to change it in specinv=1. There are only two settings possible: on or off, so this should not be difficult to do. Probably it's better for minisatip not to obey this setting, but just checking which one is correct. But I also understand why minisatip is doing this, as the specific parameter is given. It could be seen as override the auto-detection. Without this parameter minisatip is forced to check the parameter itself. A matter of interpreting?

 

Quote

No time for this. You have to do it yourself or find someone else, maybe some script expert.

 

No problem. Just found a tool which can do this for me besides the Recording Service. 

 

Quote

Don't know what you mean.

 

 

When using a transponderlist I cannot export to M3U, but actually I don't know why as I use the RTSP (SAT>IP) device profile where M3U is very common.

 

I discovered the displayed signal strength is incorrect when using tuner type DVB-C and the channelscan is done with RTSP (SAT>IP) Network Device. When importing an M3U file directly without channelscan, the displayed signal strength is correct, but this way the tuner type is set to TS Stream. Is this a bug?

 

Thanks for your answers! I got further every day 

Edited July 14, 2017 by retrofan1979

[retrofan1979]

43 minutes ago, retrofan1979 said:

No, I did not expect a change, but at default DVBViewer sends specinv=0 to minisatip which obey this setting which causes to fail tuning as my cable operator uses specinv=1. I asked the programmer of minisatip to check the specinv=0 parameter and if it doesn't get a signal, to change it in specinv=1. There are only two settings possible: on or off, so this should not be difficult to do. Probably it's better for minisatip not to obey this setting, but just checking which one is correct. But I also understand why minisatip is doing this, as the specific parameter is given. It could be seen as override the auto-detection. Without this parameter minisatip is forced to check the parameter itself. A matter of interpreting?

 

It looks like the specinv parameter is indeed mandatory when reading the SAT>IP specifications 1.2.2, so it's correct DVBViewer uses this setting. However, it's also correct that minisatip wants to process this parameter the way it gets it. Maybe therefor DVBViewer could add an option to use specinv=1 instead of 0 in the device settings tab? Just for compatibility? Then I also don't need the %3 trick anymore 

Edited July 14, 2017 by retrofan1979

[Griga]

18 hours ago, retrofan1979 said:

When importing an M3U file directly without channelscan, the displayed signal strength is correct, but this way the tuner type is set to TS Stream.

 

The TS Stream reception type is designed for different kinds of network streams, even for Internet TV/Radio (see here, Channel List section at the beginning and the Streaming chapter). However, I wouldn't use it for Sat>IP because it lets DVBViewer work as "thin client" (see Sat>IP specs) with static URLs. In contrast to virtual RTSP devices this is quite limited because it doesn't allow DVBViewer to request data dynamically.
 

AFAIK the DVBViewer signal strength handling is the same in both cases. Dunno why minisatip handles it differently.

 

Please note that the RS may remove all TS Stream channels in your list because it doesn't know this reception type. It is only supported by the DVBViewer Media Server.

[retrofan1979]

When exporting SAT>IP urls with the Recording Service, I see also the tnr (transponder?) parameter. What's this? AFAIK this is only for DVB-S(2) but not for DVB-C? Don't see it in the SAT>IP protocol.

 

rtsp://192.168.0.4:554/?freq=140&msys=dvbc&sr=6900&specinv=1&mtype=256qam&tnr=0,140000,6900,0,0,5,0,0,5011,5001,5000,19591,96,0,24,0,2107,1536,-1,4000&pids=0,16,17,18,20,5000,5001,5101,5011

 

Expected:

rtsp://192.168.0.4:554/?freq=140&msys=dvbc&sr=6900&specinv=1&mtype=256qam&pids=0,16,17,18,20,5000,5001,5101,5011

 

It looks like the specinv parameter is indeed mandatory when reading the SAT>IP specifications 1.2.2, so it's correct DVBViewer uses this setting. However, it's also correct that minisatip wants to process this parameter the way it gets it. Maybe therefor DVBViewer could add an option to use specinv=1 instead of 0 in the device settings tab? Just for compatibility? Then I also don't need the %3 trick anymore  Probably this is very easy for you.

 

By the way, what is Spectrum Inversion and why are cable operators handling them differently?

Edited July 15, 2017 by retrofan1979

[retrofan1979]

4 hours ago, Griga said:

 

However, I wouldn't use it for Sat>IP because it lets DVBViewer work as "thin client" (see Sat>IP specs) with static URLs. In contrast to virtual RTSP devices this is quite limited because it doesn't allow DVBViewer to request data dynamically.

 

Could you tell more about requesting data dynamically by DVBViewer? What are the differences with static URLs?

Edited July 15, 2017 by retrofan1979

[Griga]

21 hours ago, retrofan1979 said:

I see also the tnr (transponder?) parameter. What's this?

 

Channel data as used internally by the RS. Appending it to the URL makes some things easier for the RS, e.g. tuning encrypted channels. This is not covered by the Sat>IP specs. However, Sat>IP clients are expected to ignore all parameters they don't know.

 

Basically static RTSP URLs are created by the server according to its own needs. "Thin clients" must only comply with the underlying RTSP network protocol. They don't need to know Sat>IP and can use the URL without understanding how it is composed. That's why VLC can play it though it is no Sat>IP client.

 

21 hours ago, retrofan1979 said:

By the way, what is Spectrum Inversion and why are cable operators handling them differently?

 

Please search the web for more information.

 

19 hours ago, retrofan1979 said:

What are the differences with static URLs?

 

Please read the Sat>IP specifications.

[Derrick]

Am 7/15/2017 um 08:39 schrieb retrofan1979:

By the way, what is Spectrum Inversion and why are cable operators handling them differently?

They won't. So called spectrum inversion in baseband processing is a simple swap of I,Q signals. This won't cause any harm because the right order of rotation is automatically detected.

 

Zitat

In order to get a rotation-invariant constellation, this unit shall apply a differential encoding of the two Most Significant
Bits (MSBs) of each symbol.

EN 300 429 (DVB cable standard)

 

Here it seems to me a pure syntax matter without any content

 

https://www.dsprelated.com/showarticle/51.php

 

[Retrofan]

Hi Griga,

We discussed about specinv parameter in DVBViewer Pro for SAT>IP.

Will the next version have an option to change it from 0 (default, off) to 1 (on)?

Or does the latest build already have this option?

Then I don't have to adapt the transponderlists anymore ;-)

You told me this parameter is mandatory, which I understand, but to change this setting would be very helpful for compatibility.

 

DVBLink TVSource does have the fast scan feature like AuroraTV: entering homing channel parameters which will find all available transponders.

It would be great if DVBViewer (Pro) will also have it in the next version.

Could you add this as well?

 

Thank you!

[Derrick]

Doesn't it make more sense to fix the linux server?

[retrofan1979]

No, for compatibility reasons this option is useful ;-)

[Derrick]

May  be...

But the only incompatible device is your server. I wonder how the guy can tell whether the spectrum is "inverted" or not. To be sure you need a very  expensive real time spectrum analyser. But even then it simply doesn't  matter.

[Griga]

@Derrick: Your comments are off target because you didn't get what I stated above. Neither the server nor the client are the problem, but the bad design of the Sat>IP specs.

 

For the client there are two options:

1. don't specify spectral inversion (against the Sat>IP specs)
2. specify spectral inversion off or on (hardcoded), hoping that it is correct or that the server will ignore it if not.

In case 1. there are two options for the server:

1. reject the request with an error message because it doesn't comply with the specs
2. accept the request and let the hardware/driver detect spectral inversion automatically

In case 2. there are again two options for the server:

1. assume that the client just sends dummy data, ignore it and let the hardware/driver detect spectral inversion automatically
2. assume that the client had a reason for specifying spectral inversion and pass it on to the hardware/driver

2.2.  is what DVBViewer and minisatip currently are doing, and it doesn't work if spectral inversion must be switched on. IMO 2.1 would be better. That's how the DMS handles it. However, in most cases there is no other choice because the Microsoft BDA specs don't include passing spectral inversion to a DVB-C device (it's only defined for DVB-S). Only (old?) EMPIA DVB-C devices have a proprietary interface for setting up spectral inversion.

 

A solution could be to let the user decide what the client shall do (omit spectral inversion, set it to off or on), e.g. with a tweak. But unfortunately spectral inversion is a per transponder setting, so it can't be covered by a general setting. On the other side the hassle for adding it as a per transponder setting in the UI wouldn't pay because it's only relevant in very rare cases. Furthermore, configuring spectral inversion correctly requires a technical understanding that most users don't have.

 

So I think the server should simply ignore spectral inversion if it can be done without disadvantage. Everything else creates too many complications for the client implementation and the user.

[Derrick]

vor 4 Minuten schrieb Griga:

So I think the server should simply ignore spectral inversion if it can be done without disadvantage. Everything else creates too many complications for the client implementation and the user.

That's what I meant

 

It doesn't matter anyway. Maybe some legacy stuff or a lack of understanding of basic digital modulation techniques

 

[Griga]

Just now, Derrick said:

That's what I meant

 

Be clear about the fact that the server doesn''t fully comply with the Sat>IP specs in this case. It probably wouldn't get a certification from SES.

[Derrick]

vor 18 Stunden schrieb Retrofan:

DVBLink TVSource does have the fast scan feature like AuroraTV: entering homing channel parameters which will find all available transponders.

It would be great if DVBViewer (Pro) will also have it in the next version.

If you're referring to logical channel numbers (LCN) starting from a home transponder and a dedicated network ID that has been asked before. No much chance

[nuts]

I think all "random fake Parameters", because of bad designed Sat>IP specs at least should be worth a (global) tweak.

We already have a per transponder solution (post #2) and it's a very rare issue, so imho there is no need to add this in the UI, but a tweak (on/off) would be nice.  

 

[Retrofan]

2 hours ago, Derrick said:

If you're referring to logical channel numbers (LCN) starting from a home transponder and a dedicated network ID that has been asked before. No much chance

 

Why not? It's very user-friendly, most TV sets do work this way in our country and we don't need transponderlists. AuroraTV does support this way of scanning and is very fast: it only takes 15 seconds to scan all 360 channels!

[Retrofan]

4 hours ago, Griga said:

But unfortunately spectral inversion is a per transponder setting,

 

With the homing channel (home transponder) this problem is automatically fixed. The setting for specinv could be saved into the profile per cable operator.

Edited August 2, 2017 by Retrofan

[Derrick]

vor einer Stunde schrieb Retrofan:

 

With the homing channel (home transponder) this problem is automatically fixed. The setting for specinv could be saved into the profile per cable operator.

You. don't get it. The possible ambiguity in the complex plane (IQ) is automatically resolved by differential encoding (see citation above). There is no explicit flag or anything else to signal a so called spectral inversion. Maybe it's  a design flaw of your (old) hardware.

 

LCN would be nice to have and is state of the art of receivers and TVs but not with DVBViewer

[Griga]

Some time ago we had a similar problem with DVB-T/T2, but the other way round:

 

http://www.dvbviewer.tv/forum/topic/59624-dvbviewer-600/

 

Quote

Added: RTSP Device: Tweak for letting the RTSP Device send a complete DVB-T parameter set to a Sat>IP server including some fake values, in order to formally comply with the specifications. (see here, (2)). The tweak can be added to RTSP Network Device sections in the file hardware.xml:

 

<entry name="AllParams">1</entry>

 

 

A Panasonic TV set as Sat>IP server insisted on getting the complete DVB-T/T2 parameter set as described in the Sat>IP specs. Otherwise it just responded with an error code. However, the bloody server didn't really need the params because random fake values made it work.

 

This tweak isn't applied to DVB-C yet, but it can be added easily. It would let DVBViewer send no spectral inversion information by default unless it is explicitely specified (by using TransEdit or manipulating an exported INI channel list, see here) or the "AllParams" entry in the hardware.xml forces sending a fake value.

 

What does minisatip do if the client omits the spectral inversion information?

[retrofan1979]

10 hours ago, Griga said:

This tweak isn't applied to DVB-C yet, but it can be added easily. It would let DVBViewer send no spectral inversion information by default unless it is explicitely specified

 

This would be great! could you send it to me so I can test it for you?

Edited August 3, 2017 by retrofan1979

[retrofan1979]

10 hours ago, Griga said:

 

What does minisatip do if the client omits the spectral inversion information?

 

Minisatip obeys the given parameters. If the spectral inversion parameter isn't there it will autodetect by DVB hardware.

[retrofan1979]

With AuroraTV the URL below works for fast channelscan. However, they also added support to input the Network-ID like DVBLink TVSource does.

rtsp://192.168.0.4:554/?freq=164.00&msys=dvbc&mtype=64qam&sr=6900&pids=0,1,16,17,18,20

Edited August 3, 2017 by retrofan1979

[Retrofan]

Hi Griga, did you work on this? Just curious...