Re: [vdr] Thunderstorm over Munich
On Sun, 27 May 2007, Andrew Herron wrote: > I have to say that I agree with both of you... constructive criticism is > best! > > As a quiet 'user' of vdr, for about a year, I agree with the sentiments in > Martin's post. It is very frustrating that vdr exits when reception is less > than perfect. I personally would prefer it if vdr announced on screen that > there was a bad signal condition. This is particularly frustrating if at the > time you are just watching a perfectly good recording. I agree, with all. I would suggest to handle viewing recording or running a plugin (dvd plugin or mp3/mplayer etc.) would get a priority, for example 90. Then every recording that has lower priority would not cause emergency exits, no matter what. But if recording has higher priority, it can cause restarts. That's my suggestion. This is not that big problem for me, but lately I've got couple strange emergency exits. First live view looks ok and vdr was recording a show or was just starting. I started to watched old recorded show, after a while vdr restarts. Log shows just that emergency exit was initiated. Okay, my system does that only once, after that the recorded show can be watched ok. Marko Myllymaa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
Thanks all for your replys! At least I feel heard by the community. Yes, you are right - I can not address my thoughts without emotions. So we get into ITIL terminology. I will not do it 100% correct, as we need the application of ITIL to the current problem. Okay, here it comes. Some call it "features", some would call it "services". The VDR "suite" is providing vertical and horizontal services. Vertical Services are most of the time "end user services", whereas horizontal services are "platform services". To get into detail: Vertial: * Show a live DVB stream * Record a DVB stream * Time-Shift-View * Show a recording * .. you name it, we have it .. there's a lot more! -> When we would build up a service catalogue, we would also have to make SLA's on it. This would be the case, when a service provider (that's actually me!) is providing serivces to customers (my beloved!). And here comes the story: everybody wants to have 100% availability, that's clear. I do regular service updates with my VDR, where all services are down. This I can schedule so, that there is no interference with my end customers. Okay, all services are seen as single instances. End-Users do not understand, why recording a DVB stream is linked to showing a recording! -> Please Klaus, explain - in words that my Granny will understand! Second: There is something that's called "höhere gewalt". Examples: I want to watch TV, but there is a power outage. Nobody would blame me - personally. When I want to go across the alps with my car and it snowed 2 meters over night, nobody would blame me, that i was not able to go across. When I want to get tanned by sun and it's raining, it's simply impossible. When there is a huge cloud over my sat dish, even my 85cm is too small. I can not influence the weather. Everboy will understand! Horizontal: * The socalled API It's a platform, that is not visible to the endcustomer, but totally necessary as a good software is always open for new vertical services! The hassle with this is, that end-users do not care about the API. Modules must simply link in. Klaus had a long nightmare behind about this. So API is necessary, but also a lot of work with almost no refund. Something out scope for ITIL - Patching: And then we have the BigPatch fraction. I love those guys, they do also great job. They are not building on an API, they are modifying the source. Why are they doing this - should some of you ask yourself? Answer for me is simple: I did also do a feature request, something that was already developed, Klaus only needed to include in his source. But people started discussing, that we don't need. -> If we don't need, why is there a BigPatch. So no new feature (again a vertical service), which is frustrating. -> ".. inaction is a weapon of mass destruction." If you like musik, check your mp3 library for: http://www.lyricstop.com/m/massdestruction-faithless.html So: what would be the next steps: it's clear, VDR is not able (willing or what ever, again I don't care) to split up the services, so i must find workarrounds. Make many instances of VDR running on my machine. One is doing recording, one EPG search, the other is providing "Show" Sevice. -> do I really have to do this? And how to do it? Next would be that i have to split up physically into seperate boxes .. *puh* Finally - Business Economics: Talking about the "Cost of Service" and the "Total Cost of Ownership". When I split up VDR instances, the costs increase and over the lifetime the costs get multipied. Do I take Windows or Linux -> it's just a cost fact: Linux costs me, in my environment less. Do I buy a DVB-Recorder or do I build up (custom made). Also simple: I need to compare the service catalogue. All commercial services do not offer me "noad", "vdradmin", "epgsearch", "femon". This is the reason for me to use VDR. So: I use a lot of the API, I use BigPatch to get the 10 seconds jumps. This is what make VDR unique and worth using it. But writing such a long mail is frustrating :( Martin Thanks all for your replys! At least I feel heard by the community. Yes, you are right - I can not address my thoughts without emotions. So we get into ITIL terminology. I will not do it 100% correct, as we need the application of ITIL to the current problem. Okay, here it comes. Some call it "features", some would call it "services". The VDR "suite" is providing vertical and horizontal services. Vertical Services are most of the time "end user services", whereas horizontal services are "platform services". To get into detail: Vertial: * Show a live DVB stream * Record a DVB stream * Time-Shift-View * Show a recording * .. you name it, we have it .. there's a lot more! -> When we would build up a service catalogue, we would also have to make SLA's on it. This would be the case, when a service provider (that's actually me!) is providing serivces to customers (my beloved!). And here comes the story: everybody wants to have 100% availabil
[vdr] [PATCH] vdr-dvdswitch crashing when pressing an arrow key in empty image directory
Hi there!
Opening DVDSwitch menu if the image directory is empty, and then pressing some
arrow key crashes vdr.
The attached patch solves this bug.
Matthias
--
Matthias Schwarzott (zzam)
Index: dvdswitch-0.1.3/menu.c
===
--- dvdswitch-0.1.3.orig/menu.c
+++ dvdswitch-0.1.3/menu.c
@@ -754,8 +754,10 @@ eOSState cMainMenu::MenuMove(eKeys Key)
SetHelp();
mItem = (cMainMenuItem*)Get(Current());
- MainMenuOptions.setLastSelectItemName(mItem->FileName());
- MainMenuOptions.LastSelectItemType(mItem->Type());
+ if (mItem) {
+MainMenuOptions.setLastSelectItemName(mItem->FileName());
+MainMenuOptions.LastSelectItemType(mItem->Type());
+ }
return state;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
On Monday 28 May 2007 10:38:50 Marko Myllymaa wrote: > On Sun, 27 May 2007, Andrew Herron wrote: > > I have to say that I agree with both of you... constructive criticism is > > best! > > > > As a quiet 'user' of vdr, for about a year, I agree with the sentiments > > in Martin's post. It is very frustrating that vdr exits when reception is > > less than perfect. I personally would prefer it if vdr announced on > > screen that there was a bad signal condition. This is particularly > > frustrating if at the time you are just watching a perfectly good > > recording. > > I agree, with all. I would suggest to handle viewing recording or running > a plugin (dvd plugin or mp3/mplayer etc.) would get a priority, for > example 90. Then every recording that has lower priority would not cause > emergency exits, no matter what. But if recording has higher priority, it > can cause restarts. Hmm... IMO it is good that vdr tries to fix the recording problem with a restart. If I have the choice between a corrupted recording and being interrupted by a restart, I would choose the restart. However, it gets anoying when vdr restarts constantly. That is IMO what bothers us here. So if vdr could have some sort of restart-retry timeout, things would be better, IMO. A solution might be to create a file like .update, e.g. /video/.restart, that contains the timestamp of the vdr restart, when one happens. Could simply be a file with the time_t to make things realy simple. Vdr reads that file on its next start, seconds later, and knows that it did try a restart. So it will not try another restart for a while. Kind regards, Stefan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
On 05/28/07 11:30, martin wrote: > Thanks all for your replys! At least I feel heard by the community. > ... [ ... lengthy pamphlet, repeated three(!) times ... ] Martin, why don't you simply remove the cThread::EmergencyExit(true) calls from recorder.c and remux.c? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
Klaus Schmidinger wrote: > On 05/28/07 11:30, martin wrote: >> Thanks all for your replys! At least I feel heard by the community. >> ... > > [ ... lengthy pamphlet, repeated three(!) times ... ] > > Martin, why don't you simply remove the cThread::EmergencyExit(true) > calls from recorder.c and remux.c? > how about a compile or start switch for this /Lars/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
On 05/28/07 16:44, Lars Bläser wrote: > Klaus Schmidinger wrote: >> On 05/28/07 11:30, martin wrote: >>> Thanks all for your replys! At least I feel heard by the community. >>> ... >> [ ... lengthy pamphlet, repeated three(!) times ... ] >> >> Martin, why don't you simply remove the cThread::EmergencyExit(true) >> calls from recorder.c and remux.c? >> > > how about a compile or start switch for this I'll change this in version 1.5. This hint was just to tell Martin how to immediately make VDR 1.4.x work the way he apparently expects it to. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] new video-card with h264 decoder
Hello what do you think about this card ? Is it good choice for future vdr with hdtv support ? http://www.hardspell.com/english/doc/sho...=622&pageid=644 >From the results we can see the HD acceleration of HD2600 and HD2400 is >striking. The CPU usage is only about 5% by using 1.6GHz Sempron 2800+ to decode 1080p H.264 movies. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dropping pixel font in VDR 1.5?
On Sunday 27 May 2007 18:49, Klaus Schmidinger wrote: > I'm currently implementing support for Freetype fonts in VDR 1.5 > (based on Alexander Riedel's patch) and would like to completely > drop all the pixel font stuff. > > Just to make sure there won't be somebody who absolutely needs > the pixel fonts, please let me know if this is ok. Since probably > most of you will be running VDR with UTF-8 anyway (once it is > supported, which will be very soon), my guess would be that the > pixel fonts are really obsolete. > The extrecmenu-plugin uses pixel fonts to display icons. Some unused character numbers are assigend with those new "characters" to display a symbol of a dvd, directory, This looks very nice and is a great usability enhancement. So i think something similar (integrating icons in the OSD) should be possible also in future VDR versions. Greetings Thomas Wehrspann ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
because i'm speak some dialekts like basic or turbo pascal .. but not C :( and i am not the only one, who has got the problem. and i can't tell my granny to remove the cThread :)) > Date: Mon, 28 May 2007 14:23:04 +0200> From: [EMAIL PROTECTED]> To: > vdr@linuxtv.org> Subject: Re: [vdr] Thunderstorm over Munich> > On 05/28/07 > 11:30, martin wrote:> > Thanks all for your replys! At least I feel heard by > the community.> > ...> > [ ... lengthy pamphlet, repeated three(!) times ... > ]> > Martin, why don't you simply remove the cThread::EmergencyExit(true)> > calls from recorder.c and remux.c?> > Klaus> > > ___> vdr mailing list> > vdr@linuxtv.org> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr _ MSN Unterhaltung: Alle TV - Highlights - Mit der MSN Programmsuche! Jetzt checken! http://tv.unterhaltung.msn.de/tv?ocid=BAN1v0___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Thunderstorm over Munich
and again, start separating the services .. PS: sorry for the 3-times :( saw it now .. my apologies! > Date: Mon, 28 May 2007 16:43:33 +0200> From: [EMAIL PROTECTED]> To: > vdr@linuxtv.org> Subject: Re: [vdr] Thunderstorm over Munich> > On 05/28/07 > 16:44, Lars Bläser wrote:> > Klaus Schmidinger wrote:> >> On 05/28/07 11:30, > martin wrote:> >>> Thanks all for your replys! At least I feel heard by the > community.> >>> ...> >> [ ... lengthy pamphlet, repeated three(!) times ... > ]> >>> >> Martin, why don't you simply remove the > cThread::EmergencyExit(true)> >> calls from recorder.c and remux.c?> >>> > > > > how about a compile or start switch for this> > I'll change this in version > 1.5. This hint was just to tell> Martin how to immediately make VDR 1.4.x > work the way he apparently> expects it to.> > Klaus> > > ___> vdr mailing list> > vdr@linuxtv.org> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr _ Windows Live Messenger: Jetzt den Nachfolger vom MSN Messenger kostenlos downloaden! http://get.live.com/messenger/overview___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1.5.x Shutdown
Chris wrote: > My shutdown script checks for different running processes (or connections) > and does not quit vdr if at least one of the tests returns true. But since > 1.5.2 (or probably since 1.5.0) the shutdown script remains as a zombie > in such cases until vdr actually quits. The shutdown script has always been a fire-and-forget script that did not evaluate any return codes or output. The only change that landed together with the VDR shutdown rewrite in 1.5.1 is that the script is now called detached from VDR, so it can run in parallel and will not terminate together with VDR. Some shutdown scripts may need to be adapted. If you want to investigate: thread.c:SystemExec() is called with the new parameter Detached=true. STDIN is redirected to /dev/null, STDOUT and STDERR are same as VDR, all other FD's get closed as before. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new video-card with h264 decoder
Igor Nikanov wrote: > Hello > > what do you think about this card ? Is it good choice for future vdr with > hdtv support ? > > > http://www.hardspell.com/english/doc/sho...=622&pageid=644 >>From the results we can see the HD acceleration of HD2600 and HD2400 is >>striking. > The CPU usage is only about 5% by using 1.6GHz Sempron 2800+ to decode 1080p > H.264 movies. Unable to see what is behind the link because the link is corrupt. But I can guess that you're talking about AMD's new line of gfx cards with UVD. Yes, nice feature and definitely takes huge amount of CPU load off. However, there are few problems: -linux drivers are missing (AMD has said to provide open source drivers but until I see them I don't believe it. ATI has never delivered open source drivers and binary drivers do not work that well - pretty ok though.) -if you plan to receive SDTV resolution material or any other non-full HD resolution material you need to deinterlace (usually) and upscale it to full HD (assuming that you are into HD material). This will require more CPU power than what 1.6GHz Semprom will offer. Maybe these new cards will assist on that area too but not from the beginning. At the moment it seems that NVidia provides the best gfx cards for linux HDTV usage. Hopefully AMD will provide something real to compete against NVidia. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1.5.x Shutdown
Monday, May 28, 2007, 9:46:12 PM, Udo wrote: > The shutdown script has always been a fire-and-forget script that did > not evaluate any return codes or output. The only change that landed > together with the VDR shutdown rewrite in 1.5.1 is that the script is > now called detached from VDR, so it can run in parallel and will not > terminate together with VDR. Some shutdown scripts may need to be adapted. > If you want to investigate: thread.c:SystemExec() is called with the new > parameter Detached=true. STDIN is redirected to /dev/null, STDOUT and > STDERR are same as VDR, all other FD's get closed as before. You can reproduce the problem pretty easy: If I use an 'empty' shutdown script that just starts with "#!/bin/sh" or bash or whatever, the script itself becomes a zombie. And if I use a script with just an empty line, "sh" becomes the zombie. So in either way, something is wrong and it can not be the script's fault. It would be helpful if someone could test this behavior. My assumption is that the problem occurs because of the missing wait call (if SystemExec is called 'detached'). I know, if VDR would wait in there, the script wouldn't run simultaneously. But if VDR never waits for the child's PID, the child's termination never gets handled and imho that's why the script remains as a zombie. waitpid( -1, &dummy, WNOHANG) called at some place later should do the trick. Or waitpid() explicitly for the child's PID, if we want to store the PID anywhere. -- Chris ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1.5.x Shutdown
Chris <[EMAIL PROTECTED]> wrote:
> My assumption is that the problem occurs because of the missing wait
> call (if SystemExec is called 'detached'). I know, if VDR would wait
> in there, the script wouldn't run simultaneously. But if VDR never
> waits for the child's PID, the child's termination never gets handled
> and imho that's why the script remains as a zombie.
>
> waitpid( -1, &dummy, WNOHANG) called at some place later should do the
> trick. Or waitpid() explicitly for the child's PID, if we want to
> store the PID anywhere.
i once found this code somewhere and since use this:
int
System(const string &cmd) {
// The parent process forks and then waits right there for the child
// to terminate. The child process then forks again, giving us achild
// and a grandchild. The child exits immediately (and hence the parent
// waiting for it notices its death and continues to work). Now the
// grandchild does whatever the child was originally supposed to do.
// Since its parent died, it is inherited by init, which will do
// whatever waiting is needed.
switch (fork()) {
case 0:
if (!fork()) system(cmd.c_str());
_exit(0);
break;
case -1: break;
default: wait(NULL);
}
return (0);
}
i didn't look at vdr's SystemExec, but maybe this code snipet comes in
handy.
best regards ...
clemens
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
