Posts by iampivot

    I have seen all the new fancy ones with pip etc, but they are simply too demanding on my ion2 atom 525 board, so it takes about half a second to get the osd up. I guess I should have qualified my statement as 'visually one of the best, yet efficient...".

    Hi, thanks for putting me on the right path. It was me using an old unsupported OSD plugin called pearlHD. It seems like it uses custom calculations for drawing which doesn't work with the latest VDR. Switching to EnigmaNG or others seems to work.


    Too bad there's no current version of pearlHD, it's visually one of the best OSD implementations.

    Since around october this year, my yavdr ansible installation (which I regularily update with apt dist-upgrade), has an OSD display that is cut on the right side. I'm wondering if this can be a software issue, or indicates a hardware problem? I'm running on an nvidia ion2 motherboard (ASUS AT5IONT-I Atom D525).


    Screenshot here; https://snipboard.io/81T3qY.jpg

    Yes, shorttext is what I mean, I didn't know the correct terminology.


    Shouldn't this be considered a bug in the skins, if they truncate the text? I assume longer shorttext is allowed in the dvb standard?


    LCARS shows it correctly, but my god that skin is painful on the eyes. Sorry to any trekkies out there..


    Ok, will try skindesigner skins.


    It's so hard to find a nice skin, my favourite has been pearlHD, but it's a text2skin with its issues, so am looking for something similar, but all the skindesigner skins (at least those that can be automatically installed from within) doesn't look quite as good.

    I'm looking for a skin that shows the entire leadtext when viewing program information.


    In the attached screenshot, the lead text in the program information is truncated instead of word-wrapped. The main program information text is correctly wrapped, but here in Australia, most program descriptions have only lead text.


    Am unsure if this is possible to fix in a skin, as it seems all the skins I've tried (am running yavdr 0.6.1) seems to have this problem.


    The July update with VDR version 2.0.6 resulted in EPG not being fetched at all in my setup. I am running with DVB-T in Australia.


    I tried reverting back the changes to the files device.c, nit.c, nit.h, pat.c, pat.h, remux.c, remux.h, sdt.c and sdt.h by reverse patching the 2.0.5-2.0.6 diff (for those files only) and got EPG working again.



    Am wondering if there could be any YAVDR specific changes that might have an impact here, or if anyone else is having EPG issues with VDR 2.0.6?

    Am getting repeated such messages in my syslog, and the X server seems not to start up properly;


    [ 111.604745] NVRM: GPU at 0000:03:00: GPU-7137dfab-57d7-b8f7-a5d9-4de8170f414f


    [ 124.224625] init: openbox main process (2164) terminated with status 1
    [ 124.224717] init: openbox main process ended, respawning
    [ 124.247385] init: plymouth-stop pre-start process (2174) terminated with status 1
    [ 126.662377] NVRM: GPU at 0000:03:00: GPU-7137dfab-57d7-b8f7-a5d9-4de8170f414f


    All I did was run apt-get dist-upgrade a few days ago. I've seen something about a problem with the nvidia driver and to hold off updates for 24 hours, but that period seems to have passed now?


    Is there a manual workaround to get it up and running again?

    This happens with the PearlHD(Native) skin. If I use the default VDR skin, there's not crash.
    Here's a backtrace with gdb;



    root@htpc:~# gdb vdr-dbg /var/log/vdr/core.13280
    GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
    Copyright (C) 2012 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-linux-gnu".
    For bug reporting instructions, please see:
    <http://bugs.launchpad.net/gdb-linaro/>...
    Reading symbols from /usr/bin/vdr-dbg...done.
    [New LWP 13280]
    ...
    [New LWP 13358]



    warning: Can't read pathname for load map: Input/output error.
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    Core was generated by `/usr/bin/vdr-dbg --lirc=/var/run/lirc/lircd -v /srv/vdr/video.00 -c /var/lib/vd'.
    Program terminated with signal 6, Aborted.
    #0 0x00007f8f14ac6445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
    (gdb) ba
    #0 0x00007f8f14ac6445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
    #1 0x00007f8f14ac9bab in abort () from /lib/x86_64-linux-gnu/libc.so.6
    #2 0x00007f8f14b03e2e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
    #3 0x00007f8f14b99007 in __fortify_fail () from /lib/x86_64-linux-gnu/libc.so.6
    #4 0x00007f8f14b97f00 in __chk_fail () from /lib/x86_64-linux-gnu/libc.so.6
    #5 0x00000000004a7722 in cReplayControl::ShowProgress (this=0x2c3cad0, Initial=<optimised out>) at menu.c:5197
    #6 0x00000000004a78bd in cReplayControl::ShowTimed (this=0x2c3cad0, Seconds=2) at menu.c:5117
    #7 0x00000000004a7d8c in cReplayControl::MarkToggle (this=0x2c3cad0) at menu.c:5311
    #8 0x00000000004a8463 in cReplayControl::ProcessKey (this=0x2c3cad0, Key=k0) at menu.c:5517
    #9 0x00007f8f0df7cc4b in myReplayControl::ProcessKey(eKeys) () from /usr/lib/vdr/plugins/libvdr-extrecmenu.so.1.7.27
    #10 0x00000000004604ed in main (argc=<optimised out>, argv=<optimised out>) at vdr.c:1130
    (gdb)

    This problem seems to only occur on the first logically DVB card installed. If I switch to using a frontend of the second card with the femon plugin (eg. the second playtv USB tuner), I have no such problems. If I swap the USB plugs around, the problem stays with the first logically assigned card.


    Am wondering if this can be an anomaly related to the dynamite patch/plugin?

    Sorry for replying in English.


    If you use the xine plugin (not the xinelibout / sxfe plugin), do you see in your logs;


    vdr: [xxx] TS continuity error (yy)



    Do you ever see any pixelisation / breakup of the picture a fraction of a second after the freeze? Am asking since you might in that case see something similar to what I'm experincing; weird stuttering ('ruckeln') every 21 seconds


    I only see this on the first physical card attached (single or dual frontend), not on the second. If I switch the cards (swap USB plugs), the problem doesn't follow the card, it's always on the cards that is logically the first card attached.