[vdr] Remote plugin with Hauppauge Nova-T usb2
Has anyone managed to get the built-in detector in a Hauppauge Nova-T usb2 working with vdr with the remote plugin? I'm just swapping a Nova-T PCI card for a dual-tuner Nova-T 500. So far, it looks like the DVB part is working (not tested properly yet but I have 3 DVB devices) but I'm now tring to get a working remote again. I had been using a "new type" Hauppauge remote on the old PCI card through LIRC (after patching the CX88 source for the keymap). I'm hoping that I can just use the /dev/input/eventX from the USB Nova device without fighting LIRC (the remote generates keypresses which makes using irrecord a nightmare!). The USB remote device appears as /dev/input/event1: I: Bus=0003 Vendor=2040 Product=9301 Version= N: Name="IR-receiver inside an USB DVB receiver" P: Phys=usb-:00:10.3-1/ir0 S: Sysfs=/class/input/input1 H: Handlers=kbd event1 B: EV=3 B: KEY=afc302 2002805 0 0 0 4 18000 180 4801 9e1680 0 800200 ffc And should be accessible by the vdr user: crw-rw-r-- 1 root video 13, 65 Oct 24 22:16 event1 evtest seems to work correctly, i.e. lists the keys and all keys seem to give the correct named codes. When I run vdr with the remote plugin, I get the following relevant bits: Oct 25 01:45:00 vdr-tng vdr: [11605] device /dev/input/event1: IR-receiver inside an USB DVB receiver Oct 25 01:45:00 vdr-tng vdr: [11605] remote: using '/dev/input/event1' Oct 25 01:45:00 vdr-tng vdr: [11605] remote control softdevice-dfb - keys known Oct 25 01:45:00 vdr-tng vdr: [11605] remote control remote-event1 - learning key At this point, I see the OSD message about learning keys and it asks me to press the "Up" key. At this point, nothing happens! Pressing keys on the remote has no effect and it gets no further. As far as I can see, it all looks good until it gets to the actual remote plugin! Am I missing something simple here, or am I wasting my time and should go back to trying to get LIRC working with this device?! Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] System reboots...
I've compiled vanilla vdr 1.4.3 on fresh Ubuntu installation. When I run vdr, systems goes to reboot without any information. What is the easiest way to figure out what is the reason of reboot? kernel 2.6.15 Nexus WinTV FF card Thanks! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] mini-PCI card suggestion
I'm building a remote VDR device on a Dell GX260 SFF PC, which has 1x AGP low-rise slot and 1x PCI I'm having trouble finding a selection of video cards which will fit in the SFF case. Can someone recommend a card? It needs to have s-video out (doesn't need to have VGA - but must have s-video/Component/RGB) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Diseqc setup ?
Thank you very much, I'll will try at home :) I have three quad lnb so it should be possible to use all cards on my system. I really hope this one will work :-) -- Grégoire FAVRE ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: Diseqc setup ?
Grégoire FAVRE wrote: Could someone help me to find the right 1.0 setup for A Astra 19.2E B Hotbird 13.0E C Astra 28.2E Something like this _might_ work for you. It works for me. Two DVB-S cards accessing the same LNBs and switches simultaneously will _not_ work without the LNB sharing patch. --- 8< --- # E0 command from master, no reply required, first transmission # 10 Any LNB, switch or SMATV #22 Position A #23 Option A #26 Position B #27 Option B # port 1 option a position a # port 2 option a position b # port 3 option b position a # port 4 option b position b S19.2E 11700 V 9750 t v W15 [E0 10 23] W15 [E0 10 22] W15 t S19.2E 9 V 10600 t v W15 [E0 10 23] W15 [E0 10 22] W15 T S19.2E 11700 H 9750 t V W15 [E0 10 23] W15 [E0 10 22] W15 t S19.2E 9 H 10600 t V W15 [E0 10 23] W15 [E0 10 22] W15 T S13.0E 11700 V 9750 t v W15 [E0 10 23] W15 [E0 10 26] W15 t S13.0E 9 V 10600 t v W15 [E0 10 23] W15 [E0 10 26] W15 T S13.0E 11700 H 9750 t V W15 [E0 10 23] W15 [E0 10 26] W15 t S13.0E 9 H 10600 t V W15 [E0 10 23] W15 [E0 10 26] W15 T S28.2E 11700 V 9750 t v W15 [E0 10 27] W15 [E0 10 22] W15 t S28.2E 9 V 10600 t v W15 [E0 10 27] W15 [E0 10 22] W15 T S28.2E 11700 H 9750 t V W15 [E0 10 27] W15 [E0 10 22] W15 t S28.2E 9 H 10600 t V W15 [E0 10 27] W15 [E0 10 22] W15 T --- 8< --- -sjm ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Any DST change problems?
We're coming up to the weekend when Daylight Saving Time ends in Europe. I seem to recall last time I tried this that there were problems with setting timers before the changeover to record programmes after it. Is this still an issue, and if so would restarting VDR after the change help? I see that timers.conf has the events in 'wallclock' time (when setting timers through vdradmin at least). -- Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: Diseqc setup ?
Hello, I have found that my DiSEqC is 1.0. Could someone help me to find the right 1.0 setup for A Astra 19.2E B Hotbird 13.0E C Astra 28.2E I don't know exactly what's to take from : http://www.vdr-wiki.de/wiki/index.php/DiSEqC http://www.vdr-wiki.de/wiki/index.php/Diseqc.conf Thank you very much, -- Grégoire FAVRE ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Hauppage wintv nova-t PCI?
Is it a "good" card to use with VDR? It's a USB via PCI-device, is this a good or a bad thing, does it matter at all? Thanks! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: > > On 24 Oct 2006, at 12:44, C.Y.M wrote: > >> Somehow, mplayer is able to detect the areas in the VDR recordings >> that need >> extra "padding" to keep the sync. There must be some kind of pattern >> in the >> data that the player recognizes and it knows it must insert a null >> frame. How >> to go about finding how it works and creating an algorithm. > > So you're certain that it's always picture frames being dropped, causing > audio to be behind the video? > >From what I understand, it could be either video or audio that is using "stacked" data. Either a video frame that does not "change" or perhaps a few seconds of silence on the audio track could trigger this. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo schrieb: On 24 Oct 2006, at 12:44, C.Y.M wrote: Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm. So you're certain that it's always picture frames being dropped, causing audio to be behind the video? Since mplayer is open source , someone who is able to do changes on that should contact someone at mplayer/xine. I think Nico Sabbi is working on dvb area on mplayer side. Further i think mplayer is checking very closely sync issues. For most stations the video stream should fulfil the task of the PCR stream, but here people that really know what they are talking about should step in ;) Furthermore mplayer-dvb list might be applicable. Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: On 24 Oct 2006, at 12:44, C.Y.M wrote: Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm. So you're certain that it's always picture frames being dropped, causing audio to be behind the video? Despite of the lost frame, the playback seems to be in sync. On the other side, I havent heard any jumps in sound yet. This could only be possible when the timing of audio and video would be different and the software would try to keep video and audio in sync by dropping sometimes a single video frames. On the other side, if the same recording works when playing back video with the MP2 track, it looks like a buffering or packaging issue, as if in this case the DD packages would not fit into a certain time scale. With kind regards Jörg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
On 24 Oct 2006, at 12:44, C.Y.M wrote: Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm. So you're certain that it's always picture frames being dropped, causing audio to be behind the video? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Joerg Knitter wrote: > Klaus Schmidinger wrote: >> C.Y.M wrote: >>> Since it has been several years now and I have never been able to >>> solve the a/v >>> desync issues with my Nexus-S FF card when playing back recordings... >> >> I'm replaying many recordings (actually most of what I watch >> are recordings ;-) and don't even remember when was the last >> time I had an A/V desync. > > There is one more issue, that seems to be related. On some recordings, > here RTL Television with AC3 playback, sometimes single frames seem to > be skipped during playback. I watched a recording of "Alarm für Cobra > 11" yesterday and could identify at least 6 little jumps. > > I have isolated a 20 MByte part of this recording where this effect was > clear to see - I can send it by seperated mails or upload it somewhere > if someone gives me an URL. > > The weird thing: Playing those isolated scenes does not show the effect > as people can see if they play the whole recording from the beginning, > but rewinding the short clip to a certain point makes it possible to > reproduce the problem. And again: This just happens when playing back > the AC3 audio track. > Somehow, mplayer is able to detect the areas in the VDR recordings that need extra "padding" to keep the sync. There must be some kind of pattern in the data that the player recognizes and it knows it must insert a null frame. How to go about finding how it works and creating an algorithm. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Klaus Schmidinger wrote: C.Y.M wrote: Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings... I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync. There is one more issue, that seems to be related. On some recordings, here RTL Television with AC3 playback, sometimes single frames seem to be skipped during playback. I watched a recording of "Alarm für Cobra 11" yesterday and could identify at least 6 little jumps. I have isolated a 20 MByte part of this recording where this effect was clear to see - I can send it by seperated mails or upload it somewhere if someone gives me an URL. The weird thing: Playing those isolated scenes does not show the effect as people can see if they play the whole recording from the beginning, but rewinding the short clip to a certain point makes it possible to reproduce the problem. And again: This just happens when playing back the AC3 audio track. With kind regards Jörg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] desperated with vdr-burn
Lot of thanks! I don't tested it yet, but when I go home I'll try it. Seems to be a definitive solution for the problem. Thanks again. Tobias Grimm wrote: Leo Márquez wrote: vdr-burn still fail for me. :-( Please forget my private mail. With a small hint from Sascha I found the problem. The usage of "$" in the format strings contained in the English texts lead to a truncation of the string, because VDR uses "$" to separate a context string from the English translation. That's why I didn't had this problem in German :-) A fixed Debian package (version 0.1.0~pre21-4) is available in my repository. Until it's fixed in the CVS, a patch can be downloaded here: http://vdr-developer.org/mantisbt/view.php?id=184 (90_i18n-fix.dpatch.gz) Tobias -- Leo Márquez [ Enginyeria del Software - Internet ] [ Calidae - www.calidae.com ] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
