Re: [vdr] VDR stops replay due to strong wind condition
Udo Richter writes: > 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 Such as CA authorization needing refreshing, and the card waiting for it. Or bad weather outside. > it. And in many cases, a clean restart fixes this for me - because for Then you are lucky. yours, Jouni ___ 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
hi, Steffen Barszus writes: > 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 The problem is that the watchdog timer is able to recover from some VDR or VDR+plugin problems, and should have a short timeout, such as one minute, whereas the recording stuff should not have a timeout (unless for some that have buggy drivers). yours, Jouni ___ 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
Re: [vdr] Is GrabImage only for PAL resolution when using FF cards?
On 3/18/07, VDR User <[EMAIL PROTECTED]> wrote: 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. Grab works perfect for NTSC if I use my FF card with xine in softmode. It appears that VDR is just calling the dvb driver and getting the resolution from that. Somewhere in the ttpci code, it is hardcoded to PAL... Hmmm where to find it. This is only an issue with FF cards in NTSC. Regards. ___ 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] Is GrabImage only for PAL resolution when using FF cards?
I noticed that when the screenshot plugin starts, it grabs a PNM image to /dev/null, but the resolution is not right. Fory my system, everything should be in NTSC resolution. How is vdr getting 768x576 for the capture screen resolution? I would like this to be 720x480 instead. Mar 18 21:04:26 sid vdr: [4336] starting plugin: screenshot Mar 18 21:04:26 sid vdr: [4336] grabbing to PNM 100 768 576 Mar 18 21:04:26 sid vdr: [4336] grabbed image to /dev/null Best Regards. ___ 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
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
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
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 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] 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
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
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
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
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?
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] 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?
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
[vdr] plugin errors with vdr 1.5.1
Hi I don't know if this is useful. 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. Then most of my plugin probs went away. Don't have the faintest idea what I am doing so you can ignore/use if you wish. cheers Anthony Kelly ___ 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
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 can’t watch the movie, because > the perception of the DVB signal is currently bad. Why does VDR exit, > when the signal is bad? It’s not VDR’s 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] VDR stops replay due to strong wind condition
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 can't watch the movie, because the perception of the DVB signal is currently bad. Why does VDR exit, when the signal is bad? It's not VDR's 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 Mar 18 15:30:30 htpc vdr: [13538] executing '/home/martin/rec.sh after "/video/Matrix_statt_Mattscheibe/2007-03-18.15.07.50.50.rec"' Mar 18 15:30:30 htpc vdr: [13538] saved setup to /video/setup.conf Mar 18 15:30:32 htpc vdr: [13538] deleting plugin: streamdev-server Mar 18 15:30:32 htpc vdr: [13538] deleting plugin: text2skin Mar 18 15:30:32 htpc vdr: [13538] deleting plugin: epgsearch Mar 18 15:30:33 htpc vdr: [13549] EPGSearch: Leaving conflict check thread Mar 18 15:30:33 htpc vdr: [13538] deleting plugin: femon Mar 18 15:30:33 htpc vdr: [13538] deleting plugin: xine Mar 18 15:30:33 htpc vdr: [13538] exiting Mar 18 15:30:34 htpc vdr: [15308] VDR version 1.4.6 started ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.1: Interface race
Stefan Huelswitt wrote: there is a race condition while terminating vdr. Early in the shutdown process the Interface class is deleted. If a signal is raised after that point, the signal handler will call Interface->Interrupt() which is allready deleted. The best fix is probably to disable all signal handlers at the beginning of the shutdown part, right after 'Exit:'. signal(SIGxxx, SIG_DFL) for all the signals should do. Cheers, Udo ___ 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
[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] Hard link cutter [was: Suggestion: High speed cutting]
Matthias Schwarzott wrote: Another thing that comes to my mind, but is sure hard to implement: If I do two or more simultanous recordings from the same channel, why couldn't VDR record this to the same file, and hardlink it to both directories. That would reduce the need to create one long recording, if one would like to record two or more shows that are broadcasted one after the other. This would indeed be very difficult to implement. The practical advantage however would probably be minimal. Its usually not a performance problem to do parallel recording, and there's no need for it except overlapping timers. And these overlaps of 15 minutes or so are not worth the effort. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
Re: [vdr] softdevice audio problem. audio repacker issue?
Reinhard Nissl schrieb: > Hi, > > Martin Wache wrote: > Is there a reason why the cAudioRepacker is used in transfer mode and during recordings, but not while replaying? >>> Well, when cAudioRepacker was active while recording, then there is no >>> need for it when replaying such a recording. >> Wouldn't it make more sense to use the repacker only when replaying and >> in transfer mode and not while recording? >> Like it is now, it is possible that the device gets either repacked >> audio frames (transfer mode and new recordings) or not repacked frames. >> If the device needs repacked frames the device has to find out if it is >> replaying an old recording to play and if so, split the packets. I guess >> in most cases it is a lot simpler just to repack everything. Which means >> in most cases to do the repacking twice... > > Fiddling around with repacking at that late stage is quite a mess > especially in trickspeed mode. You have to do it anyway when parsing the content of the packets to decode them. And you can do it even better, because you know what should be inside. I never had any problem implementing trickspeed modes for the softdevice, also when there was no repacker in the vdr. FFmpeg does a good job parsing those packets, and I guess ffmpeg is much better tested and faster than cAudio/VideoRepacker. > And cVideoRepacker causes "high" CPU load > because there is no length information in the video stream so the whole > stream has to be scanned for the 00 00 01 pattern. Furthermore, consider > the memcpying involved in this process. In my opinion that is a reason not to do the repacking at in the vdr. > That's why we have chosen the > earliest stage possible (cRemux) to do this complex stuff just once. > No, as I said earlier, you don't guarantee that the repacking is done, so one have to check that the packet are fine in any case. And checking them is not more work than completely parsing the packets. So in fact because the repacking is only done sometimes one hast to do the work twice. And during the decoding one has to parse the packets anyway, so it is much simpler _only_ to parse them properly in the decoder. >>> And old recordings will vanish as time passes by. >> I don't buy this argument. I know that there are VDR users with large >> archives of recordings, do you want to tell them that they can't use >> them any more? > > No, I don't, as there is no need to. VDR's device interface > specification doesn't state any relationship between PES packets and > their content, so a device implementation shouldn't rely on that. > So you are saying that we have to repack in any case... which means that the packets are completely parsed twice. Didn't you say something about "high cpu load" and "complex stuff" above? For soft devices that actually should not matter too much, because of the strong cpus, but the people who suffer are the ones which are using hardware decoders and weak cpus. And as far as I know they don't need repacking... >> But anyway, actually I think the best would be only to repack audio and >> video if the replaying device needs it. As far as I know FF cards don't >> need it, the softdevice doesn't need it (ok, it depends on the ffmpeg >> version one uses, but the patch I send fixes this). >> So why not let the device choose if repacking is needed or not? It >> should now if repacking is needed, and in most cases it should be able >> to do it by itself. > > Well, it isn't just a matter of the output device. cVideoRepacker takes > care that VDR's index file contains valid entries. Before > cVideoRepacker, the index file could address incomplete frames or even > miss some frames. > I agree that it is cleaner to have an index file which points to complete frames, but I never experienced any problems without repacking. I switched the repacking of in my vdr... I don't think that it is necessary. Bye, Martin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] softdevice audio problem. audio repacker issue?
Stefan Lucke schrieb: > On Saturday 17 March 2007 22:05, Martin Wache wrote: >> I attached a patch with make the softdevice use av_read_frame(), it has >> still some issues, but it solves the problems Stefan reports. > > Martin, thats really great. > Thank you. > This solves the issue I had with playback of some old recordings. > > 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? Bye, Martin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hard link cutter [was: Suggestion: High speed cutting]
On Sonntag, 18. März 2007, Reinhard Nissl wrote: > Hi, > > Richard Lithvall wrote: > > Why not just change the naming of video files to four, five or even > > eight digits? > > The problem is not the file name, it's the index file. An index entry > stores the file number as "uchar", which allows 256 recording files. > I do not know if the index file has a signature/magic-code at the start. If yes, it should be easy to define a new index-format with Longer integers for the file number. Another thing that comes to my mind, but is sure hard to implement: If I do two or more simultanous recordings from the same channel, why couldn't VDR record this to the same file, and hardlink it to both directories. That would reduce the need to create one long recording, if one would like to record two or more shows that are broadcasted one after the other. Matthias -- Matthias Schwarzott (zzam) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
