Re: [vdr] German translation for Plugin
Hi, I agree with Klaus abnd others to keep the term plugin. I am old enought to recall the German Datasheets from Siemens. It was hard to find the right things because of all the German names. -- Many regards, dmfhhp ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Choice of recording format
TS is what's broadcast, so every device that's able to play DVB broadcasts must be able to play TS. Therefore recording the TS as is (of course only the PIDs belonging to one programme) makes the most sense. I am hoping that recording takes all PIDs belonging to a program, including all private streams for all subtitles. And even without any plugin to request them. Later when you process the file with some other software, then subtitles or other sound tracks might be needed. Or they can be discarded on TS editors later. But you cannot generate them if you don't have them. I think removing 'not plugin requested PIDs' saves very little space on disk. And proportionally even less for HD recordings. For a hour HD programme ( HD H.264: ~5.5GB (@ 12Mbps) AC3: ~170MB (@ 384kbps) MPEG2 audio: ~100MB (@ 224kbps) DVB subtitles: 50MB (just a guess 50kb per subtitle image * 1000 subtitles per show) TXT subtitles: 0.5MB (just a guess 0.5kB * 1000 subtitles per show) So I suggest on TS-format (at least make it setup-menu configurable): - record all audio tracks - record all dvb subtitles tracks - record all txt subtitles tracks (might be handy on MKV SRT-conversion) - I know Klaus' intention to convert TXT - DVB subtitles just to store one format on file at recording time? But I don't like that because it is not recording the original stream. - Jori smime.p7s Description: S/MIME cryptographic signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Choice of recording format
On 12.01.2009 10:42, Magnus Hörlin wrote: -Ursprungligt meddelande- Från: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] För jori.hamalai...@teliasonera.com Skickat: den 12 januari 2009 09:52 Till: vdr@linuxtv.org Ämne: Re: [vdr] Choice of recording format TS is what's broadcast, so every device that's able to play DVB broadcasts must be able to play TS. Therefore recording the TS as is (of course only the PIDs belonging to one programme) makes the most sense. I am hoping that recording takes all PIDs belonging to a program, including all private streams for all subtitles. And even without any plugin to request them. Later when you process the file with some other software, then subtitles or other sound tracks might be needed. Or they can be discarded on TS editors later. But you cannot generate them if you don't have them. I think removing 'not plugin requested PIDs' saves very little space on disk. And proportionally even less for HD recordings. For a hour HD programme ( HD H.264: ~5.5GB (@ 12Mbps) AC3: ~170MB (@ 384kbps) MPEG2 audio: ~100MB (@ 224kbps) DVB subtitles: 50MB (just a guess 50kb per subtitle image * 1000 subtitles per show) TXT subtitles: 0.5MB (just a guess 0.5kB * 1000 subtitles per show) So I suggest on TS-format (at least make it setup-menu configurable): - record all audio tracks - record all dvb subtitles tracks - record all txt subtitles tracks (might be handy on MKV SRT-conversion) - I know Klaus' intention to convert TXT - DVB subtitles just to store one format on file at recording time? But I don't like that because it is not recording the original stream. - Jori Thanks Jori, I fully agree. Hope Klaus does too The TS version of VDR records exactly the same PIDs as the PES version did. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Choice of recording format
-Ursprungligt meddelande- Från: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] För jori.hamalai...@teliasonera.com Skickat: den 12 januari 2009 09:52 Till: vdr@linuxtv.org Ämne: Re: [vdr] Choice of recording format TS is what's broadcast, so every device that's able to play DVB broadcasts must be able to play TS. Therefore recording the TS as is (of course only the PIDs belonging to one programme) makes the most sense. I am hoping that recording takes all PIDs belonging to a program, including all private streams for all subtitles. And even without any plugin to request them. Later when you process the file with some other software, then subtitles or other sound tracks might be needed. Or they can be discarded on TS editors later. But you cannot generate them if you don't have them. I think removing 'not plugin requested PIDs' saves very little space on disk. And proportionally even less for HD recordings. For a hour HD programme ( HD H.264: ~5.5GB (@ 12Mbps) AC3: ~170MB (@ 384kbps) MPEG2 audio: ~100MB (@ 224kbps) DVB subtitles: 50MB (just a guess 50kb per subtitle image * 1000 subtitles per show) TXT subtitles: 0.5MB (just a guess 0.5kB * 1000 subtitles per show) So I suggest on TS-format (at least make it setup-menu configurable): - record all audio tracks - record all dvb subtitles tracks - record all txt subtitles tracks (might be handy on MKV SRT-conversion) - I know Klaus' intention to convert TXT - DVB subtitles just to store one format on file at recording time? But I don't like that because it is not recording the original stream. - Jori Thanks Jori, I fully agree. Hope Klaus does too /Magnus H ___ 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 Mon, Jan 12, 2009 at 10:27:42AM +0100, jean-p...@goedee.nl wrote: What must I do to make it work with 64bits system? I?m a simple user with no coding experience. Could you post your error, I am under x86_64 and only patch I needed was one found on vdrportal.de : --- tools.c 2009-01-06 23:09:35.0 +0100 +++ tools.c.mod 2009-01-06 23:09:43.0 +0100 @@ -1608,7 +1608,7 @@ // kind of write gathering enabled), but the syncs cause (io) load.. // Uncomment the next line if you think you need them. //fdatasync(fd); - off_t headdrop = min(curpos - totwritten, off_t(totwritten * 2)); + off_t headdrop = min(off_t(curpos - totwritten), off_t(totwritten * 2)); posix_fadvise(fd, curpos - totwritten - headdrop, totwritten + headdrop, POSIX_FADV_DONTNEED); totwritten = 0; } (Well I also use patch to allow more features...). -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.3 (streamdev)
On Mon, Jan 12, 2009 at 10:27:42AM +0100, jean-paul at goedee.nl wrote: What must I do to make it work with 64bits system? I?m a simple user with no coding experience. Could you post your error, I am under x86_64 and only patch I needed was one found on vdrportal.de : --- tools.c 2009-01-06 23:09:35.0 +0100 +++ tools.c.mod 2009-01-06 23:09:43.0 +0100 @@ -1608,7 +1608,7 @@ // kind of write gathering enabled), but the syncs cause (io) load.. // Uncomment the next line if you think you need them. //fdatasync(fd); - off_t headdrop = min(curpos - totwritten, off_t(totwritten * 2)); + off_t headdrop = min(off_t(curpos - totwritten), off_t(totwritten * 2)); posix_fadvise(fd, curpos - totwritten - headdrop, totwritten + headdrop, POSIX_FADV_DONTNEED); totwritten = 0; } (Well I also use patch to allow more features...). -- Thanks its compiling but I get now a error with compiling streamdev. PLUGIN_NAME_I18N='streamdev' -I../../../include -I. -o server/livestreamer.o server/livestreamer.c In file included from server/livestreamer.c:6: ./remux/ts2ps.h:13: error: âMAXTRACKSâ was not declared in this scope server/livestreamer.c: In member function âbool cStreamdevLiveStreamer::SetChannel(const cChannel*, eStreamType, int)â: server/livestreamer.c:464: error: new initializer expression list treated as compound expression server/livestreamer.c:464: error: no matching function for call to âcRemux::cRemux(bool)â ../../../include/vdr/remux.h:25: note: candidates are: cRemux::cRemux() ../../../include/vdr/remux.h:25: note: cRemux::cRemux(const cRemux) server/livestreamer.c: In member function âvirtual int cStreamdevLiveStreamer::Put(const uchar*, int)â: server/livestreamer.c:506: error: âclass cRemuxâ has no member named âPutâ server/livestreamer.c: In member function âvirtual uchar* cStreamdevLiveStreamer::Get(int)â: server/livestreamer.c:530: error: âclass cRemuxâ has no member named âGetâ server/livestreamer.c: In member function âvirtual void cStreamdevLiveStreamer::Del(int)â: server/livestreamer.c:555: error: âclass cRemuxâ has no member named âDelâ make[1]: *** [server/livestreamer.o] Error 1 make[1]: Leaving directory `/tmp/vdr/vdr-1.7.3/PLUGINS/src/streamdev' *** failed plugins: streamdev make: *** [plugins] Error 1 Thanks JP ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3 (streamdev)
On Mon, 12 Jan 2009 11:30:36 +0100, jean-paul wrote Thanks its compiling but I get now a error with compiling streamdev. Patch: http://www.vdr-developer.org/mantisbt/view.php?id=506 Cheers, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Choice of recording format
So I suggest on TS-format (at least make it setup-menu configurable): - record all audio tracks - record all dvb subtitles tracks - record all txt subtitles tracks (might be handy on MKV SRT-conversion) Thanks Jori, I fully agree. Hope Klaus does too The TS version of VDR records exactly the same PIDs as the PES version did. So I understand this that no TXT-subtitles recording is happening without txtsubs-plugin. And PAT/PMT tables needs to be modified on the fly to drop those PIDs? smime.p7s Description: S/MIME cryptographic signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Any reason the remotetimers plugin is not part of e-tobi.net ?
Hi, Any reason the remotetimers [1] plugin is not part of e-tobi.net [2] ? Is there an alternative, other than using the remoteosd plugin (that I'm already using, but have a low WAF). [1] http://vdr.schmirler.de/ [2] http://www.e-tobi.net/repositories/repositories.html -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
Klaus Schmidinger a écrit : On 08.01.2009 18:50, user.vdr wrote: On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger 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 The channel number would be unnecessary, because that information is stored in the 'info' file. However, it is contained in the recording's directory name, so that in case two timers of the same VDR instance record the exact same programme, but on different channels, they don't mix their data into one big pile of goo (which could have happenend in VDR 1= 1.7.2). No need to make this a string - it's just a safety precaution (besides, two channels might have the *same* name, but never the same number). -MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR instances recording the same show. This is a usual problem of multiple instances sharing a single /video dir. As we're talking about safety here, why not address it right now, once and for all ? If you do not have a unique identifier for each VDR instance yet, the only thing I can think of is hostname + SVDRP port number (this identifies both single instance on many hosts, and multiple instances on a single host). -- NH ___ 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 12.01.2009 13:41, Nicolas Huillard wrote: Klaus Schmidinger a écrit : On 08.01.2009 18:50, user.vdr wrote: On Tue, Jan 6, 2009 at 7:06 AM, Klaus Schmidinger 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 The channel number would be unnecessary, because that information is stored in the 'info' file. However, it is contained in the recording's directory name, so that in case two timers of the same VDR instance record the exact same programme, but on different channels, they don't mix their data into one big pile of goo (which could have happenend in VDR 1= 1.7.2). No need to make this a string - it's just a safety precaution (besides, two channels might have the *same* name, but never the same number). -MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR instances recording the same show. This is a usual problem of multiple instances sharing a single /video dir. As we're talking about safety here, why not address it right now, once and for all ? I did - by using the resume id. This should be unique for any VDR instance accessing a common video directory. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
Klaus Schmidinger a écrit : On 12.01.2009 13:41, Nicolas Huillard wrote: -MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR instances recording the same show. This is a usual problem of multiple instances sharing a single /video dir. As we're talking about safety here, why not address it right now, once and for all ? I did - by using the resume id. This should be unique for any VDR instance accessing a common video directory. Well, I re-read the MANUAL regarding this issue before my posting above ;-) The resume ID is described excactly as I use it : Defines an additional ID that can be used in a multi user environment, so that every user has his/her own resume files for each recording. The valid range is 0...99, with 0 resulting in a file named 'resume.vdr', and any other value resulting in 'resume.n.vdr'. ie. it does not define the VDR instance, but the user instance... In practice, I set this to the same 0 value on every VDR, because I want to be able to stop a replay on one VDR, and continue viewing it on another VDR, starting at the position I stopped it... -- NH ___ 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 12.01.2009 16:01, Nicolas Huillard wrote: Klaus Schmidinger a écrit : On 12.01.2009 13:41, Nicolas Huillard wrote: -MM-DD-hh.mm.ch-ri.rec does not solve the problem of multiple VDR instances recording the same show. This is a usual problem of multiple instances sharing a single /video dir. As we're talking about safety here, why not address it right now, once and for all ? I did - by using the resume id. This should be unique for any VDR instance accessing a common video directory. Well, I re-read the MANUAL regarding this issue before my posting above ;-) The resume ID is described excactly as I use it : Defines an additional ID that can be used in a multi user environment, so that every user has his/her own resume files for each recording. The valid range is 0...99, with 0 resulting in a file named 'resume.vdr', and any other value resulting in 'resume.n.vdr'. ie. it does not define the VDR instance, but the user instance... In practice, I set this to the same 0 value on every VDR, because I want to be able to stop a replay on one VDR, and continue viewing it on another VDR, starting at the position I stopped it... Well, I thought that this id could also be used here, but apparently I was wrong. Ok, then let's have another id for this... Klaus ___ 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 Mon, 12 Jan 2009 16:04:09 +0100, Klaus Schmidinger wrote On 12.01.2009 16:01, Nicolas Huillard wrote: The resume ID is described excactly as I use it : Defines an additional ID that can be used in a multi user environment, so that every user has his/her own resume files for each recording. The valid range is 0...99, with 0 resulting in a file named 'resume.vdr', and any other value resulting in 'resume.n.vdr'. ie. it does not define the VDR instance, but the user instance... In practice, I set this to the same 0 value on every VDR, because I want to be able to stop a replay on one VDR, and continue viewing it on another VDR, starting at the position I stopped it... Well, I thought that this id could also be used here, but apparently I was wrong. Ok, then let's have another id for this... Much appreciated - thanks! Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT question (was: WinTV USB CI-Module and recommended distribution for VDR?)
Sascha Vogt wrote: Hi Lauri, Lauri Tischler schrieb: Sascha Vogt wrote: as my hardware is shipping (went for the ASUS M2N78Pro, GeForce 8300 with an Athlon X2 4850e, hopefully that'll work with VDPAU and HD videos) Couldn't find M2N78Pro, do you mean M3N78PRO ? Sorry, you're right, meant the M3N78Pro. Does this board have at least headers for a parallel printer port? I can't find a hi-res picture of it, and docs do not mention it, so I fear I couldn't use my graphical VFD if I where to decide on this board in favour of some 8200-based still in ATX form factor. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.3
Klaus Schmidinger wrote: On 12.01.2009 16:01, Nicolas Huillard wrote: Well, I thought that this id could also be used here, but apparently I was wrong. Ok, then let's have another id for this... Klaus Thanks. There aren't too many projects of this magnitude that responds this quickly to user wishes. Even though I would have liked to see teletext subs recorded by default and multiple frontend support I fully understand your priorities. /Magnus H ___ 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 Mon, Jan 12, 2009 at 9:58 AM, Magnus Hörlin mag...@alefors.se wrote: Thanks. There aren't too many projects of this magnitude that responds this quickly to user wishes. Even though I would have liked to see teletext subs recorded by default and multiple frontend support I fully understand your priorities. Why not 'include teletext/closed-captioning in recordings?' as a setup option? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Minimal VDR install
Hi, folks. My current vdr is instaled over normal ubuntu desktop since forever. Now I want to try something similar starting with ubuntu server and reducing installed packages to the minimum. I found a similar ideia at this link: http://kuparinen.org/martti/comp/vdr/vdr.html Now for the questions: - Anyone with similar approach? - What is the minimum xorg needed? - Recommended settings? The ideia is to have a lightweight system installed on a usb pen (almost all files are read only, so no problem) and add one or more HDD drives to perform the recording. Those drivers will only work when a recording is scheduled. Thus reducing noise to the minimum. Currently I have almost no dB coming from my vdr box, except for the disks. I need to take in account other applications xorg needs. Like xine, mplyer, whatever. I really want to end up with a minimal/no noise fully working system. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Minimal VDR install
On Mon, Jan 12, 2009 at 11:46 AM, Chris Silva 2manybi...@gmail.com wrote: The ideia is to have a lightweight system installed on a usb pen (almost all files are read only, so no problem) and add one or more HDD drives to perform the recording. Those drivers will only work when a recording is scheduled. Thus reducing noise to the minimum. Currently I have almost no dB coming from my vdr box, except for the disks. I used to do this with a usb flashdrive but have switched to CompactFlash connected with a CF-SATA controller. Also only have one drive in the box for recording (which I'll move to my fileserver eventually). For the harddrive I just set a spindown timeout so it goes to sleep when not in use. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Minimal VDR install
Chris Silva wrote: Hi, folks. My current vdr is instaled over normal ubuntu desktop since forever. Now I want to try something similar starting with ubuntu server and reducing installed packages to the minimum. I found a similar ideia at this link: http://kuparinen.org/martti/comp/vdr/vdr.html Now for the questions: - Anyone with similar approach? - What is the minimum xorg needed? - Recommended settings? The ideia is to have a lightweight system installed on a usb pen (almost all files are read only, so no problem) and add one or more HDD drives to perform the recording. Those drivers will only work when a recording is scheduled. Thus reducing noise to the minimum. Currently I have almost no dB coming from my vdr box, except for the disks. I need to take in account other applications xorg needs. Like xine, mplyer, whatever. I really want to end up with a minimal/no noise fully working system. Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr I run minimal diskless ubuntu setups on a vdr server and three clients. The basic cli install of ubuntu desktop is 600MB and on the server there's not very much to add, just what's needed to compile vdr and an nfs server. On the clients I just install xinit and xorg-driver plus what's needed to compile xine. Then I start X with startx and vdr-sxfe/xbmc/performous with the remote using .xinitrc/irexec. No gdm or window manager, except for on my desktop client. And with a picoPSU the clients run at 30W so they're silent all right. The server with three hdd's and raid5 use a bit more but it's hidden away in the attic so I can't hear it anyway. I usually start by installing the latest version of ubuntu on one computer and then duplicate that directory for every client. Then it's just to boot that install for every client and add the rest of the packages needed for that hardware (I have one intel, one nvidia and one amd client so I can follow their respective X driver progress). /Magnus H ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT question
Hi Lucian, Lucian Muresan wrote: Sascha Vogt wrote: Hi Lauri, Lauri Tischler wrote: Sascha Vogt wrote: as my hardware is shipping (went for the ASUS M2N78Pro, GeForce 8300 with an Athlon X2 4850e, hopefully that'll work with VDPAU and HD videos) Couldn't find M2N78Pro, do you mean M3N78PRO ? Sorry, you're right, meant the M3N78Pro. Does this board have at least headers for a parallel printer port? I can't find a hi-res picture of it, and docs do not mention it, so I fear I couldn't use my graphical VFD if I where to decide on this board in favour of some 8200-based still in ATX form factor. Nope, sorry, I can't find any parallel ports on the port. There is an internal COM Port available. I guess you'd need an USB-parallel converter. Greetings -Sascha- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT question
On Mon, Jan 12, 2009 at 9:46 PM, Sascha Vogt funkyf...@gmx.net wrote: Hi Lucian, Lucian Muresan wrote: Sascha Vogt wrote: Hi Lauri, Lauri Tischler wrote: Sascha Vogt wrote: as my hardware is shipping (went for the ASUS M2N78Pro, GeForce 8300 with an Athlon X2 4850e, hopefully that'll work with VDPAU and HD videos) Couldn't find M2N78Pro, do you mean M3N78PRO ? Sorry, you're right, meant the M3N78Pro. Does this board have at least headers for a parallel printer port? I can't find a hi-res picture of it, and docs do not mention it, so I fear I couldn't use my graphical VFD if I where to decide on this board in favour of some 8200-based still in ATX form factor. Nope, sorry, I can't find any parallel ports on the port. There is an internal COM Port available. I guess you'd need an USB-parallel converter. Greetings -Sascha- Or a COM - LPT converter and forget the USB drivers. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-xine-0.9.0 plugin
Hi, after being away 7 month from VDR development I'm pleased to announce release 0.9.0. You can find it on my homepage as usual: http://home.vr-web.de/~rnissl Excerpt from HISTORY: 2009-01-12: Version 0.9.0 - Updated INSTALL and MANUAL accordingly. - Fixed several multithreading issues which got triggered on SMP systems (thanks to Edgar (gimli) Hucek for reporting issues and testing fixes). - Added support for VDR-1.7.3 besides TS still pictures. - Pulled patched VDR-1.7.2's remux.[ch] for a quick adaption to to VDR-1.7.3 (thanks to Klaus Schmidinger for his approval). - Fixed PTS handling in xine-lib's FFmpeg decoder for recent FFmpeg versions which should provide better A/V sync now. - Added patch sets to input_vdr.c which allow to omit parts of the MRL, e. g. vdr:// should be sufficient now (thanks to Ludwig Nussel for providing them). - Make use of new OSD functionality in xine-lib-1.2. For now an OSD implementation must provide both new features to have vdr-xine make use of it. - Extended OSD support in xine-lib-1.2 to allow truecolor OSDs as well as hardware scaled OSDs. The new functionality is currently only provided by VDPAU enabled installations. - Added frame grabbing support for accelerated frame formats to xine-lib. Previously, xine-lib exitted the app when frame grabbing was requested for accelerated frame formats like xxmc. You'll now get a green image in that case. Reading back the content of an accelerated frame is currently only provided by VDPAU enabled installations. - Hacked support for VDR-1.7.1's new cDevice::PlayTs() method. - Grab image nolonger needs pnmcut to select the relevant area of the TV image. Besides that, grab image respects the aspect ratio you select in VDR's setup menu, i. e. a 16:9 setup and a 16:9 broadcast will grab you a image without black borders. A mismatch of aspect ratios will add black borders to the image to match the visual impression you get on your TV set. Additionally, the grabbing of field pictures was corrected with regard to color upsampling. - A script mkNoSignal.sh is provided to create custom logos. Just provide PNG files named noSignal16x9*.png (and ...4x3... respectively) and have the tools mentioned in INSTALL in your path. You'll have to move your custom logos then over the default files. - The vdr-xine logo is now available in two aspect ratios (4:3 and 16:9) as more channels provide 16:9 content. Then vdr-xine selects the logo which matches VDR's DVB setup option video format. - Added the ability to detect discontinuities in live TV and to start a new buffering period in such a case. This will help to resume to fluent playback from bad weather conditions or when disconnecting and reattaching the antenna cable. - Updated it_IT.po (thanks to Diego Pierotto for providing the translations). Enjoy. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
