Re: [vdr] scan-s2 and dvb-apps
scan-s2 was an evolution based on scan code. I've added support for S2 API, some patches from other contributors, added some switches that were requested by users and fixed some bugs. The core wasn't changed too much. I don't know how scan looks today, but if it wasn't totally rewritten, I don't think it should be too complicate to merge between the 2 and have only 1 application. On Tue, Feb 23, 2010 at 3:31 PM, Manu Abraham abraham.m...@gmail.comwrote: Hi Abbe, On Tue, Feb 23, 2010 at 4:30 PM, abbe normal 1abenor...@gmail.com wrote: hi manu why would there have to be 2 scan packages couldnt there be one that does the same for both types of devices... i would think dvb scan should be able to do anything dvb not just s2 or s or is it asking to much from it... abbe scan does scan of dvb channels as you are aware of. scan-s2 original commit seems to be a derivative of scan, though it is not incremental nor based on patches, but a dump of files instead. This is the part that gave me headaches on how to get scan-s2 merged into scan. I can't simply replace scan with scan-s2, because scan is even better maintained. The other case would be that both scan and scan-s2 would coexist, being the last thing that I would do. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] mini-PCIE with Broadcom Crystal HD Hardware Decoder (BCM970012) for HD playback with free drivers
As far as I understand Intel presented their new chips on CES show called Arrandale and Clarkdale. Both has integrated graphics accelerator and other things. Those will be based on i7, i5 and i3 cores. In addition to Atom based pineview chips that also include graphics accelerator. So now we have new options in case Atom will not provide enough juice. Lets hope they will also release Linux drivers for those chips. On Tue, Jan 5, 2010 at 9:53 PM, Tony Houghton h...@realh.co.uk wrote: On Tue, 05 Jan 2010 18:32:03 + Gavin Hamill g...@acentral.co.uk wrote: The Crystal HD decoder will doubtless appear in netbooks very soon, and I fully expect thin Intel Atom PCs to also feature it on-board. When those boards/machines appear, we will be on the way to a *reliable* open source STB which supports modern HD codecs + playback. Is it intended for the netbook market then? I didn't realise that. Hopefully Intel will realise that VGA is obsolete (and that they need to stop using inefficient chipsets with cheap noisy coolers) otherwise Ion will still be the only viable option for an Atom HTPC, making Crystal HD theoretically redundant. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mdadm software raid5 arrays?
Simon, Pay attention that /boot can be installed only on a single disk or RAID-1 where every disk can actually work as a stand alone disk. I personally decided to use RAID-5 on 3 disks with RAID-1 on 3xsmall partitions for /boot and RAID-5 on the rest. RAID-5 also allows easier expansion in the future. On Tue, Nov 10, 2009 at 8:48 PM, Simon Baxter linu...@nzbaxters.com wrote: Thanks - very useful! So what I'll probably do is as follows... * My system has 4x SATA ports on the motherboard, to which I'll connect my 4x 1.5TB drives. * Currently 1 drive is in use with ~30G for / /boot and swap and ~1.4TB for /media * I'll create /dev/md2, using mdadm, in RAID1 across 2 ~1.4TB partitions on 2 drives * move all active recordings (~400G) to /dev/md2 * split /dev/md2 and create a raid 1+0 (/dev/md1) using 4x partitions of ~1.4TB across 4 drives At this point I have preserved all my data, and created a raid1+0 for recordings and media. I should now use the remaining ~100G on each drive for raid protection for (root) / and /boot. I've read lots on the web on this, but what's your recommendation? RAID1 mirror across 2 of the disks for / (/dev/md0) and install grub (/boot) on both so either will boot? On Tue, Nov 10, 2009 at 09:46:52PM +1300, Simon Baxter wrote: What about a simple raid 1 mirror set? Ok.. short comparison, using a single disk as baseline. using 2 disks raid0: (striping) ++ double read throughput, ++ double write throughput, -- half the reliability (read: only use with good backup!) raid1: (mirroring) ++ double read throughput. osame write throughput ++ double the reliability using 3 disks: raid0: striping +++ tripple read performance +++ tripple write performance --- third of reliability raid1: mirroring +++ tripple read performance osame write throughput +++ tripple reliability raid5: (distributed parity) +++ tripple read performance -lower write performance (not due to the second write but due to the necessary reads) +sustains failure of any one drive in the set using 4 disks: raid1+0: four times the read performance ++ double write performance ++ double reliability please note: these are approximations and depending on your hardware they may be off by quite a bit. cheers -henrik ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] mdadm software raid5 arrays?
In general good experience. I don't record much, so I don't worry about speed. There are many web pages about raid5 speed optimizations. The slowdown in raid5 writes mostly happen when a part of a strip (chunk of data) has to be written, so the driver has to read the strip, and write it back. The optimizations talk about alignment of file system block size with raid strip size. Since we're talking about movie recordings (huge files), then big file system blocks will not create much waste. Smaller strip size will probably reduce the read performance a bit, but will increase write speed since there will be less cases where not the whole strip has to be updated. In one sentence, you won't know if it's slow until you'll try :) RAID 10 will obviously give better write speed, but I'm not yet convinced that raid 5 can't handle 4 recordings at the same time. If we're talking about HD recording, it's about 3Gigs/hour, meaning less than MByte per second. Don't think there should be a problem to write 3-4 MByte/sec without any raid. By the way, I had a very bad experience with LVM on top of raid in latest distros, so if you want to save some hairs on your head, don't try it :) On Fri, Nov 13, 2009 at 1:06 AM, Simon Baxter linu...@nzbaxters.com wrote: Thanks Alex. I think I've decided to go RAID 1+0 rather than RAID 5 as I'm worried about the write speed. I often record 3 or 4 channels at once and do see some slow down on OSD responsiveness during this. What's your experience with RAID5? - Original Message - From: Alex Betis To: VDR Mailing List Sent: Friday, November 13, 2009 1:03 AM Subject: Re: [vdr] mdadm software raid5 arrays? Simon, Pay attention that /boot can be installed only on a single disk or RAID-1 where every disk can actually work as a stand alone disk. I personally decided to use RAID-5 on 3 disks with RAID-1 on 3xsmall partitions for /boot and RAID-5 on the rest. RAID-5 also allows easier expansion in the future. On Tue, Nov 10, 2009 at 8:48 PM, Simon Baxter linu...@nzbaxters.com wrote: Thanks - very useful! So what I'll probably do is as follows... * My system has 4x SATA ports on the motherboard, to which I'll connect my 4x 1.5TB drives. * Currently 1 drive is in use with ~30G for / /boot and swap and ~1.4TB for /media * I'll create /dev/md2, using mdadm, in RAID1 across 2 ~1.4TB partitions on 2 drives * move all active recordings (~400G) to /dev/md2 * split /dev/md2 and create a raid 1+0 (/dev/md1) using 4x partitions of ~1.4TB across 4 drives At this point I have preserved all my data, and created a raid1+0 for recordings and media. I should now use the remaining ~100G on each drive for raid protection for (root) / and /boot. I've read lots on the web on this, but what's your recommendation? RAID1 mirror across 2 of the disks for / (/dev/md0) and install grub (/boot) on both so either will boot? On Tue, Nov 10, 2009 at 09:46:52PM +1300, Simon Baxter wrote: What about a simple raid 1 mirror set? Ok.. short comparison, using a single disk as baseline. using 2 disks raid0: (striping) ++ double read throughput, ++ double write throughput, -- half the reliability (read: only use with good backup!) raid1: (mirroring) ++ double read throughput. osame write throughput ++ double the reliability using 3 disks: raid0: striping +++ tripple read performance +++ tripple write performance --- third of reliability raid1: mirroring +++ tripple read performance osame write throughput +++ tripple reliability raid5: (distributed parity) +++ tripple read performance -lower write performance (not due to the second write but due to the necessary reads) +sustains failure of any one drive in the set using 4 disks: raid1+0: four times the read performance ++ double write performance ++ double reliability please note: these are approximations and depending on your hardware they may be off by quite a bit. cheers -henrik ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Looking for new maintainer of scan-s2 application
Hello all, I'm leaving the DVB-S world for now due to low available content in my area. Hence I will not be able to maintain anything related. Any one is willing to take the ownership of scan-s2 application? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Analog inputs configuration
Hello all, Unfortunately I'll have to abandon my race to DVB-S(2) transmissions since there is not much valuable content in my area (and not planned as well). I think how to continue the project with analog capturing cards connected to my cable settop boxes controller by IR blasters. Since my cable provider HD content is not planned for more than 1080i, component capture card might be enough for that. I'm thinking about a server - multi-client configuration while the server will be connected to few settop boxes and stream the content to the clients in real-time. Anyone have experience with such installation? Is VDR capable of doing that? Not a politically-correct question: maybe there are other programs that are capable of doing that? (I preffer not to use MythTv, I don't like it, maybe XBMC?) What capturing cards you'd advice? Are those capturing cards well supported in Linux? PCI-e cards are supported? How's the quality of the recordings and real-time streaming? Will really appreciate any answer. Thanks. Alex. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Need help - trying to run xinelibout with 1.7.9
Hi all, I'm trying to recover my VDR machine after upgrade to Fedora11 (long sad story). On the way, I've decided to give a try to VDPAU, installed nVidia 185.18.36, xinelib 1.2-vdpau. Compiled all needed plugins and now struggle with xinelibout to get the output. Using 1.7.0 with xinelibout 1.0.4 I get TS discontinuity errors on some channels I watch (no output when it happens). Using 1.7.9 with xinelibout 1.0.4 I get TCP buffer too small errors with astronomic lengths. Found on some german sites to try latest CVS version since there were some buffers changes. Using 1.7.9 with CVS xinelibout version I get ERROR (xine_input_vdr.c,860): Resource temporarily unavailable I've used the xinelibout with xv output for now. What am I doing wrong? Anyone faced with such problems? Thanks. Alex. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fast compact distro for vdr
On Fri, Aug 28, 2009 at 9:51 PM, Damien Bally bir...@free.fr wrote: gimli a écrit : A start point : http://sourceforge.net/apps/trac/archvdr/ Sounds good. Is it superior to slackware in term of boot time compared to slackware (which I'm using) ? I'd like a system booting in a few seconds. Regarding the boot time, I never shut down the VDR box, instead I suspend it. Its possible to wake up with a remote. Takes about 5-7 seconds to boot. I believe that time can be shortened even more. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Digital encoding in first(top) video row
Hello all, I have few DVB-S channels with first (top) row of the video shown on the screen as a set of black and while pixels that definitely represent a digital information. I clearly see some counters running there. The same channel broadcasting by local cable provider don't have that line shown. Do you think they intentionally hide that row? Or there is a problem with MPEG decoding for those channels in VDR? Is there any way to auto detect and hide that row? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] epgsearch as default EPG browser/guide?
Hello all, Is there a way to configure VDR show the epgsearch plugin as default guide? Currently I can access the plugin by pressing green button or from the menu. I'd like it to replace the default EPG browser when pressing guide button and another place (less important for me) when pressing info button and than back button. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] epgsearch as default EPG browser/guide?
Thanks to all. Will try that this weekend. On Wed, May 27, 2009 at 10:58 PM, Johannes Lautner hans.newslet...@haelwe.de wrote: Alex Betis schrieb: Hello all, Is there a way to configure VDR show the epgsearch plugin as default guide? Check the patches folder in the source-folder of epgsearch File README.patches (Ver 0.9.24): -- Description of patches -- - MainMenuHooks-v1_0.patch: patches vdr to allow plugins to replace main menu items like 'Schedule', 'Recordings',... Use this one, if epgsearch shall replace the schedules menu. This patch is also used by other plugins like the extrec-plugin. Regards Hans ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [OT] NVidia ION mini-ITX arriving
On Tue, May 12, 2009 at 1:53 PM, Nicolas Huillard nico...@huillard.netwrote: http://www.mini-itx.com/2009/05/04/zotac-ion-itx-atom-mini-itx-board-unboxing-and-salivating ...which means 1080p HD playback from an embedded Mini-ITX board with a fanless 1.6GHz processor whilst consuming 21W. The ION-ITX-A has its own DC converter onboard, and is supplied with a 90W AC Adapter. Fanless?! All the pictures there clearly show the CPU fan. Ofcause it will be a lot better than other solutions we have today. Nice silent drop-in replacement for any mini-ITX / micro-ATX mobo. -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2 little bugs report
On Tue, May 5, 2009 at 7:55 PM, Peter Evertz l...@pec.homeip.net wrote: I am 44 years old and it happens to me too :) A press pause again for stopping live-view is a good idea. It happens often after watching a recording. If I accidential stopped the replay, and press pause then. Or the recording was at its end and i press pause. Navigating the menus an hitting yellow on the wrong place. Then always: stop replay stop recoding find the recorded garbage and delete it. And putting away the remote is not the best solution for me :) Same issue here with my 2 year old kid. But I think he presses the big red glowing button on MCE remote :) Confirmation will be a good idea, but not by pressing the pause button twice. I think it could be a good idea to implement multiple-button commands and allow configuration for every command. By default it could be set to once pressed pause button, others might set it to pause+ok. This will solve some more problems I can think of, such as remotes with few buttons, so sequences will allow them to use much more VDR commands. Maybe there is a need for a single point of remote control processing where that multi-button feature will be implemented, so all other plugins could use it somehow. VDR User schrieb: On Mon, May 4, 2009 at 1:00 AM, Gerald Dachs v...@dachsweb.de wrote: Quoting marti...@embl.de: Also one little thing that is driving me crazy. My 3 years old daughter presses accidentally the Pause button and starts al l sort of instant recordings silenty, my wife then complains vdr is broken because she can´t change channels. What I am asking for is for some possibility to make the instant recording ask for confirmation before starting the instant recording. My 1.5 years old son and my 3 years old daughter would do the same, but I have found an easy workaround. I put the remote control out of their reach. Yes, I agree that is the best solution. As would any sane person. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 2 little bugs report
On Wed, May 6, 2009 at 5:34 PM, VDR User user@gmail.com wrote: On Wed, May 6, 2009 at 6:07 AM, Alex Betis alex.be...@gmail.com wrote: Same issue here with my 2 year old kid. But I think he presses the big red glowing button on MCE remote :) Confirmation will be a good idea, but not by pressing the pause button twice. I think it could be a good idea to implement multiple-button commands and allow configuration for every command. By default it could be set to once pressed pause button, others might set it to pause+ok. This will solve some more problems I can think of, such as remotes with few buttons, so sequences will allow them to use much more VDR commands. Maybe there is a need for a single point of remote control processing where that multi-button feature will be implemented, so all other plugins could use it somehow. This sounds like a lot more work then simply getting a remote that better suits your needs. For the record, I also have accidentally started an instant-recording but after years of using VDR, I've only done it a few times and it was no problem to just delete go delete it. I also have intentionally started an instant-recording and am glad I didn't have to confirm it. Call me crazy but problems like 'my kid starts recordings' and 'my remote doesnt have enough buttons' seem like issues easily solved by the user, not VDR. And yes, I'm a parent too. I guess Klaus will decide is addressing those is appropriate for the VDR core but if so, I sure hope the new osd implementation comes first! :] I vote with my 2 hands for OSD priority as well. Having a remote with less buttons might be done in intention to have smaller and sexier devices in your living room. MCE is not a nice thing to look at :) Cheers, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelibout --hud + xcompmgr = tearing
2009/3/18 Jörn Reder jo...@zyn.de Alex Betis wrote: I gave the nice xinelibout hud another try, but have to revert back since running composite manager creates tearing while watching movies. I've tries with xcompmgr with -n option. Does anybody know how to fix that? Or maybe there is another lightweight composite manager available? Without xcompmgr running there is no tearing at all. This is a known limitation of (at least) the NVidia drivers. Quoting the NVidia README: --snip-- The Composite extension also causes problems with other driver components: [...] On X.Org 7.1 and higher, the driver will properly redirect video into offscreen pixmaps. Note that the Xv adaptors will ignore the sync-to-vblank option when drawing into a redirected window. --snip-- Regards, Jörn Jörn, You didn't reply to my last posts. Following is my system X version, I can't find anything similar to version 7.1 mentioned in your quote, do you know what component version they reffer? X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-128.1.1.el5 i686 Current Operating System: Linux htpc 2.6.27.19-170.2.35.fc10.i686 #1 SMP Mon Feb 23 13:21:22 EST 2009 i686 Build Date: 10 March 2009 07:20:48PM Build ID: xorg-x11-server 1.5.3-15.fc10 Thanks. -- Joern Reder - http://www.exit1.org/ - http://search.cpan.org/~jred/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelibout --hud + xcompmgr = tearing
On Thu, Mar 19, 2009 at 9:27 PM, Alex Betis alex.be...@gmail.com wrote: 2009/3/18 Jörn Reder jo...@zyn.de Alex Betis wrote: I gave the nice xinelibout hud another try, but have to revert back since running composite manager creates tearing while watching movies. I've tries with xcompmgr with -n option. Does anybody know how to fix that? Or maybe there is another lightweight composite manager available? Without xcompmgr running there is no tearing at all. This is a known limitation of (at least) the NVidia drivers. Quoting the NVidia README: --snip-- The Composite extension also causes problems with other driver components: [...] On X.Org 7.1 and higher, the driver will properly redirect video into offscreen pixmaps. Note that the Xv adaptors will ignore the sync-to-vblank option when drawing into a redirected window. --snip-- Thanks for the info. How can I check the X.Org version I have? I've looked on xorg modules in yumex and see some of them are 7.3.5, 7.3.9, 7.4 Ok, found it, but it doesn't look like the right numbers. X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.18-128.1.1.el5 i686 Current Operating System: Linux htpc 2.6.27.19-170.2.35.fc10.i686 #1 SMP Mon Feb 23 13:21:22 EST 2009 i686 Build Date: 10 March 2009 07:20:48PM Build ID: xorg-x11-server 1.5.3-15.fc10 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Regards, Jörn -- Joern Reder - http://www.exit1.org/ - http://search.cpan.org/~jred/ http://search.cpan.org/%7Ejred/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelibout --hud + xcompmgr = tearing
2009/3/18 Jörn Reder jo...@zyn.de Alex Betis wrote: I gave the nice xinelibout hud another try, but have to revert back since running composite manager creates tearing while watching movies. I've tries with xcompmgr with -n option. Does anybody know how to fix that? Or maybe there is another lightweight composite manager available? Without xcompmgr running there is no tearing at all. This is a known limitation of (at least) the NVidia drivers. Quoting the NVidia README: --snip-- The Composite extension also causes problems with other driver components: [...] On X.Org 7.1 and higher, the driver will properly redirect video into offscreen pixmaps. Note that the Xv adaptors will ignore the sync-to-vblank option when drawing into a redirected window. --snip-- Thanks for the info. How can I check the X.Org version I have? I've looked on xorg modules in yumex and see some of them are 7.3.5, 7.3.9, 7.4 Regards, Jörn -- Joern Reder - http://www.exit1.org/ - http://search.cpan.org/~jred/ http://search.cpan.org/%7Ejred/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xinelibout --hud + xcompmgr = tearing
Hello all, I gave the nice xinelibout hud another try, but have to revert back since running composite manager creates tearing while watching movies. I've tries with xcompmgr with -n option. Does anybody know how to fix that? Or maybe there is another lightweight composite manager available? Without xcompmgr running there is no tearing at all. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelibout --hud + xcompmgr = tearing
On Tue, Mar 17, 2009 at 11:14 PM, Torgeir Veimo torg...@pobox.com wrote: On 17 Mar 2009, at 22:02, Alex Betis wrote: I gave the nice xinelibout hud another try, but have to revert back since running composite manager creates tearing while watching movies. I've tries with xcompmgr with -n option. Does anybody know how to fix that? Or maybe there is another lightweight composite manager available? This is usually caused by the gfx driver in question. If you're running on intel gfx hardware, there might be an updated xorg driver that fixes it. I'm with nVidia 8400 and 180.29 drivers. Without the manager there is no tearing, so I believe the settings are ok. -- Torgeir Veimo torg...@pobox.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] image 0.3.0 with high resolution output
Hi all, In case you have a high resolution output device (LCD/Plasma) you probably noticed that image plugin show low quality results even when the original image is a very high quality/resolution. To fix it, replace the following lines in liboutput/encode.c file from: m_nWidth = 720; m_nHeight = m_bUsePAL ? 576 : 480; to m_nWidth = 1920; m_nHeight = 1080; Or other output resolution if you don't have a full HD screen. Developers of image plugin, it would be great to have those 2 parameters configurable for that plugin. Also, I've noticed the xinelibout (or OSD) stuck many times when I use image plugin. And another improvement: Since image conversion takes lots of time (about 2-3 seconds on E6600) it will be great if the plugin will try to cache next or previous image (depends on user direction) in advance, so the switch will be instant. Converting 9 images to show the 3x3 screen takes VERY long. Maybe should convert them to a very low resolution images to make is faster. Beside that, thanks for a good plugin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput improvements
Hello all, I don't know whether xineliboutout developers read this list, if not, could someone pass the following to them somehow? Here are few points for improvements in xineliboutput: - Buffers problem on startup - There is no way to rewind a media file to start from the beginning (I would suggest a color button to do it when list of files is shown) - I would like to be able redefine the remote control keys, for example, in file playback both right and FWD buttons increase speed of the playback and both left and REW decrease the speed of playback. I would like to reassign one of those pairs to rewind and skip, the same as green and yellow buttons do it today. Or at least set replay and skip buttons do the same. - Trying to show images larger than current screen resolution crash the vdr-sxfe. I would expect automatic resize of the image. - Media files with file names in right-to-left language (hebrew for example) are shown in reverse. Nautilus shows them correctly somehow, so I believe its possible to get codepage of the UTF name and show it in correct direction. That's all for now. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput improvements
On Mon, Mar 9, 2009 at 7:00 PM, Pertti Kosunen pertti.kosu...@pp.nic.fiwrote: Alex Betis wrote: - There is no way to rewind a media file to start from the beginning (I would suggest a color button to do it when list of files is shown) Red button does this when file is playing. Oh, ok. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A new possibility for lower power high performance VDR
On Sun, Mar 8, 2009 at 4:03 PM, Mika Laitio lam...@pilppa.org wrote: I have myself thinked about the possibility of running vdr/xineliboutput client on low end systems that just have usb 2.0 but not any graphic cards or free pci slots available. Has anybody experiences from the usb vga or usb dvi graphic card adapters like these? I think the answer is here: Sewell claims that these USB-driven monitors have the same quality as standard DVI monitors at displays of* up to 20-inches* And what about all the GPU power? Someone has to handle MPEG decoding in hardware. As I see it, if you want low power silent box in your living room you'll have to keep a server with cards/USBs somewhere in your basement. If I had a basement, that's exactly that I would do :) Well, at the moment I have amd X2 4850 cpu on my server and one of the client is about 10 year old Pentium III 733 mhz with 10 mb network card and and integrated intel graphich card. This client user vdr-xineliboutput to 20 VGA monitor and works very well with SD channels. I have also tested streaming from VDR to Nokia N810 internet tablet. In that test I used the Streamdev plugin on server and mplayer on Nokia N810. (I have not tested xineliboutput with N810 because xine related libs seems to be hard to find for it and I did not had time by myself to start building everything for that...) So it indicates that the client do not neccessary need to have so much power on client unless the USB graphich card is very different beast from the resource eating standpoint. The life is going toward high definition. My E6600 can hardly handle that with CPU decoding. By low power silent box I mean an Atom based set-top box with integrated video chip - short term it's probably nVidia, but I think Intel will join that club pretty soon. Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] compil vdr-1.7.4 against v4l-dvb hg as of today
On Fri, Mar 6, 2009 at 4:17 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 03.03.2009 22:23, Gregoire Favre wrote: Hello, just tried compiling vdr-1.7.4 against my v4l-dvb hg's source which fails if I don't use this : --- vdr.c~ 2009-01-18 12:02:37.0 +0100 +++ vdr.c 2009-03-03 22:17:49.0 +0100 @@ -32,6 +32,7 @@ #include pwd.h #include signal.h #include stdlib.h +#include linux/types.h #include sys/capability.h #include sys/prctl.h #include termios.h vdr.c compiles just fine here with the most recent version of v4l-dvb from linuxtv.org (6bd427caa0cb). I did report a problem with the driver's header files, though, in http://linuxtv.org/pipermail/linux-dvb/2009-March/031934.html However, there has been no repsonse to that, and the problem still persists with the current version. Just curious: don't you have a problem compiling dvbdevice.c? I've faced the same problem after upgrading kernel to 2.6.27.19 Found the solution on the net: add the following to VDR Makefile: DEFINES += -D__KERNEL_STRICT_NAMES Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [patch] compil vdr-1.7.4 against v4l-dvb hg as of today
On Fri, Mar 6, 2009 at 4:52 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 06.03.2009 15:37, Alex Betis wrote: On Fri, Mar 6, 2009 at 4:17 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de mailto:klaus.schmidin...@cadsoft.de wrote: On 03.03.2009 22:23, Gregoire Favre wrote: Hello, just tried compiling vdr-1.7.4 against my v4l-dvb hg's source which fails if I don't use this : --- vdr.c~ 2009-01-18 12:02:37.0 +0100 +++ vdr.c 2009-03-03 22:17:49.0 +0100 @@ -32,6 +32,7 @@ #include pwd.h #include signal.h #include stdlib.h +#include linux/types.h #include sys/capability.h #include sys/prctl.h #include termios.h vdr.c compiles just fine here with the most recent version of v4l-dvb from linuxtv.org http://linuxtv.org (6bd427caa0cb). I did report a problem with the driver's header files, though, in http://linuxtv.org/pipermail/linux-dvb/2009-March/031934.html However, there has been no repsonse to that, and the problem still persists with the current version. Just curious: don't you have a problem compiling dvbdevice.c? I've faced the same problem after upgrading kernel to 2.6.27.19 Found the solution on the net: add the following to VDR Makefile: DEFINES += -D__KERNEL_STRICT_NAMES Let's be careful to not mix up two different things here. There's apparently the problem Gregoire reported, which he solved by adding an #include, but which doesn't happen here (kernel 2.6.25.20). That one has nothing to do with the driver. @Gregoire: does this happen with plain vanilla VDR 1.7.4 or are there any patches involved? Can you compile dvbdevice.c with the latest driver header files? @Alex: are you referring to the problem Gregoire reported or to the one I reported? I refer to your problem with many redefinitions like the following: /usr/include/sys/select.h:78: error: conflicting declaration 'typedef struct fd_set fd_set' /usr/include/linux/types.h:12: error: 'fd_set' has a previous declaration as 'typedef struct __kernel_fd_set fd_set' I probably missed Gregorie's error report, so I don't know what was it about. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Sound freeze and out of sync in xinelibout
Hello all, I'm experiencing some problems with sound when playing media files (movies) using xinelibout 1.0.3, xine-lib 1.2 Sometimes the sound freeze for few seconds and than continue and sometimes goes out of sync with the picture. I don't see it with live broadcast, but happens frequently while playing a video file. Anyone experienced the same? Is there anything can be done to fix it? I saw that xinelibout 1.0.4 is out, but I didn't see anything mentioned about sound in HISTORY file. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Sound freeze and out of sync in xinelibout
An update, Just saw that my live stream also has a delay in sound. I probably switch channels too fast and didn't notice it before. Will be glad for any solution. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe from background script
On Sat, Feb 21, 2009 at 5:42 PM, Stefan Ellenberger stefan_...@hotmail.comwrote: I do have a similar solution to the one Ville used in KDE - set up a shell script - issue a killall -q -9 vdr-sxfe command first (if there is no vdr-sxfe task running this will be ignored) - call vdr-sxfe again So you don't have a script that re-run vdr-sxfe in case it crashes? Looks like this: #!/bin/sh /usr/bin/killall -q -9 vdr-sxfe /usr/bin/vdr-sxfe --fullscreen --post volnorm --reconnect xvdr://localhost I do have to use sigterm (-9) paramter, because I do get tcp buffer overflows quite often. So the connection to vdr gets lost but the task itself keeps running and can't be terminated cleanly by sighub or sth similar. Yeah, it happen pretty often for me as well. Any ideas how to improve that? I have a channel with many audio tracks that cause the buffer to get filled as well and drop frames. In addition to ~/.*config*/*autostart *I do place a softlink to this script in K-Menu Favorites and assign a HOTKEY. So if I press this hotkey on my wireless keyboard the script gets restarted. Maybe there is a way to get kde-lirc working with this script as well so you have it on your remote? Might be tricky when you already have a lirc session assigned to vdr. I'd be interested in a solution to that. I'm pretty sure you can assign hotkeys in gnome as well, might be worth trying. Thanks. I'll try to find something similar in gnome. I use remote, so I'm not sure gnome will see the pressed keys as is. irexec is probably the way to go. -- Gruppenchats mit dem neuen, verbesserten Messenger. So geht's! Hier klicken! http://download.live.com/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-sxfe from background script
Hi all, I wonder what am I doing wrong. I've set up a script that will run vdr-sxfe in a loop. When I want to restart vdr-sxfe, I just kill it and the script is suppose to run it again. The problem is that when this script is run in background ( at the end), the job is shown as stopped. I've tried to run vdr-sxfe itself in background, it opens the window and the job stops. I know there is a switch that will run it in daemon mode, but that's not that good for the script I want to have. Any ideas what can be wrong or any other ways to run vdr-sxfe from background? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe from background script
Wow... you write alot! :) On Fri, Feb 20, 2009 at 11:54 PM, Ville Aakko ville.aa...@gmail.com wrote: Hi! 2009/2/20 Alex Betis alex.be...@gmail.com: Hi all, I wonder what am I doing wrong. The problem is that when this script is run in background ( at the end), the job is shown as stopped. I've tried to run vdr-sxfe itself in background, it opens the window and the job stops. I know there is a switch that will run it in daemon mode, but that's not that good for the script I want to have. I think I hit the problem you are having before, but in my current solution I do not need to face it. Currently, I log in automatically via kdm, which loads KDE (could be xfce or whatever you want, though I haven't tested because currently I want to use KDE) and automatically runs a script (~/.kde/Autostart/vdr-sxfe.sh) that starts vdr-sxfe. I I use gnome with auto login and it runs my vdr-sxfe.sh script as well. don't background the vdr-sxfe.sh process in the script. I have two Me too. In that case everything works fine, even if I kill the vdr-sxfe process and the script restarts it. loops there; the second is in case vdr-sxfe crashes, to restart vdr-sxfe (vdr-sxfe doesn't do that anymore quite often) and the second In my case vdr-sxfe doesn't crash, but it freezes on startup a lot. Restarting it generally helps. is for suspend / resume (some parts of lirc/VFD don't like suspend on my setup). The latter waits from the start of suspend until end of resume to restart vdr-sxfe. And, also it looks for the errorlevel of How did you implement the wait? With a flag-file that is set in suspend script and deleted after resume? vdr-sxfe ehwn it exits; if it is not a clean one, it assumes it was not initiated by the user (and allows automatic shutdowns). Good idea. I planned to kill both vdr-sxfe and vdr-sxfe.sh to use the desktop. I could also swtich to another desktop and leave the frontend running as is. Now we came to the real problem: when I kill the script, how do I restart it so it will run in foreground. Do you really need to background vdr-sxfe the way you try to do it? On my setup, If I want to exit vdr-sxfe to use the desktop (actually, I don't need to do that but I can, also this disable automatic shutdowns on my setup via a kludge) I just press esc on my keyboard to shutdown vdr-sxfe (this leaves vdr running in the background). I have bound another button to restart vdr-sxfe again (to enable automatic shutdowns etc.). You could kill all running vdr-sxfe sessions whenever you run the script again (so that would actually work as a restart, too, Though, I don't need restarting vdr-sxfe, so I haven't done it). I can send my script if you need it. Do you restart vdr-sxfe or the script? I need the script to be restarted and run in foreground. I didn't try using irexec yet, will try it later today. I hope it doesn't run the commands in background since it will not work for vdr-sxfe. Please send the script, I might learn something from it. Thanks. The rest might be offtopic or not, but I think in general your problem is related to a lack of documentation / examples / init scripts etc. Agree. needed when configuring VDR to display via X (as opposed to a full featured card or some other deticated output device that doesn't require X) At least for gentoo there are nice init sciŕipts and configuration files for VDR and its plugins. But it seems that the init scripts assume that a user has a full-featured card or another deticated ouput device for the TV. But if one needs X for the display instead (which more and more users will be using for several reasons), I'm still really in the dark how to do that elegantly. Not even the vdr-sxfe documentation had examples / ideas of ho to achieve the automation! I.e. I want to have a VDR showing the picture via HDMI without having to log in and running vdr-sxfe manually every time. The problem might actually lie in the several differen't use cases there are; some setup might only use the X for a deticated VDR, but some other users would need other software to run under the X session, too. In my case, I needed VDR to start automatically whenever I push the power button, but still have an easy way to switch to other prorams and / or desktop. Of course this is a complicated matter, as depending on the distribution / init scripts used, VDR might be run as root or a detidcated user 'vdr', but the additional software would not be run as such. I found the dilemma very confusing. So, I had sevveral questions but no ready solutions / answers; How should I start X.org / Which user should I run X as? Which user should run vdr-sxfe (or some other X output backend)? And if I'm not using a client/server setup, how on earth am I going to start an X session before the init scripts run VDR, to play along nicely with the init scripts? Do I need to log in as user 'vdr' (to start an X session) before
Re: [vdr] auto shutdown (-s) question
On Sat, Feb 7, 2009 at 12:44 AM, Udo Richter udo_rich...@gmx.de wrote: On 06.02.2009 13:49, Alex Betis wrote: I'm playing now with autoshutdown script (the one that is specified with -s switch) and have a question. When power button is pressed, VDR calls the script, but lets say the script decided not to shutdown the PC (other background work is done). I see that VDR shows a countdown of 5 minutes saying that it will shutdown soon. VDR does not know whether the shutdown script initiated the shutdown or decided to ignore it, so it simply sets the SHUTDOWNRETRY time (6 minutes) until next shutdown attempt. The 5-minute countdown will automatically start after the first minute. What are the common ways to cancel that? I thought about sending a back button using SVDRP. Is there any other methods? There is no official way to announce background activity from outside of VDR. Sending a keystroke would work, but probably shifts shutdown several hours into the future. Sending a poweroff when done is also a bad idea, as an user might be using VDR by now. The easiest way is to just assume that no one sees the countdowns, and keep trying shutdown until it succeeds. Any user activity will make the countdown disappear anyway. Ok, got the idea. I thought VDR will shutdown itself after that counter, something that is not really wanted. After trying it, I see that it just counts down and call the script again. I saw somewhere in the manual also that it leaves the control to the script (to kill it) and do not exit by itself. Thanks. Plugins have more control over shutdown, they can report their activity and can even announce future activity, leaving VDR the decision to shut down until then or not. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] auto shutdown (-s) question
Hi all, I'm playing now with autoshutdown script (the one that is specified with -s switch) and have a question. When power button is pressed, VDR calls the script, but lets say the script decided not to shutdown the PC (other background work is done). I see that VDR shows a countdown of 5 minutes saying that it will shutdown soon. What are the common ways to cancel that? I thought about sending a back button using SVDRP. Is there any other methods? When VDR will try to shutdown next? After user idle timeout? Thanks. Alex. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 / mplayer / spdif Nexus = pb with DTS tracks
On Mon, Feb 2, 2009 at 2:26 PM, kafifi kaf...@orange.fr wrote: Hello, I am using vdr-1.6.0 and mplayer with Nexus FF card and it's spdif output. When I run some 720p_AC3.avi movies, my HC ampli receives 5.1 audio without problem. But with movies with DTS audio tracks, vdr+mplayer give only PCM in stereo mode. There is an issue with DTS passthrough. When I try mplayer **without vdr**, DTS is working : Mplayer -ao mpegpes afm hwac3 movie.avi My mplayer.sh.conf has theses lines : USEAC3=true AC3AOUT=-ao mpegpes -afm hwac3 Did I missed something ? Do you know how could I fix this issue ? I'm not an expert in that since I didn't get to receiver connection yet, but I think there is also hwdts codec. I think the correct switch is -ac hwdts. Thank you. == Here is the log logger: *** Starting mplayer.sh Version 0.8.7 logger: *** DEBUG: Variable CFGFIL has value /DATA/configVDR/mplayer.sh.conf logger: *** DEBUG: Variable USEAC3 has value true logger: *** DEBUG: Variable AC3AOUT has value -ao mpegpes -afm hwac3 logger: *** DEBUG: Variable TV_ASPECT has value 16/9 logger: *** DEBUG: Variable PAL has value true logger: *** DEBUG: Variable NTSC has value false logger: *** DEBUG: Variable USE_SPEED has value true logger: *** DEBUG: Variable DETC_FILTER has value ivtc=1 logger: *** DEBUG: Variable MPLAYER has value /usr/bin/mplayer logger: *** DEBUG: Variable VOP has value lavc=5000 logger: *** DEBUG: Variable VO has value mpegpes:card=1 logger: *** DEBUG: Variable AO has value mpegpes:card=1 logger: *** DEBUG: Variable CACHE has value 8192 logger: *** DEBUG: Variable CACHESTR has value -cache 8192 logger: *** DEBUG: Variable FRAMEDROP has value true logger: *** DEBUG: Variable FDSTR has value -framedrop logger: *** DEBUG: Variable LIRCRC has value logger: *** DEBUG: Variable LIRCSTR has value logger: *** DEBUG: Variable SUBTITLE has value -subpos 80 -sub-bg-color 0 -sub-bg-alpha 30 logger: *** DEBUG: Variable REMOTE has value -slave -nolirc logger: *** Use Option USERDEF at your own risk! logger: *** DEBUG: Variable USERDEF has value -quiet logger: *** DEBUG: Variable XResPAL has value 352 480 528 544 688 704 720 logger: *** DEBUG: Variable XResNTSC has value 352 480 512 640 704 720 logger: *** DEBUG: Variable SLOW_CPU has value false logger: *** DEBUG: *** Option DVDFiles not set correctly! You will not be able to play VCD/DVD logger: *** DEBUG: Variable DVDFiles has value logger: *** DEBUG: *** Option DVD not set correctly! You will not be able to play VCD/DVD logger: *** DEBUG: Variable DVD has value logger: *** DEBUG: Variable DVDLANG has value fr logger: *** DEBUG: Variable DVDOPTIONS has value -aop list=volume:volume=170 logger: *** DEBUG: Variable VCDOPTIONS has value logger: *** DEBUG: Variable MPEG_DIRECT has value true logger: *** DEBUG: Variable SUFFIX has value .mkv logger: *** DEBUG: Variable MPLAYER_V1 has value true logger: *** DEBUG: Calling getvidxy function to analyze source video stream ... logger: *** DEBUG: OutputFromMPLAYER: ID_VIDEO_ID=0 ID_VID_0_NAME=Cliffhanger (1993) ID_AUDIO_ID=0 ID_AID_0_NAME=DTS 5.1 768 kbps ID_AID_0_LANG=eng ID_FILENAME=/VIDEO/DIVX/Cliffhanger (1993) - 720p x264 DTS US.mkv ID_DEMUXER=mkv ID_VIDEO_FORMAT=avc1 ID_VIDEO_BITRATE=0 ID_VIDEO_WIDTH=1280 ID_VIDEO_HEIGHT=532 ID_VIDEO_FPS=23.976 ID_VIDEO_ASPECT=2.4060 ID_AUDIO_FORMAT=8193 ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=6 ID_LENGTH=6762.71 ID_VIDEO_CODEC=ffh264 ID_AUDIO_BITRATE=768000 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=2 ID_AUDIO_CODEC=dts logger: *** DEBUG: MPLAYER_RETURN: 0 logger: *** DEBUG: parsed output for ORIG_X: 1280 logger: *** DEBUG: parsed output for ORIG_Y: 532 logger: *** DEBUG: parsed output for ORIG_FPS: 23.976 logger: *** DEBUG: parsed output for ORIG_ASPECT: 2.4060 logger: *** DEBUG: parsed output for VIDEO_FORMAT: avc1 logger: *** DEBUG: parsed output for AUDIO_CODEC: dts logger: *** INFO: Source Video has Resolution of 1280 x 532 ... logger: *** DEBUG: Film logger: *** DEBUG: Variable MAX_X has value 1024 logger: *** DEBUG: Variable NEW_Y has value 425 logger: *** INFO: For Sqare Pixels we would scale to 1024 x 425 ... logger: *** DEBUG: Variable XResTEMP has value 352 480 528 544 688 704 720 logger: *** DEBUG: Variable AnzahlVonXResTEMP has value 7 logger: *** DEBUG: Variable NEW_X has value 720 logger: *** DEBUG: setting REAL_Y = FULL_Y logger: *** DEBUG: Variable CMDLINE has value /usr/bin/mplayer -vo mpegpes:card=1 -ao mpegpes:card=1 -vf scale=720:425,expand=720:576:-1:-1:1,lavc=5000:25 -speed 1.04 -framedrop -cache 8192 -slave -nolirc -subpos 80 -sub-bg-color 0 -sub-bg-alpha 30 -quiet MPlayer 1.0rc2-4.3.2 (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (Family: 6, Model: 15, Stepping: 13) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled
Re: [vdr] Disabling EPG update from air or shift it in time
On Sun, Feb 1, 2009 at 11:58 AM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 31.01.2009 11:51, Alex Betis wrote: ... [ EPG for time shifted channels ] ... As an example, 75.0E has NTV and NTV-2, or DTV and DTV-2 Please post the complete channels.conf entries of these channels. Here it is: This couple looks like sending the EPG shifted correctly: HTB;GTSS:12640:vM2O0S0:S75.0E:22000:503:504,505:0:0:100:58:103:0 HTB-3;GTSS:12640:vM2O0S0:S75.0E:22000:501:502:0:0:500:58:103:0 This couple looks like not shifting the EPG at all: DTV-0;GTSS:12640:vM2O0S0:S75.0E:22000:201:202:0:0:200:58:103:0 DTV-2;GTSS:12518:vC78M2O0S0:S75.0E:22000:701:702=eng:0:0:504:86:100:0 This one looks like shifting the EPG in wrong direction (its scrambled, but I've compared the content of EPG.data with official site): CTC+7;CTC Media:12640:vM2O0S0:S75.0E:22000:401:402:0:2600:400:58:103:0 Looks like you got all sorts of variations: some do it right, some do it wrong, and some don't do it at all ;-) Since every channel has its own SID, it also has its own EPG data, which logically needs to correspond to the times the programmes are actually broadcast. So far I don't se any proper solution than having the providers fix this. As I wrote, those channels started transmitting EPG not long ago, so I hope the issue will be fixed one day. I agree that its probably a provider fault. Anyway, I think a configuration that will allow disabling EPG from DVB might be useful for those who retrieve all EPG data from the net, that in most cases contains more data than transmitted by the provider. By the way, if we already discussing EPG... I think the epg.data is very limited. I would like to see an option to integrate pictures or even movies in that file. Ofcause I could place tags in description and have a plugin that could parse those tags and show the pictures stored somewhere else, but I think it should all be located in the same place. I use s script that updates those channels from internet, so I don't mind to disable EPG update received on the channel. You can set the table id of these events to 0 (see man 5 vdr). The problem is not with overwriting the data, but appending the wrong data for that channel. I see both script inserted and DVB transmitted data that are differ. Is there such table id setting per channel and not per EPG entry? No, this is per EPG event, not per channel. I'll probably patch the code for now to disable the received EPG processing. But as I see it, there is an issue even when the EPG is correctly transmitted by a provider, for example: What VDR will do when there is a change in the program and there is a delay in transmission of some program? Will it have 2 entries for the same program or update the previous entry? VDR will update/replace all EPG entries according to the new tables. There shouldn't be double entries. If EPG time is in UTC, than that's a mystery how should those coupled channels be handled. As I said, each channel has its own SID, and therefore its very own EPG data, which needs to be adjusted to the actual broadcast times of that channel. As an example: if you have two channels, say ABC and ABC+1, where ABC+1 broadcasts everything one hour later that ABC, then if the air time of event XY is 8:00 for channel ABC, it needs to be 9:00 for channel ABC+1. All times given in UTC, of course. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
On Sun, Feb 1, 2009 at 9:03 PM, user.vdr user@gmail.com wrote: The use is simple, show more information for programs. Many sities of the channels provide that information already, including pictures and movie trailers. There is also IMDB that can be used. As an example, MythTv has a nice use of IMDB for stored movies. Same can be implemented for live movies as well. I always thought it would be cool if VDR was able to pull a poster/cover and IMDB summary of movies but I doubt we'd see that in vdr core. A plugin maybe. I'd think a cache somewhere would be far more effecient then using epg.data for that though. That's also an option. I had a thought of saving description in HTML format, so it will be easy to design the output. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
On Sat, Jan 31, 2009 at 12:10 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 31.01.2009 06:13, Alex Betis wrote: On Fri, Jan 30, 2009 at 11:50 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de mailto:klaus.schmidin...@cadsoft.de wrote: On 30.01.2009 22:12, Alex Betis wrote: Hi all, Is there any configuration that disables EPG updates received on the channel? Or is there a way to shift time of those updates before they are written to EPG.data? The problem is that I have some channels that are transmitted for different time zones that start transmitting EPG info, but looks like the EPG is not shifted. There are some other shifted channels that do transmit the EPG properly, so I believe that's a provider problem. The times given in EPG data are supposed to be in UTC, so different time zones are of no interest. If teh times are not in UTC, the providers are messing up. So how VDR or any other settop box should know that the channel is shifted in time? Beats me! :) As an example, 75.0E has NTV and NTV-2, or DTV and DTV-2 Please post the complete channels.conf entries of these channels. Here it is: This couple looks like sending the EPG shifted correctly: HTB;GTSS:12640:vM2O0S0:S75.0E:22000:503:504,505:0:0:100:58:103:0 HTB-3;GTSS:12640:vM2O0S0:S75.0E:22000:501:502:0:0:500:58:103:0 This couple looks like not shifting the EPG at all: DTV-0;GTSS:12640:vM2O0S0:S75.0E:22000:201:202:0:0:200:58:103:0 DTV-2;GTSS:12518:vC78M2O0S0:S75.0E:22000:701:702=eng:0:0:504:86:100:0 This one looks like shifting the EPG in wrong direction (its scrambled, but I've compared the content of EPG.data with official site): CTC+7;CTC Media:12640:vM2O0S0:S75.0E:22000:401:402:0:2600:400:58:103:0 I use s script that updates those channels from internet, so I don't mind to disable EPG update received on the channel. You can set the table id of these events to 0 (see man 5 vdr). The problem is not with overwriting the data, but appending the wrong data for that channel. I see both script inserted and DVB transmitted data that are differ. Is there such table id setting per channel and not per EPG entry? No, this is per EPG event, not per channel. I'll probably patch the code for now to disable the received EPG processing. But as I see it, there is an issue even when the EPG is correctly transmitted by a provider, for example: What VDR will do when there is a change in the program and there is a delay in transmission of some program? Will it have 2 entries for the same program or update the previous entry? If EPG time is in UTC, than that's a mystery how should those coupled channels be handled. Klaus Thanks. Alex. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Disabling EPG update from air or shift it in time
Hi all, Is there any configuration that disables EPG updates received on the channel? Or is there a way to shift time of those updates before they are written to EPG.data? The problem is that I have some channels that are transmitted for different time zones that start transmitting EPG info, but looks like the EPG is not shifted. There are some other shifted channels that do transmit the EPG properly, so I believe that's a provider problem. I use s script that updates those channels from internet, so I don't mind to disable EPG update received on the channel. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Disabling EPG update from air or shift it in time
On Fri, Jan 30, 2009 at 11:50 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 30.01.2009 22:12, Alex Betis wrote: Hi all, Is there any configuration that disables EPG updates received on the channel? Or is there a way to shift time of those updates before they are written to EPG.data? The problem is that I have some channels that are transmitted for different time zones that start transmitting EPG info, but looks like the EPG is not shifted. There are some other shifted channels that do transmit the EPG properly, so I believe that's a provider problem. The times given in EPG data are supposed to be in UTC, so different time zones are of no interest. If teh times are not in UTC, the providers are messing up. So how VDR or any other settop box should know that the channel is shifted in time? As an example, 75.0E has NTV and NTV-2, or DTV and DTV-2 I use s script that updates those channels from internet, so I don't mind to disable EPG update received on the channel. You can set the table id of these events to 0 (see man 5 vdr). The problem is not with overwriting the data, but appending the wrong data for that channel. I see both script inserted and DVB transmitted data that are differ. Is there such table id setting per channel and not per EPG entry? Regards, Alex. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] no channel update for certain channels
On Wed, Jan 28, 2009 at 2:26 AM, Malcolm Caldwell malcolm.caldw...@cdu.edu.au wrote: On Tue, 2009-01-27 at 10:34 +0100, Matthias Dahl wrote: Hi. For certain situations, it'd be great to exclude some channels from the automatic channel update. For example, when one has entered a channel manually which broadcasts wrong channel informations. With the next channel update, all is overwritten. So one has to either completely disable the automatic updates or live without the channel for the time being. I had just a quick look over the vdr source and figured it wouldn't be too hard to come up with a patch to support something like this I guess. So I wanted to ask if this new feature would be considered ok for inclusion into vdr-1.7.x or if there are reasons against it? Otherwise I would put it on my todo list and get to it when I get some time... if no one else does it in the meantime that is. :-) I deal with this type of problem by having two copies of the channel, with one with rid=1. The one with rid=0 will be automatically updated to incorrect values, while the one with rid=1 will not be updated, so it can be tuned as needed. Can you have 2 channels without changing anything in the code? I had to change some functions to have this. I found that VDR deletes duplicate channels by default. What is rid by the way? Best regards, matthias. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Sirius 4.8E - channels.conf and sources.conf
On Sun, Jan 25, 2009 at 1:17 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 25.01.2009 12:04, Artem Makhutov wrote: Hi, Klaus Schmidinger schrieb: On 25.01.2009 11:42, Artem Makhutov wrote: Hello, I am wondering on why the Sirius 4.8° satellite is noted as S5E Sirius 4 in sources.conf and S5.0E is used in diseqc.conf and channels.conf... Well, I guess the source from which this information was taken initially was wrong (or has this sat been repositioned?). As far as I can remember the sat was not repositioned. If we change this now, all existing diseqc.conf and channels.conf files would have to be changed accordingly. I wouldn't have a problem with that, since I don't receive that sat position ;-) I also have no problems with changing the files :) I am just wondering on why this sat is noted without the .0 in the sources.conf. There are plenty of sat positions that have no trailing .0 in sources.conf. This is optional, S5E is exactly the same as S5.0E. If you like this to be changed, just provide a patch. This should be changed to S5.0E or S4.8E. We could stick with S5.0, since this is used in some sources. Lyngsat is using 5.0E in the name of the HTML file, but 4.8E is used in the text : http://www.lyngsat.com/5east.html Aha, so they're making the same mistake ;-) Those who use scan-s2 application from: http://mercurial.intuxication.org/hg/scan-s2 ** You can override the orbital position received from satelite by specifying: -O pos Orbital position override 'S4W', 'S19.2E' - good for VDR output I've added that parameter after I saw some channels found with invalid positions (I'm not talking about 5.0 or 4.8, but totally invalid). This ofcause is not acceptable for those who use diseqc. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] channel-change-prediction, doable? stupid idea?
On Wed, Jan 21, 2009 at 8:33 PM, Gerald Dachs v...@dachsweb.de wrote: Assumed I have 2 free Tuners and I zapp through the channels of one tuner. Would it be possible to tune the 2. tuner to the same time to the after next channel in change direction, so that for the next channel change in the same direction it would be possible to channge to the 2. tuner instead of changing the channels of the 1. tuner. Channels gets changed afterwords. Does this work? Is changing of the tuners faster than changing channels? Would this flicker? Does this happen already? If you're going into that direction, I think in addition to zaps there might be a need to get back to previous channel regardless of zapping or manual channel selection. Many remote controls even have a special button for that. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] understanding xinelibout code (or maybe any plugin code)
Hi all,
Anybody here is familiar with xinilibout code?
Or maybe it's a generic concept of plugins that I don't really know...
What is assigned to input_vdr-f.input_control? I couldn't find
initialization place.
Don't know if it makes a different, but vdr-sxfe is run with --lirc switch.
I hate pointers to functions!
static void process_xine_keypress(input_plugin_t *input,
const char *map, const char *key,
int repeat, int release)
{
/* from UI -- input plugin -- vdr */
LOGDBG(Keypress: %s %s %s %s,
map, key, repeat?Repeat:, release?Release:);
if(input) {
vdr_input_plugin_t *input_vdr = (vdr_input_plugin_t *)input;
if(input_vdr-f.input_control) {
input_vdr-f.input_control(input, map, key, repeat, release);
} else {
LOGMSG(Keypress --- NO HANDLER SET);
}
} else {
LOGMSG(Keypress --- NO PLUGIN FOUND);
}
}
Thanks.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe + remote control
On Sun, Jan 18, 2009 at 3:56 PM, Alex Betis alex.be...@gmail.com wrote: On Sun, Jan 18, 2009 at 3:44 PM, Ville Aakko ville.aa...@gmail.comwrote: If I understood the issue correctly, Alex (the OP) has problems because the USB receiver gives BOTH kb events and makes a lirc device, and the KB events are not wanted and cause problems. I'd look in /dev/input to see which event device is the one for the KB side of the receiver and disable it; perhaps via Xorg.conf (I'd assume this is somehow possible). That would be a general solution for all software, including those that don't have an option for disabling keyboaard.But, as already stated by Jukka, vdr-sxfe already has one... but then maybe we didnt understand the issue correctly =) Thanks all for the replies. I'll try both --nokbd and spcifying which input should be used for keyboard in xorg.conf as soon as I'll get home. To sum the replies, looks like I have to use --lirc option for vdr-sxfe and --lirc=/dev/null with vdr. 2 more issue I still have to resolve: - repetition problem for the keys, pressing 1 might produce 111. Will probably have to play with some options in lircd.conf. - Key sequences configuration, play button is mapped to something like CTRL, SHIFT, P, how do I configure vdr-sxfe to understand the whole sequence as a single button? Ok, found my mistake. remote.conf has to include the same button names as they appear in lircd.conf and vdr has to be restarted when remote.conf is changed, I thought restarting vdr-sxfe should be enough since its the application that connects to lirc after all. By the way, --nokbd to vdr-sxfe doesn't really ignore keyboard input for me. Changing xorg.conf doesn't help as well, input from remote still act as a keyboard input. But that stops as soon as there is a connection to licrd (vdr-sxfe connects). The only thing left now is dealing with keyboard sequences since many major buttons on my RC sends sequences for every press (color buttons, stop, play, FW, RW, menu...). -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe + remote control
On Sun, Jan 18, 2009 at 3:44 PM, Ville Aakko ville.aa...@gmail.com wrote: If I understood the issue correctly, Alex (the OP) has problems because the USB receiver gives BOTH kb events and makes a lirc device, and the KB events are not wanted and cause problems. I'd look in /dev/input to see which event device is the one for the KB side of the receiver and disable it; perhaps via Xorg.conf (I'd assume this is somehow possible). That would be a general solution for all software, including those that don't have an option for disabling keyboaard.But, as already stated by Jukka, vdr-sxfe already has one... but then maybe we didnt understand the issue correctly =) Thanks all for the replies. I'll try both --nokbd and spcifying which input should be used for keyboard in xorg.conf as soon as I'll get home. To sum the replies, looks like I have to use --lirc option for vdr-sxfe and --lirc=/dev/null with vdr. 2 more issue I still have to resolve: - repetition problem for the keys, pressing 1 might produce 111. Will probably have to play with some options in lircd.conf. - Key sequences configuration, play button is mapped to something like CTRL, SHIFT, P, how do I configure vdr-sxfe to understand the whole sequence as a single button? -- -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-sxfe + remote control
Hello all, Please help me with remote control configuration since I'm breaking my head on a wall for more than a week already. RC is the only thing at the moment that stops me using the VDR as my main TV source. I've bought a nifty (and cheap) remote and a nice USB receiver. Looks like a clone of MCE remote. It has a small joystick to control the mouse. The USB receiver pass keyboard and mouse events to the system, so I can use it instead of my keyboard without any LIRC configuration. BUT, I do want to use LIRC since I want to bound one of the buttons for other tasks (such as switching to XBMC or running vdr-sxfe to pass sound to my sound system instead of the TV). irw works ok. I've set /etc/lircrc to pass the commands to vdr-sxfe and ircat shows them successfuly. I've added some commands such as LIRC.Volume+ and LIRC.Volume- manually to remotes.conf, but it doesn't really help. I can run vdr-sxfe with --lirc and see that it receives the codes direcly without my lircrc configuration, but it will miss many features since some of the RC buttins send sequnce of keys, which can be catched using lircrc configuration. Without specifying --lirc, vdr-sxfe seems to receive the keyboard commands instead the commands from LIRC. Can anyone help me please? People who have the original MCE remote, does your IR receiver also pass keyboard commands to the system? I saw that as soon as there is a connection to lircd (such as with irw or ircat) the keyboard events are not passed the system any more and that's good, but vdr-sxfe doesn't connect unless I'll use the --lirc switch. I'm stuck with that. Any help will be appreciated. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe + remote control
On Sat, Jan 17, 2009 at 6:50 PM, Kimmo Taskinen kimmo.taski...@dnainternet.net wrote: Hi, I'm not quite sure if I understood your problem right. So you get the right codes with irw and have put them on remote.conf. remotes.conf as you wrote is not right place. Do you start vdr with --lirc option? If you use --lirc for vdr-sxfe you should give --lirc to vdr (at least I don't). Will try to clarify: I run VDR with --lirc=/dev/null When I run vdr-sxfe with --lirc and with --verbose, I can see that it receives events the same way as irw, but it also receives keyboard events that are passed to the system by the driver. This way I'm loosing all the lircrc configuration such as repetition rate. When I run vdr-sxfe without --lirc, I can't see that it receives any event beside the keybord events from the driver. I've added mapping of buttons to lircrc as follows: begin prog= vdr-sxfe remote= linux-input-layer button= KEY_F10 repeat= 0 config= LIRC.Volume+ end but looks like vdr-sxfe still doesn't receive those events. cheers, Kimmo On 17 Jan 2009, at 17:32, Alex Betis wrote: Hello all, Please help me with remote control configuration since I'm breaking my head on a wall for more than a week already. RC is the only thing at the moment that stops me using the VDR as my main TV source. I've bought a nifty (and cheap) remote and a nice USB receiver. Looks like a clone of MCE remote. It has a small joystick to control the mouse. The USB receiver pass keyboard and mouse events to the system, so I can use it instead of my keyboard without any LIRC configuration. BUT, I do want to use LIRC since I want to bound one of the buttons for other tasks (such as switching to XBMC or running vdr-sxfe to pass sound to my sound system instead of the TV). irw works ok. I've set /etc/lircrc to pass the commands to vdr-sxfe and ircat shows them successfuly. I've added some commands such as LIRC.Volume+ and LIRC.Volume- manually to remotes.conf, but it doesn't really help. I can run vdr-sxfe with --lirc and see that it receives the codes direcly without my lircrc configuration, but it will miss many features since some of the RC buttins send sequnce of keys, which can be catched using lircrc configuration. Without specifying --lirc, vdr-sxfe seems to receive the keyboard commands instead the commands from LIRC. Can anyone help me please? People who have the original MCE remote, does your IR receiver also pass keyboard commands to the system? I saw that as soon as there is a connection to lircd (such as with irw or ircat) the keyboard events are not passed the system any more and that's good, but vdr-sxfe doesn't connect unless I'll use the -- lirc switch. I'm stuck with that. Any help will be appreciated. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe + remote control
On Sat, Jan 17, 2009 at 10:28 PM, Gerald Dachs v...@dachsweb.de wrote: Do you start vdr with --lirc option? If you use --lirc for vdr-sxfe you should give --lirc to vdr (at least I don't). No, that will not work. If you give both vdr and vdr-sxfe the option --lirc you will get every action twice. I use the option --lirc with vdr-sxfe and the option --lirc=/dev/null with vdr, so that I can use lirc with xbmc after I have stopped vdr-sxfe without stopping vdr. That's about that I've tried to do. How do you stop the vdr-sxfe? Assign a RC button to ESC? How about the repetition setting in vdr-sxfe if you're not using the lircrc? Thanks. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe + remote control
On Sat, Jan 17, 2009 at 11:41 PM, Gerald Dachs v...@dachsweb.de wrote: Am Sat, 17 Jan 2009 22:37:47 +0200 schrieb Alex Betis alex.be...@gmail.com: On Sat, Jan 17, 2009 at 10:28 PM, Gerald Dachs v...@dachsweb.de wrote: Do you start vdr with --lirc option? If you use --lirc for vdr-sxfe you should give --lirc to vdr (at least I don't). No, that will not work. If you give both vdr and vdr-sxfe the option --lirc you will get every action twice. I use the option --lirc with vdr-sxfe and the option --lirc=/dev/null with vdr, so that I can use lirc with xbmc after I have stopped vdr-sxfe without stopping vdr. That's about that I've tried to do. How do you stop the vdr-sxfe? Assign a RC button to ESC? No, I kill it from a script Ok, also an option. How about the repetition setting in vdr-sxfe I don't know what this is Doesn't your RC produce multiple pushes when you don't release the button in short time? When you don't want that to happen, you can set repeat = 0 in lircrc. When you do want that to happen, such as for volume or up/down buttons, you just set the repeat option to the rate you want to have. How do you solve that issue within vdr-sxfe? Could you also post your remotes.conf as an example? Or at least few buttons from it. Thanks. if you're not using the lircrc? I use lircrc, but only for starting the script that kills vdr-sxfe and starts xbmc and vice versa. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Serial IR receiver + wakeup from suspend
Hello all, I wonder if anybody here is using IR receiver that is connected to the PC with 9-pin serial cable and is able to wake the machine from suspend mode? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Color keys replacement
On Sun, Jan 11, 2009 at 9:44 PM, JJussi linux-...@jjussi.com wrote: Hi! Related question.. Is it possible to change order of those colors (what represent color-keys) at screen? Because my remote have those colors, but two of those are in different order... Take a screwdriver, open the remote and switch the buttons :) I thought the colors and the order are all the same... Another thing to worry about when buying a remote! -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] S2-3200 vdr needed material ?
On Sat, Jan 10, 2009 at 2:25 PM, Artem Makhutov ar...@makhutov.org wrote: Hi, On Sat, Jan 10, 2009 at 12:08:31PM +0200, Mika Laitio wrote: No, and I am little confused where is the version I could try with vdr.1.7.x. I found out 3 candidates while googling, should I try one of these with vdr-1.7.3 or some other one? - http://home.vrweb.de/~bergwinkl.thomashttp://home.vrweb.de/%7Ebergwinkl.thomas, This page mentions the patch only for vdr-1.5 - VDR-Extensions-Patch-65/vdr-1.7.2_extensions.diff seems to include livebuffer patch (but has unfortunately also many other patches within same patch and wont propably apply with 1.7.3) - VDR-Extensions-Patch-65/plugin-patches/setup-0.3.1-livebuffer.diff You should be able to use the VDR Extensions Patch 65 (with VDR 1.7.2). I have not tried it soo far, as I am still running VDR 1.7.1. You can enable single pathes in the patch pack, so you don't have to apply them all. What's this patch pack? Do you mean the patch selection by commenting/uncommenting individual patches from Make.config.template that the vdr-1.7.2_extensions.diff modifies? Yes, I think so. I have not tried to apply the patches manually. I am using a Gentoo ebuild which applies them for me. Anyway, for vdr-1.7.3, the vdr-1.7.2_extensions.diff failed to apply in many places. For vdr-1.7.2 the patch applied as expected, but I have not yet tried the LiveBuffer/vdr-xineliboutput in there. I have just setup S2API drivers with VDR 1.7.2 and the livebuffer patch from VDR Extensions Patch 65. Everything works pretty well. I can watch even watch HDTV using xineliboutput and vdr-xine. What are your channel switching times? I've used 1.7.1 + extension patches 64 to have the livebuffer + xinelibout and was unhappy with switching time, even on the same transponder. I've went back to 1.7.0 + the same xinelibout and see big improvements in switching time. I can see sync early messages in VDR logs, so I assume it makes the difference. Livebuffer probably breaks the ability to sync early. Regards, Artem ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Color keys replacement
On Sat, Jan 10, 2009 at 6:54 PM, user. vdr user@gmail.com wrote: On Sat, Jan 10, 2009 at 8:34 AM, Alex Betis alex.be...@gmail.com wrote: Hi all, A question regarding the color keys functionality in VDR. Some remotes I see in shops don't have the color keys, is there any replacement key for those? Is it possible to map them to 1,2,3,4? Can you think of a scenario both color keys and numbers might be used in the same menu? You can map any function to any key you want. One example of numbers colors being used in the same menu is the main menu itself. Numbers take you straight to sub-menus or plugins while the color keys perform functions like start recording or change the audio pid. Good point. My advice, just buy a remote with the color keys and save yourself some hassle! Yeah, that are my thoughts as well. I just look on the latest products of logitech and see that there are no color buttons. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] LIRC configuration
Hello all, Not a VDR question, but I'm sure someone can help me here. I've finally bought a remote control for my HTPC from a company named SunWave, model SMR-140. Looks like a MCE clone. It has an USB IR receiver that recognized as keyboard and mouse device (the remote has a joystick that can be used to move mouse). I can use the remote without lirc since it operates as keyboard. Few questions about that: 1. I want to install XBMC in near future so I'll need irexec functionality. Do I really need lirc for that? Or is there any other option to do it? 2. The remote sends sequence of keys for a single button, for example play button sends LEFTCTR, LEFTSHIFT and P. How can I map that sequence to represent a single button? 3. If someone has that remote (or maybe other remotes with the same strange behavior). The behavior of stop button is very strange. It sends back or forward or homepage or bookmark depending on what Sx button was pressed before. Pressing stop again gives no input at all untill I'll press a Sx button. Is there any trick to make it work in more expected way? Thanks! Alex. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
On Thu, Jan 8, 2009 at 11:17 PM, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: On 08.01.2009 20:41, Alex Betis wrote: On Thu, Jan 8, 2009 at 7:50 PM, user. vdr user@gmail.com mailto:user@gmail.com wrote: On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger klaus.schmidin...@cadsoft.de mailto:klaus.schmidin...@cadsoft.de wrote: + The directory name for a recording has been changed from -MM-DD-hh[.:]mm.pr.lt.rec (pr=priority, lt=lifetime) to -MM-DD-hh.mm.ch-ri.rec (ch=channel, ri=resumeId). Is the channel number even necessary information to store in a dirname? I've experienced many times where channels have been shuffled (requiring a rescanning a new channels.conf) so channel 100 could be one network today and a different one tomorrow. Maybe a better choice would be using the channel shortname, for example: -MM-DD-hh.mm.CNN-ri.rec -MM-DD-hh.mm.BBC-ri.rec I don't know how VDR work, but I think it will be wise to have a file with the same filename and .info or even .epg extension that will have relevant EPG section for the recorded program including full channel name. That's all already contained in the 'info' file of a recording. Great! So I didn't reinvent the wheel :) If the recording timer was set manualy, maybe it should include all programs that lay between start and end of the recording. It stores the EPG data of the longest broadcast within the timer window. That's fine if only one program is intended to be recorded. What if someone wants to record a bunch of programs? There are lots of music shows in the night between 31/12 and 01/01 of every year. With old tape recorder I just pressed REC and hope that the tape will contain as many programs as possible. In such case I would like to see all recorded programs descriptions. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Soft RAID-5 + LVM file system corruption
Some updated, to close that issue for those who will find it in the list later. File system corruption was not the only anomaly in my system, for example WiFi card had different MAC address every boot and few more interesting things... I've replaced memory modules although memtest didn't find any problem with all its tests. It's too early to be sure, but so far everything looks fine, so I'm staying with LVM over RAID5 for now since its the most flexible way to manage hard disk space. On Thu, Dec 18, 2008 at 9:51 PM, Alex Betis alex.be...@gmail.com wrote: Hello all, A system question, not so VDR related, but I hope someone in the list use the same configuration. From time to time my system won't boot since ext3 file system got corrupted and asks me to log in as root and run fsck manually. No bad blocks are found, just incorrectly stored nodes that are always fixed. I have 3 320GByte SATA disks partitioned to several large partitions, those partitions are configured to software RAID-5 between disks and on those RAID-5 partitions there are 2 LVM volumes, one for system and another for storage. There are also 250 MByte partition on every disk, while 2 of them are configured to software RAID-1 and mapped to /boot. System LVM gets corrupted more often since its used more intensively. Does anybody here have the same configuration? Or any other software RAID-5 configuration? Did anyone faced such problems? Maybe someone facing the same problem without RAIDs? Any help will be appreciated. I'm running on Fedora 10 with 2.6.27 kernel. I had the same problem with Fedora 8 as well. Thanks. Alex. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Soft RAID-5 + LVM file system corruption
On Fri, Dec 19, 2008 at 11:21 AM, Nicolas Huillard nico...@huillard.netwrote: Tony Houghton a écrit : On Thu, 18 Dec 2008 23:32:31 +0200 Alex Betis alex.be...@gmail.com wrote: I've tried Ubuntu about a year ago, but it didn't support any RAID nor LVM configurations in installation stage, so I went back to Fedora, which has all those options. I can't find much about this on ubuntu.com, but its alternate (text mode installer) download definitley used to support LVM and no doubt still does. I'm pretty sure it's based on Debian's installer, which apparently does also support RAID. I installed Debian with RAID + LVM at the text installer stage many times. One can install almost any RAID + LVM mix directly with the installer. No problem since many years, but I always use ReiserFS, even for /boot. I also use RAID1 instead fo RAID5. I've spent half a day googling around to see if someone had the same problem as I have. People reported even worse problems than mine, all reported that it happened only with ext3, but did not happen with reiser. Looks like big caches on hard drives cause some problems so the journal info is not properly written. Since ext3 doesn't have CRC on journal blocks, it can't detect the problem. The issue is supposed to be solved in ext4. Although other file systems didn't report any problem, everyone said it still doesn't mean there is no problem, maybe other FSs didn't detect it yet. Also, many sysadmins that manage large systems write against LVM when not needed (like in our case), according to them its just adds non-needed complexity and cause some problems. I kinda agree with them. So I'm in process now of removing the LVM and stay with RAID1 for boot, RAID5 for system, swap and storage. I'll probably stay with ext3 for now. My home server : * hda1, hdc1 : /boot, selected by the BIOS * hda2 + hdc2 : RAID1 + LVM, for system FS (/, /var, /usr, etc) * hda3, hdc3 : bare swap * hda4 + hdc4 : LVM (/home, /backup) * hdb1 + hdd1 : LVM in stripped mode (/video) My hosting servers have similar setups, with DRBD in the game (network RAID1). How do you setup this thing? Can't you just use rsync or something similar? -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Soft RAID-5 + LVM file system corruption
Hello all, A system question, not so VDR related, but I hope someone in the list use the same configuration. From time to time my system won't boot since ext3 file system got corrupted and asks me to log in as root and run fsck manually. No bad blocks are found, just incorrectly stored nodes that are always fixed. I have 3 320GByte SATA disks partitioned to several large partitions, those partitions are configured to software RAID-5 between disks and on those RAID-5 partitions there are 2 LVM volumes, one for system and another for storage. There are also 250 MByte partition on every disk, while 2 of them are configured to software RAID-1 and mapped to /boot. System LVM gets corrupted more often since its used more intensively. Does anybody here have the same configuration? Or any other software RAID-5 configuration? Did anyone faced such problems? Maybe someone facing the same problem without RAIDs? Any help will be appreciated. I'm running on Fedora 10 with 2.6.27 kernel. I had the same problem with Fedora 8 as well. Thanks. Alex. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Duplicate channels list
Strange... I sent that email to the list, but it doesn't appear there. Resending... Hi Klaus, What is the motivation behind the logic of not allowing duplicate channels in channels.conf file? I've tried to mimic channels settings of my Topfield receiver where I have favorite channels divided in different groups, while I can still access any channel on any satellite. I've intended to have it that way: :News :Sport :Kids :Radio :@1 All :Sat1 :Sat2 :Sat3 Where SatX group has all the channels of that satellite and News,Sport,Kids,Radio groups will act as favorite channels groups having the same channels as in SatX groups. I had to change some functions in channels.c to update all duplicate channels when an update should be done. If anyone is interested I'll post it here. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and Switching time
Found a solution for the delay, please try it and report if it helps you and even more important if it doesn't break something else. Special testing should be done for HD channels with high streams. Change line 77 in xine_input_vdr.c from: #define METRONOM_PREBUFFER_VAL (4 * 9 / 25 ) to: #define METRONOM_PREBUFFER_VAL 128//(4 * 9 / 25 ) Some documentation says something that large buffers are needed for mosaic channels (what is it anyway?). Looks like there is another buffer somewhere on the way... Please report the results. Thanks. On Thu, Dec 11, 2008 at 11:23 PM, Alex Betis alex.be...@gmail.com wrote: Gents, could you please run vdr-sxfe with --verbose flag and check if you see the prebuffer= line in console output when you switch the channel? Please state the number you see there and please write again your vdr, xine-lib and xinelibout versions. Thanks. 2008/12/11 Rolf Ahrenberg rahre...@cc.hut.fi On Thu, 11 Dec 2008, Goga777 wrote: 4. vdr 1.7.0(1) xineliboutput, directfb - 2-3 sec, xineliboutput, x11 - 2-4 sec seems it's due to of tcp/ip and pipes which are using xineliboutput Well, I have vdr-1.6.0 and xinelibout-cvs with vdr-sxfe on my development setup using latest kernel drivers (S2API, DVB-T card) and haven't ever noticed as slow zapping as you documented: the channel switching time is about one second. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and Switching time
On Fri, Dec 12, 2008 at 4:47 PM, Theunis Potgieter theunis.potgie...@gmail.com wrote: On 12/12/2008, Alex Betis alex.be...@gmail.com wrote: Found a solution for the delay, please try it and report if it helps you and even more important if it doesn't break something else. Special testing should be done for HD channels with high streams. Change line 77 in xine_input_vdr.c from: #define METRONOM_PREBUFFER_VAL (4 * 9 / 25 ) to: #define METRONOM_PREBUFFER_VAL 128//(4 * 9 / 25 ) so from 14400 to 128 lol, making it smaller helps with higher streams? I wrote that special testing is needed for high streams, I didn't write that it helps it somehow. I personally don't have HD channels available, so can't test myself. As I also wrote, there is probably another buffer on the way (driver?), so it might be enough. By the way, I'm more than sure there is a buffer in driver since scan-s2 gets messages from previous channel after it already tuned to a new one. At least with stb0899 (TT3200 and Twinhan 1041) driver. Some documentation says something that large buffers are needed for mosaic channels (what is it anyway?). Looks like there is another buffer somewhere on the way... Please report the results. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 1.7.1 + multiple audio streams on channel = buffer problem
Hi, I'm with 1.7.1 and observe some buffer problems on channels with multiple audio streams. Bandwidth of audio steams probably make a different since I observe problems with channel that has 6 audio tracks or even 4 audio tracks, while there are other channels with 4 tracks that have no problem at all. I guess thats a result of moving to TS. Any hint what buffer should I increase? VDR log shows the following: Dec 12 19:37:09 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:09 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:13 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:14 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:14 htpc vdr: [21748] buffer usage: 90% (tid=21747) Dec 12 19:37:15 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:18 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:19 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC1): skipped 348 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC5): skipped 588 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC4): skipped 1260 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC0): skipped 1260 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC3): skipped 1356 bytes while syncing on next audio frame Dec 12 19:37:19 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:19 htpc vdr: [21746] cAudioRepacker(0xC2): skipped 1660 bytes while syncing on next audio frame Dec 12 19:37:22 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:23 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:23 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:27 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:27 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:27 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC4): skipped 636 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC0): skipped 636 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC3): skipped 732 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 2 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC2): skipped 57 bytes to sync on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC5): skipped 1756 bytes while syncing on next audio frame Dec 12 19:37:32 htpc vdr: [21746] 1 cRepacker messages suppressed Dec 12 19:37:32 htpc vdr: [21746] cAudioRepacker(0xC1): skipped 756 bytes to sync on next audio frame Dec 12 19:37:35 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:36 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:36 htpc vdr: [21748] buffer usage: 60% (tid=21747) Dec 12 19:37:39 htpc vdr: [21748] buffer usage: 70% (tid=21747) Dec 12 19:37:40 htpc vdr: [21748] buffer usage: 80% (tid=21747) Dec 12 19:37:40 htpc vdr: [21748] buffer usage: 90% (tid=21747) Dec 12 19:37:40 htpc vdr: [21748] buffer usage: 60% (tid=21747) Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and Switching time
Gents, could you please run vdr-sxfe with --verbose flag and check if you see the prebuffer= line in console output when you switch the channel? Please state the number you see there and please write again your vdr, xine-lib and xinelibout versions. Thanks. 2008/12/11 Rolf Ahrenberg rahre...@cc.hut.fi On Thu, 11 Dec 2008, Goga777 wrote: 4. vdr 1.7.0(1) xineliboutput, directfb - 2-3 sec, xineliboutput, x11 - 2-4 sec seems it's due to of tcp/ip and pipes which are using xineliboutput Well, I have vdr-1.6.0 and xinelibout-cvs with vdr-sxfe on my development setup using latest kernel drivers (S2API, DVB-T card) and haven't ever noticed as slow zapping as you documented: the channel switching time is about one second. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with S2API (update)
On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger [EMAIL PROTECTED] wrote: On 07.12.2008 13:21, Klaus Schmidinger wrote: Attached is an updated version of the patch to make VDR use the S2API. Dominik Strasser reported that he got log entries like Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0 out of range (451875..723) and I now also get Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0 out of range (500..4500) when trying to tune to a DVB-S2 channel. The attached patch logs the value put into the DTV_SYMBOL_RATE slot, and it appears to be fine. Why the value falls back to 0 when tuning is currently totally unclear (as is the large frontend value in Dominik's case). Any help in debugging this would be appreciated. Some more info: apparently the problem only happens if a DVB-S2 card (a TT-budget S2 3200 in my case) is (attempted to be) tuned to a DVB-S2 channel after the driver has been freshly loaded. Once the card has been tuned to a DVB-S channel, subsequent tuning to DVB-S2 channels works fine. That scenario works fine with scan-s2 utility. Now I'm unsure whether this is a VDR bug or a driver bug... Where is the origin of frontend value? I think its VDR internal and is not received from the driver... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Few more questions about xinelibout
On Fri, Dec 5, 2008 at 12:25 AM, Petri Helin [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 11:43 PM, Alex Betis [EMAIL PROTECTED] wrote: Hi all, Few more questions about xinelibout. I've run the frontend now as a separate task and looks like it doesn't crash now except when I try to open a picture, I'll try to debug it later. Perhaps your pictures a too big for xv? Try to reduce their size. I would expect the software to do it... The questions are probably very simple: - When I playback a file, how can I move back? When replaying a live stream my and keys act as backward and forward buttons. In file playback forward runs the movie forward indeed, but backward button slows the playback until its fully stopped. This is a standard feature/restriction of many software players. You can jump backwards a given number of seconds, but a true rewind is not possible. Jump back is good enough, the question is how can I do it in xinelibout frontend? - Does deinterlacing settings from VDR menu apply also to movie playback? Sometimes I can see effects of picture is not sync with the screen, I mean that the picture is shown as its 2 halfs (top and bottom) that are moving in very little difference. Thats mostly seen when the whole picture is moved. Sounds like tearing to me. Usually caused by difference in the output refresh rate and the video being played back, or just crappy drivers (like Intel with certain hardware combined with Textured video). I was looking for the right word... tearing... I have nVidia 177.82 driver. Again, mplayer has no such problem. Thanks. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Few more questions about xinelibout
On Fri, Dec 5, 2008 at 10:59 AM, Petri Helin [EMAIL PROTECTED] wrote: I've run the frontend now as a separate task and looks like it doesn't crash now except when I try to open a picture, I'll try to debug it later. Perhaps your pictures a too big for xv? Try to reduce their size. I would expect the software to do it... You need to patch xine-lib to do that. But first I suggest you try out with smaller pictures to confirm the reason. What is the resolution of the pictures? You're right! Small sized pictures (640x480) do not crash it, while the ones from my camera without conversion (3072x2304) crash it. Could you point me to a patch xine-lib to scale automatically? The questions are probably very simple: - When I playback a file, how can I move back? When replaying a live stream my and keys act as backward and forward buttons. In file playback forward runs the movie forward indeed, but backward button slows the playback until its fully stopped. This is a standard feature/restriction of many software players. You can jump backwards a given number of seconds, but a true rewind is not possible. Jump back is good enough, the question is how can I do it in xinelibout frontend? See the README file under Media player key bindings for video files: GreenJump 1 min back Yellow Jump 1 min forward 1, User8 Jump 20 s back 3, User9 Jump 20 s forward Thanks! I've read it long ago and forgot that part already. - Does deinterlacing settings from VDR menu apply also to movie playback? Sometimes I can see effects of picture is not sync with the screen, I mean that the picture is shown as its 2 halfs (top and bottom) that are moving in very little difference. Thats mostly seen when the whole picture is moved. Sounds like tearing to me. Usually caused by difference in the output refresh rate and the video being played back, or just crappy drivers (like Intel with certain hardware combined with Textured video). I was looking for the right word... tearing... I have nVidia 177.82 driver. Again, mplayer has no such problem. Try xine-ui with the same file. If that works, compare files ~/.xine/config and ~/.xine/config_xineliboutput for any differences. Strange thing is that I don't see tearing any more. But I'll know where to look in case it comes back. By the way, I assume the configuration is overwritten by frontend somehow since the config_xineliboutput says there is no deinterlacing, while frontend settings include deinterlacing. Do you know where the frontend configuration is stored? The plugins\xineliboutput in VDR config is empty. Thanks again! -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Few more questions about xinelibout
On Fri, Dec 5, 2008 at 11:06 AM, Gerald Dachs [EMAIL PROTECTED] wrote: Quoting Alex Betis [EMAIL PROTECTED]: I was looking for the right word... tearing... I have nVidia 177.82 driver. Again, mplayer has no such problem. You could try to activate all sync to vblank irqs with nvidia-settings. I've checked it now, its set to Sync to VBlank already in XVideo setting tab. It's not set in OpenGL, but I don't use it for playback. As I wrote, the problem is gone somehow. Thanks. Gerald This message was sent using IMP, the Internet Messaging Program. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Switching time
Hi all, Another question to bother you... How long does it takes to switch a FTA channel on your system? In my case DVB-S. I wonder if this timing sounds ok to you (I think its kind of slow): 1.7.1 + ext64-livebuffer + xinelibout 2 channels on the same transponder - about 2 seconds - video and sound playing right after the switch. 2 channels on different transponders - about 4 seconds - sound is playing right after the switch, image is shown, but start moving about 1 more second later. Please let me know what is your status on that (including version you're using). Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Switching time
On Sat, Dec 6, 2008 at 12:58 AM, VDR User [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 11:34 AM, Morfsta [EMAIL PROTECTED] wrote: On Fri, Dec 5, 2008 at 11:05 AM, Alex Betis [EMAIL PROTECTED] wrote: 2 channels on the same transponder - about 2 seconds - video and sound playing right after the switch. 2 channels on different transponders - about 4 seconds - sound is playing right after the switch, image is shown, but start moving about 1 more second later. Sounds long, I can channel change on DVB-T and DVB-S almost instantaneously. You can normally fix this by recompiling your kernel with low latency settings (timer frequency, kernel queuing methods etc) - normally selecting the best settings for a desktop helps. I agree. My channel changes are about 1 second regardless if I'm switching on different transponders or lnbs. You're saying that kernel provided by distributors (Fedora 10 in my case) is not tuned for desktops? Interesting... Will try that after I'll try moving back to 1.7.0. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Few more questions about xinelibout
Hi all, Few more questions about xinelibout. I've run the frontend now as a separate task and looks like it doesn't crash now except when I try to open a picture, I'll try to debug it later. The questions are probably very simple: - When I playback a file, how can I move back? When replaying a live stream my and keys act as backward and forward buttons. In file playback forward runs the movie forward indeed, but backward button slows the playback until its fully stopped. - How can I restart the playback? Last position in the movie is stored, which is good, but how can I reset it and start from the beginning? - Does deinterlacing settings from VDR menu apply also to movie playback? Sometimes I can see effects of picture is not sync with the screen, I mean that the picture is shown as its 2 halfs (top and bottom) that are moving in very little difference. Thats mostly seen when the whole picture is moved. I'm sure its something with the settings since playback of the movie in gxine or mplayer gives me good results. Will appreciate any help with that. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput OSD and playback problems
On Mon, Dec 1, 2008 at 3:04 PM, Antti Seppälä [EMAIL PROTECTED][EMAIL PROTECTED] wrote: 2008/12/1 Alex Betis [EMAIL PROTECTED]: Hi, Please advice how to configure xineliboutput in the best way... I have 1.7.1 + ext64 patches, xineliboutput 1.0.3, nVidia card with latest drivers. After many tests I have the following: Using --hud gives best OSD I ever seen, but it shows only the OSD when the output window is in focus and no playback. When I select another window (loose focus), I see the playback, but this way I can't control it... Reports about this pop-up occasionally so I'll try to clarify: You need a compositing window manager to see both the hud osd and video at the same time. I recommend xcompmgr because it can run in parallel to your normal window manager and serve the necessary compositing extensions as an addition. Of the compositing managers I've tried it also seems to be the fastest / least cpu intensive. So install xcompmgr and run: xcompmgr -n prior to starting vdr-sxfe --hud You'll need to setup xorg.conf so that compositing is enabled. IOW you should have lines similar to following in you xorg.conf: Section Extensions Option Composite Enable EndSection Thanks alot! xcompmgr is definitely takes less than compiz that I've tried to use. Concerning your other display issues (opengl osd etc.) I'd recommend trying without patched vdr and maybe latest version of xine-lib. False alert, I guess I had left a remote session to HTPC from other computer, so that caused high CPU usage. Right now I've set with XV video and I have about 12-15% CPU with cheap tvtime (mplayer mode) deinterlacing and 18-20% CPU with non-cheap deinterlacing mode which in my opinion gives best results I could find so far. OpenGL takes about 2-3% more than that. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput OSD and playback problems
On Tue, Dec 2, 2008 at 12:14 AM, Tony Houghton [EMAIL PROTECTED] wrote: On Tue, 2 Dec 2008 00:05:54 +0200 Alex Betis [EMAIL PROTECTED] wrote: Right now I've set with XV video and I have about 12-15% CPU with cheap tvtime (mplayer mode) deinterlacing and 18-20% CPU with non-cheap deinterlacing mode which in my opinion gives best results I could find so far. OpenGL takes about 2-3% more than that. According to http://linuxtv.org/wiki/index.php/Development:_The_DVB_Decoder_Challenge#Deinterlacing it should be possible to use OpenGL to mimic a CRT TV's phosphor for deinterlacing but I haven't seen or even heard of the idea put into practice. I'll try to play around with it more. In fact I saw better picture with OpenGL when deinterlacing was disabled at all. Not sure I saw those alternating alpha and alpha parameters in the menu... -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput - invalid data
On Sun, Nov 30, 2008 at 10:36 PM, Alex Betis [EMAIL PROTECTED] wrote: On Sat, Nov 29, 2008 at 11:47 PM, Niels Wagenaar [EMAIL PROTECTED]wrote: You have two options: - Go back to 1.7.0; - Use the LIVEBUFFER patch by patching VDR 1.7.1 with the VDR-Extensions patch; See http://linuxtv.org/pipermail/vdr/2008-October/017948.html for more information. Thank you Niels. Looks like it works. Few questions: Does you (or anybody) know where I can find explanation of every module in that extension pack in English? For an average SD channel, how long the default 5MB buffer of LIVEBUFFER can store the data? What happen when the buffer is full? Old data is discarded or the new data is ignored? Two more questions... :) In channels list I see an unknown character before the channel name (for me it looks like a square. It appeared after the extension patches. Anyone knows how to get rid of it? I remember long ago when watching channels that were recorded (or probably time shifted) on the disk I saw a bar that shows the location in the buffer. Anyone knows if its possible to see that bar for LIVEBUFFER shifting? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput OSD and playback problems
Hi, Please advice how to configure xineliboutput in the best way... I have 1.7.1 + ext64 patches, xineliboutput 1.0.3, nVidia card with latest drivers. After many tests I have the following: Using --hud gives best OSD I ever seen, but it shows only the OSD when the output window is in focus and no playback. When I select another window (loose focus), I see the playback, but this way I can't control it... Using opengl video output gives me the best playback quality with lowest CPU usage, but it doesn't show any OSD at all, nor software nor hardware. Using xv video output with deinterlacing takes about 40-50% of CPU on my E6600 system. OSD is shown ok (don't remember already, but I think only software based OSD works well). Using xxmc video output with deinterlacing takes less than 40% CPU, hardware OSD works well, but with tvtime deinterlacing looks like frames are dropped. Non tvtime deinterlacing doesn't look that good. Using xvmc output doesn't work since there is a module that can't be found. Please advice how can it be configured to have both low CPU, good deinterlaced image and an OSD (preffered the --hud one). Thank you. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput - invalid data
Hi, I'm trying to configure xineliboutput 1.0.3 with VDR 1.7.1. Compilation and installation seems to go ok, but playback doesn't work. I can see OSD in opened window, but when it gets to the channel itself CPU usage jumps to 100% and the log contains: Nov 30 01:24:17 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (185008 bytes) ! Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (185008 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:17 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (192000 bytes) ! Nov 30 01:24:17 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (192000 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:18 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (243888 bytes) ! Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (243888 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:18 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (260816 bytes) ! Nov 30 01:24:18 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (260816 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:19 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (245728 bytes) ! Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (245728 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:19 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (242416 bytes) ! Nov 30 01:24:19 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (242416 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:20 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (249776 bytes) ! Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (249776 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:20 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (257320 bytes) ! Nov 30 01:24:20 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (257320 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:21 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (268176 bytes) ! Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (268176 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:21 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (268912 bytes) ! Nov 30 01:24:21 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (268912 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:22 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (237632 bytes) ! Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (237632 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:22 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] get_buf_element: jumbo PES (215000 bytes) ! Nov 30 01:24:22 htpc vdr: [13512] [input_vdr] vdr_plugin_write: PES too long (215000 bytes, max size 8192 bytes), data ignored ! Nov 30 01:24:23 htpc vdr: [13512] [xine..put] cXinelibDevice::PlayAny: invalid data ! Any ideas? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR - S2API: 2 questions
On Sat, Nov 22, 2008 at 6:35 PM, Klaus Schmidinger [EMAIL PROTECTED] wrote: On 22.11.2008 17:25, Georg Acher wrote: On Sat, Nov 22, 2008 at 06:21:51PM +0200, Alex Betis wrote: On Sat, Nov 22, 2008 at 5:14 PM, Klaus Schmidinger [EMAIL PROTECTED] wrote: Maybe I'm totally missing something here, but I can't figure out how an application using the S2API driver can tell whether a DVB device is DVB-S or DVB-S2. Can somebody please point me in the right direction here? I run into the same question when made changes in scan-s2 application. The question I want to ask is why do you really need it? Ressource allocation. If there is also a S-only tuner avaliable you don't want to waste the precious S2-tuner for S-stuff. Also it can be important for timer collision checking. Exactly. If a channel is DVB-S2, I don't even want to try a DVB-S only card. Good point. Lets wait for someone on dvb list to answer. Am I really to believe that S2API doesn't provide that information? If so, what exactly does the S2 in S2API stand for? ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Windows remote client
I've decided to use VLC with streamdev, works fine for now. Not sure about multicast, it works with unicast streams, but since I have only one remote client it doesn't matter for me. Thanks everybody for replies. On Fri, Nov 21, 2008 at 10:02 AM, Theunis Potgieter [EMAIL PROTECTED] wrote: VLC runs on *nix and Windows, I've read where streamdev is combined with vlc enables the stream to be multicast. On 20/11/2008, Alex Betis [EMAIL PROTECTED] wrote: Hello all, Is there a plugin for VDR (I use 1.7.1) that allows a windows based client to watch the channels remotely? What windows based clients can I use in that case? Is there a network overhead for watching a stream? I mean if the stream is 5Mbit, will it take 5Mbit of my network or the traffic will take more? In case the client is used with a small window that can't show the whole picture, will the network load be reduced? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.7.1 + xine = memory leak?
Hi all, I think there is a memory leak with xine as output device (I have version 0.8.2). Watching the same channel for 15 minutes rises memory usage of VDR process from 10MB to about 200! Switching channel free that memory. I've tried to do the same with streamdev and the memory stays on 10MB level, so I have a feeling its related to xine. If someone have similar setup, please test it on your machine and share results. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Windows remote client
Hello all, Is there a plugin for VDR (I use 1.7.1) that allows a windows based client to watch the channels remotely? What windows based clients can I use in that case? Is there a network overhead for watching a stream? I mean if the stream is 5Mbit, will it take 5Mbit of my network or the traffic will take more? In case the client is used with a small window that can't show the whole picture, will the network load be reduced? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Windows remote client
On Thu, Nov 20, 2008 at 7:42 PM, [EMAIL PROTECTED] wrote: Hi The best solution, at my opinion, is to use the plugin vomp under vdr and run the vompclient under windows, you will have access to channels, records and timers http://www.loggytronic.com/vomp.php Thanks. Nice project. I'll try to use it, few questions still bother me. What is MVP that that client was intended to use? Why creating its own GUI and not pass the output of VDR (with all the menus) on the network to the client as VLC and streamdev do it? Maybe the intention was to pass only DVB traffic... Anyone tried to use the VOMP client as an output device on Linux instead of xine or softdevice? Thanks! Best regards Selon Alex Betis [EMAIL PROTECTED]: Hello all, Is there a plugin for VDR (I use 1.7.1) that allows a windows based client to watch the channels remotely? What windows based clients can I use in that case? Is there a network overhead for watching a stream? I mean if the stream is 5Mbit, will it take 5Mbit of my network or the traffic will take more? In case the client is used with a small window that can't show the whole picture, will the network load be reduced? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Windows remote client
Any ideas if it can decode MPEG4 and playback mp3? On Thu, Nov 20, 2008 at 9:14 PM, Gavin Hamill [EMAIL PROTECTED] wrote: On Thu, 2008-11-20 at 21:04 +0200, Alex Betis wrote: Thanks. Nice project. I'll try to use it, few questions still bother me. What is MVP that that client was intended to use? Hauppauge MediaMVP - small hardware device that was supposed to use its own Hauppauge Windows software as its 'server' - the vomp plugins allow VDR to be the server for these devices. Why creating its own GUI and not pass the output of VDR (with all the menus) on the network to the client as VLC and streamdev do it? Maybe the intention was to pass only DVB traffic... The vomp windows client seems to be a software implementation of the MediaMVP hardware, so hence it's using the same protocols :) There is no standard method by which to 'pass all the menus on the network'... Anyone tried to use the VOMP client as an output device on Linux instead of xine or softdevice? Yes, works fine. I use it from time to time with a full-featured card. Mainly I just stream a single channel with VLC, tho :) gdh ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Twinhan 1041 card (stb0899) - femon 1.6.2 gives no signal info
Hi, Anyone with stb0899 (Twinhan 1041, TT3200) card can see signal info using femon? Currently it shows no signal info at all. I previously used Twinhan 1034 card and femon wasn't working properly as well. I use Igor's S2API drivers. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New Video Decode and Presentation API from NVidia
Good news! Competition with Intel benefits us all :) On Fri, Nov 14, 2008 at 9:03 PM, Goga777 [EMAIL PROTECTED] wrote: FROM XORG lIST I'm pleased to announce a new video API for Unix and Unix-like platforms, and a technology preview implementation of this API from NVIDIA. The API is called VDPAU (Video Decode and Presentation API for Unix). The current API documentation is here: ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/index.html Some highlights of VDPAU: * Defines an API for GPU-accelerated decode of MPEG-1, MPEG-2, H.264, and VC-1 bitstreams. * Defines an API for post-processing of decoded video, including temporal and spatial deinterlacing, inverse telecine, and noise reduction. * Defines an API for timestamp-based presentation of final video frames. * Defines an API for compositing sub-picture, on-screen display, and other UI elements. Note that VDPAU does not address content protection. Some highlights/limitations of NVIDIA's current implementation: * Supported on NVIDIA GPUs with the NVIDIA second generation video processors (see the end of this announcement for a complete GPU list). * Currently, only one video stream can be decoded at a time; we hope to lift this restriction eventually. * Available in the 180.06 NVIDIA public beta release: http://www.nvidia.com/object/linux_display_ia32_180.06.html http://www.nvidia.com/object/linux_display_amd64_180.06.html http://www.nvidia.com/object/freebsd_180.06.html http://www.nvidia.com/object/solaris_display_180.06.html The VDPAU support in the NVIDIA 180.06 beta release is still very preliminary. We are aware of cases of visual corruption and in some cases GPU hangs. We will be working on these issues over the next several NVIDIA driver releases. While NVIDIA's VDPAU implementation is not ready for end user use yet, it should be far enough along that interested application developers can begin working with it. Additionally, NVIDIA has developed patches to ffmpeg and MPlayer to demonstrate a video player using VDPAU: ftp://download.nvidia.com/XFree86/vdpau/mplayer-vdpau-3076399.tar.bz2 These patches include changes against libavcodec, libavutil, ffmpeg, and MPlayer itself; they may serve as an example of how to use VDPAU. Once we do some further testing, bugfixing, and cleanup, we will contribute the MPlayer patches to the MPlayer developers. If other hardware vendors are interested, they are welcome to also provide implementations of VDPAU. The VDPAU API was designed to allow a vendor backend to be selected at run time. Thanks, Andy Ritger Manager, NVIDIA Linux Graphics Driver VDPAU is currently supported on the following NVIDIA GPUs: Desktop GPUs: GeForce 200 Series GeForce 9 Series GeForce 86xx Series GeForce 85xx Series GeForce 84xx Series GeForce 8800 GTS 512 GeForce 8800 GT GeForce 8800 GS Mobile GPUs: GeForce 98xxM GeForce 9700M GeForce 96xxM GeForce 9500M GeForce 9300M GeForce 9200M GeForce 8800M GeForce 8800M GTS GeForce 8800M GTX GeForce 8600M Motherboard GPUs: GeForce 9400 GeForce 9300 GeForce 9100 GeForce 8300 GeForce 8200 VC-1 support in NVIDIA's VDPAU implementation currently requires GeForce 9300 GS, GeForce 9200M GS, GeForce 9300M GS, or GeForce 9300M GS. ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
