[vdr-plugin-satip] this and that

  • Hi!


    The plugin is now workin on my Raspberry. But after about a minute the picture freezes. When changing the channel all is okay again for the next minute, than it freezes again.


    Debug says:


    additional stuff not fine transfre.c:1037: 0 0


    About 10 seconds after this message the picture freezes.


    Any ideas?


    Thanks


    Niel

    Client Wohnzimmer:
    RPi, VDR 2.1.6, rpihddevice, satip, remotetimers, osdteletext
    Client Schlafzimmer:
    zurzeit keiner
    VDR-Server:
    Epia 5000, 8 GB DOM, Skystar 2 HD, VDR 2.1.6, satip, svdrpservice
    (dient als Homeserver, macht auch noch andere Sachen, Zugriff auf 1TB NAS)
    Satip-Server:
    GSS.box DSI 400

  • Hi,
    there is something I don't understand (having read the Sat>IP spec more than once and reading also through the API documentation on linuxtv.org): What are Pilot Tones for? If I compare the channels.conf (for DVB-S/S2) and the query syntax for Sat>IP I can only find one single parameter for DVB-S2 channels that is not set in the channels.conf. If we assume that the tuner in the Sat>IP server and on a DVB-S PCI card or USB adaptor work similar, how could VDR tune to a channel without this "Pilot Tones" parameter, that is mandatory due to the Sat>IP spec:

    Zitat

    Physical Tuning
    Standard DVB-S/S2 tuning parameters are passed to the SAT>IP server frontend in order to tune to a given transponder. For DVB-S the mandatory parameters are: “src”,“freq”,”pol”,”msys”,”sr” and”fec”. For DVB-S2 the mandatory parameters are: “src”,“freq”,”pol”,”ro”,”msys”,”mtype”,”plts”,”sr” and”fec”.


    Except for this parameter (that is said to be auto detectable by some devices) everything that is needed to tune the Sat>IP server to a specific channel is already present in VDR. Only the "src" parameter could be a problem, but only if the DiSeq configuration of the physical DVB-S card and the one where the Sat>IP server is connected to is different. For this (in my opinion VERY rare) case a particular configuration could be passed to the satip plugin. All other cases can be handled by VDR without any additional information and a plugin should not unnecessarily add complexity where it is not needed.


    Unfortunately (only in this case;-) ) I am not a software engineer but a mechanical engineer and so I only thought about possible implementations without implementing them right away. However I thought of ways how I could implement something using as much existing code as possible. The iptv plugin implements a device that introduces a new service type (IPTV) and uses special channels.conf entries: First it introduces a parameter how to get the stream (http address, script parameter etc. which is obvious) but second the frequency has to be set to a unique value. I think this has to be done as VDR would otherwise try to find additional "channels" on this "transponder" (identified by frequency and polarization). This makes perfectly sense for streams accessible by a unique http address. This makes no sense for Sat>IP! Sat>IP exports DVB-S devices via network and thats it. If VDR records a timer on DVB-S transponder than it should be possible to tune to other channels on the same transponder too. VDR takes care if these channels are on one the same transponder. So pressing "channel up" changes not to the next channel in the list but to the next available channel, i.e. the next channel that can be received without to retune. To tune to a channel VDR has to talk to the FRONTEND to tune to the frequency and to the DEMUX to get a TS stream with the wanted video and audio PIDs. If VDR wants to receive a second channel on the same transponder it only has to set the additional PIDs in the DEMUX device to receive a TS stream with video and audio PIDs of TWO channels. VDR itself has to demux the TS again to e.g. record the first channel and display the second channel. In case of Sat>IP the FRONTEND tuning is done with an rtsp message specifying the physical parameters stated above and the PIDs in the DEMUX are set either in the same rtsp call all at once or by subsequent "addpid=XXX" messages. I don't know how VDR EXACTLY tunes to a channel what has to implemented in a plugin to translate these function calls into Sat>IP rtsp messages. That this is possible can be seen in the vtuner implementation for satip.


    In the announce thread it is said, that the plugin always receives the complete transponder (pids=all). I can't find this in the plugin code. It would also just add unnecessary network traffic which would certainly cause problems on slower clients. Am I right?


    Don't get me wrong, I appreciate your work and any other work making Sat>IP accessible for VDR. I am just searching for the best possible solution. If I can help with my limited programming skills: I am in!


    Darkstar.

    Hardware: Seagate Dockstar@1500MHz, GSS Box DSI 400 SAT>IP Server, VDR 2.1.6 mit Streamdev-Server
    Videoausgabe: RaspberryPi mit MLD-4.0.1-RPi an LG 42LM660

  • how could VDR tune to a channel without this "Pilot Tones" parameter, that is mandatory due to the Sat>IP spec:


    VDR uses auto setting for pilot.


    Except for this parameter (that is said to be auto detectable by some devices) everything that is needed to tune the Sat>IP server to a specific channel is already present in VDR. Only the "src" parameter could be a problem, but only if the DiSeq configuration of the physical DVB-S card and the one where the Sat>IP server is connected to is different. For this (in my opinion VERY rare) case a particular configuration could be passed to the satip plugin. All other cases can be handled by VDR without any additional information and a plugin should not unnecessarily add complexity where it is not needed.


    I guess you overlooked the spec and missed T2 system id and SISO/MISO settings required for DVB-T2. The current DVBAPI doesn't support these ones - if ever.


    That this is possible can be seen in the vtuner implementation for satip.


    The vTuner implementation faces all the same problems as this plugin if it's want to dynamically attach/detach SAT>IP streams. Static configuration would be pure madness, IMO. VDR's retuning is currently a bit nasty as first it sets new parameters, then closes the device and finally opens the device again. When closing the device, you'll never know whether you'll need to reopen right away and therefore I have to always teardown the RTSP connection. One solution would keep the RTSP connection alive all the time even while idling, but I prefer on demand functionality.


    In the announce thread it is said, that the plugin always receives the complete transponder (pids=all). I can't find this in the plugin code..


    Because it doesn't. The plugin receives only the pids VDR has requested and as the specs allow to stream all the pids, the whole transponder is available for VDR if needed.


    Btw. I've already refactored the plugin to utilize existing T and S sources, so it's no big deal! The upcoming version will work with your current channels.conf entries.

  • Zitat

    Btw. I've already refactored the plugin to utilize existing T and S
    sources, so it's no big deal! The upcoming version will work with your
    current channels.conf entries.

    Cool! looking forward to the new version. And BTW: Thanks for the new Plugin ! :D

    Zum Guggen: yavdr0.6 + Silverstone GD04 + Intel DH57DD + Intel G6950 + Nvidia GT630 + Unicable/Jess-Sat (JPS0501-12) mit DD/L4M Max8 + 4TB WD-red + bequiet SFX300W
    Zum Testen : yavdr-Ansible + GMC Toast + B365M+i3-8100+ Nvidia GT1030 + L4M CineS2v6 o. SAT>IP Plugin mit DD-O'net
    VaaS (VDR-as-a-Service): yavdr06 + ML03+DH67BL+G530+2GB RAM + 2TB WD-EARX + Zotac GT610 + L4M v5.4 + bequiet SFX300W
    Squeezeboxserver: DN2800ML im Streacom F1CS NAS: HP ProLiant MicroServer NL36+ Smart Array P212

  • Great news that it will be possible to use the unmodified channels.conf.


    Will it be possible to somehow bind one tuner to the VDR client? Just to be sure that the VDR system will have a tuner available if a recording is scheduled.

  • Because it doesn't. The plugin receives only the pids VDR has requested and as the specs allow to stream all the pids, the whole transponder is available for VDR if needed.

    I should have written, "is able receive a complete transponder over one tuner", but I decided to word it a bit simpler, sorry for that ...


    Btw. I've already refactored the plugin to utilize existing T and S sources, so it's no big deal! The upcoming version will work with your current channels.conf entries.

    But this does need VDR 2.1.6+ most probably, where Klaus do implement some changes, right?


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • VDR's retuning is currently a bit nasty as first it sets new parameters, then closes the device and finally opens the device again. When closing the device, you'll never know whether you'll need to reopen right away and therefore I have to always teardown the RTSP connection. One solution would keep the RTSP connection alive all the time even while idling, but I prefer on demand functionality.


    VDR closes the dvr handle when the last cReceiver is detached. However, we could as well postpone closing the handle for a short time (some seconds) to keep it open in case of channel switching. I don't know if this will actually work, there might be residual data in some buffers. For a quick test you could try commenting out the lines

    Code
    if (!receiversLeft)
         Cancel(-1);


    from cDevice::Detach(cReceiver *Receiver). That way the dvr handle will never be closed when the last cReceiver is detached.


    Zitat


    Btw. I've already refactored the plugin to utilize existing T and S sources, so it's no big deal! The upcoming version will work with your current channels.conf entries.


    This is great news!
    And I have just ordered an "Octopus Net" so I can help testing ;-).


    Klaus

  • Do I understand this right: I can change my LNB to the Inverto-LNB, plug it to my local Ethernet and VDR should work with it using the satip-plugin?


    It even seems to exist in a dual-sat-Setup (e.g.13.0E / 19.2E).


    In this case I think you need 2 Inverto LNB's und 2 Cat Cables. In SatIp spec there can coexist multible SatIp Servers.

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0


  • In this case I think you need 2 Inverto LNB's und 2 Cat Cables. In SatIp spec there can coexist multible SatIp Servers.

    I was referring to the FAQ of the Inverto-LNB:

    Actually I couldn't find any product with that specification on their page. So you seem to be right.


    Christian

  • Debug says:
    additional stuff not fine transfre.c:1037: 0 0
    About 10 seconds after this message the picture freezes.
    Any ideas?


    Unfortunately, the error message itself is completely bogus, but I guess it's due to some networking errors (is your power adapter stable enough?):

    Code
    Curl_readwrite: remove debug output
    
    
    The text "additional stuff not fine" text was added for debug purposes a
    while ago, but it isn't really helping anyone and for some reason some
    Linux distributions provide their libcurls built with debug info still
    present and thus (far too many) users get to read this info.


    I'd need a debug log of the plugin for analyzing the problem...

  • Hi!


    I'm not at home this week. I'll make a log of the plugin on saturday or sunday, when i'm home again.


    Niel


    Edit: (Home again!)


    Hi!


    Here's the log.


    Niel

    Dateien

    Client Wohnzimmer:
    RPi, VDR 2.1.6, rpihddevice, satip, remotetimers, osdteletext
    Client Schlafzimmer:
    zurzeit keiner
    VDR-Server:
    Epia 5000, 8 GB DOM, Skystar 2 HD, VDR 2.1.6, satip, svdrpservice
    (dient als Homeserver, macht auch noch andere Sachen, Zugriff auf 1TB NAS)
    Satip-Server:
    GSS.box DSI 400

    Einmal editiert, zuletzt von Niel ()

  • Here's the log.


    Thanks. Could you provide me the exact manufacturer, model, and content of this URL: http://192.168.13.29:8080/desc.xml (IP is your SAT>IP device)?


    Code
    ERROR (thread.c,227): Keine Berechtigung
    ERROR: [sectionfilter.c,105]: write(): Die Ressource ist zur Zeit nicht verfügbar


    You should start the VDR as root and define the VDR user via a command-line parameter (-u). Now, threading priority tweaks don't work in your environment and that might cause buffer over/underflows which might lead to the described problems in your setup.

  • Hi!


    The URL is my Sat>IP-Device, a Grundig Sat Systems GSS.box DSI 400, Firmware V1.13.0.105.


    The content of this URL you can find in the attached file.


    Starting the vdr as root with -u and my username dosn't fix the problem. It's still the same.


    Thanks!


    Niel

    Dateien

    Client Wohnzimmer:
    RPi, VDR 2.1.6, rpihddevice, satip, remotetimers, osdteletext
    Client Schlafzimmer:
    zurzeit keiner
    VDR-Server:
    Epia 5000, 8 GB DOM, Skystar 2 HD, VDR 2.1.6, satip, svdrpservice
    (dient als Homeserver, macht auch noch andere Sachen, Zugriff auf 1TB NAS)
    Satip-Server:
    GSS.box DSI 400

  • When trying to set up a session with TSS-400 I receive the followin error log from satip plugin (VDR 2.0.5):
    TSS400 has IP addr 192.168.1.138:
    Seems that the session-id is not handled correctly here.


  • There's now a new version available (0.1.0) that's adapted to existing C/S/T channels. No more separate Z/Y channel sources as requested, but there's a new setup option no, that hopefully let's you choose whether you want to prefer network devices over the local DVB cards and vice versa. If you're going to use femon plugin together with satip, you'll also need an updated version 2.0.4 of that one. All the tested C, T, T2, S, S2 seems to be working now.


    Niel: Could you verify that your Grundig is now correctly detected: name is correct and the model is DVBS2-4?


    clh27: The session header should be utilized correctly now.

Jetzt mitmachen!

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