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% availability, that's clear. I do regular service
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 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
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] 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...=622pageid=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
