Beiträge von Zuikkis

    Hi!


    I have been having this weird random problem. VDR becomes very unresponsive and starts skipping frames etc, then when I use "top" I see that python process is using 100% of CPU..


    This seems to be the vdr-frontend. There is a python script in /etc/init/vdr-frontend.conf


    If I kill the python process, vdr-frontend dies but becomes back soon. The high cpu load is gone, but will come back later.


    This is yavdr 0.5.


    I'm tempted to remove the whole frontend, why is it needed? I'm not using xbmc and my VDR box is running 24h, it would probably work just fine with VDR just started directly.. Is vdr-frontend doing something useful?

    Hi,


    I recently updated my yavdr system to new motherboard, with more slots for tuners. The setup is otherwise exactly same, even the hard drive was just transferred to the new machine.


    A new problem appeared.. When vdr is (re)started, eventlircd start to loose keypresses. Perhaps only 25% of presses goes through to the vdr. They don't show in the "irw" either.


    "restart eventlircd" fixes it, so this is not a very big problem. But if VDR restarts for some reason like emergency exit or some random crash, eventlircd must be restarted for the remote to work properly.


    Does anyone know how to fix this? Or, can I add "restart eventlircd" to some script so it would be restarted every time VDR restarts?

    Ok, my motorized dish works now..


    I'm having some trouble with rotorng. I can control the dish nicely, but east and west are reversed! I'm sure the motor is installed properly, because it successfully finds many satellites. I understand this must be some sort of problem in the motor itself, because move east/west are direct diseqc commands? This is of course more a cosmetic problem, just caused a lot of disbelief when I moved "west" from S1W and suddenly found S13E Hotbird.. :)


    Then, transponder scan doesn't work. It does seem to scan, but doesn't find any channels, even if I do have correct frequency/sr/fec settings etc and STR/SNR2 is showing signal.


    If I quit VDR, I can run w_scan from the command line, and it successfully finds all channels and writes channels.conf for that satellite.. But not very flexible. :) Still possible though, and only needs to be done once for each satellite. W_scan is good in that it doesn't need any initial tuning data, so you can also use it to check which satellite you are tuned to if you are unsure.


    Also the "Sys: " selection doesn't work. It shows "Sys: DVB-S2" at start. If I press OK, it says "???". There is no way to make it back DVB-S2 after that. This might be related to the channel scan problem, perhaps the parameters are incorrect somehow?

    My rotor dish is not working yet, so this is still theory. :) But quick googling gives this:
    http://www.linuxtv.org/pipermail/vdr/2009-April/020238.html

    Code
    S19.2E 11700 V  9750  t W15 [E0 31 6B 01] W15 v t
    S19.2E 99999 V 10600  t W15 [E0 31 6B 01] W15 v T
    S19.2E 11700 H  9750  t W15 [E0 31 6B 01] W15 V t
    S19.2E 99999 H 10600  t W15 [E0 31 6B 01] W15 V T


    (the syntax is E0 header, 31 first rotor, 6B = gotostored position
    I assume "01" is the stored position number, same as numbers defined in rotorng.conf


    Just copy those four lines for each satellite you are using, with "01" changed to the position number.


    I think you can still use rotorng to fine tune the satellite positions and store them etc. Just have matching diseqc.conf and rotorng.conf..

    VDR has no manual option to move the dish. Only switch by channel with a complex diseqc.conf syntax. I really love the easyness of rotorng.
    I still havent had time to check whats wrong with my installation.


    Greetings,
    MrNike

    diseqc.conf is really not all that complicated, once you figure out the initital command it's just copy/paste..


    diseqc.conf also allows you to configure which satellites are available on which frontends! I think this is lacking in rotorng? I will need this, I have one fixed dish to 1W and other bigger dish with rotor..

    Hi,


    just a quick note. :) I installed rotorng 0.3 with yavdr 0.5. I installed the patch from this thread.


    First I was wondering why RotorNG segfaulted when it was trying to send diseqc commands. Just a click on "Goto nn" or "Move left/right" was enough, instant segfault.


    But then I realized that I haven't copied rotorng.conf in place.. I copied the file, and it now seems to work. :)


    However, I'm thinking, is rotorng really needed after you have stored all the positions? VDR diseqc.conf can run the motor.. But VDR has no internal mechanism to store the positions.

    Ok, now it happened again.


    I think it is somehow related to my PCI audio card, perhaps it's simply broken or bad drivers? I now ordered a HDMI switcher with SPDIF output, so I can use audio out though HDMI and discard this PCI card.


    In the log you see that audio is stopped and started again for some reason? I can also hear a small "cut" in the sound at the same time when the video is corrupted.


    Jan 30 12:35:16 yavdr vdr: audio/alsa: wait underrun error? 'Broken pipe'
    Jan 30 12:35:17 yavdr vdr: [softhddev] empty video packet 142 bytes
    Jan 30 12:35:17 yavdr vdr: audio/alsa: writei underrun error? 'Broken pipe'
    Jan 30 12:35:17 yavdr vdr: audio/alsa: stopping play 'PREPARED'
    Jan 30 12:35:17 yavdr vdr: audio: wait on start condition
    Jan 30 12:35:17 yavdr vdr: audio: start? 32ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 64ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 96ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 128ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 160ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 192ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 224ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 256ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: video/vdpau: 19:33:54.611: decoder render too slow 142ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 288ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: start? 320ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: video/vdpau: 1359531738506809 display time 100000
    Jan 30 12:35:17 yavdr vdr: video: speed up video, droping frame
    Jan 30 12:35:17 yavdr vdr: video/vdpau: missed frame (4/16174)
    Jan 30 12:35:17 yavdr vdr: audio: start? 352ms skip 0ms
    Jan 30 12:35:17 yavdr vdr: audio: ----> 352ms start
    Jan 30 12:35:17 yavdr vdr: video: slow down video, duping frame
    Jan 30 12:35:17 yavdr vdr: video: 19:33:54.591 +160 381 0/\ms 62+7 v-buf

    I built it with -DDEBUG two days ago, obviously it now has worked without problems after that. :) So no news..


    The problem was present with DVB-S and DVB-T tuners, and also while watching recordings.


    I don't think it's temperature. I have the machine running 24h, "nvidia-smi -a" shows GPU core temperature of 31C..

    I have tried changing the interlacing and scale settings, no change. Also as I said, there is no difference if I watch HD or SD channels, both have the problem.


    And also, sometimes it can work many hours without a single glitch. I sometimes change some setting and think that the problem is gone, until it starts again the next day..


    If I make a recording while it is bugging, I can later watch the recording without any problem.. there's probably no point to send any recordings to you, I'm sure it will play without glitches.

    I am having random problems with softhddevice. There are random glitches in the image, looks exactly the same as with invalid mpeg stream.. Mosaic, picture "breaking apart" etc. The picture is usually fine for several minutes, then bugs for a few seconds, and then again fine for several minutes. Sometimes it works nicely for the whole evening, sometimes bugs so often than it's nearly unwatchable.


    I first thought I have bad reception, but this is not the case. If I hit "record" while corrupted video is on screen, I can watch the program later without corruption, or at least the errors move the different place. So it must be softhddevice problem?


    It makes no difference if it's HD or SD channel. Also channel makes no difference, same on every channel from Thor 1W..


    I think it is some sort of AV sync problem perhaps? I have a separate PCI audio card which I use for SPDIF output. I guess most users are using hdmi audio? Perhaps there is too much clock difference between video/audio because I have them on separate cards?


    When the picture is fine, I get almost no AV messages in syslog.. But the video problem is showing, I get a lot of messages like this:


    Jan 24 12:35:58 yavdr vdr: video: speed up video, droping frame
    Jan 24 12:35:58 yavdr vdr: video: slow down video, duping frame
    Jan 24 12:35:58 yavdr vdr: video: 17:52:46.371 +330 340 0/\ms 37+8 v-buf
    Jan 24 12:35:59 yavdr vdr: video: slow down video, duping frame
    Jan 24 12:35:59 yavdr vdr: video: speed up video, droping frame
    Jan 24 12:35:59 yavdr vdr: video: 17:52:46.851 -65 296 0/\ms 52+6 v-buf
    Jan 24 12:35:59 yavdr vdr: video: speed up video, droping frame
    Jan 24 12:35:59 yavdr vdr: video: slow down video, duping frame
    Jan 24 12:35:59 yavdr vdr: video: 17:52:47.031 +58 336 0/\ms 52+7 v-buf
    Jan 24 12:36:02 yavdr vdr: video: slow down video, duping frame
    Jan 24 12:36:02 yavdr vdr: video: speed up video, droping frame
    Jan 24 12:36:02 yavdr vdr: video: 17:52:49.931 -30 195 0/\ms 47+6 v-buf
    Jan 24 12:36:05 yavdr vdr: video: speed up video, droping frame
    Jan 24 12:36:05 yavdr vdr: video: slow down video, duping frame
    Jan 24 12:36:05 yavdr vdr: video: 17:52:53.891 +64 139 0/\ms 39+8 v-buf
    Jan 24 12:36:06 yavdr vdr: audio/alsa: wait underrun error? 'Broken pipe'
    Jan 24 12:36:07 yavdr vdr: video: slow down video, duping frame
    Jan 24 12:36:07 yavdr vdr: video: speed up video, droping frame
    Jan 24 12:36:07 yavdr vdr: video: 17:52:55.791 -17 269 0/\ms 44+5 v-buf
    Jan 24 12:36:08 yavdr vdr: video: slow down video, duping frame
    Jan 24 12:36:08 yavdr vdr: video: 17:52:56.051 +82 269 0/\ms 45+8 v-buf



    Looks suspicious, what's the point to do duping frame and then droping frame right after, during the same second? The AV sync code must somehow "oscillate" so it corrects too much and then has to fix again?


    I'm using yavdr 0.5.0, and the latest softhddevice that comes from apt-get.. Geforce GT210 graphics card.

    Hey, thanks for the hint!


    I actually have three Alsa cards. The on-board audio, geforce output, and separate pci card. I'm using the pci card for digital output. Geforce is connected to video projector which has no audio..


    It was one of last steps in my installation to add this pci card. I got it working fine, but it's possible I didn't reboot afterwards, until this last boot which broke everything. :)


    I used -a option with softhddevice, to set alsa device.


    I'm not at home so can't test it now, but this sounds like "solved" already..

    :modon Deleted text part, please note terms of use :modoff


    I noticed another symptom! If I change settings from the www settings and click "save", it will wait a while and report an error. Syslog shows that vdr does not restart. So some thread of vdr is probably stuck? It still serves VDR Live and streamdev quickly.

    Hi!


    First of all, thanks for the great product! I have been a VDR user for five years, with many vdr systems. Yavdr was very easy to setup compared to my previous boxes!


    I have the 0.5.0 stable from the web page. I had to compile my own driver for my tbs6922 dvb-s2 card, but even that went quite well. :modon Deleted text part, please note terms of use :modoff


    Then I rebooted the perfectly working system.. It doesn't work anymore. :( It boots normally with Yavdr logo on screen, but then displays just a black screen with mouse pointer at the center.


    however, VDR is alive and working. The www interface works fine, and I can even watch live video with streamdev!


    I have nvidia geforce 210, the gpu-accelerated softhddevice worked fine before the reboot. I can change it to other setting like xinelib, and it makes no difference.


    syslog shows no errors, exactly the same messages when it was working.