Posts by tmn505

    Thanks lnj for posting this. I checked if there's something two days before the patch was sent.


    Anyway, as already stated, Hans will work on striping analog video parts from the drivers. This will move it from staging back to maintained area. Should be at least easier to bring back the analog capabilities, when the driver is still in tree, if someone wants to do it. Sadly the OSD part of DVB API will go away and I don't think it'll ever come back.


    After Hans will post changes to ML, it would be good to see some test feedback. One doesn't need to be subscribed to the ML, You can download raw message from kernel lore (https://lore.kernel.org/linux-media), example: https://lore.kernel.org/linux-…rkuil-cisco@xs4all.nl/raw. Open it in Your mail client, hit reply. To not break threading, fill 'In-Reply-To' field with 'Message-Id' of downloaded message (view the source of message to get it). That way it'll show the popularity of the driver.

    If I'll be Cc-ed to the patch, I'll notify it here.

    I doubt that that is possible.

    I'm not sure, but Videobuf seems to be used to transfer the DVB-Data too.


    Sorry, I should be more specific, I meant the budget cards supported by ttpci driver (didn't realize that saa7146 also support particular budget cards). From brief look at the source, only ttpci/budget-av.c contains videobuf references.

    Btw. when zoran driver was removed and Corentin stepped-up to convert the driver, Hans responded with small check list: https://lore.kernel.org/linux-…c6-ea9036afac3d@xs4all.nl. Hope this helps, for me that's way over my head.


    Falls das Anfang 2023 raus fliegt, ist es dann zuletzt in Kernel 6.1 als deprecated und in 6.0 regulär.

    Wahrscheinlich wird 6.1 oder vielleicht 6.0 LTS Support bekommen.

    Mit etwas Glück hält das bis Ende 2028, mindestens jedoch bis Ende 2025.


    The 6.1 seem to be next LTS candidate.


    Ich würde mir im Kernel aktuelle und gepflegte Treiber für Budget Karten wünschen.

    As already mentioned, the videobuf code should be easily stripped from the ttpci driver. That would cause issues for someone wanting to also convert saa7146 driver, since both drivers currently are entangled with each other, and I personally don't want to do that until last moment.


    Das scheint aber nicht möglich zu sein, bei dem derzeitigen Maintener (?).

    Well, nobody asked or complained yet on the mailing list or #linux-media IRC channel on OFTC. I'll do that somewhere after Christmas (unless someone beats me to it), just want to give time for anyone wanting to convert saa7146 as well as the ttpci driver to videobuf2, so I don't thwart his/hers efforts.

    Regarding the budget cards, aside from converting the driver to vb2, there's also possibility to simply strip the video input capabilities from the driver. We could probably convince Hans to do this himself, as apparently the vendor of Omnicom S2 PCI card is still selling it (https://www.omicom.info/PayPal_Omicom_S2_PCIr3.html, personally didn't try to order it). But as that would create not good position for full-featured cards, I won't post any request to Media ML until someone posts patches for removal of the driver.

    As I'm not subscribed to linux-media@vger.kernel.org mailing list, just recently got aware that most part of drivers using videobuf version 1, have been moved to staging/media/depreciated area. This means that at some point these drivers could be removed if not converted to videobuf version 2 (maintainers wrote "some time next year"). The move started with https://lore.kernel.org/linux-…1455527ece2a@xs4all.nl/#t followed by https://lore.kernel.org/linux-…-hverkuil-cisco@xs4all.nl and https://lore.kernel.org/linux-…59-43c0b7f56486@xs4all.nl which in result landed in 6.1 kernel.


    This post is to raise some awareness about it, as I don't have skills to do the driver conversion myself. Hope someone in VDR community can step-up and do the task.

    SurfaceCleanerZ arleady mentioned what are the usual use cases for VDR. You could use already proposed options and I'll add another one, add xineliboutput plugin and connect to local VDR with vdr-sxfe. All of them work but are a little bit clunky to use, if TV watching is not the main thing You do on Your PC.


    And there's a solution (buzzword!) for Your problem, install kaffeine. It's not on par with features that usual Windows programs You used have, but the basics are there. There's fine YouTube video from Hauppauge which illustrate how to set it up

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    . Good luck.

    I do use tbsdtv drivers on 5.10 kernel albeit on Arch Linux x86_64. This might be an ARM drivers specific issue or patches applied on Armbian kernel. Judging from this site https://www.linuxtv.org/wiki/index.php/TBS5922 and the issue You linked, the compilation fails on module which Your card doesn't use. Use the build system to select the drivers You need:

    Code
    git clone https://github.com/tbsdtv/media_build.git && cd media_build
    make download
    make -C linux untar
    make menuconfig #select Your card here
    make -j($nproc)
    sudo make install

    In the menuconfig there are a lot of things pre-selected, try to narrow Your card modules to build as few drivers as possible, so the possibility of failed compilation goes lower. Good luck.

    In tntnet 3.0 there's no tntnet-config. You'll have to use pkg-config.

    But that's not all, later at compilation You'll get:

    Code
    g++ -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include   -std=c++11 -Wfatal-errors -Wundef -Wno-deprecated-declarations -Wno-overloaded-virtual -Wno-unused-variable -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"live"' -DTNTVERSION=30000 -DCXXTOOLVER=30000 -DHAVE_LIBPCRECPP -I/include -I.. recordings.cpp
    recordings.ecpp: In member function 'virtual unsigned int {anonymous}::_component_::operator()(tnt::HttpRequest&, tnt::HttpReply&, tnt::QueryParams&)':
    recordings.ecpp:59:6: error: 'deletions_type' has not been declared
       59 | for (deletions_type::const_iterator it = deletions.begin(); it != deletions.end(); ++it) {
          |      ^~~~~~~~~~~~~~
    compilation terminated due to -Wfatal-errors.
    make[1]: *** [Makefile:34: recordings.o] Error 1
    make: *** [Makefile:191: pages] Error 2

    So it's better to use older cxxtools+tntnet for now.

    At some point where I used VDR on OpwnWrt I had to add similar patch. Back then I didn't delve what was the issue, but seeing it now the issue probably stems from using different source of libjpeg. Most distros use libjpeg-turbo now, but previously some used libjpeg from IJG (OpenWrt 18.06.x).

    Es geht so für alle Treiber im neuen media_build's wegen dieses commit:
    https://git.linuxtv.org/media_…c951fe52629b722f79c70883f
    Der build einstellt den CONFIG_DVB_DEMUX_SECTION_LOSS_LOG auf y. Um das zu umgehen ausführe Ich diese befehle:


    Code
    git clone git://linuxtv.org/media_build.git
    cd media_build
    make download
    make untar
    make stagingconfig
    sed -i '/CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=y/d' v4l/.config
    make


    Vergiss nicht der Treiber zum installieren.

    Add the following to Your ~.xine/config_xineliboutput:

    Code
    video.output.vaapi_swap_uv_planes:1


    or search it for this string, uncomment and change the value to 1.
    For further tweaking, here You have some vaapi options explained:
    https://github.com/huceke/xine…i/blob/vaapi/README.vaapi


    Edit:
    Sorry, this is false, don't think this'll solve Your problem. When checked later I executed it with --video=xv.