vdr-plugin-satip on DSI-400 and clones

    Hello,


    to seperate out issues (and success stories) with the satip-plugin running on DSI-400 devices, I thought it would be a good idea to do an extra thread. Currently I do test a DSI-400 (V 1.13.0.105) with the following setup:


    vdr 2.1.6 with satip plugin 0.2.2 on Fedora 20 (with curl 7.36 from Fedora 21/rawhide) running in a libvirt based VM.


    Additional plugins: streamdev-server, live (with OSD patch), epgsearch.


    vdr startup arguments: /opt/vdr/bin/vdr -w 60 -l 3 -u vdr -L /opt/vdr/lib -v /video --userdump -P satip -d4 -Pstreamdev-server -P live -P epgsearch


    WIth the latest changes, I do get a mostly working solution for HD and SD recording. Thanks for this!


    I do see currently two issues:
    1. (probably cosmetic) When Session Ids do start with "0" the log says that the DSI-400 returns a wrong Id back within the responses (missing the leading "0") This is what I do see in the log:



    So it seems that libcurl detects the issue an spits out an error, but besides this error no further problem arises. I do assume that this is a firmware problem of the DSI-400.


    2. At start of recording I often do see that multiple ts files are generated until finally one starts that has most of the content:


    Example:


    [michaelc@satip 2014-04-08.22.50.8-0.rec]$ l
    insgesamt 7688340
    -rw-r--r--. 1 vdr vdr 3553764 8. Apr 22:50 00001.ts
    -rw-r--r--. 1 vdr vdr 1788068 8. Apr 22:50 00002.ts
    -rw-r--r--. 1 vdr vdr 880404 8. Apr 22:50 00003.ts
    -rw-r--r--. 1 vdr vdr 7864545532 9. Apr 00:16 00004.ts
    -rw-r--r--. 1 vdr vdr 2073312 9. Apr 00:16 index
    -rw-r--r--. 1 vdr vdr 865 8. Apr 22:50 info



    This is the log when these files were created. It seems that multiple SETUP commands are done.



    Do others see the same behaviour? Any hints on hwo to proceed with debugging?


    Cheers,
    Michael

    Zitat von micclass

    2. At start of recording I often do see that multiple ts files are generated until finally one starts that has most of the content:

    Is the VDR service restarting here several times if trying to record? Or do you just see this amount of sessions timing out?


    The first could be a reason for the several TS files, it seems you just grabbed for messages belonging to satip in syslog ... ?


    Regards
    fnu

    HowTo: APT pinning

    Hello,

    Zitat

    Is the VDR service restarting here several times if trying to record? Or do you just see this amount of sessions timing out?

    as the process ID of the vdr process stays the same all the time, I do read the log as there are no restarts of vdr. But in the past I remember that I did see some restarts together with sessions that timed out.


    Cheers,
    Michael

    Zitat von micclass

    1. (probably cosmetic) When Session Ids do start with "0" the log says that the DSI-400 returns a wrong Id back within the responses (missing the leading "0")


    Are you using libcurl version 7.36.0 or newer?


    Zitat von micclass

    2. At start of recording I often do see that multiple ts files are generated until finally one starts that has most of the content:


    This happens due to VDR's implementation of opening/closing devices more than necessary.

    Zitat

    Are you using libcurl version 7.36.0 or newer

    Yes! "vdr 2.1.6 with satip plugin 0.2.2 on Fedora 20 (with curl 7.36 from Fedora 21/rawhide) running in a libvirt based VM. " The issue is only happening when the Sessio ID start s with "0"!


    Cheers,
    Michael

    ... just another datapoint ....


    After cleaning up my channels.conf (I had originally used the one from my normal vdr installation with lots of unused channels including radio), I do not see the "SATIP: detected <x> RTP packet errors" any more.


    Recordings now do seem to be working fine for as long as I do record just one program at one time. Starting the second record while already one is running leads to the following behaviour (mostly reproducible). The second recording gets a "ERROR: video data stream broken" and then vdr restarts. After the restart both records are running fine.


    Is this just me seeing this behaviour?


    Cheers,
    Michael

    Zitat von micclass

    Is this just me seeing this behaviour?

    No, me too, quite a while, rofa is working on this and I'm testing ... so stay tuned ... ;)


    Regards
    fnu

    HowTo: APT pinning

    Zitat von rofafor

    Don't hold your breath! :)

    We don't hold breath, we stay calm and thankfully for the the awesome work ... :tup

    HowTo: APT pinning

    rofafor:


    Zitat

    micclass: I'd need a tcpdump capture from your session problems to find out the root cause.

    https://www.michaelclass.de:444//vdr_dsi400_001.pcapng.gz


    But beware this is 240MB in size. If you only need portions of it, please let me know what I should filter for.


    The dump was taken when I have started to record two different channels and the "video data stream broken" error occured. vdr was restarting after the error.


    Cheers,
    Michael

    Zitat

    You seem to be filtering out PAT tables and therefore VDR cannot find valid pids.

    Correct! I have configured one filter in satip plugin for PAT. WIthout doing this I am getting corrupted recordings. When I enable PAT filter, I do get clean recordings.


    Cheers,
    Michael

    Zitat von micclass

    WIthout doing this I am getting corrupted recordings.

    I guess it might be more necessary to look after that issue instead of disabling PAT filter. The latter prevents also decoding of crypted channels ...


    Regards
    fnu

    HowTo: APT pinning

    Hello,


    if disabling of PAT filter causes the issue, I do agree that the whole thing comes back to make satip on a DSI400 working with PAT filter enabled.


    I do understand nothing about the functionality of PAT filter and why it results in issuing RTSP PLAY command roughly every 200-300ms just to exchange one PID And even the PID exchanged is repeated in a small loop for a small set of PIDs. (e.g. in the case that I currently watching:


    PLAY rtsp://192.168.2.15/stream=80?pids=6510,6520,6521,6523,6522,6531,18,20,0,17,16,66


    and the last PID (66) is cycling through 65,66 and 67 all the time. It is hard for me to believe that this is sane behaviour. Does this really need to be that fast (3-4 PLAY command per second)? Is it really necessary to continuously cycle through the small set of PIDs?


    Is there somewhere some documentation which could help me understand what is tried to achieve here?


    Cheers,
    Michael

    It's just the PMT scanner. VDR is continuously checking all the available PMT tables one by one and finding out any updated information. I guess PMT pids are closed when they aren't needed anymore in order to save those precious pid filtering resources.


    I'll take your words that DSI-400 can't handle this rate. Am I correct or is this pid shuffling just annoying you when you're tracing the network traffic?

    Zitat

    I'll take your words that DSI-400 can't handle this rate. Am I correct
    or is this pid shuffling just annoying you when you're tracing the
    network traffic?

    I cannot prove that in a sientific mannor. The behaviour I do see is simple the following:


    Disabling PAT filter in satip plugin -> clean records no corruptions to TS streams
    Enabling PAT filter in satip plugin -> corruptions in TS streams, "garbage" in records


    When I do watch the debug log of satip plugin, the major difference between the two cases (with and without diabled PAT filter) is that in the first case (disabled PAT filter) I do see only every couple of seconds an RTSP OPTION command to keep the straem alive, where in the second case (with enabled PAT filter) I do see 3-4 RTSP PLAY commands every second.


    As this seems to be the major difference between the two cases, I assume that the DSI400 has issues with the rate of PLAY commands (even though this would be against the SATIP specification where in Chapter 3.5.5 it is stated that "A change in parameters shall not interrupt the playing stream and shall not lead to any packet loss within the stream." )


    Cheers,
    Michael

    Zitat von micclass

    do see only every couple of seconds an RTSP OPTION command to keep the straem alive, where in the second case (with enabled PAT filter) I do see 3-4 RTSP PLAY commands every second.


    That's odd because the minimum OPTIONS command interval should be 30 seconds. You might consider increasing the ePidUpdateIntervalMs value in tuner.h to give DSI-400 more settling time between the PLAY commands.

    Zitat von micclass


    2. At start of recording I often do see that multiple ts files are generated until finally one starts that has most of the content:


    Zitat von rofafor

    .... consider increasing the ePidUpdateIntervalMs value in tuner.h to give DSI-400 more settling time between the PLAY commands.


    ePidUpdateIntervalMs = 250


    Tested several recordings of individual and multiple transponders


    I do not see multiple ts files more ......


    Regards
    Manfred

    ... and again a new datapoint ...


    Slowing down the rate of the PLAY commands (by increasing ePidUpdateIntervalMs) did not fix the corruptions in the recordings. So what I did now is the following:


    I have hacked the cSatipTuner::UpdatePids so that it remembers the last pids set and will use "addpids" and "delpids" commands for further invocations.


    So the PLAY commands which are frequently issued do now look like:


    PLAY rtsp://192.168.2.15/stream=15?&addpids=6400&delpids=6300 RTSP/1.0


    And this change make a difference. I do now get clean recordings with PAT filter enabled.


    My code is not looking C++-ish and probably has still some errors, but at least this makes me think that it would be worth going this route.


    Cheers,
    Michael

    Zitat von micclass

    I have hacked the cSatipTuner::UpdatePids so that it remembers the last pids set and will use "addpids" and "delpids" commands for further invocations.


    Oh, great catch! The first version of plugin used that technique, but after adding the buffering I simplified the code by using only the "pids" parameter. :)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden