Posts by micclass

    Hello

    Really? I don't see why they would make the VDR to crash - the plugin should just try to retune the channel after 5 seconds. I'd like to see syslog entries during the malfunction.

    I was seeing that sessionM was undefined in case of 404 errors and thus the following code (from tuner.c, line 245 in vers 0.3.2)


    Code
    1. if (nextServerM && nextServerM->Quirk(cSatipServer::eSatipQuirkSessionId) && startswith(*sessionM, "0"))


    crashes vdr, as the startswith function tries to access memory through an undefined pointer. But I have to admit that I have to reproduce this with version 0.3.2 (I definitely was seeing the crash with 0.3.1).


    But: I really would prefer to have vdr exiting if we do get repeatedly 404 errors. Going in an indefinite retune loop would not help in this (very rare and probably not for a lot of people relevant) case. If vdr ends (preferrable with an error state), I can do the reboot of the DSI400 in the runvdr script and restart vdr and things will start working again.


    And again: For me this is a rare case and needs usage of the DSI400 with multiple vdr instances and some hard crashes. It is not easy to reproduce. I will see if I can catch one of the crashes to further investigate.


    Cheers,
    Michael

    Hello,


    just one other thing that I am currently playing with and which might be helpful for somebody else: Even though the vdr with satip plugin is working stable for me, I am able to lockup the DSI400 in rare cases when I do use two vdr instances (one with -d3 to get three tuners and the other one with -d1 to only get one tuner) and one of the vdr instances crashes. The behaviour I do see is that the DSI400 is returning 404-Errors (which are not correctly handled in the satip plugin and make vdr crash). What I have to do in the error case, is to reboot the DSI400 (web interface is still working in that situation). To be able to automate this task, I have written a small script to do the reboot. I am now using the script in my runvdr when vdr is crashing in a short period very often.


    I thought that someone might be interested in the script too and will share here:



    Cheers,
    Michael

    Hello,


    just one other comment here (might help someone with limited knowledge like me ...) Setting up a headless vdr with only a DSI-400 as receiver was working, but showing some weird behaviour with regards to sometimes missing EPG data. Only after I have configured the "dummydevice" plugin, EPG is working reliably. Up so far I had only built headless vdr setups with DVB cards which worked without the dummydevice plugin. But as my new vdr instance (running in a libvirt VM) now does not have any local dvb cards any more, it seems that dummydevice is needed.


    Cheers,
    Michael

    Attached is the patch against satip-0.2.3. This again is a bit of a hackery as in 0.2.3 pidsM is still needed, so that I had to maintain the list of active pids (in pidsM from original code) and the two lists of pids to be added/deleted (pidsAddM/pidsDelM) which I do use to compute the addpids/delpids arguments.


    But the good news is, that with this version I have yet to see the vdr restarts due to video stream timeouts. So it's either fixed or at least less frequent.


    Cheers,
    Michael

    Hello,


    I have rewritten the patch for the addpis/delpids logic to be a bit less of a hack (still would win noting in a "beautiful C++"-contest ;-) ) This is what I am running now. I can use the PAT filter without corruptions in recordings. I do not have experience with encrypted channels. But I still do see some "ERROR: video data stream broken" messages including a restart of vdr in some cases. I will try to further investigate into this. Unfortunately I will have little time in the next 2-3 weeks due to work related things.


    Cheers,
    Michael


    *update* Sorry I was just seeing that there is version 0.2.3 of the satip plugin since a couple of days. I have based this on 0.2.2. Willl change it to 0.2.3. BUt this neeeds a few changes and test.

    ... 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

    Quote

    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

    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

    Quote

    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

    rofafor :


    Quote

    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

    ... 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

    Quote

    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

    Hello,

    Quote

    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

    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

    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

    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

    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

    Hallo,


    ich verwendet auch va-api. Im dezidiert Video-Abspieler habe ich zwar 'ne nVidia Karte (und damit vdpau) drinnen, aber ich schau auch öfters mal auf meinem Arbeitsrechner fern. Und das ist ein SandyBridge System (mit 2 Monitoren). Da hab ich dann keine extra Grafikkarte drinnen (die Intel Grafik von SandyBridge reicht mir ansonsten massig aus!). SoftHDDevice funktioniert, allerdings hab ich hin und wieder mal einen Absturz und manchmal hängende Bilder beim Umschalten von SD and HD oder umgekehrt. (hier kommt ausschiesslich 720p von den öffentlich rechtlichen Sendern als HD an!).


    Wär schade, wenn ich wieder auf xine zurückgehen müsste (das war immer ein ziemliches gepfriemel zum bauen. - bau den vdr selbst, VDR 2.0.1, OS is Fedora 18)


    Gruß Michael