Re: [vdr] Filesystem hierachy standard patch needs review.
On Fri, Apr 6, 2012 at 9:50 PM, Gero geronimo...@gmx.de wrote: I can't stand when things are installed all over the place. Let's take a quick look at real life: if you need to exchange the tooth belt on your motorcycle - will you perform that task in your living room? if you visit your friend for the first time and you look for a cold beer - will you look in his bedroom? In real life we all spread our things all over the house to keep them in order. The refrigerator will be placed in the kitchen, the car in the garage and your bed will most probably be in your bedroom. I don't spread things all over my house and from the sound of it neither do you(?). All my bathroom items are in the bathroom. All my kitchen items are in my kitchen. All my office items are in my office. I keep everything VDR in one place. It works great (for me). I see no reason to put a VDR binary in one dir, plugin binaries in another dir, config files in another dir, this stuff in this dir, that stuff in yet another dir.. If you like to sleep on toilet or shit in your kitchen - I don't mind. For me, people that like to keep their PC in order behave quite natural, there's no need to offend them for thinking different. I'm not sure who is offended but if my personal preference opinion offends you, maybe you shouldn't value other peoples preferences opinions so much because it's not a big deal. Instead of going on about that stuff, which is completely irrelevant, maybe someone can answer what I've already asked: As far as the patch, is it really necessary to split the files up even further? What is the real benefit? Also, don't different distros use different dir structures, so what's common on some may not be on others? If this is an attempt to standardize something, it's probably best to find a standard that exists across _all_ distros (if this isn't the case here). Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Filesystem hierachy standard patch needs review.
On Fri, Apr 6, 2012 at 11:25 AM, Gero geronimo...@gmx.de wrote: Well, *I* think, that there's a big difference between keeping things in order compared to spreading things all over the place. I can't stand when things are installed all over the place. It's too messy and pointless in my opinion. I'm in the habit of simply running VDR from it's source dir and using symlinks. It makes things very easy like archiving working/test sources, changing between versions without any needless 'reinstall'ing, etc. I see no benefit what-so-ever to installing over running VDR from the source dir, unless of course you're using pre-compiled binaries. As far as the patch, is it really necessary to split the files up even further? What is the real benefit? Also, don't different distros use different dir structures, so what's common on some may not be on others? If this is an attempt to standardize something, it's probably best to find a standard that exists across _all_ distros (if this isn't the case here). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.27
On Sat, Mar 31, 2012 at 4:10 PM, Dominic Evans oldma...@gmail.com wrote:
- The channel name column in the What's on now/next menu now adjusts its
width to display the full short name of each channel (suggested by Dominic
Evans).
Unfortunately, this doesn't seem to be working. I just upgraded to vdr
1.7.27 and the channel name is now only a single character for every
channel.
I had the same problem here as well. Klaus has fixed it, try the patch below:
diff -pruN vdr-1.7.27-orig/channels.c vdr-1.7.27/channels.c
--- vdr-1.7.27-orig/channels.c 2012-03-25 22:46:14.294920001 -0700
+++ vdr-1.7.27/channels.c 2012-03-28 09:29:23.734920001 -0700
@@ -955,7 +955,7 @@ int cChannels::MaxShortChannelNameLength
if (!maxShortChannelNameLength) {
for (cChannel *channel = First(); channel; channel = Next(channel)) {
if (!channel-GroupSep())
-maxShortChannelNameLength =
max(Utf8StrLen(channel-ShortName()), maxShortChannelNameLength);
+maxShortChannelNameLength =
max(Utf8StrLen(channel-ShortName(true)), maxShortChannelNameLength);
}
}
return maxShortChannelNameLength;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xine plugin and vdr 1.7.27
On Fri, Mar 30, 2012 at 9:02 AM, Jouni Karvo jouni.ka...@iki.fi wrote:
it seems xine-plugin 0.9.4 does not compile with vdr 1.7.27.
I'm not sure if Rnissl has done a proper fix yet but in the meantime
you can try:
diff -pruN xine-0.9.4-orig/Makefile xine-0.9.4/Makefile
--- xine-0.9.4-orig/Makefile2012-03-30 09:54:28.0 -0700
+++ xine-0.9.4/Makefile 2012-03-30 09:55:25.0 -0700
@@ -97,7 +97,7 @@ OBJS = $(PLUGIN).o xineDevice.o xineLib.
### The main target:
-all: libvdr-$(PLUGIN).so i18n xineplayer
+all: libvdr-$(PLUGIN).so xineplayer
### Implicit rules:
diff -pruN xine-0.9.4-orig/xine.c xine-0.9.4/xine.c
--- xine-0.9.4-orig/xine.c 2012-03-30 09:54:28.0 -0700
+++ xine-0.9.4/xine.c 2012-03-30 09:55:01.0 -0700
@@ -13,7 +13,6 @@
#include xineDevice.h
#include xineSettings.h
#include xineSetupPage.h
-#include xineI18n.h
@@ -208,9 +207,6 @@ bool cPluginXine::ProcessArgs(int argc,
bool cPluginXine::Initialize(void)
{
-#if APIVERSNUM 10507
- RegisterI18n(PluginXine::Phrases);
-#endif
// Initialize any background activities the plugin shall perform.
m_remote = new PluginXine::cXineRemote(m_remoteOn);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
On Tue, Mar 13, 2012 at 8:08 AM, Torgeir Veimo torg...@netenviron.com wrote: I've seen this a lot lately. due to tuning problems with my nova-t 500s, I've gotten frequent zero length recordings. Playing back these either using the xine plugin, or xineliboutput, causes VDR to crash and restart. I'm using yavdr with only trivial modifications. I compile VDR myself and never have this problem. I use vdr-xine and have been test softhddevice but in case of an empty recording, VDR just returns to live tv. Sounds like a yavdr problem -- last I heard yavdr uses a bunch of patches but since I don't use it I don't know that 100%. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
On Tue, Mar 13, 2012 at 11:54 AM, Frank Neumann v...@auktion.hostingkunde.de wrote: last I heard yavdr uses a bunch of patches but since I don't use it I don't know that 100%. Well that's always good and cheap to talk about things about any individual heard about ... :-( There is nothing wrong with passing along what you've heard. Furthermore, I intentionally pointed out that I don't know that to be 100% true. Your claim that my comment is cheap is completely uncalled for. If you wanted to reply, rather than trying to insult me you should have clarified that YES yavdr applies patches to VDR, or NO it does not. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr crashes when replaying zero length recording
On Tue, Mar 13, 2012 at 12:43 PM, Frank Neumann v...@auktion.hostingkunde.de wrote: That's what I read: Hey stupid I'm super cool and able to compile VDR by myself, you're a nobody just able to use this bullshit yaVDR ... Then you're a complete idiot because that is NOT what I said. Grow up. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Theses Client/Server VDR
On Sun, Mar 4, 2012 at 5:39 AM, Tony Houghton h...@realh.co.uk wrote: Servers able to (dis)allow timer privileges (create, modify, delete) for each client. Servers able to (dis)allow recording privileges (edit, delete) for each client. A reasonable idea, but IMO it would need to be easily configurable on the fly, eg in vdradmin, not buried in a config file that requires VDR to be restarted after editing. I think restarts should be avoided as much as possible. There's nothing more annoying than restart/reboot, especially when it's not necessary! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton h...@realh.co.uk wrote: Signal the server to start recording. But then the client has to be able to match up its buffer with what the server has recorded after the buffer filled and let the server know when the temp recording is no longer needed. Complicated. Maybe something like this would work... User can define how much of his ram he wants used for buffering. VDR uses x% of this for constant buffering. The remainder is only used when pause/rewind has been pressed. When the remainder is filled, the entire buffer is dumped to disk as a temp recording, which continued to be recorded until a) live view has been resumed for X secs, or b) until the show ends. The temp recording is then purged after a user defined X minutes (or never if 0) of it's last modified timestamp. If live buffering is to be added, it should have some flexibility, but it still doesn't need to be overly complicated. Whatever the actual live buffer behavior, I believe a ram-based solution is the best choice for a number of reasons. Have the server record everything it plays and not bother with buffering in the client. I don't think most people want VDR to work that way because of extra load on the hard drive. HELL NO! I will not use software that forces my harddrive(s) into a constant write state 24/7. I don't want the extra wear. I don't want the extra heat. I don't want the extra power consumption. And I'm certainly not alone. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter udo_rich...@gmx.de wrote: Am 01.03.2012 07:03, schrieb VDR User: one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain.. The number of Klaus per VDR has always been quite limited. A developer team would surely speed things up, but I also understand that Klaus prefers to keep all development in his own hands instead of delegating and supervising. Letting 'his baby' off the hook isn't easy, and I would understand if he prefers to keep it under control. I'm not talking about him releasing control of anything. I'm talking about people wanting willing to help develope, being assigned a code task and parameters. When the work is complete, Klaus reviews and either accepts/merges, or instructs the coder what needs to be changed. There's no reason for Klaus to release control of anything in this model. As long as there's a clear instruction of what he wants, and good communication along the way, I can't think of any good reason against it. In a sense this already happens, just on a smaller scale. VDR already contains non-Klaus code. Surely there's a middle ground where development can be assisted because in reality this doesn't need to take forever. Nobody expects it to be finished in a week, but it doesn't need to take forever either. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, Feb 29, 2012 at 12:20 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: Yes, the next stable version will be 2.0. Version 1.0 was the SD version, and version 2.0 shall be the HD version ;-). Sounds good! :) I'll see to make client/server a priority after that. I honestly had to read this a couple times to make sure I wasn't misunderstanding some how. This is a huge announcement and I think everyone will agree a big step in the right direction to suit modern needs. Since it sounds like true server/client will really happen for VDR now, maybe it would be a wise idea to start a dedicated thread to it for collecting information on identifying the needs/wants, and ways they can be met. This is a great opportunity to thoroughly think things through so the actual server/client design integration addresses all the necessary considerations. ...What an awesome way to start off the day! You're my hero Klaus! :D ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, Feb 29, 2012 at 11:45 AM, Udo Richter udo_rich...@gmx.de wrote: In any case this would be the biggest rewrite of major parts of VDR ever, with lots of breakage, total loss of plugin compatibility and very long development cycle. It's not a small task, but I believe the end product will be well worth the effort. VDR has the benefit of having coder support. If people are willing (as I think they would be), one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain.. It's a lot of work but there's no reason it should take years to complete either. Especially if the design is well-thought out ahead of time. As far as plugin breakage.. I would expect there to be some growing pains and plugin maintainers needing to fix/add support for this is just a necessary part of the progression. Keep in mind, people have been wishing for VDR to go this route for quite a while so even if it means extra work fixing plugins, I think you'll find more people welcoming this change than not. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
I'm included in the list of people that wished VDR supported real server/client. I don't mean hacks and workarounds but real true support, which of course means a major redesign. I know several users who hated to but left VDR because it lacks this. Bringing VDR to modern times/needs would be absolutely great but based on previous posts it seems very unlikely this is going to happen. :( Then again it looked like Klaus would never give HD non-FF priority and that need was meet so who knows? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
On Thu, Feb 23, 2012 at 2:38 AM, fnu v...@auktion.hostingkunde.de wrote: Dudes, did set up a basic VDR on Ubuntu Precise yesterday and it did work as expected. Install a minimal Ubuntu from alternate installer, add apt-get install xorg nvidia-current, VDR e.g. from our yaVDR PPA (ppa:yavdr/unstable-vdr, ppa:yavdr/main) incl. vdr-plugin-softhddevice and you're almost done. SoftHDDevice does start with this basic Xorg from Ubuntu repository, no additional WM like openbox, fluxbox, lightdm etc. needed. I've been testing softhddevice basically since I first saw this thread. I never heard of softhddevice before that. So far it works fairly well. There are a few issues to sort out (such as issues ffw/rew h264 recordings, allowing users to set the color of the non-video area *for plasma tv users, etc) but overall it's off to a great start imo. Also, the issues I've found also existed and were fixed in vdr-xine so I'm confident they could be fixed in softhddevice as well. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
What's the url for this plugin? I would definitely like to try it! Does it also have a built-in media player? Does it support an HD osd? I've always used xine-lib-1.2 vdpau + vdr-xine and the mplayer plugin for media playback. Then recently tried xineliboutput because it has a built-in media player. Thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
On Tue, Feb 7, 2012 at 8:07 AM, fnu v...@auktion.hostingkunde.de wrote: Does it support an HD osd? Where ist the difference? Plugin does support OSD size up to display resolution ... How about the new truecolor osd VDR has now? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
On Tue, Feb 7, 2012 at 8:55 AM, fnu v...@auktion.hostingkunde.de wrote: How about the new truecolor osd VDR has now? Well, you did ask regarding a HD OSD which isn't automatically a true color OSD ... Sorry, I had two questions. 1) does it support HD resolution, and 2) does it support truecolor. I should have been more clear. Sounds like the answer is yes to both though. Whereas AFAIK true color OSD is also possible with SD (576i) output, e.g. xine/xineliboutput. The main problem, there isn't any real true color OSD skin out there, to use it ... I've made several truecolor themes for yaepghd but bball (the author) never added support for it so I've been hoping for another option to use them. Do you know of any VDR skinning tutorial? Maybe my work can be used afterall. But the skins I did test, looked impressive with softhddevice :-) I've now tried softhddevice and upon first impression, I like it! However, I do have some things to say... - I haven't figured out how to enter fullscreen mode. The README.txt does say you need a windows manager but that installs too much crap I don't need/want. Fullscreen mode should be possible _without_ a windows manager. - There's a lot of junk logging, such as: video: 23:29:31.541 +833 432 206/\ms 3 v-buf video: 23:29:31.541 +833 432 206/\ms 3 v-buf video: 23:29:31.561 +853 432 206/\ms 3 v-buf video: 23:29:31.561 +853 432 206/\ms 2 v-buf video: 23:29:31.581 +843 545 206/\ms 7 v-buf video: 23:29:31.581 +826 529 206/\ms 7 v-buf video: 23:29:31.601 +813 495 206/\ms 7 v-buf If this is useful for debugging or dev work, it should only be enabled with a debug switch or something, but spamming the log with info that appears useless to a regular user is bad behavior. - Helpful logging is missing. For example, I didn't see anything telling me I'm using VDPAU. I didn't see anything telling me what the current deinterlacer being used is. These types of infos _are_ useful imo and should be present in the log. - I didn't see an option to toggle between surround sound and surround-to-stereo mix anywhere. This is very useful to people who don't leave their receiver and surround sound speakers on 24/7. And also for people who watch channels with surround sound but only have stereo speakers. All our systems are minimal. All using VDPAU. All using audio+video over HDMI. No windows/desktop/etc, only xserver - only because vdr-xine/xineliboutput/xine-lib need it to create video output. All systems are installed on usb stick or sdhc card. I'm not sure how (un)stable the plugin is yet but I'd like to continue using this plugin while it matures. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
On Tue, Feb 7, 2012 at 11:05 AM, fnu v...@auktion.hostingkunde.de wrote: - I haven't figured out how to enter fullscreen mode. Well, AFAIK this is mentioned in the README. There are a couple of switches/options for the plugin start, one of them is -f for full screen. An other one is -d for the correct display and -x to start xorg by the plugin. And no, there is no need for a display manager, I wonder where you got this information ... most of us do test the plugin on existing Linux desktop installtion, because there's quit a way to go ... From vdr -h: softhddevice (0.4.7) - A software and GPU emulated HD device -a device audio device (fe. alsa: hw:0,0 oss: /dev/dsp) -p device audio device (alsa only) for pass-through (hw:0,1) -d displaydisplay of x11 server (fe. :0.0) -fstart with fullscreen window (only with window manager) -g geometry x11 window geometry wxh+x+y -xstart x11 server -s start in suspended mode -w workaround enable/disable workarounds no-hw-decoder disable hw decoder, use software decoder only no-mpeg-hw-decoder disable hw decoder for mpeg only alsa-driver-broken disable broken alsa driver message See -f.. only with window manager.. Also, with the -g option, what is wxh+x+y supposed to mean exactly? wxh(resolution?)+x(x position for top left corner of the window?)+y(y position of top left corner of the window?)...? That's just a guess -- it should be made more clear imo. Also, if softhddevice can start an xserver, it should be able to do it in fullscreen mode so I see no reason at all for windows manager requirement. Btw, most of the users I know don't use a Linux desktop, they have dedicated systems connected directly to their tv. I think it's good to consider at least the most common setups. But VDPAU is IMHO closed to be ready for production use, but not VA-API or even XvBA ... That's good news since I'm a VDPAU-only user. ;) I did want to build an i5-based VDR test box just for fun though so eventually I do plan on trying the other option. Since author johns AFAIK isn't dealing with this mailing list, you could place your questions here in this tread: http://www.vdr-portal.de/board17-developer/board21-vdr-plugins/109700-softhd device-software-vdpau-va-api-cpu-decoder-und-ausgabe-plugin/?s=b83100f9ae841 a9015a5769eb450a5611c1c7cb8 Don't worry just post in english, you'll get the answer also in english. Or feel free to open a new one in english, you will get answers in english ... ;-) Thanks, I just send him a private message providing a link to this thread and asked that he read it when he has a few free minutes so I don't have to copypaste. I do see some promise with this plugin and it's _great_ that one finally exists which will offer different HW accelerated options, and not require xine-lib. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
On Tue, Feb 7, 2012 at 11:48 AM, Gerald Dachs v...@dachsweb.de wrote: Thanks, I just send him a private message providing a link to this thread and asked that he read it when he has a few free minutes so I don't have to copypaste. He told already in the vdr-portal that he wouldn't like to subscribe to this list. Generally it might be better if you would have a little bit more work doing cutpaste than the plugin author, because he is very busy working on the plugin. There's a large non-german speaking VDR population that wouldn't know that because of the fact. I've noticed in the past that people at vdr-portal seem to get annoyed when someone asks them to repeat what they've already said in german, but again in english. :\ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SoftHDDevice
On Tue, Feb 7, 2012 at 12:21 PM, fnu v...@auktion.hostingkunde.de wrote: -f start with fullscreen window (only with window manager) Hmm, AFAIK xorg does come with a build in window manager, I'm not 100% sure, but I guess it's called xwm. Xorg comes with a ton of useless dependencies. It's a complete waste when only xserver is needed. It's possible xorg comes with xwm but I'm certain that xserver doesn't. This provides just basic window work and I did use just pure xorg over years with the softdevice plugin. There was no need to install openbox, fluxbox etc. You don't need a windows manager with xine/vdr-xine either, but according to softhddevice own text, -f requires it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput and xine-ui not fitting together
On Fri, Feb 3, 2012 at 7:22 AM, Manfred Schmidt-Voigt manfred.schmidt-vo...@mannitec.de wrote: Hello xineliboutput specialist, after an update of my debian-sid Desktop last weekend I have no longer a working xineplugin (xineplug_inp_xvdr.so) for the xine-ui. xine-ui now ist based on libxine2 but the libxine1-xvdr plugin is based on libxine1 (as the name allready states). Are there any plans to create a debian package of the plugin which fits also to libxine2? Did you try contacting the xine-lib debian maintainer directly? Maybe he's unaware of the problem. Regardless, you can always just compile themself as I do. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.23
On Mon, Jan 23, 2012 at 9:46 AM, Halim Sahin halim.sa...@t-online.de wrote: Hi, The media_build repo contains only backported drivers. Are you sure that the new api changes were backported? The media_build repo is a daily snapshot of what you'd get with media_tree (minus the kernel source itself). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] howto ignore lines in channels.conf
On Sun, Jan 15, 2012 at 3:29 AM, Ville Skyttä ville.sky...@iki.fi wrote: Even though they'd get lost when VDR writes it, allowing comments there would be an improvement so distros (and VDR itself) could ship the file with some comments in it that instruct users what they need to do before things will work, or what the file is for, or... Same thing applies to remote.conf, setup.conf, and timers.conf. If the AllowComments parameter exists just for the purpose of disallowing comments in files where VDR doesn't preserve them, I suggest removing that restriction altogether and allowing comments everywhere. Allowing comments and preserving them are two different things. For files where VDR doesn't preserve them it could note that on the first line of such files, for example like: # Warning: VDR will overwrite this file without preserving comments. I see no real benefit in complicating file (which stores only channel information) functions with what you've suggested. It just seems like a bunch of unnecessary work inside VDR for something that isn't any more useful than simply putting such info/comments in the README, MANUAL, INSTALLATION, or other appropriate files. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] shouldn't a vdr recording pause during status 3 flag?
On Fri, Jan 13, 2012 at 11:33 AM, Lou tuxoho...@hotmail.de wrote: Where can I find tarballs for vdr 1.4.x? Your webspace only ships version patches (diff) ftp://ftp.tvdr.de/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LiveBuffer for vdr 1.7.x
On Sun, Jan 1, 2012 at 11:44 AM, René linu...@hertell.com wrote: the official gentoo overlay? Even better if it could be added as a basic feature of vdr (that could be turned on/off from the settings :-) Klaus? Please, please, please :-) There was talk of this some time ago, though I don't think anything solid came of it. I personally am not interested in it unless ram came be used for the buffer storage. Having a harddrive (or even worse, an ssd) in a constant write state 24/7 is not something I'd like to do. Whatever the case, I think you'll be stuck with the patch for a while. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LiveBuffer for vdr 1.7.x
On Sun, Jan 1, 2012 at 1:31 PM, René linu...@hertell.com wrote: There was talk of this some time ago, though I don't think anything solid came of it. I personally am not interested in it unless ram came be used for the buffer storage. Having a harddrive (or even worse, an ssd) in a constant write state 24/7 is not something I'd like to do. Whatever the case, I think you'll be stuck with the patch for a while. I have set my livebuffer to use 2gb memory (hdd). If i would have 4gb ram (now i have just 1gb), then i would use a 2gb ramdisk for livebuffer, and the rest for my system. This would be more than enough.. :-) But having a patch working for vdr is ok too :-) RAM is cheap enough now days that having plenty of it isn't a problem for most people. For example, 4GB will cost you less than a few hours at the pub with friends. :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr] playing divx from vdr
Arturo, please stop starting new threads when replying to the same subject. Just reply in your original thread from now on ok? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-prefermenu and vdr 1.7.21
On Wed, Dec 7, 2011 at 7:54 AM, Joe solevit...@googlemail.com wrote: A while ago, I forked the prefermenu-plugin and named it favorites. It can be downloaded from the German vdr-portal: http://www.vdr-portal.de/board1-news/board2-vdr-news/106482-announce-favorites-0-0-1-aka-skin-enabled-prefermenu/ . My version is skin enabled, so it uses the original vdr menu functions and skin. The drawback might be that the channel list is now a normal vdr menu with uses the whole OSD area. Can you please provide a few screenshots. Thanks, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine dropped frames warning
On Tue, Nov 22, 2011 at 3:53 AM, Arturo Martinez marti...@embl.de wrote: With gui.dropped_frames_warning:0 in the config file (which was added while xine was not running) I still get a popup if I use the OSD for a minute or so See screenshot: http://dl.dropbox.com/u/9975371/IMG_2022_124523.jpg So since the line does not truly disable warnings for me, my question still remains valid. Is there a different line I need to put in the config file or else how can I mod the source code to make the warnings invisible? The command works as expected so the only possible explanation is user error. So either xine was running when you edited the config file, or you didn't edit the right one as Torgeir Veimo suggested. You have to edit the config file for whichever user has started xine. If you started xine as root then edit /root/.xine/config, if you started it as user timmy then /home/timmy/.xine/config, etc.. There is one more option also.. You can use the -c command line switch to force xine to use a certain config file: xine -c /path/to/good/xine.config Then you can verify the config contains the correct setting with: [[ $(grep ^gui.dropped_frames_warning:0 /path/to/good/xine.config) ]] echo config is good :) || echo config is bad :( ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine dropped frames warning
On Sun, Nov 20, 2011 at 1:39 AM, Arturo Martinez marti...@embl.de wrote: I have added gui.dropped_frames_warning:0 but still if the system gets stressed I get a warning box Some xine dev knows by any chance how to remove xine´s ability to display warning boxes or to make them of size 0x0 pixels ? I assume you did not unload xine before editing the config file. The file can not be edited while xine is running. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine dropped frames warning
On Sat, Nov 19, 2011 at 7:04 AM, Arturo Martinez marti...@embl.de wrote: This works well but ocassionally the system is busy and I get a warning that too many frames have been dropped Is there some way I can make sure I get no such warnings? The PC has only a remote control, no mouse so it is a real problem to get these warnings I wouldn´t mind to recompile the source code if somebody could point out a patch to remove the xine´s code for the warning boxes Those annoy a lot of people. Just add this to your xine config: gui.dropped_frames_warning:0 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR and Hybrid DVB Cards ( was HVR 4000 drivers broken - adapter0/frontend1 busy in linux-media list )
This is starting to sound like a big overhaul. If that's the case, maybe it should go one step further and compartmentalize all the settings so VDR can take the next step and provide a true server/client option. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR logs and logwatch
On Sun, Nov 13, 2011 at 1:25 PM, Kartsa k...@kniivila.com wrote: Has anyone built a script for logwatch to get VDR messages from the logs? I am not familiar with perl which is mostly used with logwatch scripts. I assume it is possible to use any other language as well but thought that I would ask here if anyone has already a solution :) That's very easy but what exactly is it you want to check for in the log? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe can't connect
vdr -Pxineliboutput --local=none --remote=37890 --primary try: vdr -P'xineliboutput --local=none --remote=37890 --primary' Using double-quotes is problematic. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reencode/transcode to(!) vdr
On Thu, Oct 27, 2011 at 11:26 AM, M. Fiegert m...@trigfee.de wrote: can anybody please point me to some examples how to transcode/reencode to vdr format (ts or pes if necessary)? I found a lot of convert scripts, mencoder commandlines, ... to transcode from vdr to eg mp4. Unfortunatly I could not find anything for the opposite direction :-( How can I go the other way round (to view external files in vdr with the same comfort as native recordings) or reencode recordings (to compress pes and ts mpeg recordings to h264 with lower resolution - you don't need full picture quality on an archive of political discussions for example). I could not find a mencoder option to output ts. I guess i need to encode with mencoder and then remux with some other tool? Why don't you just use the mplayer plugin? It works with practically no effort and you don't have to waste your time unnecessarily converting things to mpeg-ts. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wanted VDR xineliboutput client
On Tue, Oct 18, 2011 at 7:10 AM, Tony Houghton h...@realh.co.uk wrote: I'm a vdpau user and can say it's works just fine here. Did you compile the xine stack yourself? I find it's very picky, eg if I try to use a repository with a set of packages that allegedly support VDPAU, vdr-sxfe doesn't work at all, and there are also difficulties getting xine, mplayer and gstreamer to all coexist with ffmpeg. I compile xine-lib-1.2 myself. I use mplayer-nogui (and have used mplayer2), but I don't use gstreamer, and don't bother installing ffmpeg since everything works fine without an external copy. Wouldn't fit. The Microserver only takes low profile cards and the x16 slot is also the one nearest the side of the case so there's no room for a double height backplane or thick heatsink like this: Sorry, I missed the low profile card requirement. An 8400GS might fit, but I wouldn't expect its VDPAU capabilities to be up to much. I currently use 8200 onboard graphics with mplayer VDPAU and it's rather jerky as if it's dropping frames just on 720p (with the TV at 1280x720 so no scaling is required). But that could be mplayer struggling to sync 24fps to 60Hz. I used 8400's before upgrading to GT220 GT240. They worked ok but the best deinterlacer I could use on HD content was bob. I haven't used an 8200igp as you are but based on my experience with 8400, I would guess 8400 is the minimum requirement. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wanted VDR xineliboutput client
On Mon, Oct 17, 2011 at 10:37 AM, Tony Houghton h...@realh.co.uk wrote: Is this client only with no DVB cards? You could use an Acer Revo, provided you're confident that you can get VDPAU working, because the Atom CPU is a bit weak for HD. An HP Microserver with an added graphics I'm a vdpau user and can say it's works just fine here. they're only about £130 with the cashback offer. Unfortunately I couldn't find a passively cooled VDPAU-capable card that would fit so I There are a few, here's on example: 1 slot passive cooled Zotac GT430 http://www.newegg.com/Product/Product.aspx?Item=N82E16814500221 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr segfault
On Thu, Oct 13, 2011 at 5:42 AM, Roland Behme r...@nugman.de wrote: What can I do to find out the offending plugin? Try to deactivate the plugins one by one. A core dump and gdb may help as well. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-checkts + vdrnfofs
This is a little off-topic but is there a VDR plugin to view nfo + jpg? Maybe even in the osd since VDR now supports truecolor..? This is the one big feature imo that things such as the mplayer plugin lack and it's really a shame. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
On Sat, Sep 24, 2011 at 4:22 PM, semsem85 sami sami8...@hotmail.com wrote: On Fri, 23 Sep 2011, Rolf Ahrenberg wrote:If you have somewhere such a recording available, I could take a look at it and make sure my patch really fixes subtitling on those Sky Italia channels. I have made a 2 min recording on one of sky italia channels. Here is the link: https://rapidshare.com/files/3992138005/1.ts Hope this helps. Thanks and best regards, Sami Will you please stop making new threads with the same title! Especially a VDR announcement title. :\ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine with new AAC LATM support
On Tue, Sep 13, 2011 at 4:16 AM, Chris Rankin ranki...@yahoo.com wrote: Just in case anyone is interested: There has been a sudden spike in xine development (1.1.19 branch), and AAC LATM audio should now be working with MPEG-TS streams. You will also need to be using FFmpeg = 0.7. Have your patches been merged yet? When will they be merged into the xine-lib-1.2 tree? I don't know anyone still using 1.1 since 1.2 is where the vdpau dev happens. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Gentoo overlay vdr-devel + vdr-xineliboutput
Hi! (this may not be perfect forum for my question, but..) If I select to use Gentoo overlay vdr-devel to get vdr-1.7.19 I cannot use vdr-xineliboutput-1.0.5-r1 plugin because it's blocked for =media-video/vdr-1.7 Why? Is there some reason? Because I have seen xineliboutput-plugin working at 1.7.18.. If mainstream gentoo distro wants to block vdr-1.7, should there be newer version of that plugin in vdr-devel overlay? -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
On Fri, Jul 29, 2011 at 7:45 AM, Tony Houghton h...@realh.co.uk wrote: http://www.ixbt.com/monitor/images/hauppauge-mediamvp/du.jpg If anyone else noticed that support for that type of remote got broken sometime after 2.6.32, I'm pleased to report mine is working again since I upgraded to kernel 3.0. I've got one of those that has worked fine in 2.6.32 up to 2.6.39.3... It's connected with a serial IR. Maybe support for your particular IR receiver broke, but that remote has been just fine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
On Fri, Jul 29, 2011 at 4:17 PM, Tony Houghton h...@realh.co.uk wrote: http://www.ixbt.com/monitor/images/hauppauge-mediamvp/du.jpg If anyone else noticed that support for that type of remote got broken sometime after 2.6.32, I'm pleased to report mine is working again since I upgraded to kernel 3.0. I've got one of those that has worked fine in 2.6.32 up to 2.6.39.3... It's connected with a serial IR. Maybe support for your particular IR receiver broke, but that remote has been just fine. Mine is connected via the DVB card. It says saa7146 in /proc/bus/input/devices but ISTR it's actually the budget or budget_ci module that handles it. It used to require a patch a few years ago and I think the patch was for the key mappings. Ahh, gotcha. Mine came with a nexus-s, which uses av7110_ir. I saw the remote and automatically associated it with the nexus. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] projects.vdr-developer.org now has a new home
On Fri, Jul 29, 2011 at 3:26 PM, Tobi listacco...@e-tobi.net wrote: Hello everyone! http://projects.vdr-developer.org/news/135 projects.vdr-developer.org is now hosted on a new server: Opteron™ 1381 Quad-Core, 4 x 2,5 GHz 4 GB RAM 2 x 500 GB (Raid 1) 500 GB FTP Backup Space IP: 85.214.78.111 The server is still fully sponsored by xeatre.tv (http://www.xeatre.tv). Thanks a lot! Thanks to Siegmar as well for providing the subdomain! It's currently running a 64bit Debian/Squeeze with Kernel 2.6.32-5. I also took the chance to change some things under the hood. The updated Redmine now runs under a Mongrel cluster served by the Nginx webserver. This should give it a minor performance boost. git-web has been replaced by cgit, which is significantly faster. You might now also use the cgit-URL's to pull a repository via http. (http://projects.vdr-developer.org/git) Instead of gitosis, I now use gitolite to manage the Git-repositories. I have plans to integrate the repository and public key management into Redmine at some time, but don't expect this very soon. The username for SSH-write-access to the Git-repositories has been changed from 'gitosis' to 'git-vdr'. You can still continue to use the old username, but I might drop this sometimes. It is easily changed with: git remote set-url origin \ git-...@projects.vdr-developer.org:repository-name.git If you are missing a feature, have any improvement suggestions or have any problem, please create an issue here: http://projects.vdr-developer.org/projects/project-management/issues/new or contact me by mail: p...@e-tobi.net I'm still fine-tuning everything and try to make projects.vdr-developer.org as secure and reliable as possible. So if the site isn't reachable in the next days for a short time, I might currently be working on it. Please try again later in this case or contact me. Have fun! Tobias Thanks for making this happen. It's a great resource for people, and is appreciated! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
On Wed, Jul 27, 2011 at 12:36 PM, Udo Richter udo_rich...@gmx.de wrote: Those kind of remotes are cool but I wouldn't want one for daily use. I prefer direct access to many options with one button press, not going through menus on a remote screen. From my experience, the keys I _really_ use, are: (1) Core keys: 0-9, Up/Dn/Left/Right, Menu/Ok/Exit, Color keys, Power, Vol+/- (2) Keys I often use: Timers, Recordings, EPG (3) Nice to have, but not essential: Info, Play/Pause/Stop/Rec/Ffwd/Fbwd (4) Rarely used: Mute, Ch+/-, Audio tracks, Subtitle tracks, Channel list I can use (1) and (2) and some of (3) completely blind. Having them on some kind of touch screen is not an option. I/we pretty much use the following daily: 0-9, up/down/left/right, ok/enter/exit, epg, recordings, timers, color keys, subtitle, play/pause/stop/ffw/rew, record, skip +/-... I also like to have a few keys available for macros. I haven't found any remote that I felt was perfect. I'd love to design one with my own specific button layout but the cost to make a custom remote exceeds my willingness to pay for it so I've got a few that are good enough. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] perfect vdr remote?
On Tue, Jul 26, 2011 at 7:39 AM, Torgeir Veimo torg...@netenviron.com wrote: The Philips Prestigo SRT9320 seem to have a perfect key layout for VDR. Does anyone have any experience with this remote with VDR? http://www.newscenter.philips.com/pwc_nc/main/shared/assets/be/Downloadablefile/Prestigo_SRT9320_product_3.jpg http://www.amazon.com/review/B0026L7B94 Those kind of remotes are cool but I wouldn't want one for daily use. I prefer direct access to many options with one button press, not going through menus on a remote screen. For that reason I'm using this exact one (and a few other which are similar): http://www.newegg.com/Product/Product.aspx?Item=N82E16880121003 The perfect remote is decided by opinion only so just get whatever _you_ like. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.19 recording issue
On Thu, Jul 21, 2011 at 1:41 AM, Mike Booth mike_boot...@iprimus.com.au wrote: I've got round the problem of noty being able to play recordings made with vdr-1.7.19 by removing recorder.c recorder.h recording.c recording.h and remux.c remux.h and replacing them with the same files from vdr-1.7.18. Not very elegant but seems to work with new recordings and in the absebce of anything else You experience this problem with vanilla VDR? Or are you adding patches that may not have been updated to work properly with VDR-1.7.19? I've been using VDR-1.7.19, have made tons of recordings, and had no problems what-so-ever playing them back or playing back older recordings from previous versions. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
On Thu, Jul 14, 2011 at 10:23 AM, Udo Richter udo_rich...@gmx.de wrote: Is there any reason why the ring buffer can't or shouldn't be dynamic aside of just not bothering to implement it? Unlimited buffers tend to get unlimited big, crashing your app with out-of-memory. Huge buffers also add lag to the signal. With no bandwidth issues, buffers are usually almost empty, with bandwidth issues, buffers are usually almost full. I'm not sure such a blanket statement can be made these days. There are plenty of apps which grow shrink buffers on the fly which seem to be perfectly stable. I suppose sloppy coding and mishandling of memory would cause the symptoms you're describing though. On a side-note, a lot of people experience a frozen vdr/xine with 100% buffer. It's never been fixed to my knowledge and it's been a while since I've seen it brought up but iirc it has nothing to do with bandwidth. Rnissl, I think, knows what actually causes that particular problem. In the end you set them as big as necessary, and as small as possible. And giving them a fixed size (possibly configurable) is less complicated, especially in a multi-threaded environment. Translation: path of least resistance. ;) Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Ring buffer overflows with streamdev and remux script
On Wed, Jul 13, 2011 at 12:05 PM, Luboš Doležel lu...@dolezel.info wrote: Apart from simplifying the script to a single line I've found a solution: I've tripled the size of the ring buffer in vdr-streamdev-server and the problem is gone. No problems after hours of playback... Is there any reason why the ring buffer can't or shouldn't be dynamic aside of just not bothering to implement it? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR record only new episodes of shows?
On Tue, Jun 7, 2011 at 12:42 PM, John Klimek jkli...@gmail.com wrote: However, my original question was about unaired/new episodes. For example, I'd like to record new episodes of The Simpsons but I don't want an episode unless it's never been aired before. It sounds like the Don't allow repeats option is just to check if it's been recorded which isn't too useful in my situation. Suppose an episode hasn't aired for several months? It's not a new episode but just an old one that hasn't aired in a while so I would want to skip that recording. I would like this option also and iirc there's actually a flag that specifies a new episode. I know at least some providers supply an original air date as well which could be compared against the current date if the new flag isn't present. It would be nice to set a timer for a show, tell it you want _all_ new episodes, and it's smart enough to detect schedule changes and so on. So basically you could record an entire series (over all seasons) if you wanted to and only need to set a timer once and forget about it. It sucks to find out there's been a schedule only after you've missed some episodes, or have to frequently clean out a cache of dupes. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
On Sat, May 28, 2011 at 1:57 AM, Johan Andersson j...@jna.pp.se wrote: I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'. 'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though. I managed to build the yavdr teams vdr-dev(1.7.17) for Ubuntu Lucid, from source with my change so I can again record TV6. The main reason for using the yavdr stuff is VDPAU, as I use xineliboutput. Getting a VDR setup with vdpau is very easy. There's no need to use special repositories, packages, etc. unless you actually want to. If vdpau is the only thing you're after, you might be creating more work for yourself by not just keeping it small simple. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Stop live TV whilst in menu
On Thu, May 12, 2011 at 12:29 PM, Dominic Evans oldma...@gmail.com wrote: Is there any patch for VDR that stops Live TV whilst you're in the menus? None that I'm aware of but what's the point of doing that anyways? If it's a matter of being too distracting or something then you can always modify the themes transparency so the background is solid and increase the OSD size to cover the entire video frame. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How about a small UK/Ireland S28.2E VDR community forum?
On Thu, May 5, 2011 at 8:38 AM, Henning Pingel henn...@henningpingel.de wrote: Maybe this could also be a good starting point for building up an English language VDR user community forum - starting off with UK/Ireland users. I always thought an English language community was missing next to the German language VDR portal (www.vdr-portal.de). There is already a large english-speaking forum located at DVBN. http://dvbn.happysat.org There are a lot of VDR and mythtv users there, some of which actually use yavdr but most who compile VDR themselves. @Rob Davis: Don't worry, you're not alone. There is a huge NA VDR community, although most of it exists outside of this mailing list and most VDR forums. The best place to associate with your kind is likely the Linux forum at DVBN. :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr + epgsearch = no timers
Hi! I have strange problem. After installing (again) whole vdr system from scratch, epgsearch plugin don't add any timers anymore. At vdradmin-am I can see all those EPG Search's and if I execute one of those, it' find what it should find. But even I click Force Update nothing comes to Timers. Yes, I have set at settings Re-create timers after delete and I have done reinstallation with apt-get purge vdr-plugin-epgsearch (that removes all config files). -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr + epgsearch = no timers
Hi! Yes I have.. And I managed to fix that problem.. Error mixing yavdr and ubuntu?!? From somewhere (I don't know where) /etc/init.d/vdr script sat --port=2001 (even SVDRP_PORT was not set anywhere) but still at /etc/vdr/setup.conf epgsearch.SVDRPPort = 6419 So, everything looked good, except timers could not be added by epgsearch plugin... :-) I found that after I managed to put epgsearch-plugin to verbose level 3 and point logfile to /tmp -directory... Thank you everyone who tried to help me solve this! :-) 03.05.2011 10:30, Harald Overas kirjoitti: Do you have a file called epgsearch.conf inside the folder /etc/vdr/plugins/epgsearch or /var/lib/vdr/plugins/epgsearch. If not create one with touch epgsearch.conf and set the correct permission chown vdr:vdr epgsearch.conf. Chech also if you have a file called epgsearchdone.data. I use the epgsearch git version from http://projects.vdr-developer.org/git/?p=vdr-plugin-epgsearch.git;a=summary Like this: [archvdr@mythpc epgsearch]$ ls -l /etc/vdr/plugins/epgsearch/ total 28 -rwxr-xr-x 1 vdr vdr 2069 Apr 26 11:40 epgsearchcats.conf -rwxr-xr-x 1 vdr vdr 987 Apr 26 11:40 epgsearchcmds.conf -rw-r--r-- 1 vdr vdr 2522 May 1 19:52 epgsearch.conf -rw-r--r-- 1 vdr vdr 2302 Apr 26 11:40 epgsearchconflmail.templ -rw-r--r-- 1 vdr vdr0 May 1 19:43 epgsearchdone.data -rwxr-xr-x 1 vdr vdr 1568 Apr 26 11:40 epgsearchmenu.conf -rw-r--r-- 1 vdr vdr 4236 Apr 26 11:40 epgsearchupdmail.templ [archvdr@mythpc epgsearch]$ Epgsearch.conf stores all the timer information from vdradmin or vdr-live before its written to vdr own /var/lib/vdr/timers.conf or /etc/vdr/timers.conf Harald On Tue, May 3, 2011 at 8:32 AM, VDRv...@jjussi.com wrote: Hi! I have strange problem. After installing (again) whole vdr system from scratch, epgsearch plugin don't add any timers anymore. At vdradmin-am I can see all those EPG Search's and if I execute one of those, it' find what it should find. But even I click Force Update nothing comes to Timers. Yes, I have set at settings Re-create timers after delete and I have done reinstallation with apt-get purge vdr-plugin-epgsearch (that removes all config files). -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TT Premium S2-6400 (F?ley Istv?n)
On Thu, Apr 21, 2011 at 11:44 AM, Udo Richter udo_rich...@gmx.de wrote: Am 20.04.2011 23:33, schrieb VDR User: On Wed, Apr 20, 2011 at 10:34 AM, Udo Richter udo_rich...@gmx.de wrote: Thats probably because you need at least an 2GHz P4 to boot windows and a virus scanner nowadays. I seriously doubt virus scanners have anything to do with anything. That seems more trying to take a cheap jab at Windows then anything else. My work PC is an Core 1 Duo 1.8GHz running XP. The PC boots to desktop in roughly a minute, but is not usable for another 2 minutes due to high CPU and disk load by McAfee virus scanner. (I use SysInternals Process Explorer to monitor.) Also, every day at 10 I cannot do anything CPU or disk hungry for 1-2 minutes because McAfee does its signature update. You really notice that, even without the sudden increase in fan noise. Just recently I've upgraded the machine from 1.5Gb to 3Gb RAM with noticeable speed improvements. (Visual Studio 2010 is a huge memory hog!) Back when XP was released, it was working with 128Mb RAM, and was well equipped with 256Mb RAM. The OS is still the same... I can't believe a dvb card vendor sets their minimum requirements based on things such as McAfee loads. It would be absurd to do so. Btw, I used XP as well for many years. However, my boot times were never more then 30 secs. However, I've never bothered running virus scanners or anything like that unless I ran into an actual problem (10 times since win95), in which case I ran one and then exited the app - never left one running full-time. My XP boxes all had 1GB or 2GB or ram. XP + 2GB + VS6 worked great. I may have also used VS2005 at one point but not since then. Is VS2010 really that much of a resource hog?? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TT Premium S2-6400 (F?ley Istv?n)
On Wed, Apr 20, 2011 at 10:34 AM, Udo Richter udo_rich...@gmx.de wrote: I was a little bit surprised to see in the specifications that it needs a CPU minimum P4 2 Ghz. Thats probably because you need at least an 2GHz P4 to boot windows and a virus scanner nowadays. The CPU and RAM demands should be not much higher than with an old SD FF card, as long as you only handle the encoded video stream like VDR does. The highest 'demand' is probably having an PCI Express socket already. (Not that PCI bandwidth wouldn't be enough either, but PCIE probably seemed more future proof and simpler.) I seriously doubt virus scanners have anything to do with anything. That seems more trying to take a cheap jab at Windows then anything else. Anyways, the requirements may be what they are because of what is actually offloaded to the decoder. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
On Sun, Apr 17, 2011 at 2:36 AM, syrius...@no-log.org wrote: vdr-sxfe output complains it can't demultiplex the stream, but that won't work when I'm away and nobody's watching tv. That won't prevent vdr from using the bad card. If the vdr-sxfe log gives you useful text for this, why can't you simply write a script that runs in the background and checks for such text every X seconds. If the text is found, it can do whatever you normally do to fix the problem. I do something similar to detect xine crashes and it works fine. Although my preference would be the buffer usage: 100% crash would be fixed once and for all. ;) But that's another issue.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
On Sun, Apr 17, 2011 at 6:39 AM, John Klimek jkli...@gmail.com wrote: My DVB-S provider sends a 9-day EPG guide only one one specific transponder. Is it possible to use only that transponder for EPG grabbing? ...or can I specify which channels/transponders to use somehow? AFAIK VDR isn't capable of that. I just remember to tune an EEPG transponder every few days. You could write a little cron script to tune your EEPG transponder each day at some hour like 4am (assuming you're sleeping at that time), let it sit for however long it takes to populate, and then tune back to the channel it was on previously. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
On Sun, Apr 17, 2011 at 9:18 AM, John Klimek jkli...@gmail.com wrote:
What's the best way to tune to that transponder? Using SVDRP?
(ie. I'm new to VDR but would I issue a CHAN command, then wait 10
minutes (or whatever), then issue another CHAN command?)
Yeah, svdrp, sorry forgot to mention that. You can issue CHAN without
a channel number to obtain the current channel. An example could be
something like:
==
#!/bin/bash
eepg_chan=whatever
prev_chan=$(svdrpsend.pl chan |sed -n 2p |awk '{print $2}')
svdrpsend.pl CHAN $eepg_chan
svdrpsend.pl SCAN
sleep 10m
svdrpsend.pl CHAN $prev_chan
==
Could I disable automatic EPG grabbing and manually tell it to grab
EPG in my script? (using SVDRP?)
The SCAN svdrp command forces a scan, but I don't know how disabling
EPG grabbing in VDR setup would affect that. I would expect the
behavior of a _forced_ scan to scan regardless of any settings since
the point is to force it.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can VDR use one specific transponder for EPG information?
On Sun, Apr 17, 2011 at 1:31 PM, Timothy D. Lenz tl...@vorgon.com wrote: Just a thought but you could set up a daily or weekly timer with a very low priority on the recording so it auto deletes it. I've never used the auto delete after set time because I never know how long it will be before I get back to watching the recording. Are you sure the epg scanner is active if the device is recording? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] preventing vdr from using a device to record
On Sat, Apr 16, 2011 at 7:28 AM, syrius...@no-log.org wrote: I'm now running one vdr instance with 4 dvb devices. One device is crashing quite often and I haven't find a way to automatically detect when it's crashed. (vdr used to issues unknown picture type message in the past) If you're not seeing anything useful to your VDR log to determine if the card has crashed, you may want to look at dmesg to see if something in there could be used. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Mon, Apr 4, 2011 at 2:34 AM, fnu v...@auktion.hostingkunde.de wrote: Hi there, to finish discussion if RGYB ist a standard or not or where does it come from: Your theory that the RGYB color scheme is a worldwide standard with only cheap obscure non-media remotes being 'non-compliant' has already been thrown out the window. I don't know why you think pasting a link to an Italian website can somehow resurrect the dead theory. Btw, no link you ever paste will outweigh what color scheme people see on their physical remotes. If you want to argue about it further then contact Panasonic, Sony, and your friends at Logitech to start with. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Mon, Apr 4, 2011 at 3:33 PM, fnu v...@auktion.hostingkunde.de wrote: === Your theory that the RGYB color scheme is a worldwide standard with only cheap obscure non-media remotes being 'non-compliant' has already been thrown out the window. I don't know why you think pasting a link to an Italian website can somehow resurrect the dead theory. Btw, no link you ever paste will outweigh what color scheme people see on their physical remotes. If you want to argue about it further then contact Panasonic, Sony, and your friends at Logitech to start with. === Well, that's a claim. It's not just any italian URL, this is the main page of the inventor and license holder for TOP Teletext. This is the company where all manufacturer do pay their license fees to, if their TV set do provide this function. The invention of T(able) O(f) P(ages) Teletext brought us the colored keys on TV remotes 25 years ago, not surprisingly in the order R(ed) G(reen) Y(ellow) B(lue). Fifteen years later, Klaus adopt these common keys and standardized this order, RGYB, for his awesome and incredible solution VDR, as they are anywhere available, except on some trashy ones ... ...shakes head... Please refer to my previous post, then let's not continue this foolishness on the VDR ml ok? Ok. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Sat, Apr 2, 2011 at 4:40 AM, fnu v...@auktion.hostingkunde.de wrote: Regardless, users always have the option to patch the feature in if it doesn't become a part of VDR's core. Here we go! Provide a patch, users can use or not w/o assuming to change vdr-core. Like the majority of users, I do use remotes following kls's VDR standard defined a century ago. I don't want to bothered w/ configurable colored keys, it can be just another cause for malfunctions, mere you guys are not willing to buy a remote which is compatible w/ VDR's standard. This is IMHO not a to high expectation, because you also buy DVB devices which are compatible w/ VDR ... If remotes would be some very expensive devices, I may follow your arguments, but you guys do often buy the cheapest you can get and expect that core VDR will changed to be usable with these sometimes pulpy devices, wereas also compatible devices are available for the same price ... You aren't doing yourself any favors by making all these silly assumptions. I mean this in the nicest way possible -- everything quoted above is complete nonsense. Nobody is ever giong to take you seriously if you keep posting such rubbish. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Sat, Apr 2, 2011 at 2:33 AM, Rolf Ahrenberg rahre...@cc.hut.fi wrote: The RGYB color enumeration is defined in the video teletext standard and every TV/STB set implementing the teletext feature DOES use the mentioned color button order. I guess the teletext is used mainly in Europe, so there might be different conventions elsewhere, but the VDR is a STB for DVB standard that documents the teletext too. I have two top end tv's, one Panasonic, one Sony. Both support teletext, neither have the color button scheme as RGYB. I would guess it's as you mentioned, maybe that scheme is commonly used in Europe but it's simply not true that RGYB is some standard used across the globe with only cheap obscure remotes not conforming to it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
I applied both your patches and skipping does seem to be improved quite a bit. Something still seems a little off however. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Fri, Apr 1, 2011 at 3:13 AM, fnu v...@auktion.hostingkunde.de wrote: The color order of the RGYB buttons is a common standard, defined for Teletext centuries ago. So, 99.999% of all remotes providing these keys do have this order. That's definitely not true. I have about 8 different remotes and at least half don't use that button order. In addition, not every remote has color buttons 4 in a row. Plenty of them make a square around other buttons such as 'ok/enter' for example. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Fri, Apr 1, 2011 at 2:54 PM, fnu v...@auktion.hostingkunde.de wrote: vdr-user: That's definitely not true. I have about 8 different remotes and at least half don't use that button order. In addition, not every remote has color buttons 4 in a row. Plenty of them make a square around other buttons such as 'ok/enter' for example. Oliver Schinagl: I wasn't aware that the order of buttons was standarized on remotes === Well, could be that not all remotes for each pinchy device might provide color keys at all or in this order. But if they are somehow TV oriented, they follow this order in a global manner, even the M$ ones, if they have colored keys. You want an evidence? Just check out the universal remotes form the big three manufactures, Philips, Logitech One-for-All, if the devices do offer colored keys, the order is RGYB, nothing left, nothing right, and you should really ask yourself, why? And, the most important point, global standard or not, it has been defined as standard in VDR a century ago, and this is a fact. I'm not sure why you're trying to argue this. There are users in this thread (including myself) that already own remote(s) that don't follow this order. Assuming they're all for some pinchy device is silly. ALL of my remotes either came with dvb cards or sold as a media remote -- all of which are 'oriented' for tv among other devices. Also, you pointing out remote makers that follow the RGYB _scheme_ doesn't void the fact that plenty of remotes exist that don't. It's funny you use Logitech as one of your examples considering they make a mixture of remotes that do and don't follow that button scheme. That goes against your claims, not suport them. Ignoring remotes that don't follow the RGYB scheme doesn't make them any less 'tv oriented' or go away. I can't imagine it's much of a leap to make the colored button position customizable and is probably something that's better to have then not. What good argument against allowing the user to customize the layout according to their actual remote button layout could there be? None that I can think of. I'd guess Klaus will consider any patches submitted to him which don't cause problems. Regardless, users always have the option to patch the feature in if it doesn't become a part of VDR's core. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
On Thu, Mar 31, 2011 at 8:27 AM, Joerg Riechardt j.riecha...@gmx.de wrote: Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxx because it's too old (diff : y) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with - readIndex = Index - 1; // Action() will first increment it! + readIndex = Index; // Index - 1 causes problems in xine I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high. This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch. I would very much appreciate if somebody with deeper knowledge of the interplay between vdr - vdr-xine - xine-lib would look into and comment on this. Are you saying that when you press skip+/-, you get a delay before the skip occurs? If so, I experience this problem too. Most of the time when I press skip+/-, there's a 4-6 second pause before the skip actually occurs. Very aggravating to say the least. The good news is that Rnissl has this problem also so there's no need to try to reproduce it -- he can already observe it locally. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
On Thu, Mar 31, 2011 at 12:01 PM, Joerg Riechardt j.riecha...@gmx.de wrote: Are you saying that when you press skip+/-, you get a delay before the skip occurs? Well, before stable replay starts. You could run xine verbose and post your log in order to know if we are talking about the same thing, I am not sure from your description. Maybe I misunderstoof you. I don't have a problem playing recordings, only when using skip+/-. If so, I experience this problem too. Most of the time when I press skip+/-, there's a 4-6 second pause before the skip actually occurs. Very aggravating to say the least. The good news is that Rnissl has this problem also How do you know? Are you in contact with him? Yes. However, I'm referring to the problem I described. I guess you may have a separate problem. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On Mon, Mar 28, 2011 at 2:24 AM, Tim rollercoas...@reel-multimedia.com wrote: - Fixed detecting frames on channels that broadcast with 50 or 60 fps. I just made a recording from arte HD with VDR 1.7.17 and everything worked fine. It played correctly (on a TT-S2 6400 prototype), the current and total times displayed by the progress display were correct and I was able to place and move an editing mark with the picture getting updated just fine. For me the frame detection works fine, but still the wrong framerate is written to the info file (always F 25 is written there). Maybe some nasty patch is breaking this for me, but i don't find it. Is this really working correct for you? Can you give me a hint where the information is transferred from the cFrameDetector to cRecordingInfo? I'll jump in and say that all my new HD recordings have the correct framerate (mixture of 59.94 and 29.97) in their relative info files. I suspect some patch you're using is breaking this and you've mentioned. The good news is it should be pretty easy to figure out which one. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump patch 0.1
On Wed, Mar 23, 2011 at 2:37 PM, Udo Richter udo_rich...@gmx.de wrote: One question here, if I shrink already existing recordings with the command line tool, is it necessary to delete the index? The command line tool just processes a single .ts file. You have to process each file of the recording, and you have to regenerate (delete) the index file. I was interested to see how your patch works but after running the command line tool on a few recordings, none of them shrunk so I can only assume that my provider doesn't include such fill data. I like the idea however and appreciate your time in developing it. There's a sample script at VDR Portal that automates this. It may be wise to post that script along with your next patch update. There are a lot of NA users who have trouble trying (and consequently stop) to navigate german-based vdr portal. Best regards ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] rotor-ng
On Tue, Mar 22, 2011 at 5:41 AM, Morfsta morf...@gmail.com wrote: At the moment you need to manually edit the file to set the positions up. A later version might include assigning or changing the position numbers directly in the plugin interface. I should at this point thank Luca Olivetti for all his work on the actuator plugin. I'm no developer, so wouldn't have been able to get this far without all the work he did on the scan interface etc. I've merely hacked his work to modify it to work with disecq 1.1 and fixed some issues with DVBS2 tuning. Ideally, we should probably work together to unify the two plugins so you can select Actuator / Disecq / GOTOX as the motor type attached and have a totally new plugin probably called Dish or something similar. I don't use a actuator/rotor myself but I know people who do and are really looking forward to your plugin. I think a good stable 'vdr-movedish' plugin has been needed for quite some time. It almost seems like a plugin you'd expect to come with vanilla VDR since it provides such a basic function. Anyways, thanks for your work. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
On Mon, Mar 14, 2011 at 12:21 AM, Simon Baxter linu...@nzbaxters.com wrote: Just switched from vdr-1.7.16 to vdr-1.7.17 and am getting these error messages. Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: switching to MPEG1/2 mode Mar 14 20:08:51 freddy vdr: [10728] cVideoRepacker: operating in MPEG1/2 mode Those aren't error messages, they're just information messages from vdr-xine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How's the 24 bit OSD VDR coming?
On Tue, Mar 8, 2011 at 1:31 PM, Udo Richter udo_rich...@gmx.de wrote: Don't get too excited about the TrueColor OSD, though. What comes with VDR is only the basic OSD platform that allows plugins to use full screen 32 bit ARGB color, with alpha blendable pixmaps and such. Do you have any numbers on OSD speed for, lets say, some prototype output device you may have at hand? An old-style 720x576x8 display has just 400k size, HD RGB32 however has 6Mb. This could limit display update speed notably for animations or video overlays using OSD. Would be nice to know how much is possible. With things like VDPAU, I would imagine some very cool things are possible and considering how many people are using VDPAU with VDR now, hopefully we'll get a good pool of skinners coming up with some great options to choose from. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] startup problems
On Thu, Feb 17, 2011 at 7:09 AM, Jouni Karvo jouni.ka...@iki.fi wrote: I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble? Check the VDR log and xine log. If VDR has a problem starting, you should be able to find out why in it's log. And if it's xine related, you then check the xine log.. And so on.. Just follow the crumbs until you find the problem. Shouldn't be too hard. :) That was done already: vdr -l 3, xine --verbose=2; there is no hint on syslog or console output - except this, on the main thread: And what happens when you take the watchdog out of the equation? Can you manually start VDR at will without any problems? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Email problem - who is the postmaster?
On Wed, Feb 16, 2011 at 8:25 AM, Stefan Taferner tafer...@kde.org wrote: Am Mittwoch, 16. Februar 2011, um 16:05:44 schrieb Paul Menzel: Dear Scott, Am Montag, den 14.02.2011, 19:54 + schrieb Scott Waye: What is the postmaster email address for this list? sorry, I do not know. I get some of the messages 7 times 20 minutes apart. I do not experience this problem. No problem here too. I honestly think the problem is on Scott's end. I've been here for years and never had that problem either. I would make sure your issues aren't being caused locally first. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] startup problems
On Wed, Feb 16, 2011 at 6:48 AM, Jouni Karvo jouni.ka...@iki.fi wrote: I don't know where to start. Is this a vdr, lirc or a driver problem, or perhaps initscript order problem? Should I try the 2.6.38-rc5, or would that be just looking for trouble? Check the VDR log and xine log. If VDR has a problem starting, you should be able to find out why in it's log. And if it's xine related, you then check the xine log.. And so on.. Just follow the crumbs until you find the problem. Shouldn't be too hard. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.16 FF card crashes
On Thu, Feb 10, 2011 at 5:13 AM, syrius...@no-log.org wrote: I've got a couple FF cards that work fine, although I've used them as budget cards ever since I moved to a VDPAU setup. Hi, do you mean you have modified your ff card as explained on http://www.linuxtv.org/wiki/index.php/DVB_TT_Budget_Patch ? No, my FF cards are unmodified. I mean that I'm not using the FF aspect -- I don't use the onboard decoder or tv output. I switched to VDPAU for decoding (back when VDPAU was developed against the xine-lib-1.1 tree), and the video cards output obviously. This was long before VDR-1.7.16 and FF support moved into a plugin (dvbsddevice in VDR-1.7.11). Do you use to have arm crashes or/and unknown picture type errors before ? I experienced arm crashes a very long time ago (years) and it was due to firmware, but since it was fixed there hasn't been any. I've never got an unknown picture type error. I have also considered modifying my ff card but i'm not sure if it will fix my issues. Any advice or feedback on that matter would really be helpful. Your card should work as is with no modifications necessary. My only advice is that you use the current firmware and driver. Maybe there's a bug in the dvbsddevice plugin? That's the only thing I can think of since there's no doubt FF cards work fine with VDR-1.7.16 when used as budget cards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.16 FF card crashes
I've got a couple FF cards that work fine, although I've used them as budget cards ever since I moved to a VDPAU setup. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Detecting recording errors
On Wed, Feb 9, 2011 at 4:59 PM, Tobias Grimm listacco...@e-tobi.net wrote: Is there a patch/plugin/tool/whatever which would make VDR somehow tag recordings where there were stream-error when recording? It shouldn't be too hard to scan a *.ts-File for discontinuity errors, but I would like to make VDR detect this while recording and somehow set a flag, so I can see if a recording might have errors. No idea anyone? What else besides continuity errors could be checked, to see if a TS recording has errors? There are at least a few tools for Windows that can do that. If you have a Windows box, you may want to look into using that for this. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] skip +/- 60 sec suggestion.
On Sun, Feb 6, 2011 at 9:17 AM, Mario Schulz dr...@arcor.de wrote: Am 06.02.2011 11:43, schrieb Torgeir Veimo: When using the skip forward / backward buttons, eg to jump through the ads, it would be convenient if the skip backward button skipped backwards 30 seconds instead of 60, on the first press. Subsequent skip backwards would skip 60 seconds as normal. This would make it easier to narrow down the start of a program after skipping ads. Binary search has already been patched into some distributions with the Liemikuutio-patch. Cf. http://www.saunalahti.fi/~rahrenbe/vdr/patches/index.php IIRC, mythtv had a feature built-in that skips ads automagically. Maybe a plugin could be written for VDR which provides the same function. Would be very cool and resolve the problem with seeking h264 recordings where the still frame will remain unchanged for several seconds and by the time it does change, its seeked several minutes. So with h264 ffw/rew you either seek no where or too far. It's pretty bad unfortunately. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] skip +/- 60 sec suggestion.
On Sun, Feb 6, 2011 at 12:16 PM, Theunis Potgieter theunis.potgie...@gmail.com wrote: IIRC, mythtv had a feature built-in that skips ads automagically. Maybe a plugin could be written for VDR which provides the same function. Would be very cool and resolve the problem with seeking h264 recordings where the still frame will remain unchanged for several seconds and by the time it does change, its seeked several minutes. So with h264 ffw/rew you either seek no where or too far. It's pretty bad unfortunately. There is a package called noad for vdr which makes the marks on where the adverts start/stop. you just need to press skip to jump to the next mark while playing or you can enable it in vdr to automatically jump. This is of course a patch that enables this feature. I'll gladly give it a try but the only url I found for noad just goes to some apache page. Do you have a current url or even hg/git address? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Problem with VDR h264 ffw/rew (using VDR-1.7.16)?
When fast forwarding or rewind h264 VDR recordings, the still frames update very slowly. Often times I've seeked several minutes in a recording before the still frame updates and this is much farther then I intended. This doesn't happen with mpeg2 recordings at all. The still frames update very often with those making seeking to the right spot no no problem. Is this a flaw in how VDR seeks h264 or would it be an issue in xine-lib or vdr-xine? This seems worthwhile to address since the still frames are the only reference a user has to tell how far he's seeked in a recording. Can someone please shed light on how to fix this? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Remote receiver options...
MCE usb remote is a good choice or you could build your own very easily using an FTDI component and an IR receiver. In either case it will cost you about $25 or less. Btw, I actually use a couple ION boxes for VDR. I don't use a server/client setup however because from what I understand it just isn't mature enough. I would like full independent osd's on each client, epg is populated by server and shared with clients, and good handling of timers. And I don't want to have to run a bunch of plugins or extra junk to make it work. If I wanted a slapped together solution out of whatever was laying around, I'd just run mythtv but that's not what I'm looking for. Come to think of it, I wonder how the new OSD system will factor into having multiple clients, or if that aspect is being considered at all. Probably not. But that's talk for another thread anyways I think. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
I could be wrong about this but it seems I remember this subject coming up some time ago and Klaus mentioning rotor support is on his todo list. My apologies if I've got that backwards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
On Sat, Jan 22, 2011 at 10:32 PM, Timothy D. Lenz tl...@vorgon.com wrote: That would be nice, I thought he said he wasn't interested in doing it because of lack of interest. I tried to get the subject going again because there are people who would want it, but it seems most of those that would use it are not programmers and rely on others to write it. There are also a lot of people who use vdr that are not on the list. So it's up to use few to speak loud :) You couldn't be more right about there being a lot of VDR users who don't make use of the mailing list. I know a large number myself and have tried to encourage them to participate here. It's hard for developers to really identify the needs/wants when people don't speak up. I've found the mailing list to be very useful and helpful, along with pretty much every developer I've contacted about various VDR related things. I wish more people would speak up, especially the NA VDR users -- there are tons of them but you'd never know it if you only read the mailing list. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
On Sat, Jan 1, 2011 at 1:29 PM, Udo Richter udo_rich...@gmx.de wrote: Hi list, This is the test version 0.0.1 of my h.264 nalu fill data removal tool. The tool deletes NALU fill data from h.264 streams embedded into TS files, like VDR recordings. The overall file structure isn't modified, only complete TS packets of NALU fill data are removed. On HD TV channels that use fixed video bandwidth, this can save 40-60% file size without loosing any data. I tried this on 3 different HD h264 recordings from 3 different channels. In all cases no packets were dropped. However, I don't believe my provider wastes bandwidth with fill data so that would explain it. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deinterlace video (was: Replacing aging VDR for DVB-S2)
On Wed, Jan 19, 2011 at 5:47 AM, Tony Houghton h...@realh.co.uk wrote: I thought there was supposed to be a flag in MPEG meta data which indicates whether pairs of fields are interlaced or progressive so decoders can determine how to combine them without doing any complicated picture analysis. Are broadcasters not using the flag properly, or xine not reading it? xine-ui's preferences dialog has an option to disable interlacing for progressive material, have you set that in whichever front-end you're using? There is. Unfortunately I can't begin to count the number of times I've seen the flag set incorrectly, essentially making it useless. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sun, Jan 16, 2011 at 6:00 AM, Tony Houghton h...@realh.co.uk wrote: I also/mainly mean more economical in power consumption and ease of installation and cooling. Most cheap GT220s have fans (most likely cheap noisy ones) so I wouldn't want one of them in my HTPC. A fanless one might overheat being packed in closely with my DVB cards. But many motherboards already have integrated NVidia chipsets with HDMI, including audio, and basic VDPAU functionality. Mine is an 8200 and I know there's also been a lot of interest in Ion systems for HTPCs, so I think finding some way of getting these systems to display 1080i nicely should be a good move. It's a bad assumption to say lesser expensive gt220 cards have cheap and noisy fans. It's simply not true. It's funny you mention ion as well. I have both ion and ion2 systems as well. One I'm using as a full time htpc, the other is a test box at the moment. And they do 1080i just fine. The ion1 box can't do temporal-spatial on 1080i but it does temporal just fine. I'm very satisfies with the very low power and no noise from the ion's. Maybe a better idea is to not assume anything at all, but rather actually look up real life data or just buy one and see for yourself (as I did). There's no reason to take guesses about any of this stuff, plenty of users have posts their results and specs at various forums. A good place to start would be nvnews.net and read the thread VDPAU testing tool. Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sun, Jan 16, 2011 at 10:22 AM, Tony Houghton h...@realh.co.uk wrote: I've bought many graphics cards over the years and every time one came with a fan it's been noisy and I've replaced it with an aftermarket cooler with a bigger heatsink, and either a bigger fan(s) or no fan. People have different standards of noisy. If everyone was as demanding as me they wouldn't have considered using an XBox as a media player! Indeed they do. I'm particular about noise as I use htpc's with my televisions. I don't want to watch something and have to listen to a fan. If I can barely hear a fan with the tv off, that is acceptable but it must be very low noise. The pictures of these cards are enough for me, I'm sticking to my assumption that if I bought a GT220 I'd have to budget for either getting a specialist model with silent cooler, or replacing the cooler myself. No, pictures aren't enough. That's as silly as saying you can look at a car and somehow magically know how it handles while driving. Sorry, doesn't cut it. Maybe a better idea is to not assume anything at all, but rather actually look up real life data or just buy one and see for yourself (as I did). There's no reason to take guesses about any of this stuff, plenty of users have posts their results and specs at various forums. A good place to start would be nvnews.net and read the thread VDPAU testing tool. The results don't give the right information to determine how well a card can handle 1080i. You apparently don't know the results come from analyzing actual playback of actual samples of actual content. Yes, the data tells you exactly what kind of performance you can expect since it's generated from actual use cases. Again, stop assuming everything and turning your nose up at first-hand experience. I've ran those tests myself, obviously know what deinterlacers I'm using, and have watched plenty of content seeing the result with my own eyes from the hardware we're talking about. Additionally I've done the same with various hardware configurations.. What you're telling people simply doesn't agree with reality. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sun, Jan 16, 2011 at 9:42 AM, Eric Valette eric.vale...@free.fr wrote: BTW: is temporal-spatial available on ion2 and do you see improvement? I think I read somewhere than the bus between the N10 and the ion2 has not the bandwidth to do 1080? Just curious The ion2 is currently being used for testing. It actually can do just over 60 fields temporal-spatial on 1080i with the latest stable driver 260.19.29. IIRC previous driver versions had some issues there. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sat, Jan 15, 2011 at 1:09 PM, Goga777 goga...@bk.ru wrote: In general, get a gt220, as it has built in audio hardware, so that you should get audio without clock drift relative to the hdmi output. It is also powerfull enough to do temporal spatial deinterlacing on 1080i material. what do you think about NVIDIA's GeForce GT 430 http://www.anandtech.com/show/3973/nvidias-geforce-gt-430 seems it's the best choice for vdr/htpc - more cold than gt220 - more powerfull - HDMI 1.4, - 3D over HDMI - Ethernet channel - Audio return channel - 4k × 2k Resolution Support It's a nice card but I'm not sure why you think it's the best choice for VDR/htpc. It's not going to give you any better image quality on HD content then you get from a gt220 at half the price. I don't see any advantage for most users in spending the extra money for one. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replacing aging VDR for DVB-S2
On Sat, Jan 15, 2011 at 2:36 PM, Tony Houghton h...@realh.co.uk wrote: I wonder whether it might be possible to use a more eonomical card which is only powerful enough to decode 1080i without deinterlacing it and take advantage of the abundant CPU power most people have nowadays to perform software deinterlacing. It may not be possible to have something as sophisticated as NVidia's temporal + spatial, but some of the existing software filters should scale up to HD without overloading the CPU seeing as it wouldn't be doing the decoding too. Well, you can get a gt220 for around $40USD which does full rate temporal-spatial 1080i and allows you to use it with an old slow cpu's that are dirt cheap if you don't already have one collecting dust in your basement. Not sure how much more economical you can get aside of free. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On Thu, Jan 13, 2011 at 1:40 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: AIUI VDR generates the OSD as a bitmap no matter which output plugin is used and the player only has the choice of how to overlay it on the video. So getting it rendered by VDPAU would be easy enough, but to upgrade it to HD would probably need some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged. The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like. Wow, wasn't expecting that! Did you get a new tv or something? ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
I agree, the less layer upon layer upon layer, the better. I also want to point out that there are a large number of users who have dedicated VDR boxes connected directly to tv's in an htpc environment, using only a remote control to navigate the menus and ssh for box maintenance. Not computer monitors, using VDR in a window in a desktop environment. The second you've required the user to have a full blown desktop, you've entered the realm of poor design. The ideal situation would be to have minimal requirements/dependencies and no bloat. Additionally, an OSD that takes advantage of vdpau as well so you not only get full HDTV, but also a full high resolution/high color OSD with low hardware requirements cost to the user to go along with it. I know the OSD has been a point of debate but the truth is people do spend a lot of time in the OSD and because of that, there's no reason that can't be an enjoyable user experience. Chalking it up as mere eye candy completely disregards that fact. It's no different to the reason why people put nice stereos in their car... to have a better experience while using it. Given the choice between a nice Benz or a base model Kia...how many people would actually choose the Kia? Not many, so lets not pretend otherwise. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghton h...@realh.co.uk wrote: 1. A stream server plugin. 2. An integrated player plugin based on xine. 3. Standalone xine-based players for connecting to the server. I propose using 1, ignoring 2 (you can disable it with CLI options, I do this anyway because it's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer. From xineliboutput's README: : (xine-lib is not required for server in network-only usage) network usage can include localhost. And you get VDR's full osd doing this? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On Wed, Jan 12, 2011 at 11:15 AM, Tony Houghton h...@realh.co.uk wrote: 1. A stream server plugin. 2. An integrated player plugin based on xine. 3. Standalone xine-based players for connecting to the server. I propose using 1, ignoring 2 (you can disable it with CLI options, I do this anyway because it's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer. From xineliboutput's README: : (xine-lib is not required for server in network-only usage) network usage can include localhost. And you get VDR's full osd doing this? Yes, if you use a libxine-based player which supports it (the support is now in libxine). So to replace xine with something else someone needs to work out how xineliboutput serves up the OSD and write something to read it. If it's embedded as private data packets or whatever in the TS I think it should be possible to hook into ffmpeg's or gstreamer's demuxers to get access to it. So there's no vdr output plugin option available that uses ffmpeg for vdpau decoding and also provides the user with VDR's osd. Hopefully someone capable of writing an output plugin will take interest after reading all the recent posts on the subject. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
