SAT>IP fixes..

[perexg]

I'll merge this after tests and the delay should be configurable (only for required devices).

[ckarrie]

@perexg Works! Fixes my bug #369 (comment)

[perexg]

This is another SAT>IP update. It should fix the --satip_xml code (static SAT>IP server discovery) and the dead tuners after a runtime. It seems that even the GSS.BOX does not like to send the tune requests very fast, so I added a serialization code (with the default 50ms delay).

[nurtext]

As far as I can see the delay is set to 250 ms… sadly this nullifies the very good channels switching times 👎

[perexg]

@nurtext : Not really. This delay is default only for the OctopusNet devices (seems they have broken firmware - even tuning takes 5 seconds). I lowered it to 250ms in last patch. For other devices, the delay is 50ms. Users can lower this value in the configuration tab per tuner through the web interface. I just put a number which I believe is safe.

Also note that the delay is for the immediate tuning, so if you watch a channel for more than the configured delay, the delay is not activated for the next channel tuning. Basically, the epggrab tasks grabs tuners in the same time and firmwares in SAT>IP boxes are not brave enough to handle this situation. The standard streaming operations are not affected.

[nurtext]

I see, thanks for clarifiyng! 👍

[ckarrie]

@perexg Still no detection via UPnp. I recompiled perexg:satip-local-ip from scratch. With --satip_xml it works great.

[ckarrie]

Okay, I have to clarify my Setup - maybe thats the problem:

• I have two tvheadend instances connecting to one OctopusNet Rack.
• One instance is connected to the first tuner, the second instance is connected to the second tuner
• The first instance works without --satip_xml, the second only with --satip_xml

[perexg]

@ckarrie : Thanks. May I ask you to grab the local network traffic using the tcpdump or wireshark ? I don't know the reason, but the OctopusNet does not reply on the valid UPnP requests in your setup. Also, both instances requires the --satip_xml static discovery ?

[ckarrie]

@perexg Thank you, regarding your first question: Yes, one moment. Your second Question: I updated my comment, see last paragraph.

[perexg]

@ckarrie : Argh... It's not possible to bind to one UDP unicast port by multiple applications. The above fix should avoid this..

[nurtext]

But multicast should work, don't know if OctoNet allows it, but GSS.BOX does for sure.

[ckarrie]

@perexg Hell yeah! This works!

[perexg]

@ckarrie : Good to hear. Fine.
@nurtext : Sure, but tvheadend sends the M-SEARCH request to enumerate the available SAT>IP servers and all servers sends back unicast UDP reponses. I wrongly used only one UDP unicast port, so only one application was receiving the unicast responses (which is ok from the kernel view).

[nurtext]

@perexg Okay, got it so far. So the unicast behavior is only used for discovery, not for streaming? Just asking because I want to use multicast on GSS.BOX to enable other SAT>IP receiver / devices (beside TVHeadend) to receive streams.

[ckarrie]

@perexg Thank you so much! I have atm one more small improvements to report: On WebUI, could you please spent some time in the help section?

[hennoa]

@perexg I had some time to do a quick test on my equipment with your latest fixes, and I can also report that it works so far. I will continue monitoring the logs, but no trouble so far. 👍

[mrarel]

@perexg I´m also testing your code on my openelec based system (x86-64bit Openelec 4.0, Intel Q1900 low power quadcore, tvheadend backend was replaced by this binary #389 here...).
Everything is fine so far, except sometimes I get artifacts on some channels. I cant see something special in the logs...
If you need any further logs or something, feel free to contact me. Thanks for this great code !
kind regards
arel

[ckarrie]

@mrarel Do you use a Gigabit Network? SD or HD channels? Encrypted?

[mrarel]

@ckarrie
I´m using Gigabit network (gss.box DSI400 via gb switch/fritzbox connected).
It is more often on HD channels, sometimes on sd channels. I also use cwc (for encrypted channels) but the artefacts doesn´t have something in common with encryption it. Very rare, but you can recognize it after some time, about 10 or 15 minutes there are some artifacts...sometimes there is no audio, but when you use "channul up - cahnnel down to come back to the same channel sound is back.
I´m starting to use "DVB Viewer recording server" to test wether the artifacts maybe has something in common with the signal level of the dsi400 or maybe with the implementation of the tvheadend (backend or client).
I´ll compare the results as soon as possible..

kind regards
mrarel

[nurtext]

@mrarel Lower power systems like RPi and & Co are known to cause problems with high bitrate streams, they are simply not powerful enought to handle it. Take a look your cpu usage (ssh into your box and have a look at the "top" / "ps aux" command), I guess this is the bottleneck. BTW: CWC is stressing the CPU too.

[ckarrie]

@perexg Thank you for your work!

[mrarel]

Hi peregx and Co.
Thanks from my side too !
great job !

just for your reference...
the artifacts I have mentioned above are as far as i can judge it are NOT related to the tvheadend implementation. The dvbviewer service also gave some artifacts at the "frontend".
Therfore it has something in common with the signal quality the dsi400 tuner can deliver...my satellit dish is not 100% correct adjusted...

@ckarrie
The "low power" J1900 Intel processor has more than enough power...(quadcore, 2ghz, intel)
Even with software de-interlacing of HD channel (1080i) and cwc tvheadend running it never needed more than 35% of cpu power (at around 15w :-)

It is a great plattform for a htpc (XBMC openelec 4.0 !!!).

@perexg
If you need further testing of tvheadend "satip" commits or something like that...feel free to leave a message !

kind regards mrarel

[perexg]

@mrarel: Thanks for testing. I think that the code is pretty stable in the tvheadend master tree now. Apart from the good dish position, it's also necessary to have a good LNB. I tried 4 types and one of them was bad (Opticum LNB quattro 0,1 dB - Gold Edition), one excellent (Inverto Black Ultra HGLN Quattro) and two good (Golden Interstar Twin/Quad and Chess Twin).

[mrarel]

@perexg
thanks for your hints concerning LNB´s etc. Maybe I have to check wether my Kathrein Multifeed-arm can hold an "Inverto Black Ultra HGLN Quattro". But I fear this would lead to a new feed-arm or something like this :-(.

Never the less the kathrein LNB was very stable in the past.
E.G. with my DD Cine S2 Card (based on the same tvheadend code) connected to the same switch had NO artefacts (I also used the same wire to connect switch with DD as I used for the DSI400).

As soon as I have some time I will adjust my dish, I think this will help to get the dsi400 a more stable environment....I fear the dsi400 is simply not as "sensible" as my DD Cine S2 card is...

kind regards
mrarel

[nurtext]

@mrarel In most cases PC DVB hardware can't be compared to embedded DVB hardware, which doesn't mean that there are no differences -quite the opposite: there are lots of them in detail: signal reception, noise level, voltage fluctuations, and so on.

A single DD Cine S2 card with dual tuners costs about as much as one DSI 400 quad SAT>IP tuner. I don't know much about the builtin hardware, but I sure know the price is in relation to the components that were used.

[ckarrie]

@mrarel: I recommend a Wavefrontier T90 Dish :-) Works fine for me :-)

Unfortunately not my setup:

[ckarrie]

@perexg Discovered a new Issue: Disabled Sat>IP Positions are used!

I have following Setup: https://docs.google.com/spreadsheets/d/1fQCSRg7vffyzFQgLrP2vXjM172XLYI_PBINoJf0g9P8/edit?usp=sharing

I disabled Tuner Nr. 4 / Position 2 but I get following in the logs:

subscription: 'epggrab' subscribing to mux, weight: 1, adapter: 'SAT>IP DVB-S Tuner #4 (192.168.178.54)', network: 'Hotbird 13.0E', mux: '11258H'

EPG Grap (and any other subscriptions reated to Hotbird + Tuner 4) should be disabled.

[nurtext]

My GSS.Box 400 stopped working after enabling all tuners… Web interface is fine, already did lots of reboots of both TVHeadend and GSS.Box… delete the whole configuration and now this:

2014-05-18 16:09:10.344 mpegts: 12551V - starting for 'initscan' (weight 2)
2014-05-18 16:09:10.344 mpegts: 12551V - tuning on SAT>IP DVB-S Tuner #1 (192.168.1.5)
2014-05-18 16:09:10.344 satip: SAT>IP DVB-S Tuner #1 (192.168.1.5) - starting 12551V
2014-05-18 16:09:10.344 mpegts: 12551V - started
2014-05-18 16:09:10.344 subscription: 'initscan' subscribing to mux, weight: 2, adapter: 'SAT>IP DVB-S Tuner #1 (192.168.1.5)', network: 'Astra 19,2', mux: '12551V'
2014-05-18 16:09:10.364 satip: 192.168.1.5 #1 - new session 648AC489 stream id 14
2014-05-18 16:09:10.364 mpegts: 12551V - open PID 0000 (0) [3/0x4513c9f8]
2014-05-18 16:09:10.365 mpegts: 12551V - open PID 0001 (1) [2/0x4513ddf8]
2014-05-18 16:09:10.365 mpegts: 12551V - open PID 0010 (16) [2/0x4513f1f8]
2014-05-18 16:09:10.365 mpegts: 12551V - open PID 0011 (17) [3/0x451405f8]
2014-05-18 16:09:10.365 mpegts: 12551V - open PID 0011 (17) [2/0x451419f8]
2014-05-18 16:09:20.000 mpegts: 12551V - initial scan no data, failed
2014-05-18 16:09:20.000 subscription: "initscan" unsubscribing
2014-05-18 16:09:20.000 mpegts: 12551V - stopping mux

Any ideas?