Posts by Zuikkis

    Yes, it is. :)

    Do you have any other plugins isntalled from other PPAs (or selfcompiled), something which must not be named here? Maybe, they have to be removed before dist-upgrade, rebuild against new vdr-dev and then reinstalled.


    In my normal config I have several self-compiled plugins, but now I really tried a clean system with all plugins from the yavdr repositories..

    I even renamed my setup.conf so vdr would create a new one, and still the OSD-problem was there. But just disabling text2skin in plugins/order.conf fixed it, OSD came back..

    Now it seems to work fine with the GotoX patch too. :)

    GotoX is something that perhaps should be included in the yavdr distribution? It's very clean and can be completely disabled in setup menu. It allows very easy rotor configuration, you just give your exact longitude/latitude location, and GotoX calculates the directions where each satellite is. Much easier than Rotor or RotorNG plugins.

    The latest version of the patch (I think) is here:
    It seems to work fine even with vdr 2.0.2.

    Edit: Bah, forget this GotoX suggestion.. :) It seems GotoX is included in vdr 2.1.1 developer version, so it will be eventually included in yavdr as well. :)

    Ok, the problem was with vdr-plugin-text2skin. I tried disabling all the "skin" plugins, and the OSD was working although that wasn't a pleasant sight. :)

    It was not updated by dist-upgrade, I don't know why. "apt-get install vdr-plugin-text2skin" gave me a newer version.

    Still a bit mystery why it didn't work at all even if I chose another theme directly in setup.conf?

    I now tested with original packages directly from apt-get..

    I get no picture because GotoX patch is missing, but the OSD problem is still there. I can change channels and syslog shows that channels are changing, but there is nothing on OSD.

    Yeah, well.. :( Sounds too much work at this point.

    I don't like to compile everything myself, because then the plugins don't update automatically etc. The VDR main source updates so rarely that it's easy to manually keep track of the changes.

    Ah sorry, it was my mistake (I think)..

    I wasn't exactly accurate on my first post.

    Right after install, I had no picture at all, vdr couldn't tune any channels. But then I remembered that I had used gotox patch with 1.7.27, and installed that to 2.0.2 as well. After that it worked as I said..

    Now I see that gotox patch has installed new items in config.c, _before_ the OSD setup fields.. So I think all plugins etc should be recompiled. Instead I moved the GotoX fields now to the last place in config.c, so perhaps it would work without recompiling.

    We'll see.. :)

    I tried to remove all OSD-related settings from setup.conf, so that vdr could set them to defaults.

    Now it seems to use lcars-default.theme. Still no difference in OSD..

    A small update to the problem, when opening Femon OSD, I see some messages in the log:

    Oct 9 13:38:10 yavdr vdr: [3430] ERROR: cFemonOsd::cFemonOsd() OSD width (0) smaller than required (1334).
    Oct 9 13:38:10 yavdr vdr: [3430] ERROR: cFemonOsd::cFemonOsd() OSD height (0) smaller than required (260).


    Sorry for asking in English, this might have been covered already in some German threads..

    I updated my Yavdr box to VDR 2.0.2, directly with "apt-get dist-upgrade"

    It worked reasonably well. I get correct picture on all channels, and the remote control works so I can change channels.

    But there is no OSD! Nothing happens if I press "Menu", and also the new channel information is not shown when changing channels. However I see normal looking OSD-messages in syslog, which would suggest that vdr "thinks" OSD is showing.

    However, DVB subtitles show up correctly, so the OSD must be working somehow? Also, if I open femon plugin with "svdrpsend PLUG femon open", femon OSD does show up. However it is in wrong resolution, very tiny in the top left corner.

    I think it must be some theme problem? Is there something I should have changed in setup.conf while upgrading from 1.7.27 to 2.0.2?


    but I need pass-through for AC3.. My receiver can play AC3 and DTS 5.1.


    I have hdmi connection to separate hdmi splitter, and from there spdif to the receiver. The receiver only supports 2 channels pcm, as seen in the log:

    audio:  44100Hz supports 2 2 2 2 2 2 2 2 channels
    audio:  48000Hz supports 2 2 2 2 2 2 2 2 channels
    audio: 192000Hz supports 0 0 0 0 0 0 0 0 channels

    So, I can't play 5.1 AAC or PCM directly..

    It seems softhddevice is using the pass-through, when I switch to the channel I get this:
    "audio/alsa: using pass-through device 'default'"

    So is softhddevice passing the raw LATM stream, or is it decoded to PCM?


    Some of my channels have LATM AAC audio. Two-channel audio works fine with softhddevice. However some movies are played with 5.1 audio, still LATM AAC encoded!

    This also "works", softhddevice converts it to stereo and I can hear audio. However there is something wrong. Dialog (center channel) plays only on the left speaker. Music and effects play on both left and right, but they don't sound exactly correct either.. Perhaps the channels are picked wrong, centre->left and surround->right for example? It probably should mix them somehow, similar to ac3->stereo downmix.

    Also of course it would be nice if you could transcode to ac3, but a working stereo downmix would be a good start. :)

    I'll try to make a small recording that shows the problem..

    sorry for the English. :)

    Thanks for the great PIP feature! However, I already have some ideas. :) Sorry if these are already been brought up in german..

    1) Could you add more PIPs? :) I have 100" screen and four tuners, would be great to have 2*2 mosaic with four channels!

    2) Perhaps the sound of the PIP channel could be outputted to different alsa device, or even mixed to the main channel?

    I'm currently watching snooker while the kid is watching Teletubbies.. I have no sound, so we can hear Tinky Winky speak. :)

    Hmm! Something interesting has happened..

    As I said, I have two TBS6922 and one TBS6891 card. I have tried IR receiver on all three, with similar results.

    But now I try it, and TBS6922's have the bug and TBS6981 doesn't! It works nicely with eventlircd now, but only with TBS6981.. But that's enough, of course.

    But on my previous machine it worked fine with TBS6922 as well. And yesterday it didn't work with TBS6981, but now does. :)

    I better not touch anything now. :)


    sorry for the small delay, had other things to do. :)

    I'm really clueless what's happening! I stopped eventlircd, and run evtest. For some reason, VDR still receives keypresses! Where do they come from? Perhaps that's the problem, keypresses coming from both eventlircd and some other route?

    Here is the evtest result..

    Are both ir-receivers connected to your DVB-cards? This would irritate eventlircd because the expected key status signals get mixed up.

    No, only single one connected.

    I can connect the ir-receiver to any DVB-card, and the behaviour is the same.. Weird.

    Anyway.. I have this now pretty much working with remote plugin.. Of course it would be better to have it working as expected, but I can live with this solution. :)

    evtest always shows all the keypresses, if eventlircd is stopped.

    irw shows the same that's received by VDR; if the keypress is missed, it won't appear on irw either..

    Having vdr-fronted stopped or started makes no difference! Keys are missed..

    In the meantime, I now tried remote plugin and it seems to work, vdr works nicely and keys are not missed.. However vdr-frontend now floods the syslog complaining that it can't find eventlircd socket. :) Perhaps it should check the socket at start, and remove eventlircd monitoring if eventlircd is not running?

    I have TBS6922 and TBS6891 dvb-s2 cards, with built-in IR receivers.. They appear in /dev/input/ directory.

    This worked fine with my previous machine, directly with eventlircd without any configuring. But I changed the motherboard, and then the keypresses started disappearing. The software should be the same, I simply changed the old harddrive to the new machine.

    Hi, thanks for your quick support!

    Now, I can do "restart eventlircd" and vdr-frontend doesn't start 100% cpu. So it's "fixed", i guess!

    However, now the vdr remote always looses half of the keypresses. :) restart eventlircd doesn't fix it.

    I'm thinking about trying the remote plugin, it probably would work just fine for me because I don't need to use the remote in xbmc? Just vdr..


    most of the log seems to be quite uninteresting, but when I kill python I get this:

    /proc/self/fd/9: line 399: 3262 Terminated python - <<END

    line 399 is in eventlircd event handling.

    I recently posted about my eventlircd problems, but no one responded.. I guess this is related! eventlircd starts loosing remote keypresses when VDR is started or restarted. "restart eventlircd" fixes it.

    However, I now notice that after eventlircd is restarted, vdr-frontend cpu goes to 100%!

    So now I have a choice.. :)
    1) If eventlircd looses half of my keypresses, vdr-frontend works ok.
    2) If eventlircd works fine, vdr-frontend starts using 100% cpu.

    Any ideas?

    Hmm, you misunderstood me. :)

    I have Nvidia card, and softhddevice is working fine. I use this machine as my only TV..

    But vdr-frontend is using 100% cpu, that is not normal.