Re: [vdr] Hard link cutter [was: Suggestion: High speed cutting]
Richard Lithvall wrote: Why not just change the naming of video files to four, five or even eight digits? The real limit is that the file format and the VDR API uses byte sized integers to represent this. (cIndexFile::Get uses an uchar *FileNumber.) This could be extended, even with moderate changes on the file format. (there are reserved bytes that could be used) However, in any case it will break compatibility for the recording format and for the VDR API. And with some tricks, 255 files are enough too, so why break things? Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] softplay problem with ffmpeg [rev 8428] (Was: softdevice audio problem. audio repacker issue?)
On Sunday 18 March 2007 10:34, Martin Wache wrote: Stefan Lucke schrieb: But there is still one drawback. It is still not playable with softplay. Neither audio nor video. There are only some accustic fragments and no video frame. For me softplay works fine with vdr recordings. Did you make sure that you compiled softplay with the same ffmpeg version like the softdevice? Yes. just did a make clean-plugins, make plugins. This is with old (vdr-1.2.1) and new recordings. My current ffmpeg revision is 8428. Will test some older like 7852 too. -- Stefan Lucke ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Martin Wache wrote: I agree that it is cleaner to have an index file which points to complete frames, but I never experienced any problems without repacking. So it seems to me that only xine's libmpeg2 has the problem to drop incomplete frames. This was annoying when moving cutting marks and I first solved this issue by patching GetNextIFrame() to deliver the missing tail too. But Klaus didn't like this hack and asked for a cleaner approach. The solution sounds quite simple: just start a new PES packet for each video frame and everything is fine. But the actual solution is quite complex: cVideoRepacker. I switched the repacking off in my vdr... I don't think that it is necessary. Maybe you are right. The benefit of avoiding memcpys when repacking is done already during the TS to PES transformation is void as long as one cannot rely on getting repacked packets all the time. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote: I switched the repacking off in my vdr... I don't think that it is necessary. Maybe you are right. The benefit of avoiding memcpys when repacking is done already during the TS to PES transformation is void as long as one cannot rely on getting repacked packets all the time. Due to the limited power of the Geode with 300MHz of the Reelbox, I've analyzed the TS-path in the vdr with gprof/oprofile and re-wrote the repacker from scratch and changed some of the related TS code in device/dvbdevice. It has a lot of optimizations: - The ringbuffer works with packet granularity (no single bytes), no extra sync checks are needed. Multiple memcpy of the same data is avoided as much as possible, especially for the video part. - The MPEG-sequence code search (ScanVideoPacket) is optimized for simple CPUs where the raw number of memory accesses and instructions is important (no memchr, that's slower on the Geode) - The video packer detects if the PES-flag in the TS header actually starts a new PES packet with I, P and B-frames at the TS beginning. After this detection, the search for start-of-picture is no longer done and the PES-flag only determines the separation. Since a lot of broadcasters are using the flag this way (especially the hingh bandwidth ones like ARD and ZDF in Germany) this saves a lot of CPU time. Services which don't allow this usually have low bandwidth anyway and are IMO not that important anyway (CNBC, Gods Channel, etc ;-) )... - There's one ringbuffer (and thus one data copying) eliminated in the way from the DVB-device to the TS receivers. Multiple ringbuffers in a row only give the illusion of better buffering... - The TS-dispatcher in cDevice::Action looks for bursts of TS-packets with the same PID and only does one Lock() and one Receive()-call for this burst instead for each single packet. Video data usually comes in bursts, so this saves a lot of unnecessary overhead. As the receiver function allows multiple packets (length parameter) this is perfectly legal. Unfortunately, some plugins don't respect the length parameter (older femon comes to mind, I don't know about the latest version). But that is easily fixed... The new repacker may have some issues with AC3 or some audio-only channels, but maybe it's worth to have a look at its code... svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/ -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] plugin errors with vdr 1.5.1
On 3/18/07, anthony kelly [EMAIL PROTECTED] wrote: I could not compile many plugins with 1.5.1 until I made the following change in ./include/vdr/osdbase.h, in class cOsdObject I moved bool needsFastResponse; from private to public scope. There is now a SetNeedsFastResponse function to set that bootlean. Your change to vdr works but you might simply want to update plugins as most of the common ones have been fixed. If you want to add 1.5.1 compatibility to a plugin, you can follow the following code example: #if APIVERSNUM = 10500 SetNeedsFastResponse(false); #else needsFastResponse = false; #endif ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Is there a patch available with your modifications? Thanks Halim On So, Mär 18, 2007 at 04:30:02 +0100, Georg Acher wrote: On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote: I switched the repacking off in my vdr... I don't think that it is necessary. Maybe you are right. The benefit of avoiding memcpys when repacking is done already during the TS to PES transformation is void as long as one cannot rely on getting repacked packets all the time. Due to the limited power of the Geode with 300MHz of the Reelbox, I've analyzed the TS-path in the vdr with gprof/oprofile and re-wrote the repacker from scratch and changed some of the related TS code in device/dvbdevice. It has a lot of optimizations: - The ringbuffer works with packet granularity (no single bytes), no extra sync checks are needed. Multiple memcpy of the same data is avoided as much as possible, especially for the video part. - The MPEG-sequence code search (ScanVideoPacket) is optimized for simple CPUs where the raw number of memory accesses and instructions is important (no memchr, that's slower on the Geode) - The video packer detects if the PES-flag in the TS header actually starts a new PES packet with I, P and B-frames at the TS beginning. After this detection, the search for start-of-picture is no longer done and the PES-flag only determines the separation. Since a lot of broadcasters are using the flag this way (especially the hingh bandwidth ones like ARD and ZDF in Germany) this saves a lot of CPU time. Services which don't allow this usually have low bandwidth anyway and are IMO not that important anyway (CNBC, Gods Channel, etc ;-) )... - There's one ringbuffer (and thus one data copying) eliminated in the way from the DVB-device to the TS receivers. Multiple ringbuffers in a row only give the illusion of better buffering... - The TS-dispatcher in cDevice::Action looks for bursts of TS-packets with the same PID and only does one Lock() and one Receive()-call for this burst instead for each single packet. Video data usually comes in bursts, so this saves a lot of unnecessary overhead. As the receiver function allows multiple packets (length parameter) this is perfectly legal. Unfortunately, some plugins don't respect the length parameter (older femon comes to mind, I don't know about the latest version). But that is easily fixed... The new repacker may have some issues with AC3 or some audio-only channels, but maybe it's worth to have a look at its code... svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/ -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR stops replay due to strong wind condition
On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote: You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-) I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two. I find this behaviour very irritating in VDR - mainly because of the facts in list thread Handling of temporarily encrypted channels recently. -- Heikki M ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
On Sun, Mar 18, 2007 at 05:25:00PM +0100, Halim Sahin wrote: Hi, Is there a patch available with your modifications? That's a bit difficult, since our vdr has no exact mainline equivalent. It may contain parts from different vdr versions. But as I've heard, it should work also on a full featured card without any modifications. Maybe you need to tweak the makefile... The remuxer itself should be API compatible, so exchanging the file and using tools.c/h from the svn should also work. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
AW: [vdr] VDR stops replay due to strong wind condition
Thanks Klaus, For that fast response. As you said: it's not your - respective VDR's Problem. Are there still so many buggy drivers around? I would appreciate to have this work-around-feature disabled by default, but be enabled with a command line option in case somebody still needs it. It's the second time, that I have to ssh my VDR, kill VDR, move my timers away, restart VDR. And as I do not use a full featured card, I also have to start playing again in XINE. It's simply annoying, and you first have to find out why VDR does not run stable. Regards, Martin PS: Disabling this feature in source means that I have to make my own version. It's always extra work that is better spent on making DVB drivers run stable. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Klaus Schmidinger Gesendet: Sonntag, 18. März 2007 15:47 An: vdr@linuxtv.org Betreff: Re: [vdr] VDR stops replay due to strong wind condition martin wrote: Hello, I try to watch recored material with my VDR. This is basically nice, but today we have strong wind. And sorry to get rude, but: Es ist so zum Kotzen, dass der VDR meint er muss sich neu starten, wenn das DVB-S signal mal nicht so gut ist. How should I explain my friends that we cant watch the movie, because the perception of the DVB signal is currently bad. Why does VDR exit, when the signal is bad? Its not VDRs Problem, but makes many things different. Regards, Martin Mar 18 15:23:00 htpc vdr: [13541] frontend 0 timed out while tuning to channel 504, tp 112515 Mar 18 15:23:21 htpc vdr: [13541] frontend 0 timed out while tuning to channel 501, tp 112574 Mar 18 15:24:27 htpc vdr: [13541] frontend 0 timed out while tuning to channel 27, tp 112633 Mar 18 15:24:45 htpc vdr: [13541] frontend 0 lost lock on channel 36, tp 112662 Mar 18 15:24:46 htpc vdr: [13541] frontend 0 regained lock on channel 36, tp 112662 Mar 18 15:24:47 htpc vdr: [13541] frontend 0 lost lock on channel 36, tp 112662 Mar 18 15:24:47 htpc vdr: [13541] frontend 0 regained lock on channel 36, tp 112662 Mar 18 15:24:48 htpc vdr: [13541] frontend 0 lost lock on channel 36, tp 112662 Mar 18 15:30:22 htpc vdr: [13543] frontend 1 lost lock on channel 4, tp 111953 Mar 18 15:30:22 htpc vdr: [13543] frontend 1 regained lock on channel 4, tp 111953 Mar 18 15:30:24 htpc vdr: [13541] frontend 0 timed out while tuning to channel 501, tp 112574 Mar 18 15:30:27 htpc vdr: [13538] stopping plugin: streamdev-server Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: text2skin Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: epgsearch Mar 18 15:30:30 htpc vdr: [13548] EPGSearch: Leaving search timer thread Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: femon Mar 18 15:30:30 htpc vdr: [13538] stopping plugin: xine Mar 18 15:30:30 htpc vdr: [13538] timer 58 (4 1507-1600 'Matrix statt Mattscheibe') stop VDR doesn't know that the signal is bad due to stormy weather. It assumes that something is wrong with the driver and does a restart because you have a timer recording. If there were no recording timer, VDR wouldn't do this. You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-) 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
AW: [vdr] VDR stops replay due to strong wind condition
So, get rid of legacy or make it at least disabled, configurable with a start option. Martin -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Heikki Manninen Gesendet: Sonntag, 18. März 2007 17:46 An: VDR Mailing List Betreff: Re: [vdr] VDR stops replay due to strong wind condition On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote: You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-) I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two. I find this behaviour very irritating in VDR - mainly because of the facts in list thread Handling of temporarily encrypted channels recently. -- Heikki M ___ 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 stops replay due to strong wind condition
Heikki Manninen schrieb: On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote: You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-) I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two. That's my experience too. My VDR has a Nexus FF card and a Skystar 2 budget card and the only situations I get emergency exits are 1. Bad weather 2. If VDR is used in locations where only one Sat connection is available. For problem 2 it would be nice if VDR would try other cards first if the card it wants to use for a recording gets no signal before giving up with emergency exit. Wolfgang ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR stops replay due to strong wind condition
Heikki Manninen schrieb: On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote: You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-) I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two. I find this behaviour very irritating in VDR - mainly because of the facts in list thread Handling of temporarily encrypted channels recently. Shouldn't it be enough to do not sprecify -w option ? : -w SEC, --watchdog=SEC activate the watchdog timer with a timeout of SEC seconds (default: 0); '0' disables the watchdog If not, in future vdr versions it should maybe handled like that ? I personally own a card combo which have needed this feature one of the most i guess (TT FF + SkyStar2 both SAT) and with drivers since around 2.6.16 it's running rock stable now. Wasn't there development ongoing to be able to do a live ARM reset without reloading the driver within a fraction of the time ? My 2 cents are, it was a good thing but nowadays something more sophisticated should be put in place. Think nobody would mind 1-3 restart to get the driver going, but after that the recording should be switched off and a comment or status should mark it with the reason of failing. (all only thinking in new dev version development direction. Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Hi, Georg Acher wrote: The new repacker may have some issues with AC3 or some audio-only channels, but maybe it's worth to have a look at its code... svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/ I'll have a look at it the next days. I must admit, that the repacker classes were designed to be integrated into the existing TS/PES remux code at almost no changes (at least no complex changes). I thought about rewriting the whole chain too but didn't find time so far respectively didn't have the need to do it. Thanks for your work in this area. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR stops replay due to strong wind condition
Heikki Manninen wrote: On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote: You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-) I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two. Well, at least I will re-enable (or reverse-patch) this feature back into my VDR, as it saved many recordings for me. This fallback is only triggered if a scheduled recording is getting not a single byte of data for at least one minute, so there's IMHO something seriously wrong about it. And in many cases, a clean restart fixes this for me - because for me its usually a malfunction of the tuner / multiswitch communication, and a power down / power up of all LNB power helps. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
AW: [vdr] VDR stops replay due to strong wind condition
Okay: how to tell my granny, that she can't watch her recording, because some emergency exit is going on? * Hot to tell her, that the sat dish is moving? - This is nothing for a normal enuser, there must be another solution! Let me tell you a story: all of our PC's are connected to the internet. Suddenly, the Internet connection is broken down. Now, the PC reboots itself every minute! Thats crazy man! Solve the problem, but do not disturb the whole system. Last time I had to retune the dish - again the wind problem - it has moved the dish. I was unable with Femon to put it back to work, because VDR constantly rebooted itself and as I am not using a FF card, I always had to restart Xine. Again: this is no sound setup. When there is a problem, try to fix it .. otherwise we could go directly with software of the richest men in the world. I say: happy blue screen and reboot is good! Please Klaus, I beg you on my knees: make your software useable for normal users. Thanks in advance, Martin PS: Hunt down those developers of firmware, that make buggy programming. :) I had 10 people sitting around today, trying to watch the movie. All said: wau, what a great system - I will also need a VDR. After 5 Minutes everbody told me its shit - sorry to say that. Well I still know, that it's the best, but all the other 9 are not convinced. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Udo Richter Gesendet: Montag, 19. März 2007 00:00 An: VDR Mailing List Betreff: Re: [vdr] VDR stops replay due to strong wind condition Heikki Manninen wrote: On su, 2007-03-18 at 15:46 +0100, Klaus Schmidinger wrote: You can disable all the cThread::EmergencyExit() calls if you don't want this. Maybe I should disable this by default in a future version - and wait until people start complaining because recordings are broken... ;-) I personally don't believe/experience that driver problems cause broken recordings nowadays or have been causing them in the past year or two. Well, at least I will re-enable (or reverse-patch) this feature back into my VDR, as it saved many recordings for me. This fallback is only triggered if a scheduled recording is getting not a single byte of data for at least one minute, so there's IMHO something seriously wrong about it. And in many cases, a clean restart fixes this for me - because for me its usually a malfunction of the tuner / multiswitch communication, and a power down / power up of all LNB power helps. 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] Re: AW: VDR stops replay due to strong wind condition
I demand that martin may or may not have written... [snip] Thats crazy man! ^ Was that supposed to be an apostrophe? I ask because I see here a box symbol, representing an unknown character... Your message's headers say ISO8859-1. Character code 0x92 is undefined in ISO8859-1, and therefore may not be properly viewable everywhere (except with software which has workarounds for broken messages generated by buggy MS software). Solve the problem, but do not disturb the whole system. You should take your own advice - stop using broken MS products, or at least configure them to use the correct encoding, in this case Windows-1252. (Actually, in that encoding, it's a single close quotation mark, not an apostrophe. So, strictly, it's *still* wrong, but at least it'd look something like what it's supposed to be.) [snip] -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Udo Richter Gesendet: Montag, 19. März 2007 00:00 An: VDR Mailing List Betreff: Re: [vdr] VDR stops replay due to strong wind condition [snip] Cheers, Udo [snip] That's not properly quoted. It could be taken for text that *you*'ve written. Again, you should take your own advice. And don't top-post. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output *more* particulate pollutants. BUFFER AGAINST GLOBAL WARMING. I'd like to, but I have to go to the post office to see if I'm still wanted. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Is GrabImage only for PAL resolution when using FF cards?
Grab screenshots are unfortunately screwed up for NTSC. I asked Klaus about this a long time ago and he suggested the problem was driver/firmware related. When I inquired I was told it's a software problem. Rather than continuing to go in cricles I just forgot the idea of getting a good screenshot. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Mailing List Etiquette
This is the 'official' and updated vdr-mailing-list-etiquette-reminder. Please take this as a serious advice. Take the time to read it, especially if you are new to mailinglists in general. E-mail formatting = Mailing list email should fit the following criteria: DO == * Trim quoted material to the minimum needed to clarify what you're talking about. * Add a blank line _before_ and _after_ each quote for better readability. * Make sure you are attributing material to the correct person (i.e. make sure the On 19/07/2002, Joe Bloggs said: is correct) * Write your responses _after_ the quoted text, not before. If your mail client makes it difficult to do this, get a new one. * Make sure lines are wrapped at maximum 76 characters (to fit an 80 character wide screen), even if the text had been quotet several times. * Use the correct number of characters at the start of each quoted line. * Set your mail client to english headers to avoid subjects like: AW: Antwort: Re: AW: AW: AW: Re: Some Topic allready trunkated If you see one, don't just add another Re: but remove all AW: and other chained Re:. * Use a descriptive subject! A message titled A small wish doesn't tell what it is about. Better use something like should do xyz or crashes when doing xyz. * If the topic of the thread changed/degrades meanwhile, change the subject too. That means: Before you start to answer, have a look into the subject your are going to reply to. For example use: New topic [WAS] old topic * Always write one separate message per topic. some people (especially those who matter) might not read mixed-up and lengthy threads. * Start a new thread when posting a new subject. * Make emails as short as possible whilst keeping them comprehensible. Don't = * Don't post in either HTML-only or in Text and HTML. If your mail client doesn't support this, change it. * Don't top post. * Don't give a one line answer having quoted the whole post. * Don't use a too long signature. Approx. 4 lines should always be enought. * Don't reply where you should have started a new thread. This means, make sure that you're not responding to an existing posting. Just changing the subject header and deleting any quoted text is NOT enough, because the message's header will still contain references to other messages. * Don't break threads by sending a new mail, where you should have replied. * Don't test post. Send your test posts to [EMAIL PROTECTED] or similar reply machines. * Don't use lengthly disclaimers. If not possible, use a freemail account. * Don't quote disclaimers and other footers. General Etiquette = This can really be summed up in one phrase - 'be polite'. Allways use your 'Real Name' when posting to mailinglists or newsgroups. If you think something is off-topic, don't reply to the list although you may want to send a short and *polite* note to the person privately telling them which list would be more appropriate; don't just say - that is OT here. Before asking a question, please Have a look at the mailing list archives at http://www.linuxtv.org/pipermail/vdr/ If someone flames or trolls the list, don't reply - it wastes everyones bandwidth and time. Don't reply to spam which gets through to the list - just ignore it when it does. Resources = * The ultimate guide to most matters to do with email etiquette is RFC-2822 which can be found at: ftp://ftp.isi.edu/in-notes/rfc2822.txt * A german site set up by some usenet-people, who take it even more serious with netiquette. http://learn.to/quote ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
