w_scan_cpp

    Hi @wirbel-at-vdr-portal ,


    This is a message for you. As you don't want to use the GitHub repository for discussing about "technical" (not user related) issues, I'll write here (not confortable, but...).


    Regarding current "open" issues:

    - wirbelscan-dev: Any idea for fixing the initialization of the SCAN_TRANSPONDER ? See https://github.com/wirbel-at-v…l/wirbelscan-dev/issues/2

    - w_scan_cpp: The identation of the XML OUTPUT is real. Please, accept my patch. And related to the enhancement for the SAT>IP support (fixing the parameter and adding the option of forcing TCP), you want to merge it?


    Futhermore, I've some questions/suggestions related to the w_scan_cpp. I'm now working on provide the option for disabling the NIT scanning (so forcing to scan only one transponder) plus the search of an specific transponder. You agree with that? Also another question is if you agree with the idea of "tweak" the scanning process. For example, selecting the time reading the SI tables, the number of times that you tune the transponder, the timeouts, enable/disable the PMT reading (for only frequencies scanning), etc. You accept to discuss about these topics?


    Regards.

    Hi Lars,


    #2 should be fixed and/or checked in any case.

    Lets works together on this. Get in touch with me via email..


    #1 is a bit more difficult, wirbelscan is used mostly used in a real VDR environment (main application as a dtv scanner plugin), w_scan_cpp is only on top of that..

    The vdr-plugin-wirbelscan is the actual DVB (DTV) scanner used in the cmdline tool called w_scan_cpp, but now alrdy ~20yrs old (~2003). SCAN_TRANSPONDER is used together with the VDR main menu app (https://www.gen2vdr.de/wirbel/wirbelscancontrol/index2.html) only. It's not intended so far (yet) to be used on wirbelscan. I'm open for suggestions, which doesnt break any existing code.



    Related on the NIT disabling: no. Definitly no. This is a channel scanner, and most useful info is captured on NIT.

    Related to the times looking for data on a transponder, i will stick on the ETSI ETR-211 standard timing rules. see it's chapter 4.4 'minimum repetition rates.'


    May be, you could reach out via email, even if you dont like it.

    Hi Wirbel,


    I prefer to comment using a technical open forum. The reason is because then other developers could participate. I hope to don't disagree if we continue discussing here. You agree?


    Regarding the current "open" issues:


    • XML output of w_scan_cpp: I'll wait until you check and fix it. The bug is present, and the "excessive" identation for services it's easy to fix.
    • SAT-IP enhancement of w_scan_cpp: Please, check my fix-patch+TCP-enable. It really works and allows scanning from NAT/routed networks. See it at https://github.com/wirbel-at-vdr-portal/w_scan_cpp/pull/6
    • vdr-plugin-wirbelscan as a library: I understand, and I agree, with the idea of not changing anything in "production". And I understand the relationship between the w_scan_cpp tool and this plugin. Nothing to say about that. However, the problem is that the initialization phase is not considering the case of a DVB_TYPE equal to SCAN_TRANSPONDER. And this is your code and your library. You have introduced the value SCAN_TRANSPONDER. Futhermore, with my "dirty" fix nothing will be break (see https://github.com/wirbel-at-v…2#issuecomment-1722475924). But this dirty fix doesn't consider if the User Transponder provided is for the TYPE passed for the scanning. From my point of view, it will be reasonable to follow the KISS principle, and then not check this. In this case when running nothing will be scanned. However, the final word is yours.
    • NIT disabling: I feel I don't have expressed clearly the suggestion (partially implemented already). In the current w_scan_cpp source code it's present the "wsetup.tp_only" but commented. This indicates "one transponder only" (or that I feel). And I use it to set the NIT=0 when scanning (in your code the NIT disable indicates: "not add new trasnponders", therefore it signifies: "only one frequency"). Then providing a User Transponder (I'm implementing this now) the output of the tool will be the scan of only one transponder/frequency (it works nice in my code, I need only to finish the parameter parsing, but the code is completed). This will be very useful for a user that wants to scan only one frequency. Remember... using the "w_scan_cpp" tool, and not anything related to the VDR. This functionality, from my point of view it's a must have. A large scanning of a satellite or terrestrial/cable network doesn't have sense in some cases. And as a CLI tool it has sense to do a: full scan or a specific scan. Do you think so? Remember: I'm speaking of the source code of the w_scan_cpp, I'm not patching anything else (except the previous "bug" inside "vdr-plugin-wirbelscan").
    • Scanning timeouts: I agree to follow all standards to complete the tasks. However, for specific tasks, like "scan if this frequency have data", it will desirable that the tool (w_scan_cpp in this case) has the option to improve the scanning time. For example, you can imagine that I want to complete this task: "Search in AERIAL network the active frequencies broadcasting ATSC signals". In this case, I don't need to parse the PMT tables. Also insn't necessary to repeat three times to tune the same frequency to check if you can lock or not. At time I see that you re-tuning until three times for the same frequency. This have sense for a full scan. And I agree that it's necessary. Nothing to change in this behaviour. However, if a technical user using the w_scan_tool wants another behaviour, then why not support it? Please, expose your point of view.


    Regards.

    Not only that, my time is at the moment way too short..


    May be i can find 1/2 hour at the weekend.

    Hi Lars,


    could you pls check on this one && comment?


    -> XML output of w_scan_cpp: I'll wait until you check and fix it. The bug is present, and the "excessive" identation for services it's easy to fix.



    branch xml_output, latest change.


    If everything is fine, it would take this one into main branch.


    I hope - not shure - that i can find a few minutes more this weekend. But difficult..

    Hi Wirbel,


    Regarding the pending patch of https://github.com/wirbel-at-vdr-portal/w_scan_cpp/pull/6 related to the SAT>IP support...


    * This patch first resolves a bug inside the current implementation. To check the bug, please do this: execute in your LAN only one SAT>IP server with the option of disabling the SSDP announcement. You can do that with minisatip or SATPI servers that are opensource and available in Linux STBs. Then start the "w_scan_cpp" tool (in any machine of the LAN) with the corresponding line to list the SAT>IP server that is not automatically announced. For example with "w_scan_cpp -t --satip-server 192.168.0.2|DVBT2-4|minisatip:0x18" (this example is from the --extended-help). And then you will see that no SAT>IP server is found. The root cause is this line of the code: std::string options("-t 16384 "); (https://github.com/wirbel-at-v…68431e2d/CmdOpts.cpp#L382). In this line you use the last space as the separator for the next command pased to the SAT>IP VDR plugin. However, the correct separator is a ";" char and not an " " (space).

    * Futhermore, when you indicate the option quirk "0x18" (as described in https://github.com/rofafor/vdr…3638007141/README#L53-L78) to set the support of TCP-over-RTSP, this protocol in not used by default. And this is the correct behaviour. However, where is the option in the tool to use it at time? Anywhere. Therefore, I've added the option "--satip-force-tcp" to use the TCP transport... if the server supports it. And the code is implemented using the standard and public API provided by the plugin. So I don't have cross any red-line. All is well done and it works. Please check it running the SAT>IP in a different routed-LAN (for example inside a WSL2 Linux) and using a command line "w_scan_cpp -t --satip-force-tcp --satip-server 192.168.111.2|DVBT2-4|minisatip:0x18" and see then that you can use the "remote" SAT>IP server through your NAT router. Nice right?


    So, please check the bug and review my code. I feel it's simple and follows the KISS model.

    Then I hope you want to merge it soon.


    Regards.


    Hmm, i'm looking at this one.


    First of all, doing different things in one patch or PR is a No-Go for me.

    One patch/PR, one topic.


    Therefore, i will split this into several topics, the commandline passed to the satip plugin will be first - bugs first, new things later.


    "execute in your LAN only one SAT>IP server with the option of disabling the SSDP announcement"

    My server doesnt support this. This features is beyond the SAT>IP spec, which requires this feature active && working for any SAT>IP server.


    "In this line you use the last space as the separator for the next command pased to the SAT>IP VDR plugin. However, the correct separator is a ";" char and not an " " (space)."

    Correct, today i stumbled on this bug, just before reading it here.

    This 'fix' in your PR is actually a noop, but should be included in any case.

    Code
    --        options += "-s" + WirbelscanSetup.SatipSvr;
++        options += "-s " + WirbelscanSetup.SatipSvr;


    Most likely, correct solution should be

    Code
    std::string options("-t 16384");


// add further satip plugin options as needed.
if (not WirbelscanSetup.SatipSvr.empty())
options += ";-s " + WirbelscanSetup.SatipSvr;


    For future contacts, i prefer by work together by email.

    This topic is for most users here too detailled and not that interesting.

    Please check latest main.

    Zitat von wirbel

    For future contacts, i prefer by work together by email.

    This topic is for most users here too detailled and not that interesting.

    That's the reason to write/comment in GitHub. I feel this forum is not the correct place to speak about such issues. Futhermore, I don't agree to share comments only by email. The spirit of a "open developers only" forum is a good way to share technical knowledge, don't you think?


    Please, read the GitHub for most topics.

    Regards.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden