From manfred.schmidt-voigt at mannitec.de Fri Feb 3 16:22:53 2012 From: manfred.schmidt-voigt at mannitec.de (Manfred Schmidt-Voigt) Date: Fri, 03 Feb 2012 16:22:53 +0100 Subject: [vdr] xineliboutput and xine-ui not fitting together Message-ID: <4F2BFBCD.3030907@mannitec.de> 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? Kind regards Manfred -- ------- Manfred Schmidt-Voigt ------- ----- www.mannitec.de ----- ------- mailto:manfred.schmidt-voigt at mannitec.de ------- From user.vdr at gmail.com Fri Feb 3 17:05:57 2012 From: user.vdr at gmail.com (VDR User) Date: Fri, 3 Feb 2012 08:05:57 -0800 Subject: [vdr] xineliboutput and xine-ui not fitting together In-Reply-To: <4F2BFBCD.3030907@mannitec.de> References: <4F2BFBCD.3030907@mannitec.de> Message-ID: On Fri, Feb 3, 2012 at 7:22 AM, Manfred Schmidt-Voigt 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. From listaccount at e-tobi.net Fri Feb 3 22:08:59 2012 From: listaccount at e-tobi.net (Tobi) Date: Fri, 03 Feb 2012 22:08:59 +0100 Subject: [vdr] xineliboutput and xine-ui not fitting together In-Reply-To: <4F2BFBCD.3030907@mannitec.de> References: <4F2BFBCD.3030907@mannitec.de> Message-ID: <4F2C4CEB.1050404@e-tobi.net> On 03.02.2012 16:22, Manfred Schmidt-Voigt wrote: > 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? I'll upload a new package tonight. Tobias From manfred.schmidt-voigt at mannitec.de Fri Feb 3 22:51:15 2012 From: manfred.schmidt-voigt at mannitec.de (Manfred Schmidt-Voigt) Date: Fri, 03 Feb 2012 22:51:15 +0100 Subject: [vdr] xineliboutput and xine-ui not fitting together In-Reply-To: <4F2C4CEB.1050404@e-tobi.net> References: <4F2BFBCD.3030907@mannitec.de> <4F2C4CEB.1050404@e-tobi.net> Message-ID: <4F2C56D3.2090809@mannitec.de> On 03.02.2012 22:08, Tobi wrote: > On 03.02.2012 16:22, Manfred Schmidt-Voigt wrote: > >> 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? > > I'll upload a new package tonight. > > Tobias > Hello Tobias, thats nice, but I have managed it now by using the sources of xineliboutput-1.0.7 and compiling this plugin on the VDR server (only plugin) and on my desktop (only the frontends). And it installs the stuff just at the right places: Installing ///usr/lib/xine/plugins/2.0/xineplug_inp_xvdr.so Installing ///usr/lib/xine/plugins/2.0/post/xineplug_post_autocrop.so Installing ///usr/lib/xine/plugins/2.0/post/xineplug_post_swscale.so Installing ///usr/lib/xine/plugins/2.0/post/xineplug_post_audiochannel.so Installing ///usr/bin/vdr-fbfe Installing ///usr/bin/vdr-sxfe So I'm happy now like it is. But maybe for others it might be helpfull. Thank you Manfred PS: my mail to the list was not sent back to my mailbox and I only saw the answer from "VDR User" only on the maillist archive: http://linuxtv.org/pipermail/vdr/2012-February/thread.html is there any reason why? -- ------- Manfred Schmidt-Voigt ------- ----- www.mannitec.de ----- ------- mailto:manfred.schmidt-voigt at mannitec.de ------- From r.scobie at clear.net.nz Fri Feb 3 23:06:28 2012 From: r.scobie at clear.net.nz (Richard Scobie) Date: Sat, 04 Feb 2012 11:06:28 +1300 Subject: [vdr] Fonts Message-ID: <4F2C5A64.6060904@clear.net.nz> Hi, I am setting up a vdr system and am trying to minimise the number of packages - there is no X11 installed. On Fedora 16, I have installed the required fontconfig and freetype packages, but when I run vdr, I get a "OSD No fonts found" message. I have also installed fontpackages-filesystem, xorg-x11-fonts-ISO8859-1-100dpi and xorg-x11-font-utils but am still getting the same error. Can someone suggest anything else I need, or where the fonts need to be? Regards, Richard From r.scobie at clear.net.nz Sat Feb 4 01:03:07 2012 From: r.scobie at clear.net.nz (Richard Scobie) Date: Sat, 04 Feb 2012 13:03:07 +1300 Subject: [vdr] Fonts In-Reply-To: <4F2C5A64.6060904@clear.net.nz> References: <4F2C5A64.6060904@clear.net.nz> Message-ID: <4F2C75BB.2090000@clear.net.nz> For the archives, all went well after installing the the gnu-free-* font packages. Regards, Richard Richard Scobie wrote: > Hi, > > I am setting up a vdr system and am trying to minimise the number of > packages - there is no X11 installed. > > On Fedora 16, I have installed the required fontconfig and freetype > packages, but when I run vdr, I get a "OSD No fonts found" message. > > I have also installed fontpackages-filesystem, > xorg-x11-fonts-ISO8859-1-100dpi and xorg-x11-font-utils but am still > getting the same error. > > Can someone suggest anything else I need, or where the fonts need to be? > > Regards, > > Richard > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > From torgeir at netenviron.com Tue Feb 7 11:21:34 2012 From: torgeir at netenviron.com (Torgeir Veimo) Date: Tue, 7 Feb 2012 20:21:34 +1000 Subject: [vdr] SoftHDDevice Message-ID: Does anyone have any experience with this plugin, and can offer some opinion on how it differs from the xineliboutput and xine plugin? -- -Tor From steffenbpunkt at googlemail.com Tue Feb 7 11:47:31 2012 From: steffenbpunkt at googlemail.com (Steffen Barszus) Date: Tue, 07 Feb 2012 11:47:31 +0100 Subject: [vdr] SoftHDDevice In-Reply-To: References: Message-ID: <4F310143.6000909@gmail.com> On 07/02/2012 11:21, Torgeir Veimo wrote: > Does anyone have any experience with this plugin, and can offer some > opinion on how it differs from the xineliboutput and xine plugin? > - no use of libxine - decoding in the plugin (no client executable (yet?), no client/server, less buffers) - decoding with ffmpeg (vaapi/vdpau/..) - very young project still, first impressions of people: some things already working well, of course not ready for production yet Just following the discussion @vdr-portal.de , no own experience yet ... From user.vdr at gmail.com Tue Feb 7 16:57:16 2012 From: user.vdr at gmail.com (VDR User) Date: Tue, 7 Feb 2012 07:57:16 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <4F310143.6000909@gmail.com> References: <4F310143.6000909@gmail.com> Message-ID: 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 From vdr at auktion.hostingkunde.de Tue Feb 7 17:07:21 2012 From: vdr at auktion.hostingkunde.de (fnu) Date: Tue, 7 Feb 2012 17:07:21 +0100 Subject: [vdr] SoftHDDevice In-Reply-To: References: <4F310143.6000909@gmail.com> Message-ID: <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> > What's the url for this plugin? I would definitely like to try it! http://projects.vdr-developer.org/projects/plg-softhddevice > Does it also have a built-in media player? No, at the end the mplayer- and music-plugin will do this job > Does it support an HD osd? Where ist the difference? Plugin does support OSD size up to display resolution ... Cheers fnu From user.vdr at gmail.com Tue Feb 7 17:17:10 2012 From: user.vdr at gmail.com (VDR User) Date: Tue, 7 Feb 2012 08:17:10 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> Message-ID: On Tue, Feb 7, 2012 at 8:07 AM, fnu 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? From vdr at auktion.hostingkunde.de Tue Feb 7 17:55:45 2012 From: vdr at auktion.hostingkunde.de (fnu) Date: Tue, 7 Feb 2012 17:55:45 +0100 Subject: [vdr] SoftHDDevice In-Reply-To: References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> Message-ID: <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> > 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 ... 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 ... But the skins I did test, looked impressive with softhddevice :-) Regards fnu From user.vdr at gmail.com Tue Feb 7 19:41:54 2012 From: user.vdr at gmail.com (VDR User) Date: Tue, 7 Feb 2012 10:41:54 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> Message-ID: On Tue, Feb 7, 2012 at 8:55 AM, fnu 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. From vdr at auktion.hostingkunde.de Tue Feb 7 20:05:18 2012 From: vdr at auktion.hostingkunde.de (fnu) Date: Tue, 7 Feb 2012 20:05:18 +0100 Subject: [vdr] SoftHDDevice In-Reply-To: References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> Message-ID: <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> > - 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 ... But VDPAU is IMHO closed to be ready for production use, but not VA-API or even XvBA ... 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 ... ;-) Regards fnu From user.vdr at gmail.com Tue Feb 7 20:30:30 2012 From: user.vdr at gmail.com (VDR User) Date: Tue, 7 Feb 2012 11:30:30 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> Message-ID: On Tue, Feb 7, 2012 at 11:05 AM, fnu 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 display display of x11 server (fe. :0.0) -f start with fullscreen window (only with window manager) -g geometry x11 window geometry wxh+x+y -x start 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 copy&paste. 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. From vdr at dachsweb.de Tue Feb 7 20:48:50 2012 From: vdr at dachsweb.de (Gerald Dachs) Date: Tue, 07 Feb 2012 20:48:50 +0100 Subject: [vdr] SoftHDDevice In-Reply-To: References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> Message-ID: <4F318022.5010801@dachsweb.de> >> 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 copy&paste. 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 cut&paste than the plugin author, because he is very busy working on the plugin. Gerald From vdr at auktion.hostingkunde.de Tue Feb 7 21:21:31 2012 From: vdr at auktion.hostingkunde.de (fnu) Date: Tue, 7 Feb 2012 21:21:31 +0100 Subject: [vdr] SoftHDDevice In-Reply-To: References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> Message-ID: <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> > -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". 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. Regards fnu From user.vdr at gmail.com Tue Feb 7 21:35:02 2012 From: user.vdr at gmail.com (VDR User) Date: Tue, 7 Feb 2012 12:35:02 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <4F318022.5010801@dachsweb.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> <4F318022.5010801@dachsweb.de> Message-ID: On Tue, Feb 7, 2012 at 11:48 AM, Gerald Dachs 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 copy&paste. > > 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 cut&paste 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. :\ From user.vdr at gmail.com Tue Feb 7 21:37:55 2012 From: user.vdr at gmail.com (VDR User) Date: Tue, 7 Feb 2012 12:37:55 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> Message-ID: On Tue, Feb 7, 2012 at 12:21 PM, fnu 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. From vdr at auktion.hostingkunde.de Tue Feb 7 23:42:20 2012 From: vdr at auktion.hostingkunde.de (fnu) Date: Tue, 7 Feb 2012 23:42:20 +0100 Subject: [vdr] SoftHDDevice In-Reply-To: References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> Message-ID: <000501cce5e9$c08341f0$4189c5d0$@auktion.hostingkunde.de> > You don't need a windows manager with xine/vdr-xine either, but according to softhddevice own text, -f requires it. Well xorg alone would not work w/o any basic window management stuff, called it window manager or not, but bottomline it is one, included in pure xorg. If there wouldn't be a thing like this, you would not be able to open just a basic windows, like xterm. And you can do this, nowadays black on black instead of herringbone pattern, if you just install basic xorg with it's dependencies. There must be something which manages the size of the desktop, advise to open a window in a specific size on a defined position, or just fullscreen. All other stuff known as window manager just adds kind of decoration, widgets, buttons, a kind of configuration scripting etc. ... There was also no need to have an decoration manager to operate the old softdevice-plugin (SD), id did just run on the old herringbone desktop ... ;-) Regards fnu From torgeir at netenviron.com Wed Feb 8 00:11:13 2012 From: torgeir at netenviron.com (Torgeir Veimo) Date: Wed, 8 Feb 2012 09:11:13 +1000 Subject: [vdr] SoftHDDevice In-Reply-To: <000501cce5e9$c08341f0$4189c5d0$@auktion.hostingkunde.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> <000501cce5e9$c08341f0$4189c5d0$@auktion.hostingkunde.de> Message-ID: On 8 February 2012 08:42, fnu wrote: > There was also no need to have an decoration manager to operate the old softdevice-plugin (SD), id did just run on the old herringbone desktop ... ;-) And the source code license for softdevice allows you to rip that code out and add it to softhddevice. There's no better way to improve a project then to get involved. -- -Tor From r.scobie at clear.net.nz Wed Feb 8 00:22:40 2012 From: r.scobie at clear.net.nz (Richard Scobie) Date: Wed, 08 Feb 2012 12:22:40 +1300 Subject: [vdr] Using second tuner on TT S2-6400 Message-ID: <4F31B240.6010808@clear.net.nz> I have just managed to get an S2-6400 based vdr sytem up and running and am trying to work out how I can use the second tuner. Currently I have a diseqc switch with two dishes connected to tuner 1, which works now I use the "-D 0" vdr option. I did think that adding "0:" to the top of diseqc.conf file would force it to use the first tuner, but this does not work. In any case, if I add another dish to tuner 2, how do I inform vdr what sources are available on it? I get the impression that a plugin may be required, but I can't see anything suitable on the Wiki plugin page. Any help would be appreciated. Regards, Richard From listaccount at e-tobi.net Wed Feb 8 05:31:52 2012 From: listaccount at e-tobi.net (Tobi) Date: Wed, 08 Feb 2012 05:31:52 +0100 Subject: [vdr] xineliboutput and xine-ui not fitting together In-Reply-To: <5263779254%linux@youmustbejoking.demon.co.uk> References: <4F2BFBCD.3030907@mannitec.de> <4F2C4CEB.1050404@e-tobi.net> <5263779254%linux@youmustbejoking.demon.co.uk> Message-ID: <4F31FAB8.5020301@e-tobi.net> On 08.02.2012 01:31, Darren Salt wrote: > I see that that's been uploaded. Which just leaves vdr-plugin-xine... Coming soon. I'm trying to backport libxine to Squeeze, but I'll probably give up and go ahead switching my VDR to Wheezy so I'm able to at least test it before uploading. Tobias From steffenbpunkt at googlemail.com Wed Feb 8 08:12:22 2012 From: steffenbpunkt at googlemail.com (Steffen Barszus) Date: Wed, 8 Feb 2012 08:12:22 +0100 Subject: [vdr] Using second tuner on TT S2-6400 In-Reply-To: <4F31B240.6010808@clear.net.nz> References: <4F31B240.6010808@clear.net.nz> Message-ID: <20120208081222.082ee522@grobi> On Wed, 08 Feb 2012 12:22:40 +1300 Richard Scobie wrote: > I have just managed to get an S2-6400 based vdr sytem up and running > and am trying to work out how I can use the second tuner. > > Currently I have a diseqc switch with two dishes connected to tuner > 1, which works now I use the "-D 0" vdr option. > > I did think that adding "0:" to the top of diseqc.conf file would > force it to use the first tuner, but this does not work. > > In any case, if I add another dish to tuner 2, how do I inform vdr > what sources are available on it? > > I get the impression that a plugin may be required, but I can't see > anything suitable on the Wiki plugin page. > > Any help would be appreciated. Usually you connect the same source to the second tuner (using multiswitch) or in case nothing like that exist you could use channelbonding, using both tuner at the same cable with some additional hardware for a few dollar. Having different sattelites on different tuners is a bit unusual, but possibly you could configure that by using the ca value in the channels.conf - or checking the dynamite plugin which resently got added something like that. I believe there has been recently posted some basic plugin which could be adapted to what you want as well. (would need to search for it) From ajurik at quick.cz Wed Feb 8 08:35:39 2012 From: ajurik at quick.cz (Ales Jurik) Date: Wed, 08 Feb 2012 08:35:39 +0100 Subject: [vdr] Using second tuner on TT S2-6400 In-Reply-To: <4F31B240.6010808@clear.net.nz> References: <4F31B240.6010808@clear.net.nz> Message-ID: <4F3225CB.8000809@quick.cz> On 02/08/12 00:22, Richard Scobie wrote: > I have just managed to get an S2-6400 based vdr sytem up and running and > am trying to work out how I can use the second tuner. > > Currently I have a diseqc switch with two dishes connected to tuner 1, > which works now I use the "-D 0" vdr option. > > I did think that adding "0:" to the top of diseqc.conf file would force > it to use the first tuner, but this does not work. > > In any case, if I add another dish to tuner 2, how do I inform vdr what > sources are available on it? > > I get the impression that a plugin may be required, but I can't see > anything suitable on the Wiki plugin page. > > Any help would be appreciated. > > Regards, > > Richard The dvb card index in diseqc.conf is counted from 1, not from 0, so try change "0:" to "1:". For second tuner add "2:" before lines with sources connected to second tuner. BR, Ales From sergiogomez at tostado.com.ar Wed Feb 8 17:27:12 2012 From: sergiogomez at tostado.com.ar (Sergio Daniel Gomez) Date: Wed, 08 Feb 2012 13:27:12 -0300 Subject: [vdr] Using second tuner on TT S2-6400 In-Reply-To: <4F3225CB.8000809@quick.cz> References: <4F31B240.6010808@clear.net.nz> <4F3225CB.8000809@quick.cz> Message-ID: <4F32A260.10800@tostado.com.ar> El 08/02/12 04:35, Ales Jurik escribi?: > On 02/08/12 00:22, Richard Scobie wrote: > The dvb card index in diseqc.conf is counted from 1, not from 0, so try > change "0:" to "1:". For second tuner add "2:" before lines with sources > connected to second tuner. > > BR, > > Ales > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > Hi all! Some like this: ---------------------------------------------- 1: #Galaxy28 at S89W S89W 11700 V 9750 t v W15 [E0 10 39 F0] W15 t S89W 99999 V 10750 t v W15 [E0 10 39 F0] W15 T S89W 11700 H 9750 t V W15 [E0 10 39 F0] W15 t S89W 99999 H 10750 t V W15 [E0 10 39 F0] W15 T ... 2: #Hispasat at S30W S30W 11700 V 9750 t v W15 [E0 10 39 F0] W15 t S30W 99999 V 10600 t v W15 [E0 10 39 F0] W15 T S30W 11700 H 9750 t V W15 [E0 10 39 F0] W15 t S30W 99999 H 10600 t V W15 [E0 10 39 F0] W15 T ... ---------------------------------------------- I have 2 dvb cards and one diseqc in each card (one frontend in each card). But what about cards with multiple frontends? It's the same confuguration? It's # first card 1: 2: 3: 4: #second card 5: 6: ... Best regards. Sergio www.sergiodanielg.com.ar From r.scobie at clear.net.nz Wed Feb 8 19:38:07 2012 From: r.scobie at clear.net.nz (Richard Scobie) Date: Thu, 09 Feb 2012 07:38:07 +1300 Subject: [vdr] Using second tuner on TT S2-6400 In-Reply-To: <4F32A260.10800@tostado.com.ar> References: <4F31B240.6010808@clear.net.nz> <4F3225CB.8000809@quick.cz> <4F32A260.10800@tostado.com.ar> Message-ID: <4F32C10F.5040407@clear.net.nz> Thanks for all the replies, I'll try the diseqc.conf again. Long term, it may be better to move to a multiswitch for the flexibility. Regards, Richard Sergio Daniel Gomez wrote: > Hi all! > > Some like this: > ---------------------------------------------- > 1: > #Galaxy28 at S89W > S89W 11700 V 9750 t v W15 [E0 10 39 F0] W15 t > S89W 99999 V 10750 t v W15 [E0 10 39 F0] W15 T > S89W 11700 H 9750 t V W15 [E0 10 39 F0] W15 t > S89W 99999 H 10750 t V W15 [E0 10 39 F0] W15 T > ... > > > 2: > #Hispasat at S30W > S30W 11700 V 9750 t v W15 [E0 10 39 F0] W15 t > S30W 99999 V 10600 t v W15 [E0 10 39 F0] W15 T > S30W 11700 H 9750 t V W15 [E0 10 39 F0] W15 t > S30W 99999 H 10600 t V W15 [E0 10 39 F0] W15 T > ... > ---------------------------------------------- > I have 2 dvb cards and one diseqc in each card (one frontend in each card). > But what about cards with multiple frontends? > It's the same confuguration? > It's > # first card > 1: > 2: > 3: > 4: > #second card > 5: > 6: > ... > > Best regards. > > Sergio > www.sergiodanielg.com.ar > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > From werner at suse.de Thu Feb 9 16:33:31 2012 From: werner at suse.de (Dr. Werner Fink) Date: Thu, 9 Feb 2012 16:33:31 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? Message-ID: <20120209153331.GA18485@boole.suse.de> Hi, ... yep, I'm aware of http://upnp.vdr-developer.org/ but this one seems to be very dead. Nevertheless I'd like to use a VDR as recording system only using the second coax line maybe extended by uncable to use two transponders over one coax line. For this it would be perfect to be able to manage, control, and navigate the VDR and its menues over the DLNA support of this new TV. Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 ------------------------------------------------------------------ "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr From denis.loh at googlemail.com Thu Feb 9 20:45:16 2012 From: denis.loh at googlemail.com (Denis Loh) Date: Thu, 09 Feb 2012 20:45:16 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <20120209153331.GA18485@boole.suse.de> References: <20120209153331.GA18485@boole.suse.de> Message-ID: <4F34224C.1030601@googlemail.com> Am 09.02.2012 16:33, schrieb Dr. Werner Fink: > Hi, > > ... yep, I'm aware of http://upnp.vdr-developer.org/ but this one > seems to be very dead. Nevertheless I'd like to use a VDR as > recording system only using the second coax line maybe extended > by uncable to use two transponders over one coax line. For this > it would be perfect to be able to manage, control, and navigate > the VDR and its menues over the DLNA support of this new TV. > > Werner > Hi, i am still working on it. However, progess is very slow, sorry. Nevertheless, you cannot control the vdr the way you expected. An default DLNA server only allows you to show media files (and live TV) on your DLNA or UPnP capable device. You cannot schedule recordings, start/stop the server or do anything beside watching media, unfortunatelly. DLNA does not specify those features in its current version 1.5. It will be supported in 2.0 and above, however it may take some years that devices implementors will support them as they are mostly optional. I even haven't seen any TV device which supports the tuner service capability of a DLNA media server very well (In this case, you would be able to switch channels by pressing a channel number or by chan-up/chan-down). Additionally, it won't be possible to show any EPG or OSD on an DLNA device without work-a-rounds, like transcoding EPG/OSD into an MPEG stream. There is a possibility to transmit text based date, but this is not being supported by any TV device I know. Well, DLNA sounds perfect when you don't expect too much: you may exchange media from one device to another. You can share media of a certain device to others and let them play it. But you cannot play files which are not supported by the device, even though it may play the files directly for instance via USB. Sounds ridiculous, but works as designed. I work on an work-a-round to support scheduling records via browser navigation. But, this is not very user friendly because you have to "play" every command and simulate a media file to the TV. Every DLNA server must support a web page where the server allows to show additional information. I will use live among others in this case, as it seems to do everything needed. I hope this will help, somehow. Please let me know, if you miss something to be supported. Denis From radi at radylon.com Fri Feb 10 08:27:09 2012 From: radi at radylon.com (Michael Rademacher) Date: Fri, 10 Feb 2012 08:27:09 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <4F34224C.1030601@googlemail.com> References: <20120209153331.GA18485@boole.suse.de> <4F34224C.1030601@googlemail.com> Message-ID: <20120210072709.GB9974@radylon.com> Hi, On Thu, 09.02.12, at 20:45 Denis Loh wrote: > Well, DLNA sounds perfect when you don't expect too much: Thanks a lot for this clarification in contrast to the usual adulation for DLNA. :) Radi. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From werner at suse.de Fri Feb 10 18:03:51 2012 From: werner at suse.de (Dr. Werner Fink) Date: Fri, 10 Feb 2012 18:03:51 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <4F34224C.1030601@googlemail.com> References: <20120209153331.GA18485@boole.suse.de> <4F34224C.1030601@googlemail.com> Message-ID: <20120210170351.GA12249@boole.suse.de> On Thu, Feb 09, 2012 at 08:45:16PM +0100, Denis Loh wrote: > Hi, > > i am still working on it. However, progess is very slow, sorry. > Nevertheless, you cannot control the vdr the way you expected. An > default DLNA server only allows you to show media files (and live TV) > on your DLNA or UPnP capable device. You cannot schedule recordings, > start/stop the server or do anything beside watching media, > unfortunatelly. > > DLNA does not specify those features in its current version 1.5. It > will be supported in 2.0 and above, however it may take some years > that devices implementors will support them as they are mostly > optional. I even haven't seen any TV device which supports the tuner > service capability of a DLNA media server very well (In this case, > you would be able to switch channels by pressing a channel number or > by chan-up/chan-down). > > Additionally, it won't be possible to show any EPG or OSD on an DLNA > device without work-a-rounds, like transcoding EPG/OSD into an MPEG > stream. There is a possibility to transmit text based date, but this > is not being supported by any TV device I know. > > Well, DLNA sounds perfect when you don't expect too much: you may > exchange media from one device to another. You can share media of a > certain device to others and let them play it. But you cannot play > files which are not supported by the device, even though it may play > the files directly for instance via USB. Sounds ridiculous, but works > as designed. > > I work on an work-a-round to support scheduling records via browser > navigation. But, this is not very user friendly because you have to > "play" every command and simulate a media file to the TV. Every DLNA > server must support a web page where the server allows to show > additional information. I will use live among others in this case, as > it seems to do everything needed. > > I hope this will help, somehow. Please let me know, if you miss > something to be supported. Hmmm ... maybe HbbTV would be an option. Let's say for handling the VDR. Otherwise I would like to avoid softdevice as well as expensive full featured HDTV DVB-cards. Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 ------------------------------------------------------------------ "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr From pim at zandbergen.org Fri Feb 10 18:07:32 2012 From: pim at zandbergen.org (Pim Zandbergen) Date: Fri, 10 Feb 2012 18:07:32 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <20120209153331.GA18485@boole.suse.de> References: <20120209153331.GA18485@boole.suse.de> Message-ID: <4F354ED4.9050005@zandbergen.org> I suppose you could use mediatomb with vdrnfofs to share your recordings. Pim From denis.loh at googlemail.com Fri Feb 10 20:04:45 2012 From: denis.loh at googlemail.com (Denis Loh) Date: Fri, 10 Feb 2012 20:04:45 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <4F354ED4.9050005@zandbergen.org> References: <20120209153331.GA18485@boole.suse.de> <4F354ED4.9050005@zandbergen.org> Message-ID: <4F356A4D.2040200@googlemail.com> Am 10.02.2012 18:07, schrieb Pim Zandbergen: > I suppose you could use mediatomb with vdrnfofs to share your recordings. > > Pim > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Ack! These combination should work as there are many users who reported a working setup. Correct me, if I'm wrong, but I thought that hbbTV is sent by the broadcasters themselves. Maybe someone has spent some time to work on a smartTV (e.g. for samsung) app, which can be installed and used by the user. Denis From luca at ventoso.org Fri Feb 10 21:43:08 2012 From: luca at ventoso.org (Luca Olivetti) Date: Fri, 10 Feb 2012 21:43:08 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <4F354ED4.9050005@zandbergen.org> References: <20120209153331.GA18485@boole.suse.de> <4F354ED4.9050005@zandbergen.org> Message-ID: <4F35815C.20607@ventoso.org> Al 10/02/12 18:07, En/na Pim Zandbergen ha escrit: > I suppose you could use mediatomb with vdrnfofs to share your recordings. Or hack the TV to simply nfs mount the directory with the recordings Bye -- Luca From mijutu at ellipsis.fi Sat Feb 11 18:19:47 2012 From: mijutu at ellipsis.fi (Mikko Tuumanen) Date: Sat, 11 Feb 2012 19:19:47 +0200 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <4F34224C.1030601@googlemail.com> References: <20120209153331.GA18485@boole.suse.de> <4F34224C.1030601@googlemail.com> Message-ID: <201202111919.47979.mijutu@ellipsis.fi> > i am still working on it. I have a feature reuqest for the vdr dlna server. I bought a tv and fast forwarding through the dlna is terribly slow (tried minidlna) and there are no "skip one minute" or "goto hh:mm" etc. functionality at all. Skipping minute forward, backward and "goto hh:mm" like vdr does could be implemented in the dlna server. Then the user could send these commands to te server which would do the skipping (its easy when we have the vdr index files). Of course controlling can't be done with the dlna client remote control and doing this with multiple dlna clients is not so simple (need separate remote control for each client, etc). Another idea: Vdr in a cheap computer that is not able to decode and deinterlace the video properly. Connect a dlna cabable tv to the dvi output of the computer and the tv to the same network as the computer. Then it will be possible to create a cDlnaDevice that will draw osd on an X11 window and send all video to the dlna client. If the tv is remote controllable through serial port or ethernet then switching from video to osd and back could be automatic. Of course it wouldn't be osd any more, but menus could be used anyway. Unfortunately subtitles wouldn't work at all unless the tv supported them. From tlenz at vorgon.com Sat Feb 11 23:08:41 2012 From: tlenz at vorgon.com (Timothy D. Lenz) Date: Sat, 11 Feb 2012 15:08:41 -0700 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <4F35815C.20607@ventoso.org> References: <20120209153331.GA18485@boole.suse.de> <4F354ED4.9050005@zandbergen.org> <4F35815C.20607@ventoso.org> Message-ID: <4F36E6E9.6080506@vorgon.com> I'm interested in this also, but we have 2 Sony Bravias. Hacking the Tv not an option. I do know that on ours, for youtube, you can do searches and stuff using an on screen alphabet that follows the letter to number grouping you see on phones. So it does have a way to enter stuff. On 2/10/2012 1:43 PM, Luca Olivetti wrote: > Al 10/02/12 18:07, En/na Pim Zandbergen ha escrit: >> I suppose you could use mediatomb with vdrnfofs to share your recordings. > > Or hack the TV to simply nfs mount the directory with the recordings > > > Bye From listaccount at e-tobi.net Sun Feb 12 19:53:07 2012 From: listaccount at e-tobi.net (Tobi) Date: Sun, 12 Feb 2012 19:53:07 +0100 Subject: [vdr] [ANNOUNCE] vdr-osdpip 0.1.1 Message-ID: <4F380A93.4020807@e-tobi.net> Im catching up with some of the bug reports / patches that were lying around for months (Thanks guys). The changes: - Fixed compile error with newer ffmpeg versions >= svn 20100426 (closes #345) - Replaced deprected ffmpeg calls (Patch provided by mnival) (closes #690) - Updated french translation (Patch provided by mnival) (closes #691) - Avoid segfault at stop replay with keystroke '0' (Patch provided by Andreas Brachold) (closes #592) As always: Any help is welcome! Development site: http://projects.vdr-developer.org/projects/plg-osdpip Downloads: http://projects.vdr-developer.org/projects/plg-osdpip/files Git-Web: http://projects.vdr-developer.org/git/vdr-plugin-osdpip.git/ Anonymous Git-access : git://projects.vdr-developer.org/vdr-plugin-osdpip.git This is intended to be a community maintained project! Don't expect me to fix your problems, I'm merely maintaining the project! Please report any bugs, ideas or feature requests to the project site (no registration required for this!). If you want to contribute patches, new features or whatever, post an issue or patch to the projects issue tracker or request to join the project. I would happily add everyone as a project member, who would like to contribute to the project! Tobias From lucianm at users.sourceforge.net Sun Feb 12 23:11:17 2012 From: lucianm at users.sourceforge.net (Lucian Muresan) Date: Sun, 12 Feb 2012 23:11:17 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <201201271304.12550@orion.escape-edv.de> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> Message-ID: <4F383905.2080503@users.sourceforge.net> On 01/27/2012 01:04 PM, Oliver Endriss wrote: > On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >> On 25.01.2012 14:11, Oliver Endriss wrote: >>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>> On 17.01.2012 14:26, sundararaj reel wrote: >>>>> Hi, >>>>> >>>>> I am attaching a patch for vdr 1.7.23 for the problem described here: >>>>> http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199 >>>>> >>>>> There appears to be a problem in listing recordings due to a bug fix >>>>> in vdr 1.7.23. "Fixed handling symbolic links in >>>>> cRecordings::ScanVideoDir()" >>>>> >>>>> The attached patch just disables the translation of symbolic links to >>>>> "real" paths. So that all recordings appear to be under the same >>>>> (recordings) directory tree, as it was earlier. >>>>> >>>>> Please reply with your results. >>>> >>>> Can somebody who has actually this use case please confirm >>>> whether this patch fixes the problem? >>> >>> Confirmed. >>> >>> Without this patch, symbolic links are not displayed >>> correctly on my machine. >>> >>> Oliver >> >> Thanks. >> >> I believe the second call to stat() is now superfluous. >> Can you please confirm that the following patch still works >> as expected? >> >> --- recording.c 2012/01/25 09:32:39 2.45 >> +++ recording.c 2012/01/26 10:02:29 >> @@ -1120,11 +1120,6 @@ >> continue; >> }sundararaj reel >> Link = 1; >> - buffer = ReadLink(buffer); >> - if (!*buffer) >> - continue; >> - if (stat(buffer,&st) != 0) >> - continue; >> } >> if (S_ISDIR(st.st_mode)) { >> if (endswith(buffer, deleted ? DELEXT : RECEXT)) { > > Yes, it does not make any difference here. Well, with this patch, symbolic links are not displayed at all on my VDR machine, whereas with sundararaj reel's fix they are displayed correctly. Cheers, Lucian From listaccount at e-tobi.net Sun Feb 12 23:42:34 2012 From: listaccount at e-tobi.net (Tobi) Date: Sun, 12 Feb 2012 23:42:34 +0100 Subject: [vdr] projects.vdr-developer.org Message-ID: <4F38405A.7090905@e-tobi.net> Hello folks! There were a lot of gmail/hotmail accounts that left some SPAM comments. I've deleted them all, so if I accidentally deleted a valid user, please let me know and I'll restore your account! Besides this: You can always report SPAM to me, and I'll try my best to kick it out of this project site. If this gets annoying in the long term, I will probably enable manual activation of new accounts (maybe just for specific domains) or build a CAPTCHA into the automatic account verification process. Tobias From Klaus.Schmidinger at tvdr.de Mon Feb 13 10:43:51 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Mon, 13 Feb 2012 10:43:51 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <4F383905.2080503@users.sourceforge.net> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> Message-ID: <4F38DB57.1000508@tvdr.de> > On 01/27/2012 01:04 PM, Oliver Endriss wrote: >> On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >>> On 25.01.2012 14:11, Oliver Endriss wrote: >>>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>>> On 17.01.2012 14:26, sundararaj reel wrote: >>>>>> Hi, >>>>>> >>>>>> I am attaching a patch for vdr 1.7.23 for the problem described here: >>>>>> http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199 >>>>>> >>>>>> There appears to be a problem in listing recordings due to a bug fix >>>>>> in vdr 1.7.23. "Fixed handling symbolic links in >>>>>> cRecordings::ScanVideoDir()" >>>>>> >>>>>> The attached patch just disables the translation of symbolic links to >>>>>> "real" paths. So that all recordings appear to be under the same >>>>>> (recordings) directory tree, as it was earlier. >>>>>> >>>>>> Please reply with your results. >>>>> >>>>> Can somebody who has actually this use case please confirm >>>>> whether this patch fixes the problem? >>>> >>>> Confirmed. >>>> >>>> Without this patch, symbolic links are not displayed >>>> correctly on my machine. >>>> >>>> Oliver >>> >>> Thanks. >>> >>> I believe the second call to stat() is now superfluous. >>> Can you please confirm that the following patch still works >>> as expected? >>> >>> --- recording.c 2012/01/25 09:32:39 2.45 >>> +++ recording.c 2012/01/26 10:02:29 >>> @@ -1120,11 +1120,6 @@ >>> continue; >>> }sundararaj reel How did this "sundararaj reel" get in here? >>> Link = 1; >>> - buffer = ReadLink(buffer); >>> - if (!*buffer) >>> - continue; >>> - if (stat(buffer,&st) != 0) >>> - continue; >>> } >>> if (S_ISDIR(st.st_mode)) { >>> if (endswith(buffer, deleted ? DELEXT : RECEXT)) { >> >> Yes, it does not make any difference here. > > Well, with this patch, symbolic links are not displayed at all on my VDR machine, whereas with sundararaj reel's fix they are displayed correctly. So what you're saying it that this... ---------------------------------------------------------------------------------------------- --- a/recording.c +++ b/recording.c @@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char *DirName, bool Foreground, int LinkLev continue; } Link = 1; +#if 0 + // do not resolve the symbolic links in paths to real path + // thereby keeping all the recordings under one directory buffer = ReadLink(buffer); if (!*buffer) continue; +#endif if (stat(buffer, &st) != 0) continue; } ---------------------------------------------------------------------------------------------- ...works, while this... ---------------------------------------------------------------------------------------------- --- recording.c 2012/01/25 09:32:39 2.45 +++ recording.c 2012/01/26 10:02:29 @@ -1120,11 +1120,6 @@ continue; } Link = 1; - buffer = ReadLink(buffer); - if (!*buffer) - continue; - if (stat(buffer, &st) != 0) - continue; } if (S_ISDIR(st.st_mode)) { if (endswith(buffer, deleted ? DELEXT : RECEXT)) { ---------------------------------------------------------------------------------------------- ...doesn't? I find that hard to believe, because the only difference here is that the second version removes the stat() call, which is superfluous if 'buffer' is no longer modified. Klaus From lucianm at users.sourceforge.net Mon Feb 13 11:44:46 2012 From: lucianm at users.sourceforge.net (Lucian Muresan) Date: Mon, 13 Feb 2012 11:44:46 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <4F38DB57.1000508@tvdr.de> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> <4F38DB57.1000508@tvdr.de> Message-ID: <4F38E99E.6010900@users.sourceforge.net> On 13.02.2012 10:43, Klaus Schmidinger wrote: >> On 01/27/2012 01:04 PM, Oliver Endriss wrote: >>> On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >>>> On 25.01.2012 14:11, Oliver Endriss wrote: >>>>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>>>> On 17.01.2012 14:26, sundararaj reel wrote: [...] >> Well, with this patch, symbolic links are not displayed at all on my >> VDR machine, whereas with sundararaj reel's fix they are displayed >> correctly. > > So what you're saying it that this... > > ---------------------------------------------------------------------------------------------- > > --- a/recording.c > +++ b/recording.c > @@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char > *DirName, bool Foreground, int LinkLev > continue; > } > Link = 1; > +#if 0 > + // do not resolve the symbolic links in paths to real path > + // thereby keeping all the recordings under one directory > buffer = ReadLink(buffer); > if (!*buffer) > continue; > +#endif > if (stat(buffer, &st) != 0) > continue; > } > ---------------------------------------------------------------------------------------------- > > > ...works, while this... > > ---------------------------------------------------------------------------------------------- > > --- recording.c 2012/01/25 09:32:39 2.45 > +++ recording.c 2012/01/26 10:02:29 > @@ -1120,11 +1120,6 @@ > continue; > } > Link = 1; > - buffer = ReadLink(buffer); > - if (!*buffer) > - continue; > - if (stat(buffer, &st) != 0) > - continue; > } > if (S_ISDIR(st.st_mode)) { > if (endswith(buffer, deleted ? DELEXT : RECEXT)) { > ---------------------------------------------------------------------------------------------- > > > ...doesn't? > > I find that hard to believe, because the only difference here is that > the second version removes the stat() call, which is superfluous if > 'buffer' is no longer modified. Haven't really looked at the code, until now, and I also do not exactly know what the call to stat does and also didn't try to understand the whole picture now, but your patch does not simply remove just the call to stat, but also a *continue* statement from the *while* loop, this could have strong implications, so just please consider analyzing the issue with respect to that. Regards, Lucian From Klaus.Schmidinger at tvdr.de Mon Feb 13 12:00:22 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Mon, 13 Feb 2012 12:00:22 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <4F38E99E.6010900@users.sourceforge.net> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> <4F38DB57.1000508@tvdr.de> <4F38E99E.6010900@users.sourceforge.net> Message-ID: <4F38ED46.5020605@tvdr.de> On 13.02.2012 11:44, Lucian Muresan wrote: > On 13.02.2012 10:43, Klaus Schmidinger wrote: >>> On 01/27/2012 01:04 PM, Oliver Endriss wrote: >>>> On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >>>>> On 25.01.2012 14:11, Oliver Endriss wrote: >>>>>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>>>>> On 17.01.2012 14:26, sundararaj reel wrote: > > [...] > >>> Well, with this patch, symbolic links are not displayed at all on my >>> VDR machine, whereas with sundararaj reel's fix they are displayed >>> correctly. >> >> So what you're saying it that this... >> >> ---------------------------------------------------------------------------------------------- >> >> --- a/recording.c >> +++ b/recording.c >> @@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char >> *DirName, bool Foreground, int LinkLev >> continue; >> } >> Link = 1; >> +#if 0 >> + // do not resolve the symbolic links in paths to real path >> + // thereby keeping all the recordings under one directory >> buffer = ReadLink(buffer); >> if (!*buffer) >> continue; >> +#endif >> if (stat(buffer, &st) != 0) >> continue; >> } >> ---------------------------------------------------------------------------------------------- >> >> >> ...works, while this... >> >> ---------------------------------------------------------------------------------------------- >> >> --- recording.c 2012/01/25 09:32:39 2.45 >> +++ recording.c 2012/01/26 10:02:29 >> @@ -1120,11 +1120,6 @@ >> continue; >> } >> Link = 1; >> - buffer = ReadLink(buffer); >> - if (!*buffer) >> - continue; >> - if (stat(buffer, &st) != 0) >> - continue; >> } >> if (S_ISDIR(st.st_mode)) { >> if (endswith(buffer, deleted ? DELEXT : RECEXT)) { >> ---------------------------------------------------------------------------------------------- >> >> >> ...doesn't? >> >> I find that hard to believe, because the only difference here is that >> the second version removes the stat() call, which is superfluous if >> 'buffer' is no longer modified. > > Haven't really looked at the code, until now, and I also do not exactly know what the call to stat does and also didn't try to understand the whole picture now, but your patch does not simply remove just the call to stat, but also a *continue* statement from the *while* loop, this could have strong > implications, so just please consider analyzing the issue with respect to that. The original code was ---------------------------------------------------------------------------------------------- if (stat(buffer, &st) == 0) { int Link = 0; if (S_ISLNK(st.st_mode)) { if (LinkLevel > MAX_LINK_LEVEL) { isyslog("max link level exceeded - not scanning %s", *buffer); continue; } Link = 1; buffer = ReadLink(buffer); if (!*buffer) continue; if (stat(buffer, &st) != 0) continue; } ... } ---------------------------------------------------------------------------------------------- After Sundararaj's patch it looked like this (just leaving out the lines that his '#if 0' disabled): ---------------------------------------------------------------------------------------------- if (stat(buffer, &st) == 0) { int Link = 0; if (S_ISLNK(st.st_mode)) { if (LinkLevel > MAX_LINK_LEVEL) { isyslog("max link level exceeded - not scanning %s", *buffer); continue; } if (stat(buffer, &st) != 0) continue; } ... } ---------------------------------------------------------------------------------------------- Reducing this to the stat() calls results in ---------------------------------------------------------------------------------------------- if (stat(buffer, &st) == 0) { ... if (stat(buffer, &st) != 0) continue; } ... } ---------------------------------------------------------------------------------------------- As you can see, 'buffer' is no longer modified between the two calls, so they will both return the same value. The code sequence is only entered if the first stat() call returns 0, so the second call will also return 0, and thus the 'continue' statement will never be executed. Klaus From lucianm at users.sourceforge.net Mon Feb 13 12:27:14 2012 From: lucianm at users.sourceforge.net (Lucian Muresan) Date: Mon, 13 Feb 2012 12:27:14 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <4F38ED46.5020605@tvdr.de> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> <4F38DB57.1000508@tvdr.de> <4F38E99E.6010900@users.sourceforge.net> <4F38ED46.5020605@tvdr.de> Message-ID: <4F38F392.6050907@users.sourceforge.net> On 13.02.2012 12:00, Klaus Schmidinger wrote: > On 13.02.2012 11:44, Lucian Muresan wrote: >> On 13.02.2012 10:43, Klaus Schmidinger wrote: >>>> On 01/27/2012 01:04 PM, Oliver Endriss wrote: >>>>> On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >>>>>> On 25.01.2012 14:11, Oliver Endriss wrote: >>>>>>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>>>>>> On 17.01.2012 14:26, sundararaj reel wrote: >> >> [...] >> >>>> Well, with this patch, symbolic links are not displayed at all on my >>>> VDR machine, whereas with sundararaj reel's fix they are displayed >>>> correctly. >>> >>> So what you're saying it that this... >>> >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> --- a/recording.c >>> +++ b/recording.c >>> @@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char >>> *DirName, bool Foreground, int LinkLev >>> continue; >>> } >>> Link = 1; >>> +#if 0 >>> + // do not resolve the symbolic links in paths to real path >>> + // thereby keeping all the recordings under one directory >>> buffer = ReadLink(buffer); >>> if (!*buffer) >>> continue; >>> +#endif >>> if (stat(buffer, &st) != 0) >>> continue; >>> } >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> >>> ...works, while this... >>> >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> --- recording.c 2012/01/25 09:32:39 2.45 >>> +++ recording.c 2012/01/26 10:02:29 >>> @@ -1120,11 +1120,6 @@ >>> continue; >>> } >>> Link = 1; >>> - buffer = ReadLink(buffer); >>> - if (!*buffer) >>> - continue; >>> - if (stat(buffer, &st) != 0) >>> - continue; >>> } >>> if (S_ISDIR(st.st_mode)) { >>> if (endswith(buffer, deleted ? DELEXT : RECEXT)) { >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> >>> ...doesn't? >>> >>> I find that hard to believe, because the only difference here is that >>> the second version removes the stat() call, which is superfluous if >>> 'buffer' is no longer modified. >> >> Haven't really looked at the code, until now, and I also do not >> exactly know what the call to stat does and also didn't try to >> understand the whole picture now, but your patch does not simply >> remove just the call to stat, but also a *continue* statement from the >> *while* loop, this could have strong >> implications, so just please consider analyzing the issue with respect >> to that. > > The original code was > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > Link = 1; > buffer = ReadLink(buffer); > if (!*buffer) > continue; > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > After Sundararaj's patch it looked like this (just leaving out the lines > that his '#if 0' disabled): > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > Reducing this to the stat() calls results in > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > ... > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > As you can see, 'buffer' is no longer modified between the two calls, so > they > will both return the same value. The code sequence is only entered if > the first > stat() call returns 0, so the second call will also return 0, and thus the > 'continue' statement will never be executed. Now I looked a bit closer, and noticed that the "first" call to stat is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if you remove the call to the second one, could it be that you're not really cutting redundancy, maybe it actually makes a difference? Lucian From lucianm at users.sourceforge.net Mon Feb 13 12:27:14 2012 From: lucianm at users.sourceforge.net (Lucian Muresan) Date: Mon, 13 Feb 2012 12:27:14 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <4F38ED46.5020605@tvdr.de> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> <4F38DB57.1000508@tvdr.de> <4F38E99E.6010900@users.sourceforge.net> <4F38ED46.5020605@tvdr.de> Message-ID: <4F38F392.6050907@users.sourceforge.net> On 13.02.2012 12:00, Klaus Schmidinger wrote: > On 13.02.2012 11:44, Lucian Muresan wrote: >> On 13.02.2012 10:43, Klaus Schmidinger wrote: >>>> On 01/27/2012 01:04 PM, Oliver Endriss wrote: >>>>> On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >>>>>> On 25.01.2012 14:11, Oliver Endriss wrote: >>>>>>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>>>>>> On 17.01.2012 14:26, sundararaj reel wrote: >> >> [...] >> >>>> Well, with this patch, symbolic links are not displayed at all on my >>>> VDR machine, whereas with sundararaj reel's fix they are displayed >>>> correctly. >>> >>> So what you're saying it that this... >>> >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> --- a/recording.c >>> +++ b/recording.c >>> @@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char >>> *DirName, bool Foreground, int LinkLev >>> continue; >>> } >>> Link = 1; >>> +#if 0 >>> + // do not resolve the symbolic links in paths to real path >>> + // thereby keeping all the recordings under one directory >>> buffer = ReadLink(buffer); >>> if (!*buffer) >>> continue; >>> +#endif >>> if (stat(buffer, &st) != 0) >>> continue; >>> } >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> >>> ...works, while this... >>> >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> --- recording.c 2012/01/25 09:32:39 2.45 >>> +++ recording.c 2012/01/26 10:02:29 >>> @@ -1120,11 +1120,6 @@ >>> continue; >>> } >>> Link = 1; >>> - buffer = ReadLink(buffer); >>> - if (!*buffer) >>> - continue; >>> - if (stat(buffer, &st) != 0) >>> - continue; >>> } >>> if (S_ISDIR(st.st_mode)) { >>> if (endswith(buffer, deleted ? DELEXT : RECEXT)) { >>> ---------------------------------------------------------------------------------------------- >>> >>> >>> >>> ...doesn't? >>> >>> I find that hard to believe, because the only difference here is that >>> the second version removes the stat() call, which is superfluous if >>> 'buffer' is no longer modified. >> >> Haven't really looked at the code, until now, and I also do not >> exactly know what the call to stat does and also didn't try to >> understand the whole picture now, but your patch does not simply >> remove just the call to stat, but also a *continue* statement from the >> *while* loop, this could have strong >> implications, so just please consider analyzing the issue with respect >> to that. > > The original code was > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > Link = 1; > buffer = ReadLink(buffer); > if (!*buffer) > continue; > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > After Sundararaj's patch it looked like this (just leaving out the lines > that his '#if 0' disabled): > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > Reducing this to the stat() calls results in > > ---------------------------------------------------------------------------------------------- > > if (stat(buffer, &st) == 0) { > ... > if (stat(buffer, &st) != 0) > continue; > } > ... > } > ---------------------------------------------------------------------------------------------- > > > As you can see, 'buffer' is no longer modified between the two calls, so > they > will both return the same value. The code sequence is only entered if > the first > stat() call returns 0, so the second call will also return 0, and thus the > 'continue' statement will never be executed. Now I looked a bit closer, and noticed that the "first" call to stat is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if you remove the call to the second one, could it be that you're not really cutting redundancy, maybe it actually makes a difference? Lucian From Klaus.Schmidinger at tvdr.de Mon Feb 13 12:54:05 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Mon, 13 Feb 2012 12:54:05 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <4F38F392.6050907@users.sourceforge.net> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> <4F38DB57.1000508@tvdr.de> <4F38E99E.6010900@users.sourceforge.net> <4F38ED46.5020605@tvdr.de> <4F38F392.6050907@users.sourceforge.net> Message-ID: <4F38F9DD.7010009@tvdr.de> On 13.02.2012 12:27, Lucian Muresan wrote: > On 13.02.2012 12:00, Klaus Schmidinger wrote: >> On 13.02.2012 11:44, Lucian Muresan wrote: >>> On 13.02.2012 10:43, Klaus Schmidinger wrote: >>>>> On 01/27/2012 01:04 PM, Oliver Endriss wrote: >>>>>> On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote: >>>>>>> On 25.01.2012 14:11, Oliver Endriss wrote: >>>>>>>> On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote: >>>>>>>>> On 17.01.2012 14:26, sundararaj reel wrote: >>> >>> [...] >>> >>>>> Well, with this patch, symbolic links are not displayed at all on my >>>>> VDR machine, whereas with sundararaj reel's fix they are displayed >>>>> correctly. >>>> >>>> So what you're saying it that this... >>>> >>>> ---------------------------------------------------------------------------------------------- >>>> >>>> >>>> --- a/recording.c >>>> +++ b/recording.c >>>> @@ -1120,9 +1120,13 @@ void cRecordings::ScanVideoDir(const char >>>> *DirName, bool Foreground, int LinkLev >>>> continue; >>>> } >>>> Link = 1; >>>> +#if 0 >>>> + // do not resolve the symbolic links in paths to real path >>>> + // thereby keeping all the recordings under one directory >>>> buffer = ReadLink(buffer); >>>> if (!*buffer) >>>> continue; >>>> +#endif >>>> if (stat(buffer, &st) != 0) >>>> continue; >>>> } >>>> ---------------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> ...works, while this... >>>> >>>> ---------------------------------------------------------------------------------------------- >>>> >>>> >>>> --- recording.c 2012/01/25 09:32:39 2.45 >>>> +++ recording.c 2012/01/26 10:02:29 >>>> @@ -1120,11 +1120,6 @@ >>>> continue; >>>> } >>>> Link = 1; >>>> - buffer = ReadLink(buffer); >>>> - if (!*buffer) >>>> - continue; >>>> - if (stat(buffer, &st) != 0) >>>> - continue; >>>> } >>>> if (S_ISDIR(st.st_mode)) { >>>> if (endswith(buffer, deleted ? DELEXT : RECEXT)) { >>>> ---------------------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> ...doesn't? >>>> >>>> I find that hard to believe, because the only difference here is that >>>> the second version removes the stat() call, which is superfluous if >>>> 'buffer' is no longer modified. >>> >>> Haven't really looked at the code, until now, and I also do not >>> exactly know what the call to stat does and also didn't try to >>> understand the whole picture now, but your patch does not simply >>> remove just the call to stat, but also a *continue* statement from the >>> *while* loop, this could have strong >>> implications, so just please consider analyzing the issue with respect >>> to that. >> >> The original code was >> >> ---------------------------------------------------------------------------------------------- >> >> if (stat(buffer, &st) == 0) { >> int Link = 0; >> if (S_ISLNK(st.st_mode)) { >> if (LinkLevel > MAX_LINK_LEVEL) { >> isyslog("max link level exceeded - not scanning %s", *buffer); >> continue; >> } >> Link = 1; >> buffer = ReadLink(buffer); >> if (!*buffer) >> continue; >> if (stat(buffer, &st) != 0) >> continue; >> } >> ... >> } >> ---------------------------------------------------------------------------------------------- >> >> >> After Sundararaj's patch it looked like this (just leaving out the lines >> that his '#if 0' disabled): >> >> ---------------------------------------------------------------------------------------------- >> >> if (stat(buffer, &st) == 0) { >> int Link = 0; >> if (S_ISLNK(st.st_mode)) { >> if (LinkLevel > MAX_LINK_LEVEL) { >> isyslog("max link level exceeded - not scanning %s", *buffer); >> continue; >> } >> if (stat(buffer, &st) != 0) >> continue; >> } >> ... >> } >> ---------------------------------------------------------------------------------------------- >> >> >> Reducing this to the stat() calls results in >> >> ---------------------------------------------------------------------------------------------- >> >> if (stat(buffer, &st) == 0) { >> ... >> if (stat(buffer, &st) != 0) >> continue; >> } >> ... >> } >> ---------------------------------------------------------------------------------------------- >> >> >> As you can see, 'buffer' is no longer modified between the two calls, so >> they >> will both return the same value. The code sequence is only entered if >> the first >> stat() call returns 0, so the second call will also return 0, and thus the >> 'continue' statement will never be executed. > > Now I looked a bit closer, and noticed that the "first" call to stat is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if you remove the call to the second one, could it be that you're not really cutting redundancy, maybe it actually makes a difference? Now you got me ;-) I had switched back to 'stat()' instead of 'lstat()' and forgotten to reintroduce the 'lstat()'. Therefore I saw two identical calls to stat(). With the first call being lstat(), the second call to stat() is of course necessary for the following S_ISDIR() check. Sorry for the confusion, and thanks for clarifying this. So now this whole code sequence looks like this: ---------------------------------------------------------------------------------------------- if (lstat(buffer, &st) == 0) { int Link = 0; if (S_ISLNK(st.st_mode)) { if (LinkLevel > MAX_LINK_LEVEL) { isyslog("max link level exceeded - not scanning %s", *buffer); continue; } Link = 1; if (stat(buffer, &st) != 0) continue; } ---------------------------------------------------------------------------------------------- Klaus From lucianm at users.sourceforge.net Mon Feb 13 13:52:25 2012 From: lucianm at users.sourceforge.net (Lucian Muresan) Date: Mon, 13 Feb 2012 13:52:25 +0100 Subject: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier In-Reply-To: <4F38F9DD.7010009@tvdr.de> References: <201201251411.48859@orion.escape-edv.de> <4F2125D6.2020505@tvdr.de> <201201271304.12550@orion.escape-edv.de> <4F383905.2080503@users.sourceforge.net> <4F38DB57.1000508@tvdr.de> <4F38E99E.6010900@users.sourceforge.net> <4F38ED46.5020605@tvdr.de> <4F38F392.6050907@users.sourceforge.net> <4F38F9DD.7010009@tvdr.de> Message-ID: <4F390789.2050508@users.sourceforge.net> On 13.02.2012 12:54, Klaus Schmidinger wrote: > On 13.02.2012 12:27, Lucian Muresan wrote: >> On 13.02.2012 12:00, Klaus Schmidinger wrote: [...] >> Now I looked a bit closer, and noticed that the "first" call to stat >> is actually not to *stat*, but to *lstat* in vanilla vdr-1.7.23, so if >> you remove the call to the second one, could it be that you're not >> really cutting redundancy, maybe it actually makes a difference? > > Now you got me ;-) > I had switched back to 'stat()' instead of 'lstat()' and forgotten to > reintroduce > the 'lstat()'. Therefore I saw two identical calls to stat(). > With the first call being lstat(), the second call to stat() is of > course necessary > for the following S_ISDIR() check. > > Sorry for the confusion, and thanks for clarifying this. > So now this whole code sequence looks like this: > > ---------------------------------------------------------------------------------------------- > > if (lstat(buffer, &st) == 0) { > int Link = 0; > if (S_ISLNK(st.st_mode)) { > if (LinkLevel > MAX_LINK_LEVEL) { > isyslog("max link level exceeded - not scanning %s", *buffer); > continue; > } > Link = 1; > if (stat(buffer, &st) != 0) > continue; > } No problem at all, I'm glad it's now sorted out for the next developer version. Lucian From h at realh.co.uk Mon Feb 13 20:59:33 2012 From: h at realh.co.uk (Tony Houghton) Date: Mon, 13 Feb 2012 19:59:33 +0000 Subject: [vdr] xineliboutput and xine-ui not fitting together In-Reply-To: <4F2C4CEB.1050404@e-tobi.net> References: <4F2BFBCD.3030907@mannitec.de> <4F2C4CEB.1050404@e-tobi.net> Message-ID: <20120213195933.10203951@tiber> On Fri, 03 Feb 2012 22:08:59 +0100 Tobi wrote: > On 03.02.2012 16:22, Manfred Schmidt-Voigt wrote: > > > 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? > > I'll upload a new package tonight. Thanks for your work on these packages. VDPAU support at last! I've been so reluctant to compile all this stuff myself, maintaining it on at least 3 PCs and making sure it doesn't clash with other ffmpeg-based packages etc (or worse, switch to mythtv) that I hadn't been enjoying HD until now. From joachim.wilke at gmail.com Tue Feb 14 12:47:30 2012 From: joachim.wilke at gmail.com (Joachim Wilke) Date: Tue, 14 Feb 2012 12:47:30 +0100 Subject: [vdr] Missing consts in cDevice Message-ID: I suggest to add the following consts: ----------------------------------- device.h ----------------------------------- index e2ff812..cba70e5 100644 @@ -495,11 +495,11 @@ public: ///< is more than one audio track. int NumSubtitleTracks(void) const; ///< Returns the number of subtitle tracks that are currently available. - eTrackType GetCurrentAudioTrack(void) { return currentAudioTrack; } + eTrackType GetCurrentAudioTrack(void) const { return currentAudioTrack; } bool SetCurrentAudioTrack(eTrackType Type); ///< Sets the current audio track to the given Type. ///< \return Returns true if Type is a valid audio track, false otherwise. - eTrackType GetCurrentSubtitleTrack(void) { return currentSubtitleTrack; } + eTrackType GetCurrentSubtitleTrack(void) const { return currentSubtitleTrack; } bool SetCurrentSubtitleTrack(eTrackType Type, bool Manual = false); ///< Sets the current subtitle track to the given Type. ///< IF Manual is true, no automatic preferred subtitle language selection This simplifies usage of these getters in cStatus::ChannelSwitch and similar methods. -- Best Regards, Joachim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Klaus.Schmidinger at tvdr.de Wed Feb 15 16:59:06 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 15 Feb 2012 16:59:06 +0100 Subject: [vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-3 Message-ID: <4F3BD64A.7060009@tvdr.de> VDR maintenance patch 1.6.0-3 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.6.0-3.diff This is a 'diff' against version 1.6.0-2 (which is the official version 1.6.0, patched with ftp://ftp.tvdr.de/vdr/Developer/vdr-1.6.0-1.diff and ftp://ftp.tvdr.de/vdr/Developer/vdr-1.6.0-2.diff). The sole purpose of this patch is to make version 1.6 work with V4L2 and newer compilers. This version is binary compatible to the previous one, so plugins don't need to be recompiled. The changes since version 1.6.0-2: - Changed cDvbDevice::GrabImage() to use V4L2 (backport from version 1.7.3, thanks to Ralf Schueler). - Added some missing 'const' keywords to avoid compilation errors with gcc 4.4 (backport from version 1.7.8, thanks to Ralf Schueler). - Modified cSVDRP::CmdGRAB() to avoid writing into const data (backport from version 1.7.8, thanks to Ralf Schueler). - Fixed cRecordings::DelByName() to avoid compilation errors with gcc 4.4 (backport from version 1.7.9, thanks to Ralf Schueler). Have fun! Klaus From ml at websitec.de Wed Feb 15 22:48:45 2012 From: ml at websitec.de (Joerg Bornkessel) Date: Wed, 15 Feb 2012 22:48:45 +0100 Subject: [vdr] [ANNOUNCE] VDR maintenance patch 1.6.0-3 In-Reply-To: <4F3BD64A.7060009@tvdr.de> References: <4F3BD64A.7060009@tvdr.de> Message-ID: <583862906.20120215224845@websitec.de> > VDR maintenance patch 1.6.0-3 is now available at Thanks Klaus, finaly, we still waiting for the next Major Release! ;) -- Regards Gentoo Developer Joerg Bornkessel From tsuikki at zuik.org Thu Feb 16 11:55:39 2012 From: tsuikki at zuik.org (Teemu Suikki) Date: Thu, 16 Feb 2012 12:55:39 +0200 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: <4F36E6E9.6080506@vorgon.com> References: <20120209153331.GA18485@boole.suse.de> <4F354ED4.9050005@zandbergen.org> <4F35815C.20607@ventoso.org> <4F36E6E9.6080506@vorgon.com> Message-ID: Howdy! There is an installation instructions for vdr-plugin-upnp here: http://www.vdr-wiki.de/wiki/index.php/Upnp-plugin I also installed libupnp-1.6.6 with this dlna patch: http://svn.assembla.com/svn/VDR-M7x0/trunk/toolchain/patches/libupnp/1.6.6/dlna/100-CustomHeader.0.0.3.patch I'm using the plugin with VDR 1.7.15 and Playstation3. PS3 detects the VDR correctly, but there are no recordings or live channels available, it's just all empty. When looking at the log file (with -vvvvv), i see this: UPnP server message: Browse requested by 192.168.0.201. UPnP server message: ===== Browsing ===== UPnP server message: ID: 0 UPnP server message: Browse metadata UPnP server message: Filter: @id,upnp:class,res,res at protocolInfo,res at av:authenticationUri,res at size,dc:title,upnp:albumArtURI,res at dlna:ifoFileURI,res at protection,res at bitrate,res at duration,res at sampleFrequency,res at bitsPerSample,res at nrAudioChannels,res at resolution,res at colorDepth,dc:date,av:dateTime,upnp:artist,upnp:album,upnp:genre,dc:contributer,upnp:storageFree,upnp:storageUsed,upnp:originalTrackNumber,dc:publisher,dc:language,dc:region,dc:description,upnp:toc, at childCount,upnp:albumArtURI at dlna:profileID,res at dlna:cleartextSize UPnP server message: Offset: 0 UPnP server message: Count: 1 UPnP server message: Sort: (null) UPnP server message: Pushing property UPnP server message: Pushing property UPnP server message: Pushing property UPnP server message: Pushing property UPnP server message: Pushing property UPnP server error:Parsing filter failed -- Teemu 2012/2/12 Timothy D. Lenz : > I'm interested in this also, but we have 2 Sony Bravias. Hacking the Tv not > an option. ?I do know that on ours, for youtube, you can do searches and > stuff using an on screen alphabet that follows the letter to number grouping > you see on phones. So it does have a way to enter stuff. > > > On 2/10/2012 1:43 PM, Luca Olivetti wrote: >> >> Al 10/02/12 18:07, En/na Pim Zandbergen ha escrit: >>> >>> I suppose you could use mediatomb with vdrnfofs to share your recordings. >> >> >> Or hack the TV to simply nfs mount the directory with the recordings >> >> >> Bye > > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- Teemu Suikki http://www.z-power.fi/ From denis.loh at googlemail.com Thu Feb 16 13:26:26 2012 From: denis.loh at googlemail.com (Denis Loh) Date: Thu, 16 Feb 2012 13:26:26 +0100 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: References: <20120209153331.GA18485@boole.suse.de> <4F354ED4.9050005@zandbergen.org> <4F35815C.20607@ventoso.org> <4F36E6E9.6080506@vorgon.com> Message-ID: Actually, I think some of the properties are not well formatted. UPnP defines a strict pattern, which I implemented (hopefully) properly. However, some devices may ignore this pattern. I will try to find out, which of these parameters is the offending one. 2012/2/16 Teemu Suikki : > Howdy! > > There is an installation instructions for vdr-plugin-upnp here: > http://www.vdr-wiki.de/wiki/index.php/Upnp-plugin > > I also installed libupnp-1.6.6 with this dlna patch: > http://svn.assembla.com/svn/VDR-M7x0/trunk/toolchain/patches/libupnp/1.6.6/dlna/100-CustomHeader.0.0.3.patch > > I'm using the plugin with VDR 1.7.15 and Playstation3. PS3 detects the > VDR correctly, but there are no recordings or live channels available, > it's just all empty. > > When looking at the log file (with -vvvvv), i see this: > > UPnP server message: Browse requested by 192.168.0.201. > UPnP server message: ===== Browsing ===== > UPnP server message: ID: 0 > UPnP server message: Browse metadata > UPnP server message: Filter: > @id,upnp:class,res,res at protocolInfo,res at av:authenticationUri,res at size,dc:title,upnp:albumArtURI,res at dlna:ifoFileURI,res at protection,res at bitrate,res at duration,res at sampleFrequency,res at bitsPerSample,res at nrAudioChannels,res at resolution,res at colorDepth,dc:date,av:dateTime,upnp:artist,upnp:album,upnp:genre,dc:contributer,upnp:storageFree,upnp:storageUsed,upnp:originalTrackNumber,dc:publisher,dc:language,dc:region,dc:description,upnp:toc, at childCount,upnp:albumArtURI at dlna:profileID,res at dlna:cleartextSize > > UPnP server message: Offset: 0 > UPnP server message: Count: 1 > UPnP server message: Sort: (null) > UPnP server message: Pushing property > UPnP server message: Pushing property > UPnP server message: Pushing property > UPnP server message: Pushing property > UPnP server message: Pushing property > UPnP server error:Parsing filter failed > > -- > Teemu > > > 2012/2/12 Timothy D. Lenz : >> I'm interested in this also, but we have 2 Sony Bravias. Hacking the Tv not >> an option. ?I do know that on ours, for youtube, you can do searches and >> stuff using an on screen alphabet that follows the letter to number grouping >> you see on phones. So it does have a way to enter stuff. >> >> >> On 2/10/2012 1:43 PM, Luca Olivetti wrote: >>> >>> Al 10/02/12 18:07, En/na Pim Zandbergen ha escrit: >>>> >>>> I suppose you could use mediatomb with vdrnfofs to share your recordings. >>> >>> >>> Or hack the TV to simply nfs mount the directory with the recordings >>> >>> >>> Bye >> >> >> _______________________________________________ >> vdr mailing list >> vdr at linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> > > > > -- > Teemu Suikki > http://www.z-power.fi/ > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr From tsuikki at zuik.org Thu Feb 16 17:38:13 2012 From: tsuikki at zuik.org (Teemu Suikki) Date: Thu, 16 Feb 2012 18:38:13 +0200 Subject: [vdr] IS there a working UPnP-AV/DLNA support for VDR? In-Reply-To: References: <20120209153331.GA18485@boole.suse.de> <4F354ED4.9050005@zandbergen.org> <4F35815C.20607@ventoso.org> <4F36E6E9.6080506@vorgon.com> Message-ID: Hi, I think there is something else wrong, nothing is shown on my ubuntu box either with Totem player.. It should be very basic upnp player. -- Teemu 2012/2/16 Denis Loh : > Actually, I think some of the properties are not well formatted. UPnP > defines a strict pattern, which I implemented (hopefully) properly. > However, some devices may ignore this pattern. I will try to find out, > which of these parameters is the offending one. > > 2012/2/16 Teemu Suikki : >> Howdy! >> >> There is an installation instructions for vdr-plugin-upnp here: >> http://www.vdr-wiki.de/wiki/index.php/Upnp-plugin >> >> I also installed libupnp-1.6.6 with this dlna patch: >> http://svn.assembla.com/svn/VDR-M7x0/trunk/toolchain/patches/libupnp/1.6.6/dlna/100-CustomHeader.0.0.3.patch >> >> I'm using the plugin with VDR 1.7.15 and Playstation3. PS3 detects the >> VDR correctly, but there are no recordings or live channels available, >> it's just all empty. >> >> When looking at the log file (with -vvvvv), i see this: >> >> UPnP server message: Browse requested by 192.168.0.201. >> UPnP server message: ===== Browsing ===== >> UPnP server message: ID: 0 >> UPnP server message: Browse metadata >> UPnP server message: Filter: >> @id,upnp:class,res,res at protocolInfo,res at av:authenticationUri,res at size,dc:title,upnp:albumArtURI,res at dlna:ifoFileURI,res at protection,res at bitrate,res at duration,res at sampleFrequency,res at bitsPerSample,res at nrAudioChannels,res at resolution,res at colorDepth,dc:date,av:dateTime,upnp:artist,upnp:album,upnp:genre,dc:contributer,upnp:storageFree,upnp:storageUsed,upnp:originalTrackNumber,dc:publisher,dc:language,dc:region,dc:description,upnp:toc, at childCount,upnp:albumArtURI at dlna:profileID,res at dlna:cleartextSize >> >> UPnP server message: Offset: 0 >> UPnP server message: Count: 1 >> UPnP server message: Sort: (null) >> UPnP server message: Pushing property >> UPnP server message: Pushing property >> UPnP server message: Pushing property >> UPnP server message: Pushing property >> UPnP server message: Pushing property >> UPnP server error:Parsing filter failed >> >> -- >> Teemu >> >> >> 2012/2/12 Timothy D. Lenz : >>> I'm interested in this also, but we have 2 Sony Bravias. Hacking the Tv not >>> an option. ?I do know that on ours, for youtube, you can do searches and >>> stuff using an on screen alphabet that follows the letter to number grouping >>> you see on phones. So it does have a way to enter stuff. >>> >>> >>> On 2/10/2012 1:43 PM, Luca Olivetti wrote: >>>> >>>> Al 10/02/12 18:07, En/na Pim Zandbergen ha escrit: >>>>> >>>>> I suppose you could use mediatomb with vdrnfofs to share your recordings. >>>> >>>> >>>> Or hack the TV to simply nfs mount the directory with the recordings >>>> >>>> >>>> Bye >>> >>> >>> _______________________________________________ >>> vdr mailing list >>> vdr at linuxtv.org >>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >>> >> >> >> >> -- >> Teemu Suikki >> http://www.z-power.fi/ >> >> _______________________________________________ >> vdr mailing list >> vdr at linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > -- Teemu Suikki http://www.z-power.fi/ From Klaus.Schmidinger at tvdr.de Sun Feb 19 14:54:48 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Sun, 19 Feb 2012 14:54:48 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 Message-ID: <4F40FF28.9040907@tvdr.de> VDR developer version 1.7.24 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.24.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.23-1.7.24.diff MD5 checksums: a034c5e399417dfc583483f650d003ee vdr-1.7.24.tar.bz2 aa1a2b202da92e65945ff39470b26618 vdr-1.7.23-1.7.24.diff WARNING: ======== This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.7.23: - Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed a high load in case a transponder can't be received. - Improved the way DVB_API_VERSION is checked. - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Fixed asserting there is a live programme if the primary device is bonded with a device that starts a recording on a different band. - Fixed the return type of cMyDeviceHook::DeviceProvidesTransponder() in PLUGINS.html. - Fixed a crash in a plugin using cDeviceHook when VDR ends (reported by Oliver Endriss). - Some improvements to the Makefiles (thanks to Christian Ruppert). - Fixed cRecording::LengthInSeconds(), which wrongfully rounded the result to full minutes (thanks to Christoph Haubrich). - Symbolic links are no longer resolved in cRecordings::ScanVideoDir() (thanks to Sundararaj Reel). - The epg.data file is now read in a separate thread to make the startup process faster in case the file is very large (suggested by Helmut Auer). - Fixed selecting the primary device for receiving the live viewing channel in case it is bonded with an other device and has no receiver attached to it. - Fixed a possible crash when canceling VDR while displaying subtitles, and the primary device is no longer available. - Improved handling subtitles of BBC channels. - No longer using tabs as delimiter in the EPG bugfix log (they were garbled in the log file). - Added a missing '.' after the month in VPS strings. - Added some missing 'const' to cDevice (thanks to Joachim Wilke). - Fixed handling the PrimaryLimit when requesting a device for live viewing (reported by Uwe Scheffler). - Removed superfluous calls to SetVideoFormat() from device constructors. This function is called in cDevice::SetPrimaryDevice(), anyway. - An ongoing editing process is now canceled if either the original or the edited version of the recording is deleted from the Recordings menu. - The SVDRP command DELR now won't delete a recording that is currently being edited. - Removed code stub for obsolete SVDRP command MOVT. - The DVB device adapters/frontends are now probed by scanning the /dev/dvb directory instead of looping through adapter/frontend numbers. This allows for "holes" in the device numbering. - cReadDir::Next() now skips directory entries "." and "..". - Fixed a possible deadlock in time shift mode. - Fixed switching into time shift mode when pausing live video (thanks to Reinhard Nissl for helping to debug this one). Have fun! Klaus From Klaus.Schmidinger at tvdr.de Sun Feb 19 15:32:35 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Sun, 19 Feb 2012 15:32:35 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F40FF28.9040907@tvdr.de> References: <4F40FF28.9040907@tvdr.de> Message-ID: <4F410803.4040905@tvdr.de> On 19.02.2012 14:54, Klaus Schmidinger wrote: > VDR developer version 1.7.24 is now available ... >... > - Fixed switching into time shift mode when pausing live video (thanks to Reinhard > Nissl for helping to debug this one). Just realized that on channels with 50fps the info file needs to be re-read to get the actual fps rate after the index file has been written: --- dvbplayer.c 2012/02/19 10:48:02 2.23 +++ dvbplayer.c 2012/02/19 14:21:22 @@ -291,6 +291,8 @@ delete index; index = NULL; } + else if (PauseLive) + framesPerSecond = cRecording(FileName).FramesPerSecond(); // the fps rate might have changed from the default } cDvbPlayer::~cDvbPlayer() Klaus From J.Riechardt at gmx.de Sun Feb 19 19:51:38 2012 From: J.Riechardt at gmx.de (Joerg Riechardt) Date: Sun, 19 Feb 2012 19:51:38 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F40FF28.9040907@tvdr.de> References: <4F40FF28.9040907@tvdr.de> Message-ID: <4F4144BA.8050906@gmx.de> Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem. J?rg From J.Riechardt at gmx.de Sun Feb 19 20:45:18 2012 From: J.Riechardt at gmx.de (Joerg Riechardt) Date: Sun, 19 Feb 2012 20:45:18 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4144BA.8050906@gmx.de> References: <4F40FF28.9040907@tvdr.de> <4F4144BA.8050906@gmx.de> Message-ID: <4F41514E.4000801@gmx.de> Am 19.02.2012 19:51, schrieb Joerg Riechardt: > Hi, > when I replay a recording with 1.7.24 and switch several times from > replay to fast replay and back, it takes too long until VDR responds to > the remote. Happens with old recordings and recordings made with 1.7.24. > With 1.7.23 no problem. This happens with the vdr-xine plugin only. With softhddevice or xineliboutput it is ok. J?rg > J?rg > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > From Klaus.Schmidinger at tvdr.de Sun Feb 19 22:04:03 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Sun, 19 Feb 2012 22:04:03 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F41514E.4000801@gmx.de> References: <4F40FF28.9040907@tvdr.de> <4F4144BA.8050906@gmx.de> <4F41514E.4000801@gmx.de> Message-ID: <4F4163C3.2060707@tvdr.de> On 19.02.2012 20:45, Joerg Riechardt wrote: > Am 19.02.2012 19:51, schrieb Joerg Riechardt: >> Hi, >> when I replay a recording with 1.7.24 and switch several times from >> replay to fast replay and back, it takes too long until VDR responds to >> the remote. Happens with old recordings and recordings made with 1.7.24. >> With 1.7.23 no problem. > > This happens with the vdr-xine plugin only. > With softhddevice or xineliboutput it is ok. > J?rg It also works fine with the TT S2-6400. The only thing I could image to be causing this are the changes in dvbplayer.c regarding "Fixed a possible deadlock in time shift mode". Can you please try with dvbplayer.[hc] from version 1.7.23? This will also remove the fix for pausing live video, but that should be independent from this problem. Oh, and just to make sure: you haven't applied any other patches, have you? Klaus From J.Riechardt at gmx.de Mon Feb 20 00:06:41 2012 From: J.Riechardt at gmx.de (Joerg Riechardt) Date: Mon, 20 Feb 2012 00:06:41 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4163C3.2060707@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <4F4144BA.8050906@gmx.de> <4F41514E.4000801@gmx.de> <4F4163C3.2060707@tvdr.de> Message-ID: <4F418081.80200@gmx.de> Am 19.02.2012 22:04, schrieb Klaus Schmidinger: > On 19.02.2012 20:45, Joerg Riechardt wrote: >> Am 19.02.2012 19:51, schrieb Joerg Riechardt: >>> Hi, >>> when I replay a recording with 1.7.24 and switch several times from >>> replay to fast replay and back, it takes too long until VDR responds to >>> the remote. Happens with old recordings and recordings made with 1.7.24. >>> With 1.7.23 no problem. >> >> This happens with the vdr-xine plugin only. >> With softhddevice or xineliboutput it is ok. >> J?rg > > It also works fine with the TT S2-6400. > > The only thing I could image to be causing this are the changes > in dvbplayer.c regarding "Fixed a possible deadlock in time shift mode". > Can you please try with dvbplayer.[hc] from version 1.7.23? > This will also remove the fix for pausing live video, but that should be > independent from this problem. > > Oh, and just to make sure: you haven't applied any other patches, have you? > > Klaus With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. Other patches were not involved. J?rg > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > From Klaus.Schmidinger at tvdr.de Mon Feb 20 10:18:41 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Mon, 20 Feb 2012 10:18:41 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F418081.80200@gmx.de> References: <4F40FF28.9040907@tvdr.de> <4F4144BA.8050906@gmx.de> <4F41514E.4000801@gmx.de> <4F4163C3.2060707@tvdr.de> <4F418081.80200@gmx.de> Message-ID: <4F420FF1.6010202@tvdr.de> On 20.02.2012 00:06, Joerg Riechardt wrote: > Am 19.02.2012 22:04, schrieb Klaus Schmidinger: >> On 19.02.2012 20:45, Joerg Riechardt wrote: >>> Am 19.02.2012 19:51, schrieb Joerg Riechardt: >>>> Hi, >>>> when I replay a recording with 1.7.24 and switch several times from >>>> replay to fast replay and back, it takes too long until VDR responds to >>>> the remote. Happens with old recordings and recordings made with 1.7.24. >>>> With 1.7.23 no problem. >>> >>> This happens with the vdr-xine plugin only. >>> With softhddevice or xineliboutput it is ok. >>> J?rg >> >> It also works fine with the TT S2-6400. >> >> The only thing I could image to be causing this are the changes >> in dvbplayer.c regarding "Fixed a possible deadlock in time shift mode". >> Can you please try with dvbplayer.[hc] from version 1.7.23? >> This will also remove the fix for pausing live video, but that should be >> independent from this problem. >> >> Oh, and just to make sure: you haven't applied any other patches, have you? >> >> Klaus > > With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. > Other patches were not involved. > J?rg Well, then I guess it's best if I revoke that change. Any objections? Or maybe a fix for the vdr-xine problem? (See also http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1054305-geloest-timeshift-problem-mit-1-7-x/#post1054305). Klaus From ville.skytta at iki.fi Mon Feb 20 20:14:14 2012 From: ville.skytta at iki.fi (=?ISO-8859-1?Q?Ville_Skytt=E4?=) Date: Mon, 20 Feb 2012 21:14:14 +0200 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F420FF1.6010202@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <4F4144BA.8050906@gmx.de> <4F41514E.4000801@gmx.de> <4F4163C3.2060707@tvdr.de> <4F418081.80200@gmx.de> <4F420FF1.6010202@tvdr.de> Message-ID: <4F429B86.5000105@iki.fi> On 2012-02-20 11:18, Klaus Schmidinger wrote: > On 20.02.2012 00:06, Joerg Riechardt wrote: > >> With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. >> Other patches were not involved. >> J?rg > > Well, then I guess it's best if I revoke that change. > Any objections? Or maybe a fix for the vdr-xine problem? It seems that the dxr3 plugin is similarly affected, and reverting to the 1.7.23 versions gets rid of the problem for it as well. From udo_richter at gmx.de Mon Feb 20 23:11:33 2012 From: udo_richter at gmx.de (Udo Richter) Date: Mon, 20 Feb 2012 23:11:33 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F420FF1.6010202@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <4F4144BA.8050906@gmx.de> <4F41514E.4000801@gmx.de> <4F4163C3.2060707@tvdr.de> <4F418081.80200@gmx.de> <4F420FF1.6010202@tvdr.de> Message-ID: <4F42C515.2020709@gmx.de> Am 20.02.2012 10:18, schrieb Klaus Schmidinger: > On 20.02.2012 00:06, Joerg Riechardt wrote: >> With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is >> ok again. >> Other patches were not involved. >> J?rg > > Well, then I guess it's best if I revoke that change. > Any objections? Or maybe a fix for the vdr-xine problem? > > (See also > http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1054305-geloest-timeshift-problem-mit-1-7-x/#post1054305). I'm also seeing (hearing) reproducible glitches on playback with a TT-6400, on 1.7.24. I've reverted just the changes from the patch at vdr-portal, and the glitches were gone. So +1 for reverting. For ease of use the attached patch sums up the revert. Because of an indenting issue the original patch doesn't revert cleanly. Cheers, Udo -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr-1.7.24-dvbplayer-revert.diff Type: text/x-patch Size: 3326 bytes Desc: not available URL: From hma at iki.fi Thu Feb 23 06:47:40 2012 From: hma at iki.fi (Heikki Manninen) Date: Thu, 23 Feb 2012 07:47:40 +0200 Subject: [vdr] Prefer non-CI equipped adapters for FTA channel recording Message-ID: Hello, here's my current setup: 1 x Satelco DVB-C Budget with CI + CAM (Conax CIv1) 1 x Satelco DVB-C Bidget wuthout CI When recording FTA channels VDR seems to sometimes select the one adapter with CI. It would make sense to always try to use non-CI equipped adapter for these recordings leaving the one with CI free for live viewing/recording encrypted channels. Any way to achieve this through configuration? -- Heikki Manninen From Klaus.Schmidinger at tvdr.de Thu Feb 23 09:26:26 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Thu, 23 Feb 2012 09:26:26 +0100 Subject: [vdr] Prefer non-CI equipped adapters for FTA channel recording In-Reply-To: References: Message-ID: <4F45F832.2040709@tvdr.de> On 23.02.2012 06:47, Heikki Manninen wrote: > Hello, here's my current setup: > > 1 x Satelco DVB-C Budget with CI + CAM (Conax CIv1) > 1 x Satelco DVB-C Bidget wuthout CI > > When recording FTA channels VDR seems to sometimes select the one adapter with CI. It would make sense to always try to use non-CI equipped adapter for these recordings leaving the one with CI free for live viewing/recording encrypted channels. > > Any way to achieve this through configuration? Actually VDR is supposed to avoid devices with CI for FTA recordings: imp <<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid cards with Common Interface for FTA channels If this doesn't work on your system, you may want to debug the function cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) to see why it selects sich a device when it shouldn't. Klaus From hma at iki.fi Thu Feb 23 10:21:09 2012 From: hma at iki.fi (Heikki Manninen) Date: Thu, 23 Feb 2012 11:21:09 +0200 Subject: [vdr] Prefer non-CI equipped adapters for FTA channel recording In-Reply-To: <4F45F832.2040709@tvdr.de> References: <4F45F832.2040709@tvdr.de> Message-ID: On Thu, Feb 23, 2012 at 10:26, Klaus Schmidinger wrote: > On 23.02.2012 06:47, Heikki Manninen wrote: >> >> Hello, here's my current setup: >> >> 1 x Satelco DVB-C Budget with CI + CAM (Conax CIv1) >> 1 x Satelco DVB-C Bidget wuthout CI >> >> When recording FTA channels VDR seems to sometimes select the one adapter >> with CI. It would make sense to always try to use non-CI equipped adapter >> for these recordings leaving the one with CI free for live viewing/recording >> encrypted channels. >> >> Any way to achieve this through configuration? > > > Actually VDR is supposed to avoid devices with CI for FTA recordings: > > ?imp <<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid cards > with Common Interface for FTA channels > > If this doesn't work on your system, you may want to debug the function > > ?cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) > > to see why it selects sich a device when it shouldn't. Ok, will do. Before I had a CI with both Satelco cards but only one of them had the actual CAM installed. Would that have caused problems? Could it be that if the other card is busy doing live viewing or transponder scanning, VDR selects the CI-enabled device for recording? I would still prefer the non-CI device even if it would cause retuning of the channel that is being viewed. -- Heikki M From Klaus.Schmidinger at tvdr.de Thu Feb 23 10:30:16 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Thu, 23 Feb 2012 10:30:16 +0100 Subject: [vdr] Prefer non-CI equipped adapters for FTA channel recording In-Reply-To: References: <4F45F832.2040709@tvdr.de> Message-ID: <4F460728.3030304@tvdr.de> On 23.02.2012 10:21, Heikki Manninen wrote: > On Thu, Feb 23, 2012 at 10:26, Klaus Schmidinger > wrote: > >> On 23.02.2012 06:47, Heikki Manninen wrote: >>> >>> Hello, here's my current setup: >>> >>> 1 x Satelco DVB-C Budget with CI + CAM (Conax CIv1) >>> 1 x Satelco DVB-C Bidget wuthout CI >>> >>> When recording FTA channels VDR seems to sometimes select the one adapter >>> with CI. It would make sense to always try to use non-CI equipped adapter >>> for these recordings leaving the one with CI free for live viewing/recording >>> encrypted channels. >>> >>> Any way to achieve this through configuration? >> >> >> Actually VDR is supposed to avoid devices with CI for FTA recordings: >> >> imp<<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid cards >> with Common Interface for FTA channels >> >> If this doesn't work on your system, you may want to debug the function >> >> cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) >> >> to see why it selects sich a device when it shouldn't. > > Ok, will do. > > Before I had a CI with both Satelco cards but only one of them had the > actual CAM installed. Would that have caused problems? I don't think so. > Could it be that if the other card is busy doing live viewing or > transponder scanning, VDR selects the CI-enabled device for recording? > I would still prefer the non-CI device even if it would cause retuning > of the channel that is being viewed. Live viewing should not stop VDR from using a device that has a CI for recording an FTA channel. However, if there is a cReceiver attached to the on-CI device for any reason, that might keep it from being used. Just check what's actually happening in the GetDevice() function. Klaus From info at lwq.de Thu Feb 23 11:20:23 2012 From: info at lwq.de (Claus-Peter Behrens) Date: Thu, 23 Feb 2012 11:20:23 +0100 Subject: [vdr] Prefer non-CI equipped adapters for FTA channel recording References: <4F45F832.2040709@tvdr.de> <4F460728.3030304@tvdr.de> Message-ID: <2BBB6DBEE7D44B7CB1102B6B1BD2F291@Mareile> ----- Original Message ----- From: "Klaus Schmidinger" To: Sent: Thursday, February 23, 2012 10:30 AM Subject: Re: [vdr] Prefer non-CI equipped adapters for FTA channel recording > On 23.02.2012 10:21, Heikki Manninen wrote: >> On Thu, Feb 23, 2012 at 10:26, Klaus Schmidinger >> wrote: >> >>> On 23.02.2012 06:47, Heikki Manninen wrote: >>>> >>>> Hello, here's my current setup: >>>> >>>> 1 x Satelco DVB-C Budget with CI + CAM (Conax CIv1) >>>> 1 x Satelco DVB-C Bidget wuthout CI >>>> >>>> When recording FTA channels VDR seems to sometimes select the one >>>> adapter >>>> with CI. It would make sense to always try to use non-CI equipped >>>> adapter >>>> for these recordings leaving the one with CI free for live >>>> viewing/recording >>>> encrypted channels. >>>> >>>> Any way to achieve this through configuration? >>> >>> >>> Actually VDR is supposed to avoid devices with CI for FTA recordings: >>> >>> imp<<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid >>> cards >>> with Common Interface for FTA channels >>> >>> If this doesn't work on your system, you may want to debug the function >>> >>> cDevice::GetDevice(const cChannel *Channel, int Priority, bool >>> LiveView) >>> >>> to see why it selects sich a device when it shouldn't. >> >> Ok, will do. >> >> Before I had a CI with both Satelco cards but only one of them had the >> actual CAM installed. Would that have caused problems? > > I don't think so. > >> Could it be that if the other card is busy doing live viewing or >> transponder scanning, VDR selects the CI-enabled device for recording? >> I would still prefer the non-CI device even if it would cause retuning >> of the channel that is being viewed. > > Live viewing should not stop VDR from using a device that has a CI for > recording an FTA channel. However, if there is a cReceiver attached to > the on-CI device for any reason, that might keep it from being used. > > Just check what's actually happening in the GetDevice() function. > > Klaus > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > From vdr at auktion.hostingkunde.de Thu Feb 23 11:38:51 2012 From: vdr at auktion.hostingkunde.de (fnu) Date: Thu, 23 Feb 2012 11:38:51 +0100 Subject: [vdr] SoftHDDevice References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> Message-ID: <002101ccf217$55442280$ffcc6780$@auktion.hostingkunde.de> 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. Ok, from this point the most work is now to set up all the odds and ends to get proper usable VDR, xorg.conf, sensors, hddtemp, remote control etc. ... ;-) Have fun. Regards fnu -----Urspr?ngliche Nachricht----- Von: fnu [mailto:vdr at auktion.hostingkunde.de] Gesendet: Dienstag, 7. Februar 2012 23:42 An: 'VDR Mailing List' Betreff: AW: [vdr] SoftHDDevice > You don't need a windows manager with xine/vdr-xine either, but according to softhddevice own text, -f requires it. Well xorg alone would not work w/o any basic window management stuff, called it window manager or not, but bottomline it is one, included in pure xorg. If there wouldn't be a thing like this, you would not be able to open just a basic windows, like xterm. And you can do this, nowadays black on black instead of herringbone pattern, if you just install basic xorg with it's dependencies. There must be something which manages the size of the desktop, advise to open a window in a specific size on a defined position, or just fullscreen. All other stuff known as window manager just adds kind of decoration, widgets, buttons, a kind of configuration scripting etc. ... There was also no need to have an decoration manager to operate the old softdevice-plugin (SD), id did just run on the old herringbone desktop ... ;-) Regards fnu From oldmanuk at gmail.com Thu Feb 23 16:50:26 2012 From: oldmanuk at gmail.com (Dominic Evans) Date: Thu, 23 Feb 2012 15:50:26 +0000 Subject: [vdr] Intelligent management of simulcast DVB-S2 / DVB-T channels Message-ID: I remember seeing patches for marking channels as identical in terms of EPG (so e.g., a DVB-S version of the channel can automatically share the EPG entries from the DVB-T version), but has anyone worked on a patch for identifying simulcasting channels, or even had some preliminary design thoughts for how one could be implemented? I can imagine at least the following two use cases: 1) When watching live TV, channel '1' automatically selects the 'best' available version of 'BBC One London' depending on available tuners - e.g., rotating through BBC One HD (DVB-S2), BBC One (DVB-T2), BBC One (DVB-S) and BBC One London (DVB-T). This is much more intuitive than having to manually find an available broadcast of the channel. 2) For recordings, if a timer needs to start a recording on 'BBC One London', depending on its priority and a 'required quality' attribute it will similarly locate a tuner to make the recording with. Assuming it needs the DVB-S2 tuner for HD, if someone with lower priority is currently watching live TV on BBC One HD via DVB-S2 (and only one HD tuner is available) then they will be transparently switched down to the next available tuner quality. -------------- next part -------------- An HTML attachment was scrubbed... URL: From user.vdr at gmail.com Thu Feb 23 17:59:37 2012 From: user.vdr at gmail.com (VDR User) Date: Thu, 23 Feb 2012 08:59:37 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <002101ccf217$55442280$ffcc6780$@auktion.hostingkunde.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> <002101ccf217$55442280$ffcc6780$@auktion.hostingkunde.de> Message-ID: On Thu, Feb 23, 2012 at 2:38 AM, fnu 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. From user.vdr at gmail.com Thu Feb 23 17:59:37 2012 From: user.vdr at gmail.com (VDR User) Date: Thu, 23 Feb 2012 08:59:37 -0800 Subject: [vdr] SoftHDDevice In-Reply-To: <002101ccf217$55442280$ffcc6780$@auktion.hostingkunde.de> References: <4F310143.6000909@gmail.com> <000001cce5b2$92d19590$b874c0b0$@auktion.hostingkunde.de> <000201cce5b9$56146770$023d3650$@auktion.hostingkunde.de> <000901cce5cb$6ec27020$4c475060$@auktion.hostingkunde.de> <002c01cce5d6$14697780$3d3c6680$@auktion.hostingkunde.de> <002101ccf217$55442280$ffcc6780$@auktion.hostingkunde.de> Message-ID: On Thu, Feb 23, 2012 at 2:38 AM, fnu 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. From magnus at alefors.se Thu Feb 23 19:36:32 2012 From: magnus at alefors.se (=?UTF-8?B?TWFnbnVzIEjDtnJsaW4=?=) Date: Thu, 23 Feb 2012 19:36:32 +0100 Subject: [vdr] Intelligent management of simulcast DVB-S2 / DVB-T channels In-Reply-To: References: Message-ID: <4F468730.6070000@alefors.se> On 02/23/2012 04:50 PM, Dominic Evans wrote: > I remember seeing patches for marking channels as identical in terms > of EPG (so e.g., a DVB-S version of the channel can automatically > share the EPG entries from the DVB-T version), but has anyone worked > on a patch for identifying simulcasting channels, or even had some > preliminary design thoughts for how one could be implemented? > > I can imagine at least the following two use cases: > > 1) When watching live TV, channel '1' automatically selects the 'best' > available version of 'BBC One London' depending on available tuners - > e.g., rotating through BBC One HD (DVB-S2), BBC One (DVB-T2), BBC One > (DVB-S) and BBC One London (DVB-T). This is much more intuitive than > having to manually find an available broadcast of the channel. > > 2) For recordings, if a timer needs to start a recording on 'BBC One > London', depending on its priority and a 'required quality' attribute > it will similarly locate a tuner to make the recording with. Assuming > it needs the DVB-S2 tuner for HD, if someone with lower priority is > currently watching live TV on BBC One HD via DVB-S2 (and only one HD > tuner is available) then they will be transparently switched down to > the next available tuner quality. > Hi. This is an interesting topic and I have had exactly the same ideas. But I think this violates Klaus's "Keep it simple" philosophy and (as usual) I tend to agree with him. /Magnus H From udo_richter at gmx.de Fri Feb 24 00:33:06 2012 From: udo_richter at gmx.de (Udo Richter) Date: Fri, 24 Feb 2012 00:33:06 +0100 Subject: [vdr] Intelligent management of simulcast DVB-S2 / DVB-T channels In-Reply-To: <4F468730.6070000@alefors.se> References: <4F468730.6070000@alefors.se> Message-ID: <4F46CCB2.9010608@gmx.de> Am 23.02.2012 19:36, schrieb Magnus H?rlin: > This is an interesting topic and I have had exactly the same ideas. But > I think this violates Klaus's "Keep it simple" philosophy and (as usual) > I tend to agree with him. If you've ever read the algorithm that picks the best possible device for a recording, you'd probably agreed that we're already way too far from keeping it simple. These rules are already way too complex. Adding the complexity of choosing from different quality sources and up/downgrading other receivers would probably push this a lot further towards insanity. Cheers, Udo From udo_richter at gmx.de Fri Feb 24 00:43:09 2012 From: udo_richter at gmx.de (Udo Richter) Date: Fri, 24 Feb 2012 00:43:09 +0100 Subject: [vdr] Prefer non-CI equipped adapters for FTA channel recording In-Reply-To: <4F460728.3030304@tvdr.de> References: <4F45F832.2040709@tvdr.de> <4F460728.3030304@tvdr.de> Message-ID: <4F46CF0D.5080101@gmx.de> Am 23.02.2012 10:30, schrieb Klaus Schmidinger: > Just check what's actually happening in the GetDevice() function. ... and try with minimal plugins, they might introduce side effects. OSDTeletext for example is known to have such side effects on device selection. Cheers, Udo From vdr at schmirler.de Fri Feb 24 15:37:34 2012 From: vdr at schmirler.de (Frank Schmirler) Date: Fri, 24 Feb 2012 15:37:34 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F40FF28.9040907@tvdr.de> References: <4F40FF28.9040907@tvdr.de> Message-ID: <20120224143734.M43953@schmirler.de> Hi, On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote > - Fixed handling the PrimaryLimit when requesting a device for live viewing > (reported by Uwe Scheffler). Refers to the following change in device.c: - if (device[i]->ProvidesChannel(Channel, Priority, &ndr)) { // this device is basicly able to do the job + if (device[i]->ProvidesChannel(Channel, (LiveView && device[i]->IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority, &ndr)) { // this device is basicly able to do the job With this modification the GetDevice parameter Priority becomes meaningless in case LiveView is true. This should at least be mentioned in the function's documentation in device.h. Anyway, I think a better way to fix the problem would be to change the priority parameter of the GetDevice calls involved from "GetDevice(channel, 0, true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are two calls in device.c and one call in menu.c. Imagine a two card system with PrimaryLimit 20, a high priority recording (e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10) on the second card. With 1.7.24 live TV would not interrupt the low priority recording, as PrimaryLimit priority is only used when checking the PrimaryDevice, but priority 0 is used when checking the second card. The way 1.7.24 resolves the problem is not wrong as according to MANUAL PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the intention of this parameter is prefering LiveTV to low priority recordings. I'm still hoping to get a more priority driven device selection. BTW: Any update on this related issue: http://www.mail-archive.com/vdr at linuxtv.org/msg14166.html? Regards, Frank From Klaus.Schmidinger at tvdr.de Fri Feb 24 17:23:18 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Fri, 24 Feb 2012 17:23:18 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120224143734.M43953@schmirler.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> Message-ID: <4F47B976.3020906@tvdr.de> On 24.02.2012 15:37, Frank Schmirler wrote: > Hi, > > On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote >> - Fixed handling the PrimaryLimit when requesting a device for live viewing >> (reported by Uwe Scheffler). > > Refers to the following change in device.c: > - if (device[i]->ProvidesChannel(Channel, Priority,&ndr)) { // this > device is basicly able to do the job > + if (device[i]->ProvidesChannel(Channel, (LiveView&& > device[i]->IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority,&ndr)) { // > this device is basicly able to do the job > > With this modification the GetDevice parameter Priority becomes meaningless in > case LiveView is true. This should at least be mentioned in the function's > documentation in device.h. > > Anyway, I think a better way to fix the problem would be to change the > priority parameter of the GetDevice calls involved from "GetDevice(channel, 0, > true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are two calls > in device.c and one call in menu.c. > > Imagine a two card system with PrimaryLimit 20, a high priority recording > (e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10) > on the second card. With 1.7.24 live TV would not interrupt the low priority > recording, as PrimaryLimit priority is only used when checking the > PrimaryDevice, but priority 0 is used when checking the second card. > > The way 1.7.24 resolves the problem is not wrong as according to MANUAL > PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the > intention of this parameter is prefering LiveTV to low priority recordings. > I'm still hoping to get a more priority driven device selection. IIRC that whole "Primary Limit" thing was introduced because in the beginning the full featured DVB cards were unable to record and play at the same time. So it could happen that a timer occupied the primary device and left the user with a black screen. Since the old FF cards have been given the ability to do simultaneous recording and replay a long time ago, and the new TT S2-6400 has been able to do this from the very start, I'd rather prefer to do away with the "Primary Limit" altogether - to make things simpler instead of more complex ;-) So, is there anybody who would *really* miss the "Primary Limit" if it were gone? > BTW: Any update on this related issue: > http://www.mail-archive.com/vdr at linuxtv.org/msg14166.html? I assume you are referring to http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-4.diff Well, I don't like the idea of introducing yet another parameter ("volatile") here. The "priority" should be sufficient to solve this. So if you can suggest a solution that works solely with priorities, I might take a look ;-) Klaus From udo_richter at gmx.de Fri Feb 24 19:33:06 2012 From: udo_richter at gmx.de (Udo Richter) Date: Fri, 24 Feb 2012 19:33:06 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F47B976.3020906@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> Message-ID: <4F47D7E2.6070601@gmx.de> Am 24.02.2012 17:23, schrieb Klaus Schmidinger: > On 24.02.2012 15:37, Frank Schmirler wrote: >> On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote >>> - Fixed handling the PrimaryLimit when requesting a device for live >>> viewing >>> (reported by Uwe Scheffler). Hmmm, didn't even notice that change... >> Anyway, I think a better way to fix the problem would be to change the >> priority parameter of the GetDevice calls involved from >> "GetDevice(channel, 0, >> true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are >> two calls >> in device.c and one call in menu.c. My 'volatile' patch did this, and it worked so far. I like that a lot more than the 1.7.24 solution that just adds another quirk to the priority system. If in doubt, this should just raise the priority on channel switching. I don't think that it would cause any negative side effects, esp. since this priority is ignored at the end anyway. (see below) > IIRC that whole "Primary Limit" thing was introduced because in the > beginning > the full featured DVB cards were unable to record and play at the same > time. > So it could happen that a timer occupied the primary device and left the > user with a black screen. Since the old FF cards have been given the > ability > to do simultaneous recording and replay a long time ago, and the new TT > S2-6400 > has been able to do this from the very start, I'd rather prefer to do > away with > the "Primary Limit" altogether - to make things simpler instead of more > complex ;-) Keep in mind that a recording on an un-modded SD-FF device nowadays can cause broken recordings because of limited bandwidth. Being able to record and play at the same time is a rather theoretical ability, especially if its transfer mode playback. However, I never had PrimaryLimit set to anything but 0. > http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-4.diff For description: http://projects.vdr-developer.org/issues/show/10 > Well, I don't like the idea of introducing yet another parameter > ("volatile") here. > The "priority" should be sufficient to solve this. So if you can suggest > a solution > that works solely with priorities, I might take a look ;-) That patch actually goes the same way as the above fix, but beside that its more about the detaching issue, and just fixed the PrimaryLimit issue on the way, so its not directly related. Even dropping PrimaryLimit wouldn't solve this issue. One of the core problems is that VDR selects a new device for live viewing before disconnecting the old live device. Thus, all live related receivers will still be present and will block the current device from being re-used. VDR works around this just because live view has no receivers (FF cards) or -1 priority receivers (transfer mode, subtitles), that are always of lower priority than anything. As a conequence, VDR has to ignore the '-1 can always be disconnected' rule, or it would also disconnect transfer mode on timers, regardless of free devices. And this leads to the osdteletext issue that the teletext receiver still blocks the device on channel switch. VDR's own receivers also work around this because they get disconnected before doing the final and counting GetDevice call, but plugins cannot do that at that time. A clean solution should imho do these things: - Fix the find-device-before-disconnecting loop - Transfer mode devices with 'real' priorities - Honor the -1 priority as always-detachable In the end, you need to know at a very early point (ChUp pressed etc.) whether a device will be available for live view, even if it is still used right now, and might be used on (if ChUp fails). Letting VDR know that a device will probably soon be detached was one of the smarter solutions to this. Another alternative I was thinking of was to let the device know that a receiver is 'live-related', and thus can be canceled for another live view, but the 'volatile' solution was more general. Maybe it would be possible to manually lower the transfer mode receivers to -1 when calling GetDevice with live view, and raise them back to PrimaryLimit (or 0) at the end. Not sure if that's more elegant... Cheers, Udo From vdr at schmirler.de Sat Feb 25 00:21:40 2012 From: vdr at schmirler.de (Frank Schmirler) Date: Sat, 25 Feb 2012 00:21:40 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F47D7E2.6070601@gmx.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> Message-ID: <20120224221450.M33389@linogate.de> On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote > Am 24.02.2012 17:23, schrieb Klaus Schmidinger: > > IIRC that whole "Primary Limit" thing was introduced because in the > > beginning > > the full featured DVB cards were unable to record and play at the same > > time. > > So it could happen that a timer occupied the primary device and left the > > user with a black screen. Since the old FF cards have been given the > > ability > > to do simultaneous recording and replay a long time ago, and the new TT > > S2-6400 > > has been able to do this from the very start, I'd rather prefer to do > > away with > > the "Primary Limit" altogether - to make things simpler instead of more > > complex ;-) I was not aware of this as I have no FF card. For me, "Primary Limit" always was the "Priority of Live TV". Ok, MANUAL talks about being allowed to "use the primary DVB interface" and not denial to "affect live TV", but the use case "recordings that should take place only when there is nothing else to do, but should never keep the user from viewing stuff on the primary interface" clearly pointed into that direction. Always using priority 0 instead of a configurable "Primary Limit" means there's no way to get anything with less priority than live TV but without the "may always be detached" meaning of negative priorities. Streamdev is using the "Primary Limit" to control priorities between multiple clients and partially also between clients and server. Only "partially" due to transfer mode receiver device running with priority -1. Currently a plugin can't simply call GetDevice with a non-negative priority without disturbing Live TV in transfer mode. Some ugly workarounds were necessary in streamdev to handle this. > > Well, I don't like the idea of introducing yet another parameter > > ("volatile") here. > > The "priority" should be sufficient to solve this. So if you can suggest > > a solution > > that works solely with priorities, I might take a look ;-) Well, the -1 priority on the transfer mode receiver device solves the "receivers still attached when switching channels" problem. But it introduces an exceptional case which causes problems (osdteletext) or makes apparently simple things hard to handle (streamdev GetDevice). Trading this for an explicit parameter sounds like a very good deal to me. > Letting VDR know that a device will probably soon be detached was > one of the smarter solutions to this. Another alternative I was > thinking of was to let the device know that a receiver is 'live- > related', and thus can be canceled for another live view, but the > 'volatile' solution was more general. > > Maybe it would be possible to manually lower the transfer mode receivers > to -1 when calling GetDevice with live view, and raise them back to > PrimaryLimit (or 0) at the end. Not sure if that's more elegant... +1 for the "volatile" solution. Streamdev-server has to handle channel switches, too. On the server side they are not "live-related", but the problem is the same: The receivers for the previous channel are still attached. "Volatile" would obsolete an other workaround in streamdev. Regards, Frank From Klaus.Schmidinger at tvdr.de Sat Feb 25 15:39:17 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Sat, 25 Feb 2012 15:39:17 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120224221450.M33389@linogate.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> Message-ID: <4F48F295.5040401@tvdr.de> On 25.02.2012 00:21, Frank Schmirler wrote: > On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote >> Am 24.02.2012 17:23, schrieb Klaus Schmidinger: >>> IIRC that whole "Primary Limit" thing was introduced because in the >>> beginning >>> the full featured DVB cards were unable to record and play at the same >>> time. >>> So it could happen that a timer occupied the primary device and left the >>> user with a black screen. Since the old FF cards have been given the >>> ability >>> to do simultaneous recording and replay a long time ago, and the new TT >>> S2-6400 >>> has been able to do this from the very start, I'd rather prefer to do >>> away with >>> the "Primary Limit" altogether - to make things simpler instead of more >>> complex ;-) > > I was not aware of this as I have no FF card. For me, "Primary Limit" always > was the "Priority of Live TV". Ok, MANUAL talks about being allowed to "use > the primary DVB interface" and not denial to "affect live TV", but the use > case "recordings that should take place only when there is nothing else to do, > but should never keep the user from viewing stuff on the primary interface" > clearly pointed into that direction. > > Always using priority 0 instead of a configurable "Primary Limit" means > there's no way to get anything with less priority than live TV but without the > "may always be detached" meaning of negative priorities. > > Streamdev is using the "Primary Limit" to control priorities between multiple > clients and partially also between clients and server. Only "partially" due to > transfer mode receiver device running with priority -1. Currently a plugin > can't simply call GetDevice with a non-negative priority without disturbing > Live TV in transfer mode. Some ugly workarounds were necessary in streamdev to > handle this. > >>> Well, I don't like the idea of introducing yet another parameter >>> ("volatile") here. >>> The "priority" should be sufficient to solve this. So if you can suggest >>> a solution >>> that works solely with priorities, I might take a look ;-) > > Well, the -1 priority on the transfer mode receiver device solves the > "receivers still attached when switching channels" problem. But it introduces > an exceptional case which causes problems (osdteletext) or makes apparently > simple things hard to handle (streamdev GetDevice). Trading this for an > explicit parameter sounds like a very good deal to me. > >> Letting VDR know that a device will probably soon be detached was >> one of the smarter solutions to this. Another alternative I was >> thinking of was to let the device know that a receiver is 'live- >> related', and thus can be canceled for another live view, but the >> 'volatile' solution was more general. >> >> Maybe it would be possible to manually lower the transfer mode receivers >> to -1 when calling GetDevice with live view, and raise them back to >> PrimaryLimit (or 0) at the end. Not sure if that's more elegant... > > +1 for the "volatile" solution. Streamdev-server has to handle channel > switches, too. On the server side they are not "live-related", but the problem > is the same: The receivers for the previous channel are still attached. > "Volatile" would obsolete an other workaround in streamdev. Definitely *no* "volatile"! PrimaryLimit is going to be dropped, since the old FF-DVB cards can now (since version 1.7.21) be run with the --outputonly option to avoid problems with recording high bandwidth channels. Besides, with HDTV becoming ever more popular those cards are pretty much obsolete by now (the TT S2-6400 has no problems recording and replaying high bandwidth channels simultaneously). And, last but not least, people using software players won't notice this change, anyway. There was also apparently some misunderstanding about what PrimaryLimit was supposed to do. It was *never* meant to allow "Channel switching can cancel timers with priority <= Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr-developer.org/issues/show/10). Its sole purpose was to not use the primary device for recording low priority timers and leave the user with a black screen. Those days are long gone, and PrimaryLimit is obsolete and causing nothing but trouble. A recording shall *always* have priority over live viewing. Since cReceivers can have priorities between -99 and 99, the priority for an unused device has been changed from -1 to -100. The attached patch implements all these changes (*.po files left out for clarity). Please try this and let me know if anything doesn't work as expected. I did try running a recording on the primary device, so that live view would be done in Transfer mode from the secondary device (only two devices activated for testing) and had no problem with zapping through channels with Up/Down. I also tried starting a recording on device 2 while in Transfer Mode, and the live channel was switched to device 1 when the recording kicked in. Klaus -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr-1.7.24-removeprimarylimit.diff Type: text/x-patch Size: 10809 bytes Desc: not available URL: From syrius.ml at no-log.org Sun Feb 26 14:42:01 2012 From: syrius.ml at no-log.org (syrius.ml at no-log.org) Date: Sun, 26 Feb 2012 14:42:01 +0100 Subject: [vdr] Intelligent management of simulcast DVB-S2 / DVB-T channels In-Reply-To: <4F46CCB2.9010608@gmx.de> (Udo Richter's message of "Fri, 24 Feb 2012 00:33:06 +0100") References: <4F468730.6070000@alefors.se> <4F46CCB2.9010608@gmx.de> Message-ID: <87aa45n3m6.878vjpn3m6@877gz9n3m6.message.id> Udo Richter writes: > Am 23.02.2012 19:36, schrieb Magnus H?rlin: >> This is an interesting topic and I have had exactly the same ideas. But >> I think this violates Klaus's "Keep it simple" philosophy and (as usual) >> I tend to agree with him. > > If you've ever read the algorithm that picks the best possible device > for a recording, you'd probably agreed that we're already way too far > from keeping it simple. These rules are already way too complex. Adding > the complexity of choosing from different quality sources and > up/downgrading other receivers would probably push this a lot further > towards insanity. Even without the primarylimit it's still deadly complex. The very clever programming syntax used for the device selection makes it very difficult to understand and also to debug. I have an old idea in my head but I've never taken the time to do so, it's also quite erratic: disable channel and device management and allow an external program to decide how to deal with devices and channels. I wouldn't want to start from scratch and work around dvbstreamer, vdr and its plugins are wonderful ! I love it ! (it's just the device and channel management that are too limited imho) I'm not really into C++, it might already be possible to let plugins take over the channel and device management but i doubt it. -- From Klaus.Schmidinger at tvdr.de Sun Feb 26 17:26:45 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Sun, 26 Feb 2012 17:26:45 +0100 Subject: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running In-Reply-To: References: <4D73B330.6080503@tvdr.de> <20110307115410.M30707@linogate.de> <4D74D0AB.5050408@tvdr.de> <20110307125423.M60134@linogate.de> <4D74DAFB.3060002@tvdr.de> <4D7CB3DA.6020809@tvdr.de> Message-ID: <4F4A5D45.2080305@tvdr.de> On 14.03.2011 23:05, Markus Ehrnsperger wrote: > 2011/3/14 Markus Ehrnsperger: >>>> Hi, >>>> >>>> I have a suggestion: Treat the VPS margin the same way as the time a >>>> non VPS timer will start before the EPG event starts. Example: >>>> >>>> Tagesschau, starts at 8:00 PM. >>>> >>>> If I don't use VPS, I will create a timer at 7:58 PM (in case the news >>>> start slightly before 8) >>>> If I use VPS, I will create a timer at 8:00 PM. The VPS margin is 2 >>>> minutes (in this example). >>>> >>>> >>>> If I don't use VPS, another recording (with lower priority) will be >>>> stopped at 7.58 PM. The timer will start recording. >>>> If I use VPS, another recording (with lower priority) will be stopped >>>> at 7.58 PM (my suggestion). The next two minutes, the device will be >>>> used for VPS checking only. The recording will start at 8:00 PM. >>>> >>>> Of course, this might look like wasting a device for two minutes only >>>> to check the VPS. On the other side, not using VPS is even worse: I >>>> will waste the device and disk space. So, using VPS is still better. >>>> And, the timer with lower priority has lower priority by purpose. So, >>>> I want it to be interrupted. >>>> >>>> Summary: >>>> I suggest to use GetDevice as soon as the timer is within the VPS margin. >>>> This has the following advantages: >>>> - Easy to implement >>>> - Easy to understand for users, and expected behavior: The timer with >>>> higher priority has higher priority :) . >>>> - No rocket science >>>> >>>> I admit, it has some disadvantages. But, from my point of view, these >>>> are minor compared to the advantages. At the moment, I can use VPS >>>> only with care as I might miss a recording with very high priority. >>>> >>>> Markus >>> >>> Please provide a (tested) patch that implements this. >>> >>> Klaus >>> >> Hi, >> >> I attach a simple patch. I tried it out and it works for me. Any >> comments are very welkome. Sorry I didn't get to this earlier... I'd rather like to give the attached method a try. It modifies the code that actually checks whether a timer matches, and now takes into account whether the "present" event has been seen within a certain time. If it hasn't, the timer behaves like a normal timer and starts at the start time of the event (provided its priority is high enough). Klaus -------------- next part -------------- A non-text attachment was scrubbed... Name: vdr-1.7.24-vpstimer.diff Type: text/x-patch Size: 902 bytes Desc: not available URL: From vdr at schmirler.de Mon Feb 27 14:33:14 2012 From: vdr at schmirler.de (Frank Schmirler) Date: Mon, 27 Feb 2012 14:33:14 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F48F295.5040401@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> Message-ID: <20120227120750.M92341@linogate.de> On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote > There was also apparently some misunderstanding about what > PrimaryLimit was supposed to do. It was *never* meant to allow > "Channel switching can cancel timers with priority <= > Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr- > developer.org/issues/show/10). Its sole purpose was to not use the > primary device for recording low priority timers and leave the user > with a black screen. Those days are long gone, and PrimaryLimit is > obsolete and causing nothing but trouble. > > A recording shall *always* have priority over live viewing. I would be fine with that with respect to recordings, but this shouldn't be generally true for cReceivers. What I'm hoping to get is the possiblity to attach a cReceiver with a lower priority than live TV but without the "cReceivers with negative priority do not count". > Since cReceivers can have priorities between -99 and 99, the priority > for an unused device has been changed from -1 to -100. Udo Richter's patch basically turned "PrimaryLimit" into a configurable "LiveTV priority". A "LiveTV priority" > 0 gains you cReceivers with a priority less than live TV but still non-negative. To fix the "Transfer mode receiver device has priority -1" problem, he introduced "volatile". Instead of a configurable "LiveTV priority", your approach uses the fixed priority value 0 for LiveTV. The new idle priority of -100 opens the range for cReceivers with negative priority. The problem is, that *any* negative priority is still considered as "may be detached anytime", so there's still no real "cReceiver with less priority than live TV". I suggest the following additional changes: - instead of any negative priority, only priority -MAXPRIORITY gets the special meaning of "may be detached anytime" - the constructor of cReceiver should use default priority -MAXPRIORITY, so not all plugins have to be updated to keep their previous behaviour - use LIVEPRIORITY-1 as priority for cTransfer I can't however overlook the impact these modifications have. Regards, Frank From Klaus.Schmidinger at tvdr.de Mon Feb 27 18:05:39 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Mon, 27 Feb 2012 18:05:39 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120227120750.M92341@linogate.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> Message-ID: <4F4BB7E3.8020902@tvdr.de> On 27.02.2012 14:33, Frank Schmirler wrote: > On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote >> There was also apparently some misunderstanding about what >> PrimaryLimit was supposed to do. It was *never* meant to allow >> "Channel switching can cancel timers with priority<= >> Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr- >> developer.org/issues/show/10). Its sole purpose was to not use the >> primary device for recording low priority timers and leave the user >> with a black screen. Those days are long gone, and PrimaryLimit is >> obsolete and causing nothing but trouble. >> >> A recording shall *always* have priority over live viewing. > > I would be fine with that with respect to recordings, but this shouldn't be > generally true for cReceivers. What I'm hoping to get is the possiblity to > attach a cReceiver with a lower priority than live TV but without the > "cReceivers with negative priority do not count". > >> Since cReceivers can have priorities between -99 and 99, the priority >> for an unused device has been changed from -1 to -100. > > Udo Richter's patch basically turned "PrimaryLimit" into a configurable > "LiveTV priority". A "LiveTV priority"> 0 gains you cReceivers with a > priority less than live TV but still non-negative. To fix the "Transfer mode > receiver device has priority -1" problem, he introduced "volatile". > > Instead of a configurable "LiveTV priority", your approach uses the fixed > priority value 0 for LiveTV. The new idle priority of -100 opens the range for > cReceivers with negative priority. The problem is, that *any* negative > priority is still considered as "may be detached anytime", so there's still no > real "cReceiver with less priority than live TV". > > I suggest the following additional changes: > - instead of any negative priority, only priority -MAXPRIORITY gets the > special meaning of "may be detached anytime" > - the constructor of cReceiver should use default priority -MAXPRIORITY, so > not all plugins have to be updated to keep their previous behaviour > - use LIVEPRIORITY-1 as priority for cTransfer > > I can't however overlook the impact these modifications have. Me neither - and that's why I strongly oppose them ;-) What exactly is the use case for this, anyway? VDR has two purposes: "live view" and "recording". And the current priority scheme handles this pretty well IMO. Klaus From udo_richter at gmx.de Mon Feb 27 21:29:44 2012 From: udo_richter at gmx.de (Udo Richter) Date: Mon, 27 Feb 2012 21:29:44 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120227120750.M92341@linogate.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> Message-ID: <4F4BE7B8.20305@gmx.de> Am 27.02.2012 14:33, schrieb Frank Schmirler: > Instead of a configurable "LiveTV priority", your approach uses the fixed > priority value 0 for LiveTV. The new idle priority of -100 opens the range for > cReceivers with negative priority. The problem is, that *any* negative > priority is still considered as "may be detached anytime", so there's still no > real "cReceiver with less priority than live TV". Unfortunately not, because "may be detached anytime" is intentionally broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live TV freeze on recording start" bug. Extending this to priorities down to -99 doesn't change anything, and I currently see no real advantage in it: Why would someone want an unimportant stream with priority -10, and another with -20? VDR itself doesn't use them, so anything below 0 would be the same. Maybe, with some ugly hacks, Streamdev could emulate the old PrimaryLimit by adding some kind of priority offset to all streams, but as long as the rest is all broken, there's no real point in it. > - instead of any negative priority, only priority -MAXPRIORITY gets the > special meaning of "may be detached anytime" See above. Would require transfer mode to run on -99 too, otherwise would re-introduce live TV freeze. > - the constructor of cReceiver should use default priority -MAXPRIORITY, so > not all plugins have to be updated to keep their previous behaviour > - use LIVEPRIORITY-1 as priority for cTransfer Such -1 offset workarounds usually don't work, I would prefer not to have them. For example, one transfer device can still block another before detaching or via Streamdev. The only consistent solution is to give transfer mode the same priority as primary device live priority, either PrimaryLimit or 0. Cheers, Udo From vdr at schmirler.de Tue Feb 28 09:32:57 2012 From: vdr at schmirler.de (Frank Schmirler) Date: Tue, 28 Feb 2012 09:32:57 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4BB7E3.8020902@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> <4F4BB7E3.8020902@tvdr.de> Message-ID: <20120228074424.M10306@linogate.de> On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote > On 27.02.2012 14:33, Frank Schmirler wrote: > > I suggest the following additional changes: > > - instead of any negative priority, only priority -MAXPRIORITY gets the > > special meaning of "may be detached anytime" > > - the constructor of cReceiver should use default priority -MAXPRIORITY, so > > not all plugins have to be updated to keep their previous behaviour > > - use LIVEPRIORITY-1 as priority for cTransfer > > > > I can't however overlook the impact these modifications have. > > Me neither - and that's why I strongly oppose them ;-) Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's more obsolete stuff which can be thrown overboard. I feel it's time to start from scratch with the device selection code, keeping also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy). > What exactly is the use case for this, anyway? > > VDR has two purposes: "live view" and "recording". And the current > priority scheme handles this pretty well IMO. I guess in the meantime you could add "network streaming" to the list of purposes, too. There are a lots of people using streamdev out there for VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the VDR-to-VDR-Streaming part is challenging. The easy case is a headless server somewhere in the attic. No need to care about live TV. But some people's "server" is their main VDR in the living room and they usually want clients with a priority which is lower than local live TV. That's the use case. At the moment it all works pretty well in streamdev, but the whole thing is quite fragile with respect to API changes, time-consuming to maintain (e.g. an almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with VDR main thread for switching LiveTV). So it's not that streamdev depends on Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to get rid of some of the most ugly workarounds in the long run. The patch would have been a big step into that direction. Still, for a nice solution some more (but probably much less dramatic) modifications in the VDR core would be necessary. Regards, Frank From Klaus.Schmidinger at tvdr.de Tue Feb 28 10:11:48 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Tue, 28 Feb 2012 10:11:48 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120228074424.M10306@linogate.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> <4F4BB7E3.8020902@tvdr.de> <20120228074424.M10306@linogate.de> Message-ID: <4F4C9A54.70700@tvdr.de> On 28.02.2012 09:32, Frank Schmirler wrote: > On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote >> On 27.02.2012 14:33, Frank Schmirler wrote: >>> I suggest the following additional changes: >>> - instead of any negative priority, only priority -MAXPRIORITY gets the >>> special meaning of "may be detached anytime" >>> - the constructor of cReceiver should use default priority -MAXPRIORITY, so >>> not all plugins have to be updated to keep their previous behaviour >>> - use LIVEPRIORITY-1 as priority for cTransfer >>> >>> I can't however overlook the impact these modifications have. >> >> Me neither - and that's why I strongly oppose them ;-) > > Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's > more obsolete stuff which can be thrown overboard. I feel it's time to start > from scratch with the device selection code, keeping also the new challenges > in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy). That's surely something I'm going to lok at after version 2.0. >> What exactly is the use case for this, anyway? >> >> VDR has two purposes: "live view" and "recording". And the current >> priority scheme handles this pretty well IMO. > > I guess in the meantime you could add "network streaming" to the list of > purposes, too. There are a lots of people using streamdev out there for > VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the > VDR-to-VDR-Streaming part is challenging. The easy case is a headless server > somewhere in the attic. No need to care about live TV. But some people's > "server" is their main VDR in the living room and they usually want clients > with a priority which is lower than local live TV. That's the use case. > > At the moment it all works pretty well in streamdev, but the whole thing is > quite fragile with respect to API changes, time-consuming to maintain (e.g. an > almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with > VDR main thread for switching LiveTV). So it's not that streamdev depends on > Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to > get rid of some of the most ugly workarounds in the long run. The patch would > have been a big step into that direction. Still, for a nice solution some more > (but probably much less dramatic) modifications in the VDR core would be > necessary. I'll keep this in mind for "after version 2.0". Klaus From geronimo013 at gmx.de Tue Feb 28 11:24:50 2012 From: geronimo013 at gmx.de (Gero) Date: Tue, 28 Feb 2012 11:24:50 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4C9A54.70700@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <20120228074424.M10306@linogate.de> <4F4C9A54.70700@tvdr.de> Message-ID: <201202281124.51482.geronimo013@gmx.de> On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: > On 28.02.2012 09:32, Frank Schmirler wrote: > > On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote > >> On 27.02.2012 14:33, Frank Schmirler wrote: > >>> I can't however overlook the impact these modifications have. > >> > >> Me neither - and that's why I strongly oppose them ;-) > > > > Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Oups - this principle is good to start on any date. Best would be start using it today :) > > Maybe there's more obsolete stuff which can be thrown overboard. I feel > > it's time to start from scratch with the device selection code, keeping > > also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast > > thingy). This is only one aspect, that really needs to be redesigned / completely rewritten from scratch. > >> What exactly is the use case for this, anyway? > >> > >> VDR has two purposes: "live view" and "recording". And the current > >> priority scheme handles this pretty well IMO. > > > > I guess in the meantime you could add "network streaming" to the list of > > purposes, too. Sure! But talking about future, I think a good VDR-design would be a real client/server-design. Or lets say a modern VDR consists of a backend and a frontend, which may run on different machines, but may also be run on the same machine. So networking is evident and vital. If I understand things right, the decoding of streams is a frontend task, so it would be possible to abstract all datasources as input. That means, streams may come from dvb-card, network, files (any file, that might contain stream data) and of cause from plugins, that might generate streams from pictures or the like. So the backend (beside the recording/timer part) just uniforms the streams and makes them available via network. Frontend demuxes/decodes the streams (if necessary) and routes them to the real output devices. Taking into account, that networking can be broadcasted via UDP or streamed over single TCP-connection, it implies that different frontends might use the same stream from backend or each frontend might use a different stream. That also implies a complete different handling of setup and/or input/commands from frontend. If connection between backend- and frontend-vdr could be established over network, as well as using shared memory, the 2 parts could behave like one, if they were run on the same machine. With that design, vdr could handle all media, that make sense respect to looking and listening, so no more need for xbmc and other hacks ;) > > At the moment it all works pretty well in streamdev, ... As far as I understood available docs, streamdev is not able to handle recordings, so I would not say "all works" > I'll keep this in mind for "after version 2.0". Why so far? I think, many vdr-users crave for redesign and I'm sure, that some users are willing to participate. kind regards Gero From oldmanuk at gmail.com Tue Feb 28 11:34:03 2012 From: oldmanuk at gmail.com (Dominic Evans) Date: Tue, 28 Feb 2012 10:34:03 +0000 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <201202281124.51482.geronimo013@gmx.de> References: <4F40FF28.9040907@tvdr.de> <20120228074424.M10306@linogate.de> <4F4C9A54.70700@tvdr.de> <201202281124.51482.geronimo013@gmx.de> Message-ID: On 28/02/12 10:24, Gero wrote: >>> At the moment it all works pretty well in streamdev, ... > > As far as I understood available docs, streamdev is not able to handle > recordings, so I would not say "all works" Streamdev does work fine for recordings. However, I tend to use e-tobi's fuse filesystem to export the recordings dir over NFS From Eric.Valette at Free.fr Tue Feb 28 11:37:29 2012 From: Eric.Valette at Free.fr (Eric Valette) Date: Tue, 28 Feb 2012 11:37:29 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <201202281124.51482.geronimo013@gmx.de> References: <4F40FF28.9040907@tvdr.de> <20120228074424.M10306@linogate.de> <4F4C9A54.70700@tvdr.de> <201202281124.51482.geronimo013@gmx.de> Message-ID: <4F4CAE69.30403@Free.fr> On 02/28/2012 11:24 AM, Gero wrote: > I think, many vdr-users crave for redesign and I'm sure, that some users are > willing to participate. I drooped vdr in favor of tvheadend just for many of the design reason you mentioned: 1) Clear backend/front end design, 2) Better network protocol between the two, 3) code simplicity So look at the features and principles when redesigning. -- eric From geronimo013 at gmx.de Tue Feb 28 15:08:07 2012 From: geronimo013 at gmx.de (Gero) Date: Tue, 28 Feb 2012 15:08:07 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4CAE69.30403@Free.fr> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4CAE69.30403@Free.fr> Message-ID: <201202281508.07595.geronimo013@gmx.de> On Dienstag 28 Februar 2012, Eric Valette wrote: > On 02/28/2012 11:24 AM, Gero wrote: > > I think, many vdr-users crave for redesign and I'm sure, that some users > > are willing to participate. > > I drooped vdr in favor of tvheadend just for many of the design reason ... Whow - I'm impressed ;) Installation and configuration (!) - really sexy. ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, so I think it could be a good template for future vdr-development, but not serve as a vdr-replacement. At least I think, that OSD is a must have. Generation of channel-list - so fast and easy (just few mouseclicks) - I never could imagine such an ease of usage. I think it would be hard to beat that configuration in ease of use, flexibility and supported variants. With the webinterface its already ready for using android as remote :O challenging goal ;) kind regards Gero From Eric.Valette at Free.fr Tue Feb 28 15:17:21 2012 From: Eric.Valette at Free.fr (Eric Valette) Date: Tue, 28 Feb 2012 15:17:21 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <201202281508.07595.geronimo013@gmx.de> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4CAE69.30403@Free.fr> <201202281508.07595.geronimo013@gmx.de> Message-ID: <4F4CE1F1.80208@Free.fr> On 02/28/2012 03:08 PM, Gero wrote: > ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, > so I think it could be a good template for future vdr-development, but not > serve as a vdr-replacement. Well openelec distrib does have means to use tvheadend... > At least I think, that OSD is a must have. I prefer to have it in a front end that is able to manage a sophisticated remote correctly. --eric From syrius.ml at no-log.org Tue Feb 28 15:49:32 2012 From: syrius.ml at no-log.org (syrius.ml at no-log.org) Date: Tue, 28 Feb 2012 15:49:32 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4CE1F1.80208@Free.fr> (Eric Valette's message of "Tue, 28 Feb 2012 15:17:21 +0100") References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4CAE69.30403@Free.fr> <201202281508.07595.geronimo013@gmx.de> <4F4CE1F1.80208@Free.fr> Message-ID: <87k437kowi.87ipirkowi@87haybkowi.message.id> Eric Valette writes: > On 02/28/2012 03:08 PM, Gero wrote: > >> ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, >> so I think it could be a good template for future vdr-development, but not >> serve as a vdr-replacement. > > Well openelec distrib does have means to use tvheadend... > >> At least I think, that OSD is a must have. > > I prefer to have it in a front end that is able to manage a > sophisticated remote correctly. what do you use as a frontend ? xbmc, showtime ? is it possible to have multiple independant osd ? i like the xine and xinelibouput plugins way a lot, on my laptop no need to install a huge (and sometimes bloaty) media center, just have to run xine or vdr-sxfe and it comes with tv+osd+remote. -- From Eric.Valette at Free.fr Tue Feb 28 15:53:33 2012 From: Eric.Valette at Free.fr (Eric Valette) Date: Tue, 28 Feb 2012 15:53:33 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <87k437kowi.87ipirkowi@87haybkowi.message.id> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4CAE69.30403@Free.fr> <201202281508.07595.geronimo013@gmx.de> <4F4CE1F1.80208@Free.fr> <87k437kowi.87ipirkowi@87haybkowi.message.id> Message-ID: <4F4CEA6D.2020705@Free.fr> On 02/28/2012 03:49 PM, syrius.ml at no-log.org wrote: > Eric Valette writes: > >> On 02/28/2012 03:08 PM, Gero wrote: >> >>> ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, >>> so I think it could be a good template for future vdr-development, but not >>> serve as a vdr-replacement. >> >> Well openelec distrib does have means to use tvheadend... >> >>> At least I think, that OSD is a must have. >> >> I prefer to have it in a front end that is able to manage a >> sophisticated remote correctly. > > what do you use as a frontend ? xbmc, showtime ? I use XBMC in general, but may also use mplayer or vlc using the http streaming URL from the web GUI. > is it possible to have multiple independant osd ? You mean not on the same machine right? > i like the xine and xinelibouput plugins way a lot, on my laptop no > need to install a huge (and sometimes bloaty) media center, just have > to run xine or vdr-sxfe and it comes with tv+osd+remote. > The tvheadend HTSP streaming library is really thin. I guess integrating it is like integrating a streamdev client/vnsi client. -- eric From geronimo013 at gmx.de Tue Feb 28 16:40:07 2012 From: geronimo013 at gmx.de (Gero) Date: Tue, 28 Feb 2012 16:40:07 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <87k437kowi.87ipirkowi@87haybkowi.message.id> References: <4F40FF28.9040907@tvdr.de> <4F4CE1F1.80208@Free.fr> <87k437kowi.87ipirkowi@87haybkowi.message.id> Message-ID: <201202281640.07442.geronimo013@gmx.de> Hi, On Tuesday 28 February 2012 - 15:49:32, syrius.ml at no-log.org wrote: > i like the xine and xinelibouput plugins way a lot, on my laptop no > need to install a huge (and sometimes bloaty) media center, ... Agreed! That's why I like vdr-sxfe. On standard distributions one file to install and it works out of the box. Even a self-compiled frontend with fresh home-brewed xinelib is not a big thing and works without having to touch anything on the backend ... I can't do the same with xine, which is already somewhat bloated too. So, Yes - that's why I like my current VDR-setup :) kind regards Gero From vdr at schmirler.de Tue Feb 28 16:48:01 2012 From: vdr at schmirler.de (Frank Schmirler) Date: Tue, 28 Feb 2012 16:48:01 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4BE7B8.20305@gmx.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> <4F4BE7B8.20305@gmx.de> Message-ID: <20120228153601.M28085@linogate.de> On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote > Am 27.02.2012 14:33, schrieb Frank Schmirler: > > Instead of a configurable "LiveTV priority", your approach uses the fixed > > priority value 0 for LiveTV. The new idle priority of -100 opens the range for > > cReceivers with negative priority. The problem is, that *any* negative > > priority is still considered as "may be detached anytime", so there's still no > > real "cReceiver with less priority than live TV". > > Unfortunately not, because "may be detached anytime" is intentionally > broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live > TV freeze on recording start" bug. Ah, I see. The "Receiving(true)" in cDvbDevice::ProvidesChannel which came in with 1.3.8. That was the missing piece. Thanks for pointing me there. > > - the constructor of cReceiver should use default priority -MAXPRIORITY, so > > not all plugins have to be updated to keep their previous behaviour > > - use LIVEPRIORITY-1 as priority for cTransfer > > Such -1 offset workarounds usually don't work, I would prefer not to > have them. For example, one transfer device can still block another > before detaching or via Streamdev. The only consistent solution is to > give transfer mode the same priority as primary device live priority, > either PrimaryLimit or 0. That was an attempt to get a solution without "volatile". A "don't ever use priority "PrimaryLimit" (or 0) elsewhere" would have been better than nothing. Regards, Frank From user.vdr at gmail.com Tue Feb 28 17:46:59 2012 From: user.vdr at gmail.com (VDR User) Date: Tue, 28 Feb 2012 08:46:59 -0800 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120228153601.M28085@linogate.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> <4F4BE7B8.20305@gmx.de> <20120228153601.M28085@linogate.de> Message-ID: 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? From anssi.hannula at iki.fi Tue Feb 28 20:12:54 2012 From: anssi.hannula at iki.fi (Anssi Hannula) Date: Tue, 28 Feb 2012 21:12:54 +0200 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <201202281124.51482.geronimo013@gmx.de> References: <4F40FF28.9040907@tvdr.de> <20120228074424.M10306@linogate.de> <4F4C9A54.70700@tvdr.de> <201202281124.51482.geronimo013@gmx.de> Message-ID: <4F4D2736.5070909@iki.fi> 28.02.2012 12:24, Gero kirjoitti: > On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: >> On 28.02.2012 09:32, Frank Schmirler wrote: >>> On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote >>>> What exactly is the use case for this, anyway? >>>> >>>> VDR has two purposes: "live view" and "recording". And the current >>>> priority scheme handles this pretty well IMO. >>> >>> I guess in the meantime you could add "network streaming" to the list of >>> purposes, too. > > Sure! > > But talking about future, I think a good VDR-design would be a real > client/server-design. Or lets say a modern VDR consists of a backend and a > frontend, which may run on different machines, but may also be run on the same > machine. > > So networking is evident and vital. > > If I understand things right, the decoding of streams is a frontend task, so > it would be possible to abstract all datasources as input. That means, streams > may come from dvb-card, network, files (any file, that might contain stream > data) and of cause from plugins, that might generate streams from pictures or > the like. > > So the backend (beside the recording/timer part) just uniforms the streams and > makes them available via network. > Frontend demuxes/decodes the streams (if necessary) and routes them to the > real output devices. > > Taking into account, that networking can be broadcasted via UDP or streamed > over single TCP-connection, it implies that different frontends might use the > same stream from backend or each frontend might use a different stream. That > also implies a complete different handling of setup and/or input/commands from > frontend. > > If connection between backend- and frontend-vdr could be established over > network, as well as using shared memory, the 2 parts could behave like one, if > they were run on the same machine. > > With that design, vdr could handle all media, that make sense respect to > looking and listening, so no more need for xbmc and other hacks ;) I'd very much like something that would result in a better-behaving server-client VDR system, i.e. so that clients just see the recordings,timers,channels,epg just like they are on the server, instead of duplication and the mess when they get out-of-sync. I guess Klaus wants to keep VDR working as a monolithic entity like it currently is, though, but maybe a "thin-client" (VDR instance with viewing+menu only, with timers/recordings/channels transmitted from the main VDR instance) support could be added as an optional feature. (and probably a similar "headless" option to have VDR without current-channel and GUI and stuff like that, for the backend) >>> At the moment it all works pretty well in streamdev, ... > > As far as I understood available docs, streamdev is not able to handle > recordings, so I would not say "all works" > > >> I'll keep this in mind for "after version 2.0". > > Why so far? Because 1.6.0 was released a long time ago, and we want a new stable version soon? :) > I think, many vdr-users crave for redesign and I'm sure, that some users are > willing to participate. -- Anssi Hannula From geronimo013 at gmx.de Wed Feb 29 05:38:06 2012 From: geronimo013 at gmx.de (Gero) Date: Wed, 29 Feb 2012 05:38:06 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4D2736.5070909@iki.fi> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> Message-ID: <201202290538.06898.geronimo013@gmx.de> On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote: > 28.02.2012 12:24, Gero kirjoitti: > > On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: > >> > >> I'll keep this in mind for "after version 2.0". > > > > Why so far? > > Because 1.6.0 was released a long time ago, and we want a new stable > version soon? :) Sure! - But next stable version would be 1.8 - wouldn't it? So why no start redeeming pledges with 1.9? I believe any day would be a good point to start :) ...or is it preferable see people move to real client/server systems and make them fit their every day requirements? Networking has become familiar to lots of people without any IT background - nowadays lot of homes have a fritzbox with Wlan and a netbook with wlan too. Fritzbox has startet to integrate android phones with wlan - so that all is quite natural for non IT people yet. So integrating a headless vdr into existing network is no more restricted to nerds (or at least every male teenager is a nerd). kind regards Gero From lamikr at pilppa.org Wed Feb 29 06:58:21 2012 From: lamikr at pilppa.org (Mika Laitio) Date: Wed, 29 Feb 2012 07:58:21 +0200 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4D2736.5070909@iki.fi> References: <4F40FF28.9040907@tvdr.de> <20120228074424.M10306@linogate.de> <4F4C9A54.70700@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> Message-ID: <4F4DBE7D.9040703@pilppa.org> > Because 1.6.0 was released a long time ago, and we want a new stable > version soon? :) I agree, 1.7 devel versions have many nice improvements like the support for hvr-4000's multiple frontends in same adapter. Even thought most active users in this mail list very likely uses developer versions, there are probably lot of users still using stable 1.6.0 and would also prefer to run the Next stable once released. But I hope that the mentioned real client-server redesign that could handle many simultaneous clients watching different streams would be then the main goals next version after that. Current way of doing it at least with xineliboutput is just too complex and error prone. Mika From steffenbpunkt at googlemail.com Wed Feb 29 08:17:11 2012 From: steffenbpunkt at googlemail.com (Steffen Barszus) Date: Wed, 29 Feb 2012 08:17:11 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <201202290538.06898.geronimo013@gmx.de> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> <201202290538.06898.geronimo013@gmx.de> Message-ID: <20120229081711.0b8bd4dc@grobi> On Wed, 29 Feb 2012 05:38:06 +0100 Gero wrote: > On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote: > > 28.02.2012 12:24, Gero kirjoitti: > > > On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: > > >> > > >> I'll keep this in mind for "after version 2.0". > > > > > > Why so far? > > > > Because 1.6.0 was released a long time ago, and we want a new stable > > version soon? :) > > Sure! - But next stable version would be 1.8 - wouldn't it? Next stable will be 2.0 AFAIK ... From vdr at pickles.me.uk Wed Feb 29 08:24:03 2012 From: vdr at pickles.me.uk (Dave) Date: Wed, 29 Feb 2012 07:24:03 +0000 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4DBE7D.9040703@pilppa.org> References: <4F40FF28.9040907@tvdr.de> <4F4D2736.5070909@iki.fi> <4F4DBE7D.9040703@pilppa.org> Message-ID: <201202290724.03893.vdr@pickles.me.uk> On Wednesday 29 February 2012 05:58:21 Mika Laitio wrote: > > Because 1.6.0 was released a long time ago, and we want a new stable > > version soon? :) > > I agree, 1.7 devel versions have many nice improvements like the support > for hvr-4000's multiple frontends in same adapter. > Even thought most active users in this mail list very likely uses > developer versions, there are probably lot of users still using stable > 1.6.0 and would also prefer to run the Next stable once released. And the Linux distributions will generally only package 'stable' versions. -- Dave From Klaus.Schmidinger at tvdr.de Wed Feb 29 09:20:27 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 09:20:27 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120229081711.0b8bd4dc@grobi> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> <201202290538.06898.geronimo013@gmx.de> <20120229081711.0b8bd4dc@grobi> Message-ID: <4F4DDFCB.5040801@tvdr.de> On 29.02.2012 08:17, Steffen Barszus wrote: > On Wed, 29 Feb 2012 05:38:06 +0100 > Gero wrote: > >> On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote: >>> 28.02.2012 12:24, Gero kirjoitti: >>>> On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote: >>>>> >>>>> I'll keep this in mind for "after version 2.0". >>>> >>>> Why so far? >>> >>> Because 1.6.0 was released a long time ago, and we want a new stable >>> version soon? :) >> >> Sure! - But next stable version would be 1.8 - wouldn't it? > > > Next stable will be 2.0 AFAIK ... 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" ;-). I'll see to make "client/server" a priority after that. Klaus From listaccount at e-tobi.net Wed Feb 29 09:30:19 2012 From: listaccount at e-tobi.net (Tobi) Date: Wed, 29 Feb 2012 09:30:19 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <201202290724.03893.vdr@pickles.me.uk> References: <4F40FF28.9040907@tvdr.de> <4F4D2736.5070909@iki.fi> <4F4DBE7D.9040703@pilppa.org> <201202290724.03893.vdr@pickles.me.uk> Message-ID: <4F4DE21B.7030102@e-tobi.net> On 29.02.2012 08:24, Dave wrote: > And the Linux distributions will generally only package 'stable' versions. For Debian I'm already packaging 1.7.x, because 1.6 became pretty much useless nowadays. Wheezy is going to freeze in June and I hope that VDR becomes stable until then. Tobias From hma at iki.fi Wed Feb 29 12:13:17 2012 From: hma at iki.fi (Heikki Manninen) Date: Wed, 29 Feb 2012 13:13:17 +0200 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording Message-ID: I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message. This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? -- Heikki M From Klaus.Schmidinger at tvdr.de Wed Feb 29 12:18:00 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 12:18:00 +0100 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: References: Message-ID: <4F4E0968.5020203@tvdr.de> On 29.02.2012 12:13, Heikki Manninen wrote: > I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message. > > This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. > > Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? Wouldn't it be better to fix the actual problem and prevent the CAM from "disappearing"? Greetings Klaus From hma at iki.fi Wed Feb 29 12:22:28 2012 From: hma at iki.fi (Heikki Manninen) Date: Wed, 29 Feb 2012 13:22:28 +0200 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: <4F4E0968.5020203@tvdr.de> References: <4F4E0968.5020203@tvdr.de> Message-ID: On 29.2.2012, at 13.18, Klaus Schmidinger wrote: > On 29.02.2012 12:13, Heikki Manninen wrote: >> I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message. >> >> This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. >> >> Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? > > Wouldn't it be better to fix the actual problem and prevent > the CAM from "disappearing"? Of course as always. But we don't live in a perfect world ;) I'm not too happy about the idea to start testing different DVB card/CI combos on my own expense to find one that works. Especially nowadays when finding non-USB/Linux supported tuners for cable reception is next to impossible. -- Heikki M From Klaus.Schmidinger at tvdr.de Wed Feb 29 12:28:01 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 12:28:01 +0100 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: References: <4F4E0968.5020203@tvdr.de> Message-ID: <4F4E0BC1.2010503@tvdr.de> On 29.02.2012 12:22, Heikki Manninen wrote: > On 29.2.2012, at 13.18, Klaus Schmidinger wrote: > >> On 29.02.2012 12:13, Heikki Manninen wrote: >>> I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message. >>> >>> This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. >>> >>> Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? >> >> Wouldn't it be better to fix the actual problem and prevent >> the CAM from "disappearing"? > > Of course as always. But we don't live in a perfect world ;) > > I'm not too happy about the idea to start testing different DVB card/CI combos on my own expense to find one that works. Especially nowadays when finding non-USB/Linux supported tuners for cable reception is next to impossible. I wasn't suggesting that you get some new hardware. What I meant was to fix the driver, which I would assume is causing the problems. Of course, there might as well be a problem in VDR's own CAM handling code. However, I've looked through that several times and didn't find anything that looks fishy. But if somebody can point out a bug in there, I'd be happy to accept a fix. Klaus From johannes at truschnigg.info Wed Feb 29 12:29:53 2012 From: johannes at truschnigg.info (Johannes Truschnigg) Date: Wed, 29 Feb 2012 12:29:53 +0100 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: References: Message-ID: <20120229112953.GA13153@vault.local> Hi list, my CAM drops out every once in a while, too. It's rather annoying, but I don't know how to fix the problem, so I decided to work around it. Whenever my CAM fails, the kernel/DVB driver seems to notice, and the debug ringbuffer contents reflect this. An error message like "dvb_ca adapter 0: DVB CAM link initialisation failed :(" also makes its way into syslog that way (because rsyslog retrieves messages from /dev/kmsg). I wrote a simple Python program that monitors a given logfile for the appearance of this message, and then tries to trigger the appropriate SVDRP HITK sequence via a plain and simple socket connection. So far, it works quite well (no manual CAM resets had to be performed by my parents for the last four weeks this way). If anyone happens to know a more reliable way to externally trigger a CAM reset via VDR/SVDRP, please let me know - right now, everything depends on the unchanged ordering of main menu entries, which is kind of annoying. @OP: If your drivers produce a similar message to mine when your CAM flakes out, I could provide my (inelegant, but tiny and apparently working) script to you. Let me know if you want to try it :) -- with best regards: - Johannes Truschnigg ( johannes at truschnigg.info ) www: http://johannes.truschnigg.info/ phone: +43 650 2 133337 xmpp: johannes at truschnigg.info Please do not bother me with HTML-eMail or attachments. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From Klaus.Schmidinger at tvdr.de Wed Feb 29 12:40:36 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 12:40:36 +0100 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: <20120229112953.GA13153@vault.local> References: <20120229112953.GA13153@vault.local> Message-ID: <4F4E0EB4.9060105@tvdr.de> On 29.02.2012 12:29, Johannes Truschnigg wrote: > Hi list, > > my CAM drops out every once in a while, too. It's rather annoying, but I don't > know how to fix the problem, so I decided to work around it. Whenever my CAM > fails, the kernel/DVB driver seems to notice, and the debug ringbuffer > contents reflect this. An error message like > > "dvb_ca adapter 0: DVB CAM link initialisation failed :(" > > also makes its way into syslog that way (because rsyslog retrieves messages > from /dev/kmsg). > > I wrote a simple Python program that monitors a given logfile for the > appearance of this message, and then tries to trigger the appropriate SVDRP > HITK sequence via a plain and simple socket connection. So far, it works quite > well (no manual CAM resets had to be performed by my parents for the last four > weeks this way). If anyone happens to know a more reliable way to externally > trigger a CAM reset via VDR/SVDRP, please let me know - right now, everything > depends on the unchanged ordering of main menu entries, which is kind of > annoying. I also see this message in my log file from time to time. So this means that the driver apparently recognizes a CAM failure. Now the question is: why doesn't the driver report this fact to the application (VDR)? If VDR would receive this information, it could automatically do a reset. Klaus From kende at kende.fi Wed Feb 29 12:44:53 2012 From: kende at kende.fi (Kende) Date: Wed, 29 Feb 2012 13:44:53 +0200 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: <4F4E0968.5020203@tvdr.de> References: <4F4E0968.5020203@tvdr.de> Message-ID: <20120229114452.GA10161@kende.fi> On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote: > On 29.02.2012 12:13, Heikki Manninen wrote: > >I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message. > > > >This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. > > > >Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? > > Wouldn't it be better to fix the actual problem and prevent > the CAM from "disappearing"? Hola, For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case: --- dvbci.c 2007-01-04 14:49:10.000000000 +0200 +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 @@ -62,8 +62,10 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) { if (Buffer && Length > 0) { - if (safe_write(fd, Buffer, Length) != Length) + if (safe_write(fd, Buffer, Length) != Length) { esyslog("ERROR: can't write to CI adapter on device %d: %m", device->De viceNumber()); + Reset(device->DeviceNumber()); + } } } -- Kende From hma at iki.fi Wed Feb 29 12:49:17 2012 From: hma at iki.fi (Heikki Manninen) Date: Wed, 29 Feb 2012 13:49:17 +0200 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: <20120229112953.GA13153@vault.local> References: <20120229112953.GA13153@vault.local> Message-ID: On 29.2.2012, at 13.29, Johannes Truschnigg wrote: > Hi list, > > my CAM drops out every once in a while, too. It's rather annoying, but I don't > know how to fix the problem, so I decided to work around it. Whenever my CAM > fails, the kernel/DVB driver seems to notice, and the debug ringbuffer > contents reflect this. An error message like > > "dvb_ca adapter 0: DVB CAM link initialisation failed :(" Ok, that seems to be case for me as well: [ 28.712154] dvb_ca adapter 0: DVB CAM detected and initialised successfully [229405.488050] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! [229405.488063] dvb_ca adapter 0: DVB CAM link initialisation failed :( [344470.637483] budget_av: cam inserted A [344471.426622] dvb_ca adapter 0: DVB CAM detected and initialised successfully [352268.360055] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! [352268.360068] dvb_ca adapter 0: DVB CAM link initialisation failed :( Some scripting to try then.. -- Heikki M From kari at kniivila.com Wed Feb 29 14:52:16 2012 From: kari at kniivila.com (Kartsa) Date: Wed, 29 Feb 2012 15:52:16 +0200 Subject: [vdr] DVB subtitke colors vary Message-ID: <4F4E2D90.2080500@kniivila.com> Hi Lately I have been noticing that the fg color of the DVB subtitles changes irregularly between white, grey and black. If there is more than one line the lines may have different colors but the whole line is the same color. This is seen in Finnish YLE channels. Is there some setting for this? I was in the impression that color mapping should come with the subtitles but it would seem strange if they would change the color irregularly. Is this a broadcast issue or a VDR issue? I'm running Ubuntu 10.04.4 LTS. I've installed all from yavdr-stable repository and these are the installed components vdr (1.7.20/1.7.20) vompserver (0.3.1-3) femon (1.7.10) osdteletext (0.9.1) epgsearch (1.0.0) burn (0.2.0-beta7) pvrinput (2011-08-18) wirbelscan (0.0.7-pre01) vdrrip (0.3.0) conflictcheckonly (0.0.1) quickepgsearch (0.0.1) undelete (0.0.6) streamdev-server (0.5.1-git) webvideo (0.4.4) xineliboutput (1.0.90-cvs) dvd (0.3.6-b03) epgsearchonly (0.0.1) skinsoppalusikka (1.7.2) ttxtsubs (0.2.3) Player is vdr-sxfe 1.0.90-cvs also from yavdr repo. \\Karsta From Klaus.Schmidinger at tvdr.de Wed Feb 29 14:55:59 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 14:55:59 +0100 Subject: [vdr] DVB subtitke colors vary In-Reply-To: <4F4E2D90.2080500@kniivila.com> References: <4F4E2D90.2080500@kniivila.com> Message-ID: <4F4E2E6F.5000809@tvdr.de> On 29.02.2012 14:52, Kartsa wrote: > Hi > > Lately I have been noticing that the fg color of the DVB subtitles changes irregularly between white, grey and black. If there is more than one line the lines may have different colors but the whole line is the same color. This is seen in Finnish YLE channels. Is there some setting for this? I was > in the impression that color mapping should come with the subtitles but it would seem strange if they would change the color irregularly. > > Is this a broadcast issue or a VDR issue? > ... It's a known issue in VDR and will be fixed in version 1.7.25. Klaus From jarkkoka at takaisin.fi Wed Feb 29 15:16:34 2012 From: jarkkoka at takaisin.fi (Jarkko Kangas) Date: Wed, 29 Feb 2012 16:16:34 +0200 Subject: [vdr] DVB subtitke colors vary In-Reply-To: <4F4E2D90.2080500@kniivila.com> References: <4F4E2D90.2080500@kniivila.com> Message-ID: <4F4E3342.4040009@takaisin.fi> Hi There is an issue in the VDR's subtitle antialiasing. Finnish www.linuxtv.fi site can be found the patch, which fixed the problem in my VDR configuration. Link to patch -> http://www.linuxtv.fi/viewtopic.php?f=12&t=4618&start=30 Jarkko On 29.2.2012 15:52, Kartsa wrote: > Hi > > Lately I have been noticing that the fg color of the DVB subtitles > changes irregularly between white, grey and black. If there is more than > one line the lines may have different colors but the whole line is the > same color. This is seen in Finnish YLE channels. Is there some setting > for this? I was in the impression that color mapping should come with > the subtitles but it would seem strange if they would change the color > irregularly. > > Is this a broadcast issue or a VDR issue? > > I'm running Ubuntu 10.04.4 LTS. > > I've installed all from yavdr-stable repository and these are the > installed components > vdr (1.7.20/1.7.20) > vompserver (0.3.1-3) > femon (1.7.10) > osdteletext (0.9.1) > epgsearch (1.0.0) > burn (0.2.0-beta7) > pvrinput (2011-08-18) > wirbelscan (0.0.7-pre01) > vdrrip (0.3.0) > conflictcheckonly (0.0.1) > quickepgsearch (0.0.1) > undelete (0.0.6) > streamdev-server (0.5.1-git) > webvideo (0.4.4) > xineliboutput (1.0.90-cvs) > dvd (0.3.6-b03) > epgsearchonly (0.0.1) > skinsoppalusikka (1.7.2) > ttxtsubs (0.2.3) > > Player is vdr-sxfe 1.0.90-cvs also from yavdr repo. > > \\Karsta > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > From Klaus.Schmidinger at tvdr.de Wed Feb 29 16:17:07 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 16:17:07 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120228153601.M28085@linogate.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> <4F4BE7B8.20305@gmx.de> <20120228153601.M28085@linogate.de> Message-ID: <4F4E4173.5080809@tvdr.de> On 28.02.2012 16:48, Frank Schmirler wrote: > On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote >> Am 27.02.2012 14:33, schrieb Frank Schmirler: >>> Instead of a configurable "LiveTV priority", your approach uses the fixed >>> priority value 0 for LiveTV. The new idle priority of -100 opens the range for >>> cReceivers with negative priority. The problem is, that *any* negative >>> priority is still considered as "may be detached anytime", so there's still no >>> real "cReceiver with less priority than live TV". >> >> Unfortunately not, because "may be detached anytime" is intentionally >> broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live >> TV freeze on recording start" bug. > > Ah, I see. The "Receiving(true)" in cDvbDevice::ProvidesChannel which came in > with 1.3.8. That was the missing piece. Thanks for pointing me there. > >>> - the constructor of cReceiver should use default priority -MAXPRIORITY, so >>> not all plugins have to be updated to keep their previous behaviour >>> - use LIVEPRIORITY-1 as priority for cTransfer >> >> Such -1 offset workarounds usually don't work, I would prefer not to >> have them. For example, one transfer device can still block another >> before detaching or via Streamdev. The only consistent solution is to >> give transfer mode the same priority as primary device live priority, >> either PrimaryLimit or 0. > > That was an attempt to get a solution without "volatile". A "don't ever use > priority "PrimaryLimit" (or 0) elsewhere" would have been better than nothing. Even though VDR itself doesn't have the necessity for "remote receivers" (yet), I see the problem for streamdev. I have therefore reconsidered this matter and will make the following changes for the next developer version: - Revised priority handling to allow receivers with a priority that is lower than that of live viewing (with suggestions from Frank Schmirler): + An idle device (one that is not used for live viewing and has no receiver attached to it) now has priority IDLEPRIORITY (-100). + An unused CAM slot now has priority IDLEPRIORITY. + The default priority of a cReceiver is now MINPRIORITY (-99). + A device that is used only for live viewing (no matter whether it's in Transfer Mode or real live mode) now has priority TRANSFERPRIORITY (-1). + The function cDevice::Receiving() now returns true if there is any receiver attached to the device. Its boolean parameter has no meaning any more. + The default value for the Priority parameter of the function cDevice::ProvidesChannel() has been changed to IDLEPRIORITY. When searching for a device for live viewing, VDR uses priority 0 for the search (thus avoiding any devices that are serving actual timer recordings), and - if going into Transfer Mode - gives the cReceiver a priority of -1. That way the next search for a live device will be able to use the one that is currently serving the Transfer Mode, because the search has a higher priority (this is pretty much the same as it was before). Now a "remote transfer mode" (which I assume is what streamdev and the like implement) can use a "search priority" of, say, -10, and a transfer priority of -11. That way the remote mechanism will also be able to reuse devices, just like local Transfer Mode. And local live mode can override remotely used devices due to its higher priority. I'm currently testing these changes in my own production VDR (local live and transfer mode only) and will release them in version 1.7.25 shortly. Let me know then if this works for you. Klaus From Klaus.Schmidinger at tvdr.de Wed Feb 29 16:39:09 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 16:39:09 +0100 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: <20120229114452.GA10161@kende.fi> References: <4F4E0968.5020203@tvdr.de> <20120229114452.GA10161@kende.fi> Message-ID: <4F4E469D.3080205@tvdr.de> On 29.02.2012 12:44, Kende wrote: > On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote: >> On 29.02.2012 12:13, Heikki Manninen wrote: >>> I have a number of different Conax CAM modules from different manufacturers and all of them disappear from VDR after a couple of days running. Hitting CAM reset on the CI menu will bring it back "online". Naturally all Conax channel recordings will fail silently as a result of this until the CAM has been brought back up. Switching to an encrypted channel just gives the standard "channel not available" message. >>> >>> This happens (for me) with Satelco DVB-C card with Satelco CI. From what I understand, this seems to be a common problem though I'm not sure whether it is limited to Satelco devices only. >>> >>> Would it be possible to force CAM reset on all CI slots when VDR is trying to start recording non-FTA channel? >> >> Wouldn't it be better to fix the actual problem and prevent >> the CAM from "disappearing"? > > Hola, > > For me this seems to be driver issue, not VDRs fault. CI poll ioctl write seems to fail sometimes with my KNC One (saa7146) budget cards . Following patch seems to help in my case: > > --- dvbci.c 2007-01-04 14:49:10.000000000 +0200 > +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 > @@ -62,8 +62,10 @@ > void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) > { > if (Buffer&& Length> 0) { > - if (safe_write(fd, Buffer, Length) != Length) > + if (safe_write(fd, Buffer, Length) != Length) { > esyslog("ERROR: can't write to CI adapter on device %d: %m", device->De > viceNumber()); > + Reset(device->DeviceNumber()); > + } > } > } I tried this, but I'm afraid it doesn't help. The Reset() call was never triggered, even though my CAM went from normal operation to the "CAM ready" state, and not even an explicit reset via the Setup/CAM menu brought it to life again. Only after reloading the driver and restarting VDR did it work again. My theory is that switching channels is what's causing the problem. When I trigger an EPG scan, the problem typically occurs after a while. Maybe it's caused by tuning to channels that are no longer available, so the frontend times out. However, there's no reason why a frontend timeout should lead to a CAM freeze... Klaus From manuel.reimer at gmx.de Wed Feb 29 16:48:33 2012 From: manuel.reimer at gmx.de (Manuel Reimer) Date: Wed, 29 Feb 2012 16:48:33 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4DDFCB.5040801@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> <201202290538.06898.geronimo013@gmx.de> <20120229081711.0b8bd4dc@grobi> <4F4DDFCB.5040801@tvdr.de> Message-ID: <4F4E48D1.8070401@gmx.de> Klaus Schmidinger 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" ;-). > > I'll see to make "client/server" a priority after that. What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, like the other "built-in" plugins. Yours Manuel From anssi.hannula at iki.fi Wed Feb 29 16:54:18 2012 From: anssi.hannula at iki.fi (Anssi Hannula) Date: Wed, 29 Feb 2012 17:54:18 +0200 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4DE21B.7030102@e-tobi.net> References: <4F40FF28.9040907@tvdr.de> <4F4D2736.5070909@iki.fi> <4F4DBE7D.9040703@pilppa.org> <201202290724.03893.vdr@pickles.me.uk> <4F4DE21B.7030102@e-tobi.net> Message-ID: <4F4E4A2A.8020507@iki.fi> 29.02.2012 10:30, Tobi kirjoitti: > On 29.02.2012 08:24, Dave wrote: > >> And the Linux distributions will generally only package 'stable' versions. > > For Debian I'm already packaging 1.7.x, because 1.6 became pretty much > useless nowadays. Wheezy is going to freeze in June and I hope that VDR > becomes stable until then. For Mageia (upcoming mga2) I just recently updated the packages to 1.7.x, and Fedora seems to also be shipping 1.7.x already. -- Anssi Hannula From Klaus.Schmidinger at tvdr.de Wed Feb 29 16:57:23 2012 From: Klaus.Schmidinger at tvdr.de (Klaus Schmidinger) Date: Wed, 29 Feb 2012 16:57:23 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4E48D1.8070401@gmx.de> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> <201202290538.06898.geronimo013@gmx.de> <20120229081711.0b8bd4dc@grobi> <4F4DDFCB.5040801@tvdr.de> <4F4E48D1.8070401@gmx.de> Message-ID: <4F4E4AE3.6000604@tvdr.de> On 29.02.2012 16:48, Manuel Reimer wrote: > Klaus Schmidinger 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" ;-). >> >> I'll see to make "client/server" a priority after that. > > What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR, > like the other "built-in" plugins. I'll cross that bridge when I get there ;-) Klaus From kari at kniivila.com Wed Feb 29 17:34:56 2012 From: kari at kniivila.com (Kartsa) Date: Wed, 29 Feb 2012 18:34:56 +0200 Subject: [vdr] DVB subtitke colors vary In-Reply-To: <4F4E3342.4040009@takaisin.fi> References: <4F4E2D90.2080500@kniivila.com> <4F4E3342.4040009@takaisin.fi> Message-ID: <4F4E53B0.8040705@kniivila.com> Ok, thanks for the info. But I have to wait for the fix from Klaus since I am notcompiling anything my self. All must be in repos :) I have a couple of friends whose vdr box I maintain so I want to keep all as simple as possible. \\Kartsa 29.02.2012 16:16, Jarkko Kangas kirjoitti: > Hi > > There is an issue in the VDR's subtitle antialiasing. Finnish > www.linuxtv.fi site can be found the patch, which fixed the problem in > my VDR configuration. > > Link to patch -> http://www.linuxtv.fi/viewtopic.php?f=12&t=4618&start=30 > > Jarkko > > On 29.2.2012 15:52, Kartsa wrote: >> Hi >> >> Lately I have been noticing that the fg color of the DVB subtitles >> changes irregularly between white, grey and black. If there is more than >> one line the lines may have different colors but the whole line is the >> same color. This is seen in Finnish YLE channels. Is there some setting >> for this? I was in the impression that color mapping should come with >> the subtitles but it would seem strange if they would change the color >> irregularly. >> >> Is this a broadcast issue or a VDR issue? >> >> I'm running Ubuntu 10.04.4 LTS. >> >> I've installed all from yavdr-stable repository and these are the >> installed components >> vdr (1.7.20/1.7.20) >> vompserver (0.3.1-3) >> femon (1.7.10) >> osdteletext (0.9.1) >> epgsearch (1.0.0) >> burn (0.2.0-beta7) >> pvrinput (2011-08-18) >> wirbelscan (0.0.7-pre01) >> vdrrip (0.3.0) >> conflictcheckonly (0.0.1) >> quickepgsearch (0.0.1) >> undelete (0.0.6) >> streamdev-server (0.5.1-git) >> webvideo (0.4.4) >> xineliboutput (1.0.90-cvs) >> dvd (0.3.6-b03) >> epgsearchonly (0.0.1) >> skinsoppalusikka (1.7.2) >> ttxtsubs (0.2.3) >> >> Player is vdr-sxfe 1.0.90-cvs also from yavdr repo. >> >> \\Karsta >> >> _______________________________________________ >> vdr mailing list >> vdr at linuxtv.org >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> >> > > _______________________________________________ > vdr mailing list > vdr at linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > From vdr at schmirler.de Wed Feb 29 17:47:12 2012 From: vdr at schmirler.de (Frank Schmirler) Date: Wed, 29 Feb 2012 17:47:12 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4E4173.5080809@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> <4F4BE7B8.20305@gmx.de> <20120228153601.M28085@linogate.de> <4F4E4173.5080809@tvdr.de> Message-ID: <20120229164402.M9804@linogate.de> On Wed, 29 Feb 2012 16:17:07 +0100, Klaus Schmidinger wrote > Even though VDR itself doesn't have the necessity for "remote receivers" > (yet), I see the problem for streamdev. I have therefore reconsidered > this matter and will make the following changes for the next > developer version: > > - Revised priority handling to allow receivers with a priority that > is lower than that of live viewing (with suggestions from Frank > Schmirler): + An idle device (one that is not used for live > viewing and has no receiver attached to it) now has priority > IDLEPRIORITY (-100). + An unused CAM slot now has priority IDLEPRIORITY. > + The default priority of a cReceiver is now MINPRIORITY (-99). > + A device that is used only for live viewing (no matter whether > it's in Transfer Mode or real live mode) now has priority > TRANSFERPRIORITY (-1). + The function cDevice::Receiving() now > returns true if there is any receiver attached to the device. > Its boolean parameter has no meaning any more. + The default value > for the Priority parameter of the function cDevice::ProvidesChannel() > has been changed to IDLEPRIORITY. > > When searching for a device for live viewing, VDR uses priority 0 for > the search (thus avoiding any devices that are serving actual timer > recordings), and - if going into Transfer Mode - gives the cReceiver > a priority of -1. That way the next search for a live device will be > able to use the one that is currently serving the Transfer Mode, > because the search has a higher priority (this is pretty much the > same as it was before). > > Now a "remote transfer mode" (which I assume is what streamdev and > the like implement) can use a "search priority" of, say, -10, and a > transfer priority of -11. That way the remote mechanism will also be > able to reuse devices, just like local Transfer Mode. And local live > mode can override remotely used devices due to its higher priority. > > I'm currently testing these changes in my own production VDR (local > live and transfer mode only) and will release them in version 1.7.25 > shortly. Let me know then if this works for you. Wow - this is good news. Thanks for reconsidering! Frank From h at realh.co.uk Wed Feb 29 17:50:27 2012 From: h at realh.co.uk (Tony Houghton) Date: Wed, 29 Feb 2012 16:50:27 +0000 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4E48D1.8070401@gmx.de> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> <201202290538.06898.geronimo013@gmx.de> <20120229081711.0b8bd4dc@grobi> <4F4DDFCB.5040801@tvdr.de> <4F4E48D1.8070401@gmx.de> Message-ID: <20120229165027.6a805404@junior> On Wed, 29 Feb 2012 16:48:33 +0100 Manuel Reimer wrote: > Klaus Schmidinger 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" ;-). > > > > I'll see to make "client/server" a priority after that. > > What does this mean? Do you plan built-in networking support or do > you plan to improve streamdev? IMHO it is a big task to make really > good networking support. Keeping this code separate (means: A plugin) > isn't a that bad idea, I think. Of course, this plugin could be > delivered directly with VDR, like the other "built-in" plugins. I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. From linuxtv at nzbaxters.com Wed Feb 29 17:52:10 2012 From: linuxtv at nzbaxters.com (Simon Baxter) Date: Wed, 29 Feb 2012 08:52:10 -0800 Subject: [vdr] Patch suggestion: Force CAM reset before upcoming recording In-Reply-To: <4F4E469D.3080205@tvdr.de> References: <4F4E0968.5020203@tvdr.de> <20120229114452.GA10161@kende.fi> <4F4E469D.3080205@tvdr.de> Message-ID: On Wed, Feb 29, 2012 at 7:39 AM, Klaus Schmidinger < Klaus.Schmidinger at tvdr.de> wrote: > On 29.02.2012 12:44, Kende wrote: > >> On Wed, Feb 29, 2012 at 12:18:00PM +0100, Klaus Schmidinger wrote: >> >>> On 29.02.2012 12:13, Heikki Manninen wrote: >>> >>>> I have a number of different Conax CAM modules from different >>>> manufacturers and all of them disappear from VDR after a couple of days >>>> running. Hitting CAM reset on the CI menu will bring it back "online". >>>> Naturally all Conax channel recordings will fail silently as a result of >>>> this until the CAM has been brought back up. Switching to an encrypted >>>> channel just gives the standard "channel not available" message. >>>> >>>> This happens (for me) with Satelco DVB-C card with Satelco CI. From >>>> what I understand, this seems to be a common problem though I'm not sure >>>> whether it is limited to Satelco devices only. >>>> >>>> Would it be possible to force CAM reset on all CI slots when VDR is >>>> trying to start recording non-FTA channel? >>>> >>> >>> Wouldn't it be better to fix the actual problem and prevent >>> the CAM from "disappearing"? >>> >> >> Hola, >> >> For me this seems to be driver issue, not VDRs fault. CI poll ioctl write >> seems to fail sometimes with my KNC One (saa7146) budget cards . Following >> patch seems to help in my case: >> >> --- dvbci.c 2007-01-04 14:49:10.000000000 +0200 >> +++ ../vdr-1.7.21/dvbci.c 2011-10-12 10:49:45.689684447 +0300 >> @@ -62,8 +62,10 @@ >> void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length) >> { >> if (Buffer&& Length> 0) { >> >> - if (safe_write(fd, Buffer, Length) != Length) >> + if (safe_write(fd, Buffer, Length) != Length) { >> esyslog("ERROR: can't write to CI adapter on device %d: %m", >> device->De >> viceNumber()); >> + Reset(device->DeviceNumber()); >> + } >> } >> } >> > > I tried this, but I'm afraid it doesn't help. > The Reset() call was never triggered, even though my CAM went from normal > operation to the "CAM ready" state, and not even an explicit reset via > the Setup/CAM menu brought it to life again. Only after reloading the > driver and restarting VDR did it work again. > > My theory is that switching channels is what's causing the problem. > When I trigger an EPG scan, the problem typically occurs after a while. > Maybe it's caused by tuning to channels that are no longer available, > so the frontend times out. However, there's no reason why a frontend > timeout should lead to a CAM freeze... > > I've had this problem for years on my TT-2300-C-FF and TT-1501-C cards with Alphacrypt Multicam. Updating the CAM has no effect, same experience with multiple versions of VDR. Most of the time the CAM can be brought back to "Ready" by doing a CAM Reset from the VDR menus multiple times. On rare occasions the CAM will still be "Ready" but I still get "Channel not available", until I do a CAM reset a few times. I have a crude script which looks for "ERROR: can't write to CI adapter on device" in the syslog which notifies me so I can do the "CAM reset" (often multiple times) from the VDR menus. This appears to be either a bug in the dvb code - which has never been fixed. To be honest - it's nice to hear other people have had the problem!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From user.vdr at gmail.com Wed Feb 29 18:32:29 2012 From: user.vdr at gmail.com (VDR User) Date: Wed, 29 Feb 2012 09:32:29 -0800 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4DDFCB.5040801@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> <201202290538.06898.geronimo013@gmx.de> <20120229081711.0b8bd4dc@grobi> <4F4DDFCB.5040801@tvdr.de> Message-ID: On Wed, Feb 29, 2012 at 12:20 AM, Klaus Schmidinger 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 From geronimo013 at gmx.de Wed Feb 29 18:34:53 2012 From: geronimo013 at gmx.de (Gero) Date: Wed, 29 Feb 2012 18:34:53 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120229165027.6a805404@junior> References: <4F40FF28.9040907@tvdr.de> <4F4E48D1.8070401@gmx.de> <20120229165027.6a805404@junior> Message-ID: <201202291834.54099.geronimo013@gmx.de> On Wednesday 29 February 2012 - 17:50:27, Tony Houghton wrote: > On Wed, 29 Feb 2012 16:48:33 +0100 > Manuel Reimer wrote: > > Klaus Schmidinger 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" ;-). > > > > > > I'll see to make "client/server" a priority after that. > > > > What does this mean? Do you plan built-in networking support or do > > you plan to improve streamdev? IMHO it is a big task to make really > > good networking support. Keeping this code separate (means: A plugin) > > isn't a that bad idea, I think. Of course, this plugin could be > > delivered directly with VDR, like the other "built-in" plugins. > > I don't think a plugin is enough. I agree. I think, it is evident not confuse plugin-networking with client/server networking. OK, currently the client/server support works only through plugins, as there is no vdr-frontend - but Klaus should not care about plugin- networking on designing client/server functionality. C/S-communication should be completely private to vdr - just like internal communication. Plugins may keep on doing their networking, i.e. to connect other frontends like xine or whatever - but that's not the internal communication, vdr relies on. > For better client-server VDR needs to support multiple clients watching > different channels with different OSDs simultaneously. Yeah, that would be very nice :) kind regards Gero From udo_richter at gmx.de Wed Feb 29 20:45:54 2012 From: udo_richter at gmx.de (Udo Richter) Date: Wed, 29 Feb 2012 20:45:54 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <20120229165027.6a805404@junior> References: <4F40FF28.9040907@tvdr.de> <201202281124.51482.geronimo013@gmx.de> <4F4D2736.5070909@iki.fi> <201202290538.06898.geronimo013@gmx.de> <20120229081711.0b8bd4dc@grobi> <4F4DDFCB.5040801@tvdr.de> <4F4E48D1.8070401@gmx.de> <20120229165027.6a805404@junior> Message-ID: <4F4E8072.3050001@gmx.de> Am 29.02.2012 17:50, schrieb Tony Houghton: > On Wed, 29 Feb 2012 16:48:33 +0100 > Manuel Reimer wrote: >> What does this mean? Do you plan built-in networking support or do >> you plan to improve streamdev? IMHO it is a big task to make really >> good networking support. Keeping this code separate (means: A plugin) >> isn't a that bad idea, I think. Of course, this plugin could be >> delivered directly with VDR, like the other "built-in" plugins. > > I don't think a plugin is enough. For better client-server VDR > needs to support multiple clients watching different channels with > different OSDs simultaneously. Not necessarily. I think the key solution is to modularize VDR's internal structures, with well defined interfaces between them. A receiving module that provides stream sources, a recording module that does all the timer work, a frontend module that can display, a storage module that can store and provide videos, for example. A timer menu that belongs to a recording backend, a recording menu that displays content of storage modules, several frontends that can connect to one recording backend or several storage modules, and all can connect to different sources. With defined and pluggable structures between them, its easy to have them either locally connected or linked over network. Whether that's done by a plugin or VDR internally doesn't matter. 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. Cheers, Udo From udo_richter at gmx.de Wed Feb 29 21:33:31 2012 From: udo_richter at gmx.de (Udo Richter) Date: Wed, 29 Feb 2012 21:33:31 +0100 Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.24 In-Reply-To: <4F4E4173.5080809@tvdr.de> References: <4F40FF28.9040907@tvdr.de> <20120224143734.M43953@schmirler.de> <4F47B976.3020906@tvdr.de> <4F47D7E2.6070601@gmx.de> <20120224221450.M33389@linogate.de> <4F48F295.5040401@tvdr.de> <20120227120750.M92341@linogate.de> <4F4BE7B8.20305@gmx.de> <20120228153601.M28085@linogate.de> <4F4E4173.5080809@tvdr.de> Message-ID: <4F4E8B9B.60409@gmx.de> Am 29.02.2012 16:17, schrieb Klaus Schmidinger: > + The function cDevice::Receiving() now returns true if there is any > receiver > attached to the device. Its boolean parameter has no meaning any more. Please remember to drop the following line from PLUGINS.html, as it is now finally completely void: > (any negative value will allow a cReceiver to be detached from its cDevice at any time.) This was handled via Receiving(true). This still leaves the live related receivers unhandled, and since there's no way to port the 'volatile' patch without reverting your changes, we still have the old osdteletext-channel-blocking bug. What about having yet another plugin callback that fires before switching a live channel? Currently, plugins get notified after channel change, and thats too late to disconnect receivers early. And since receiving at -1 doesn't have any special meaning any more, there's no way to get receivers out of way early enough. Roughly, the callback should be at the places where these two get called: DELETENULL(liveSubtitle); DELETENULL(dvbSubtitleConverter); (Thats how VDR's own receivers get out of way.) That way, GetDevice(ch, 0, true) will still have the weired behavior of returning different devices before and after initiating the live view channel switch, but at least after disconnecting all live related receivers, the correct device will be returned. Cheers, Udo