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.
didn't change anything. Is there any other option to try?
When I change the OSD, eg toggling between now and next, the old content seems to remain but dimmed behind the new OSD, not sure if it's relevant.
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
Hi, I've been running with this patch now for a while and it works very well. Thank you!
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.
No, using vanilla yavdr without any custom stuff, only the common yavdr plugins. I will post to the vdr mailing list.
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?
Playback works well here now. Thx!
Maybe it's because the channel is 50Hz? All other channels here are 25Hz.
One HD channel here in Australia (ABC News 24, 720p 50Hz) have stuttering playback with softhddevice. It plays ok with vdr-sxfe and the xine-output plugin. I've recorded a sample, which can be downloaded here: https://dl.dropbox.com/u/6299520/test.zip (70mb, zipped).
Works now, just had to also do
dpkg -i nvidia-current_295.75-0yavdr0~precise_amd64.deb
Which I overlooked earlier in that thread. Thanks for your help!
It was a bit tricky to follow the instructions in that thread. I've done
Editing /usr/share/yavdr/events/actions/get-display-resolution replacing two lines.
sudo update-alternatives --remove-all x86_64-linux-gnu_gl_conf
But I assume there's a few more things to do?
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:
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
#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
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.