Beiträge von lars18th

  • w_scan_cpp

    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.

  • w_scan_cpp

    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.


  • w_scan_cpp

    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.

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