Posts by carel

    I'm using below patch, not sure it's 100% up-to date

    Does this mean the live-streams are updating their PIDs continuoulsly?

    Do I need to change P=1 to P=0 to avoid this? and could this have an impact on the possibility to record streams?

    In the past you shared a patch "prevent retune and obsolete", do you recommend to still apply it?

    I tested a bit further with your patch applied and with P=0 set

    It looks perfect now.. no more useless change of pids like here:

    Jan 16 11:50:18 user.debug      thuis   vdr: [409441] changing pids of channel 92 (MBC 5) from 256+256=2:257=@4:0:0 to 256+256=27:257=@15:0:0
    Jan 16 11:50:18 user.debug      thuis   vdr: [410948] changing pids of channel 92 (MBC 5) from 256+256=27:257=@15:0:0 to 256+256=27:257=@4:0:0

    Recording also goes fine!

    Note: I'm using the plain simple

    yt-dlp_linux -t mp4 --audio-multistreams --hls-use-mpegts ${URL} -o - | nc 127.0.0.1 ${PORT}

    With channel set like example:

    MBC 5;IPTV:7140:S=1|P=0|F=EXTT|U=iptvstream.sh|A=7140:I:0:256=27:257=@15:0:0:1:1:5743:7140

    'urls.conf' called in 'iptvstream.sh' links parameter 7140 to the IPTV url as usual

    I'm getting these "Retuning due to modification of channel.. " in the logs

    Does this mean the live-streams are updating their PIDs continuoulsly?

    Do I need to change P=1 to P=0 to avoid this? and could this have an impact on the possibility to record streams?

    In the past you shared a patch "prevent retune and obsolete", do you recommend to still apply it?

    Too many questions today :/


    BTW: I noticed the error

    IPTV-ERROR: Script '/etc/vdr/plugins/iptv/iptvstream.sh' won't terminate - killing it!

    This could be fixed by changing

    int retval = killpg(pidM, SIGINT);

    to:

    int retval = killpg(pidM, SIGTERM);

    in protocolext(t).cpp

    I'm using Debian here, not sure if other Distro's also have an issue with 'SIGINT'

    Hallo Zabrimus,

    Adding the tcp option was a good thing, it's much more stable now! I'm now using yt-dlp and ffmpeg over tcp and removed VLC as 'transcoder'

    What's the advantage of using yt-dlp_linux instead of the python based version yt-dlp ?

    I saw below line starting yt-dlp in your scripts: yt-dlp_linux -t mp4 --audio-multistreams

    Can you tell why these two options are used (needed) ?

    Thanks

    Ah, lifetime on disk, now I get the picture

    One thing to consider: when I set "InstantRecordTime = 0", VDR will record just the episode (if available), which is a nice feature. But it would also lead to time-shift recordings ending at te end of the event and that's not intended.

    I'll have a look at the code, maybe I can make myself a patch to add a dedicated recording tiime just for time-shifts

    Können Sie mir bitte erklären, welchen Zweck der Parameter „PauseLifetime“ hat, der standardmäßig auf einen Tag eingestellt ist?

    Wenn ich eine Live-Sendung pausiere, wird zwar ein neuer Timer erstellt, aber nur mit der Standarddauer InstantRecordTime = 120. Wenn unsere Pause also zwei Stunden überschreitet, kehren wir zur Live-Sendung zurück, wo wir meiner Meinung nach einen Tag Pause einlegen sollten, oder?

    Vielen Dank im Voraus für Ihre Erklärung!

    PS: ohne Google translate ist mein Deutsch noch viel Schlimmer!

    I run with:

    -P"softhddevice -d :0 -v va-api-egl -a hw:0,3 -w alsa-driver-broken -w alsa-close-open-delay -w still-hw-decoder"

    I also tried va-api-glx, but this fails to show a picture together with flooding messages: video/glx: vaCopySurfaceGLX failed

    VDR Log: (with va-api-egl)

    Code
    libva info: VA-API version 1.23.0
    libva info: Trying to open /usr/lib/dri/iHD_drv_video.so
    libva info: Found init function __vaDriverInit_1_23
    libva info: va_openDriver() returns 0
    2040ms 0ms 2040ms
    ratio: 16:9 6080:3429
    ALSA lib pcm.c:8772:(snd_pcm_recover) underrun occurred

    syslog with debug enabled softhddevice:

    syslog.txt

    Thanks!

    Hello lnj

    I'm testing a new N100 board with "Intel Corporation Alder Lake-N" GPU

    I can run cable channels (1080i) fine, the problem is with live streams..

    Sound is there but there's either no video or a green screen. I'm seeing below in the logs + flooding of "video/vaapi: vaSyncSurface failed"

    setup:

    vdr-2.7.7 / ffmpeg: 7.2.1 / softhddevice: latest from git

    I made a recording: http://www.nekanali.nl:8020/VTM-green-screen.tgz

    Maybe fixing this is all too difficult, then I'll re-mount my Nvidia 1080 ;)

    Carel

    Unfortunately not completely yet:

    Hallo Jojo

    I'm trying to compile the plugin in DRM mode and get the errors below

    I have latest ffmpeg , libva and libdrm 2.4.127-1

    Is this something that can be fixed in the plugin?