[vdr-plugin-satip] this and that

    Hello,


    first of all a big thank you to everybody who has committed to such a quick progress with regards to SATIP and vdr.


    For testing purpose, I have now installed a Grundig DSI400 SATIP device. I am using it in "Quattro" mode (meaning that I have connected the output of a LNB directly to the device. Watching TV via vlc works nicely with SD and HD (just to prove that the network path per se is fine).


    When I do recording the following way, I do get a nice and clean record (without any pixeling or other problems):
    curl "http://192.168.2.15/?src=1&freq=11361&sr=22000&pol=h&msys=dvbs2&pids=0,6100,6110,6120,6121,6123,6122" >xxx.ts


    I have installed vdr (2.0.5, self-compiled on Fedora 21/Rawhide) and the vdr-satip plugin. The system is intended to be a headless vdr later on (and to be virtualized with libvirt/qemu). There is no DVB device on this system. The DSI400 is detected by the vdr, EPG info is collected and I can do recordings. I am using the channels.conf from my main (Sat-Card based) vdr instance (again running 2.0.5). I have patched libcurl with the patch proposed here in this thread and am testing with and without the patch mentioned for tuner.c (all against 0.1.1 of vdr-satip).


    My problem is that the recordings from vdr via the DSI400 are all somewhat corrupt. Pictures do have lots of JPEG artefacts (mostly in the lower half of the picture) and sound is dropping very often. When playing the records with mplayer, I do get lots of errors indicating that the TS is corrupt. The behaviour is independent if the chosen program is SD or HD (which means 720p in my case).


    Now my question: As I do read from at least one other person with the same behaviour in this thread, is this currently a DSI400 general behaviour which needs investigation? Or is the plugin fully working for someone with the DSI400, so that I do need to search in my specific setup?


    Cheers,
    Michael

    micclass


    The root cause for "vd-plugin-satip" have been the very good and flexible devices from DigitalDevices, the Octopus Net. Many VDR user know and use their PCIe devices, so it's now a couple of years of success and satisfaction with L4M/DD products. DD did take care of their SAT>IP servers and offered support in HW for development and test, so it's not wrong to say Octopus Net is the reference here.


    None of the other vendors did take care of that, so it's hard to test and develop for HW nobody related does have. As it seems there is obviously room for interpretation in the spec and how is hardware equipped. It's just a feeling but my impression is, that "vdr-plugin-satip" may overrun at least that DSS400. Your explanation is more or less a confirmation of that feeling. One single stream does work, nothing else is bothering DSS400. Plugin does not work, whereas the plugin can use this one tuner for all channels on that transponder and is doing EIT scan in background with the other tuner. O'Net does not have any issues with that all ...


    Next difference I see, you grabbed "http" stream, whereas "vdr-plugin-satip" is IMHO grabbing "rstp" streams, but I don't know if this might make any difference at all.


    Honestly I think this will be not easy to solve, more a long termed try and error for the DSS400 owners, but it's your turn to help plugin's author to help you. At first step might be good to use VDR 2.1.6, whereas "vdr-plugin-satip" is developed on 2.1.5+, plugin is tested on some 2.0.x installations with O'Net ...


    Regards
    fnu

    HowTo: APT pinning

    fnu:


    Thank you for the elaborated answer. In between I have tried with vdr 2.1.6 with exactly the same results.


    Generally I wanted to comment that I am aware that other hardware (approx 3.5x more expensive!!) seems to work fine. I did not expect the DSI400 to work right out of the box. I bought it to play with SATIP not to have a fully working vdr solution right from the start. And with everything besides vdr the box is working quite nicely up so far. At least for me.
    Additionally I do think that we need to get satip plugin running on different hardware to prove and understand that the plugin is working (or rename it to Octopus if the intention is to only support one specific vendor). Right now we can not be sure that if the plugins works on Octopus because it is correctly implementing SatIP 1.2 or if the plugin is just behaving the right way against the bugs of that specific vendor implementation. It could really be that the DSI400 is crap. But the argument that the plugin works for one specific other vendors hardware is not a prove at all for such an assumption. I am still trying to find a setup w/o vdr to reproduce the behaviour I do see.


    So let's see if we can get further and make things better.


    Cheers,
    Michael

    Zitat von micclass

    is this currently a DSI400 general behaviour which needs investigation?


    I don't have the hardware, so I cannot help either. So, someone with the actual device has to find out, what's the problem here. If the HTTP works for you, you could use IPTV plugin instead. The satip plugin is using RTSP/RTP where the video is sent in UDP packets, that are much more vulnerable to any kind of networking errors (bad behaving routers and switches, badly tuned IPv4 stacks, ...). The HTTP protocol implementation just doesn't fit into these DVB streams, where pids are changing dynamically and clients are dynamically adapting to them...

    Thanks to fnu for translating the plugin with DEBUG-symbols
    and rofafor for this plugin !


    Regards


    Manfred

    abydos


    You're welcome. It might be helpful to disable "Smileys" for your post, or to use code-Tags ... ?


    And it's the wrong tread ... i will ask a mod ...


    Regards
    fnu

    HowTo: APT pinning

    Hello,


    just another question with regards to satip plugin and DSI400 (where I am hunting for currupted TS streams in HD and SD content).


    When I do run the satip plugin and tune in to some program, I do get the information that about every 300ms (read 3x per second) a PLAY command is issued.


    It looks like the following:
    PLAY rtsp://192.168.2.15/stream=50?pids=5111,5112,5113,5117,5116,5115,5118,18,20,0,17,16,5114,5100 RTSP/1.0


    The only difference between two of these PLAY commands is that the last PID (5100 in the example above) is changing. It changes to a list which repeats
    itself over and over. (in this case: 5100, 5110, 5120, 5130 and then starting again with 5100) So my question is: Is this normal behaviour? Why do we need to issue a PLAY command every 300ms?


    Cheers,
    Michael

    Yes, we should probably open a separate thread regarding the DSI 400 product. Anyway, I stumbled accross this comment here regarding rtsp-Settings:
    http://www.amazon.de/review/RCVR053SOHRQO/ref=cm_cr_rev_detmd_pl?ie=UTF8&asin=B0093KQQWE&cdForum=Fx2VLG4I4YRIE86&cdMsgID=Mx1O92H2681PT7X&cdMsgNo=1&cdPage=1&cdSort=oldest&cdThread=Tx1FYH0DR9QW0A7&store=ce-de#Mx1O92H2681PT7X
    German language, but maybe this is interesting for owners of this product.


    Regards,
    Henning

    Zitat von micclass

    Is this normal behaviour? Why do we need to issue a PLAY command every 300ms?


    Yes, it's normal. This is due to VDR's PMT scanner, that's going through available PMT pids one by one all the time. In order to get rid of this, you'll have to disable the PAT filter. Unfortunately there's a bug in 0.1.1: the filter is blacklisted indeed, but the pids are set anyway.


    I'm also using the "pids=" parameter instead of "addpids=" and "delpids=" ones due to caching the active pids in the plugin and sending any pid changes to servers on a predefined intervals only.

    Zitat von abydos

    Is a better setting :wow

    Is this a question or a finding?

    HowTo: APT pinning

    Hi,


    I also have a GSS box and I use it with yavdr 0.5 testing (vdr 2.0.4) and vdr-plugin-satip 0.2.0. I did some tests regarding the above mentioned RTSPSessionTimeout value in the GSS box. I found the following: The default timeout value in the gss box is 60 seconds (at least it was in my box). After about 60 seconds my video stream is broken, the picture freezes and wont start again. By changing that value in the gss box I can determine the time when the video stream breaks and the picture freezes.
    In the file tuner.h of vdr-plugin-satip I found two keepalive interval values and changed them:

    Code
    eMinKeepAliveIntervalMs = 30000, // in milliseconds
eDefKeepAliveIntervalMs = 50000 // in milliseconds


    The original values were 300000 and 600000 milliseconds.
    So now the value in the GSS box is 60, the KeepAliveInterval values are less than 50 seconds.
    This works very well for me.
    My conclusion: The keepalive interval value in in the file tuner.h of vdr-plugin-satip must be less than the
    RTSP Steam Timeout value in the gss box.


    Setting the value in the gss box to 0 (obviously meaning infinite) also fulfils this condition but might not be the best choice.


    KlausL

    yavdr 0.5, Mainboard: Asus M4N78-VM, 4 Gbyte RAM, CPU Sempron 140, DVB-S2: IPTV von GSS DSI.400, Display: Futaba MDM166A, Fernbedienung: Activiy-FB silber, Receiver Denon AVR-1910, TV Samsung UE40B6000
    DSI.400 Sat-IP-Server

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden