Posts by tmn505

Maybe the AI scrappers are the cause? There's a lot complain around the web about them. Any particular URL on gitweb that is accessed? On OpenWrt gitweb instance the most notorious load was on history and snapshot request.

Re: stable dvb numbers:

http://www.vdr-wiki.de/wiki/index.php/Diseqc.conf

"Fixierung der /dev/dvb/adapterI Nummern" paragraph.

Quote from jrie

Das Problem ist, dass softhddevice ohne DVB-Input kein OSD zeigt, so dass man keine Aufnahme starten kann.
Alle Tipps, die es hier gab, haben bei mir nichts geholfen (zum Testen braucht man nur eine leere channels.conf).
Die Lösung ist einfach: Mit svdrpsend eine Aufnahme starten, danach geht das OSD, und dann kann man Aufnahmen starten.
Dazu ruft in meiner commands.conf eine Fernbedienungstaste das Skript play.sh auf:
/Pfad/svdrpsend PLAY 1
Man kann auch gezielt eine Aufnahme 000du aufrufen:
NR=$(/Pfad/svdrpsend LSTR | grep 000du | awk '{print$1;}' | cut -b 5,6,7)
echo ${NR}
/Pfad/svdrpsend PLAY ${NR}

Ansonsten könnte man in softhddevice einbauen, ein Standbild bei fehlendem Signal abzuspielen, dann ginge das OSD auch so.

Edit: Ein Keymacro gehört auch noch dazu. Es ordnet einer Taste den Eintrag in der commands.conf zu.

Display More

This looks very similar to what suspendoutput plugin does.

I've had to replace PSU on a VDR system with N3150, so I could update its Arch Linux installation with newest Mesa 25.2.x where supposedly DRI2 drivers are no more. After update, HW decoding still works without issues. On AVC broadcast vdr CPU utilization is 32-42% while intel_gpu_top looks like this:

intel-gpu-top: Intel Cherryview (Gen8) @ /dev/dri/card0 -    0/ 282 MHz;  51% RC6;      512 irqs/s

         ENGINES     BUSY                                                                                MI_SEMA MI_WAIT
       Render/3D   33.72% |█████████████████████████▊                                                  |      0%      0%
         Blitter    0.00% |                                                                            |      0%      0%
           Video   13.86% |██████████▋                                                                 |      0%      0%
    VideoEnhance   44.45% |█████████████████████████████████▉                                          |      0%      0%

PID      MEM      RSS        Render/3D               Blitter                 Video              VideoEnhance       NAME 
514  269496K  266416K |██████▍              ||                     ||██▊                  ||█████████▎           | vdr  
475   36500K   35732K |                     ||                     ||                     ||                     | Xorg 

The only maybe influential setting in xorg.conf I'm using is:

Section "Extensions"
        Option "Composite" "Disable"
EndSection

Xorg log is in attachment.

Yeah, for AV1 i3-3220T is not enough.

But does it decode AV1? TBF I don't know any broadcasts in AV1, but maybe OP has sources which need that.

dvb91 If You don't need AV1 decoding maybe Your CPU is good enough for decoding AVC and HEVC?

Quote from theonlychriss

lnj Also thx from my side to look into this! For me the ultimate "proof" that softhddevice will not run correctly (and as well all other usually HW-accelerated programs) was the check via glxinfo | grep "renderer string". llvmpipe was chosen and mentioned then all the time for reasons I never found the root cause with more recent versions than 24.0.5-1ubuntu1 under kUbuntu of the packages mentioned above.

Presumably it's related to removal of DRI2 drivers from mesa (https://www.phoronix.com/news/Mesa-25.2-Drops-DRI2-Bonfire). Some time ago these drivers were moved to legacy config option (https://www.phoronix.com/news/Mesa-24.3-Legacy-X11-Option) maybe Ubuntu doesn't enable that?

That xlogin addition, as I described, is precisely for not starting X server manually or even logging user in, it handles everything for You (not much magic, everything in that project is plaintext, see for Yourself).

Today I've tested X11+softhddevice on i3-3220T with Debian 12, that's 3rd gen, any 3rd gen i3 or i5 intel is dirt cheap and should work with Your mainboard (check compatibility), worked like charm with AVC broadcasts. The -v switch of softhddevice was va-api-egl (plain one has given me "video/vaapi: vaPutSurface failed: unknown libva error", while glx "video/glx: vaCopySurfaceGLX failed", probably I missed some dev dependency). No stuttering or hiccups. But before buying anything check if changing to va-api-egl helps with Your CPU.

According to https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video Your CPU has hardware decoder for AVC, if that is what they broadcast, it should be fine. For it to work make sure to compile softhddevice with libva (VA-API), check https://wiki.debian.org/HardwareVideoAcceleration to familiarize Yourself what's needed (Arch Linux wiki also has good article about it). Just as reminder You'll probably need to set this "LIBVA_DRI3_DISABLE=1" as global variable for the decoding to work. As alternative to X11+softhddevice You could also try to use softhdcuvid's (https://github.com/jojo61/vdr-plugin-softhdcuvid) DRM plugin variant which doesn't use X11 at all, simply run with the plugin enabled and there should be image on TV (remember to shutdown X11 before).

I personally use X11+softhddevice as an output, since that's been most stable and performant on my systems. As I use Arch Linux as base, I'll describe the setup only briefly, since some details might differ.

There's this nice project called xlogin (https://github.com/joukewitteveen/xlogin), install it in Debian appropriate places, no need to start or enable its service. Download https://raw.githubusercontent.com/VDR4Arch/vdr4a…g/vdr-xorg.conf to /etc/systemd/system/vdr.service.d and that's it. Now each time You'll run vdr.service it'll pull xlogin as a dependency which will start X server to which softhddevice will be able to connect to. Remember to adjust -v option of the plugin, I use va-api-egl, You might find va-api to work better on Your hardware.

If You're talking about devices in Your footer, then I'm using the same ones, except DuoFlexS2, and they work flawless with 6.6 kernel without any additional drivers or patches.

Not yet. When introduced I didn't want to bother with additional library, but since it's packaged now I'll try it in few days.

From the ones failing I only use suspendoutput and sometime femon. These are not managed in vdr-projects and I'm not author of these patches. I'll carry them in my fork.

So we did overlap: https://github.com/tmn505/vdr4arch/commits/tmn505. Check the "vdr: bump version to 2.7.3" commit, I did import some patches from forum and seahawk1986, which resulted in only burn and dfatmo plugins not building.

Please tag the release.

AFAIK it's not maintained anymore, so looking around the forum is the the main course, see [ANNOUNCE] VDR Version 2.7.1 freigegeben.

seahawk1986 maintains Ubuntu ppa https://launchpad.net/~seahawk1986-hotmail and he's very prompt on the updates. You can find patches there for some of the unmaintained plugins.

It probably broke after this https://git.kernel.org/pub/scm/linux/…656c0b67e53cc80 which comes right after https://git.kernel.org/pub/scm/linux/…6d2b4e4cad703de. So revert 026ea897cb0731e29324536bae019512fa3dc13e and add "#include <linux/vmalloc.h>" to vtunerc_main.c. Compiles on my side, albeit with one warning:

/srv/local/tomek/vtuner-ng/kernel/vtunerc_proxyfe.c:38:6: warning: no previous prototype for ‘dvb_proxyfe_set_stat’ [-Wmissing-prototypes]
   38 | void dvb_proxyfe_set_stat(struct vtuner_dtv_fe_stats *vtuner_stats, struct dtv_fe_stats *dvb_stats)
      |      ^~~~~~~~~~~~~~~~~~~~

but should work nonetheless.

Quote from Joe_D

I have only one USB port

So You've got the newer version. I don't have any experience with that one. They probably removed first-boot from USB.

Please post output of "cat /proc/mtd" and upload copies of first two partitions (bootloader and its environment). Maybe I can figure out from strings what changes they made.

I tried it today on both devices I have and they booted initramfs by default from either of USB ports to which the drive was connected. Maybe U-Boot on Yours does not recognize USB drive or initramfs file, try different USB stick. Do You have the newer device version with one USB port? Best option to troubleshoot is connect to UART port and attach console to it to see all messages or interact with U-Boot.

For a quick test I uploaded my old initramfs image: https://www.mediafire.com/file/9ditdza0x…Boot_Image/file

MD5 sum of the file: 934cc093dc20f733db9763c217078728

To know if You booted from it, check available applications (double TAB), there should be minisatip and some others.

Quote from seahawk1986

Ich wollte das nachvollziehen, bin aber drüber gestolpert, dass das satip Binary noch kein DVBT(2) unterstützt: https://github.com/joed74/vtuner-…p_vtuner.c#L173 ff. - ist etwas überraschend, weil das Programm im Hilfetext anbietet die unterstützten Formate auf DVBT2 einzuschränken:

Code

May 16 10:34:00 [2996 satip_vtuner.c:230] debug: MSG_SET_PIDLIST:
May 16 10:34:00 [2996 satip_vtuner.c:233] debug: 0
May 16 10:34:00 [2996 satip_vtuner.c:233] debug: 16
May 16 10:34:00 [2996 satip_vtuner.c:233] debug: 17
May 16 10:34:00 [2996 satip_vtuner.c:233] debug: 18
May 16 10:34:00 [2996 satip_vtuner.c:233] debug: 19
May 16 10:34:00 [2996 satip_vtuner.c:233] debug: 20
May 16 10:34:21 [2996 satip_vtuner.c:175] debug: MSG_SET_FRONTEND
May 16 10:34:21 [2996 satip_vtuner.c:206] error: unsupported delsys 16

Found the same, some time ago when I tried it. I had to add small patch (in attachment) for DVB-T2(only) for it to work. Fortunately only msys and freq is needed for minisatip or SATPI to work, otherwise it would be impossible for me.

It doesn't, but would be nice to have such capability.