[vdr] vdr with one nexus and one S2 tuning problem
Hello, I achieved to compile the dvbs2 patched vdr1.5.13, but I can't get an image from the S2-3200. The S2-3200 is connected to an 19.2° oriented dish and the nexus to a 13°. On the nexus I have an image, on the S2 a black screen. This is what I can see in syslog regarding vdr : Jan 27 09:16:44 pccave vdr: [13657] VDR version 1.5.13 started Jan 27 09:16:44 pccave vdr: [13657] codeset is 'UTF-8' - known Jan 27 09:16:44 pccave vdr: [13657] found 22 locales in ./locale Jan 27 09:16:44 pccave vdr: [13657] loading plugin: /usr/local/lib/vdr/libvdr-pluginsetup.so.1.5.13 Jan 27 09:16:44 pccave vdr: [13657] loading /video/vdrconf/setup.conf Jan 27 09:16:44 pccave vdr: [13657] loading /video/vdrconf/sources.conf Jan 27 09:16:44 pccave vdr: [13657] loading /video/vdrconf/channels.conf Jan 27 09:16:44 pccave vdr: [13657] loading /video/vdrconf/remote.conf Jan 27 09:16:44 pccave vdr: [13657] reading EPG data from /video/records/epg.data Jan 27 09:16:44 pccave vdr: [13658] video directory scanner thread started (pid=13657, tid=13658) Jan 27 09:16:44 pccave vdr: [13658] video directory scanner thread ended (pid=13657, tid=13658) Jan 27 09:16:44 pccave vdr: [13659] video directory scanner thread started (pid=13657, tid=13659) Jan 27 09:16:44 pccave vdr: [13659] video directory scanner thread ended (pid=13657, tid=13659) Jan 27 09:16:44 pccave vdr: [13657] probing /dev/dvb/adapter0/frontend0 Jan 27 09:16:44 pccave vdr: [13661] CI adapter on device 0 thread started (pid=13657, tid=13661) Jan 27 09:16:44 pccave vdr: [13657] probing /dev/dvb/adapter1/frontend0 Jan 27 09:16:44 pccave vdr: [13662] tuner on device 1 thread started (pid=13657, tid=13662) Jan 27 09:16:44 pccave vdr: [13663] section handler thread started (pid=13657, tid=13663) Jan 27 09:16:44 pccave vdr: [13665] tuner on device 2 thread started (pid=13657, tid=13665) Jan 27 09:16:44 pccave vdr: [13666] section handler thread started (pid=13657, tid=13666) Jan 27 09:16:44 pccave vdr: [13657] found 2 video devices Jan 27 09:16:44 pccave vdr: [13657] initializing plugin: pluginsetup (0.0.6): Plugin Setup Jan 27 09:16:44 pccave vdr: [13657] setting primary device to 1 Jan 27 09:16:44 pccave vdr: [13657] assuming manual start of VDR Jan 27 09:16:44 pccave vdr: [13657] SVDRP listening on port 2001 Jan 27 09:16:44 pccave vdr: [13657] setting current skin to "sttng" Jan 27 09:16:44 pccave vdr: [13657] loading /video/vdrconf/themes/sttng-default.theme Jan 27 09:16:44 pccave vdr: [13657] starting plugin: pluginsetup Jan 27 09:16:44 pccave vdr: [13657] remote control LIRC - keys known Jan 27 09:16:44 pccave vdr: [13657] remote control KBD - keys known Jan 27 09:16:44 pccave vdr: [13667] LIRC remote control thread started (pid=13657, tid=13667) Jan 27 09:16:44 pccave vdr: [13668] KBD remote control thread started (pid=13657, tid=13668) Jan 27 09:16:46 pccave vdr: [13661] CAM 1: no module present Jan 27 09:16:46 pccave vdr: [13661] CAM 2: no module present Jan 27 09:16:46 pccave vdr: [13657] switching to channel 31 Jan 27 09:16:46 pccave vdr: [13669] transfer thread started (pid=13657, tid=13669) Jan 27 09:16:46 pccave vdr: [13670] receiver on device 2 thread started (pid=13657, tid=13670) Jan 27 09:16:46 pccave vdr: [13665] set DVB-S2 Jan 27 09:16:46 pccave vdr: [13671] TS buffer on device 2 thread started (pid=13657, tid=13671) Jan 27 09:16:55 pccave vdr: [13665] frontend 1 timed out while tuning to channel 31, tp 112722 Jan 27 09:16:55 pccave vdr: [13665] set DVB-S2 Jan 27 09:17:04 pccave vdr: [13665] set DVB-S2 Jan 27 09:17:13 pccave vdr: [13665] set DVB-S2 Jan 27 09:17:15 pccave vdr: [13657] switching to channel 30 Jan 27 09:17:15 pccave vdr: [13669] transfer thread ended (pid=13657, tid=13669) Jan 27 09:17:15 pccave vdr: [13657] buffer stats: 0 (0%) used Jan 27 09:17:15 pccave vdr: [13677] transfer thread started (pid=13657, tid=13677) Jan 27 09:17:15 pccave vdr: [13671] TS buffer on device 2 thread ended (pid=13657, tid=13671) Jan 27 09:17:15 pccave vdr: [13670] buffer stats: 0 (0%) used Jan 27 09:17:15 pccave vdr: [13670] receiver on device 2 thread ended (pid=13657, tid=13670) Jan 27 09:17:15 pccave vdr: [13678] receiver on device 2 thread started (pid=13657, tid=13678) Jan 27 09:17:15 pccave vdr: [13679] TS buffer on device 2 thread started (pid=13657, tid=13679) Jan 27 09:17:22 pccave vdr: [13665] frontend 1 timed out while tuning to channel 30, tp 112722 Jan 27 09:17:22 pccave vdr: [13665] set DVB-S2 Jan 27 09:17:31 pccave vdr: [13665] set DVB-S2 Jan 27 09:17:32 pccave vdr: [13657] switching to channel 1 Jan 27 09:17:32 pccave vdr: [13677] transfer thread ended (pid=13657, tid=13677) Jan 27 09:17:32 pccave vdr: [13657] buffer stats: 0 (0%) used Jan 27 09:17:32 pccave vdr: [13662] set DVB-S Jan 27 09:17:32 pccave vdr: [13679] TS buffer on device 2 thread ended (pid=13657, tid=13679) Jan 27 09:17:32 pccave vdr: [13678] buffer stats: 0 (0%) used Jan 27 09:17:32 pccave vdr: [13678] receiver on device 2 thread ended (pid=13657, tid=13678) Jan 27 09:17:40 pccave vdr:
Re: [vdr] vdr with control plugin and osd
Sebastian Dellit wrote: > The options for the control plugin are correct but the > Are you sure? The control plug-in must be configured to use the same tty as VDR. See the KEYB_TTY setting in /etc/default/vdr and the -t option in /etc/vdr/plugins/plugin.control.conf. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cTS2PES got 2 TS errors, 2 TS continuity errors - Channel Not Available????
On 01/27/08 08:11, Simon Baxter wrote: > Hi > > I'm running vdr-1.5.12 with a TT-1500-C card, CI and alphacrypt multi-cam. > All channels are encrypted. > > Intermittantly I try and switch to a channel and I get a "Channel not > available" message. After switching back and forth between channels, > finally the channel will select, and everything's ok. > > I've been trying to diagnose it, and so far all I can see is below: > Jan 27 20:05:29 callin vdr: [3287] switching to channel 20 > Jan 27 20:05:29 callin vdr: [3287] cTS2PES got 2 TS errors, 2 TS continuity > errors > Jan 27 20:05:29 callin vdr: [3287] buffer stats: 58656 (2%) used > Jan 27 20:05:29 callin vdr: [3287] info: Channel not available! > Jan 27 20:05:29 callin vdr: [4167] TS buffer on device 1 thread ended > (pid=3287, tid=4167) > Jan 27 20:05:29 callin vdr: [4166] buffer stats: 58280 (2%) used > Jan 27 20:05:29 callin vdr: [4166] receiver on device 1 thread ended > (pid=3287, tid=4166) > > Can anyone tell me what this cTS2PES error is, and if it's likely to be to > do with my problem? What else can I try? Maybe your CAM needs longer than TS_SCRAMBLING_TIMEOUT (default is 3 seconds) to start decrypting. You can try increasing that number in device.c. It is also very likely that I am going to remove the two lines && !cDevice::SwitchChannel(1) // ...or the next higher available one... && !cDevice::SwitchChannel(-1)) // ...or the next lower available one from vdr.c, in order to allow switching to a channel where the CAM needs quite a long time, for instance to collect new keys because it hasn't been tuned to an encrypted channel for a while. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr with one nexus and one S2 tuning problem
Hi, [EMAIL PROTECTED] schrieb: > I achieved to compile the dvbs2 patched vdr1.5.13, but I can't get an > image from the S2-3200. > The S2-3200 is connected to an 19.2° oriented dish and the nexus to a 13°. > On the nexus I have an image, on the S2 a black screen. Looks like this is OK, see below. > This is what I can see in syslog regarding vdr : ... > Jan 27 09:16:44 pccave vdr: [13657] setting primary device to 1 So your primary device is the full featured nexus, isn't it? A FF device is not able to decode a H.264 stream or when it decodes the H.264 stream according to MPEG2, it won't find any pictures, respectively. So you'll get a black screen. For H.264 playback, you'll need a software device like vdr-xine as primary device. > Jan 27 09:16:46 pccave vdr: [13657] switching to channel 31 > Jan 27 09:16:46 pccave vdr: [13669] transfer thread started (pid=13657, > tid=13669) > Jan 27 09:16:46 pccave vdr: [13670] receiver on device 2 thread started > (pid=13657, tid=13670) > Jan 27 09:16:46 pccave vdr: [13665] set DVB-S2 > Jan 27 09:16:46 pccave vdr: [13671] TS buffer on device 2 thread started > (pid=13657, tid=13671) > Jan 27 09:16:55 pccave vdr: [13665] frontend 1 timed out while tuning to > channel 31, tp 112722 This one looks OK: DVB-S2 channels are tuned on VDR device 2 (= /dev/dvb/adapter1; frontend 1 = /dev/dvb/adapter1/frontend0). > Jan 27 09:17:15 pccave vdr: [13657] switching to channel 30 > Jan 27 09:17:15 pccave vdr: [13677] transfer thread started (pid=13657, > tid=13677) > Jan 27 09:17:15 pccave vdr: [13678] receiver on device 2 thread started > (pid=13657, tid=13678) > Jan 27 09:17:15 pccave vdr: [13679] TS buffer on device 2 thread started > (pid=13657, tid=13679) > Jan 27 09:17:22 pccave vdr: [13665] frontend 1 timed out while tuning to > channel 30, tp 112722 This one looks OK, too, tuning to the same transponder. > Jan 27 09:17:32 pccave vdr: [13657] switching to channel 1 > Jan 27 09:17:32 pccave vdr: [13662] set DVB-S > Jan 27 09:17:41 pccave vdr: [13662] frontend 0 timed out while tuning to > channel 1, tp 110832 This one looks OK too. DVB-S channels shall be tuned on DVB-S capable devices only, and as a last resort, on DVB-S2 devices. But it looks like channel 1 is on ASTRA and therefore you'll get a tuning timeout on device 1 (= /dev/dvb/adapter0; frontend 0 = /dev/dvb/adapter0/frontend0) as it is connected to HOTBIRD. VDR currently assumes that all DVB-S(2) devices are able to deliver all DVB-S(2) channels (actually, it's a bit more complex). You'll need a special channel setup to bind channels to certain devices. > When I "scan" the Astra on device 1, I find a lot of services. What do you mean with "device 1"? VDR's "device 1" is your nexus and /dev/dvb/adapter1 is your S2-3200. What do you mean with "scan"? Tools like szap use DiSEqC implicitly, so maybe you've to enable DiSEqC in VDR too. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr with control plugin and osd
Hello Tobi and all readers, on Sunday, January 27, 2008 at 2:09:30 PM means Tobi: > Sebastian Dellit wrote: >> The options for the control plugin are correct but the >> > Are you sure? The control plug-in must be configured to use the same tty > as VDR. > See the KEYB_TTY setting in /etc/default/vdr and the -t option in > /etc/vdr/plugins/plugin.control.conf. Thanks for this hint. I add the line KEYB_TTY=/dev/tty1 after the line OPTIONS="-w 60" I also add a line -t /dev/tty1 in the plugin config file. When I start the vdr I geht the following error in the syslog: Jan 27 14:18:12 media vdr: [4068] max. latency time 1 seconds Jan 27 14:18:12 media vdr: [4082] clearing device because of consecutive poll timeouts Jan 27 14:18:13 media vdr: [4083] buffer usage: 70% (tid=4082) Jan 27 14:18:13 media vdr: [4083] buffer usage: 80% (tid=4082) Jan 27 14:18:14 media vdr: [4083] buffer usage: 90% (tid=4082) Jan 27 14:18:14 media vdr: [4083] buffer usage: 100% (tid=4082) Jan 27 14:18:14 media vdr: [4083] ERROR: 1 ring buffer overflow (177 bytes dropped) Jan 27 14:18:20 media vdr: [4083] ERROR: 16516 ring buffer overflows (3105008 bytes dropped) Jan 27 14:18:26 media vdr: [4083] ERROR: 20564 ring buffer overflows (3866032 bytes dropped) [...] I don't hear audio output from the tv or from my screenreader (suse blinux). When I stop the vdr with # /etc/init.de/vdr stop the stop process takes any secconds. When I restart the vdr with # /etc/init.de/vdr restart The audio output works fine but I means that an other vdr is loaded. :-/ The tty1 isn't mapped by the vdr. -- Best regards Sebastian ICQ: 264706583 | MSM: [EMAIL PROTECTED] | Skype: sebo_de | Yahoo: de_sebo E-Mail: [EMAIL PROTECTED] | Web: www.blindzeln.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr with one nexus and one S2 tuning problem
Hi, [EMAIL PROTECTED] schrieb: > I achieved to compile the dvbs2 patched vdr1.5.13, but I can't get an > image from the S2-3200. > The S2-3200 is connected to an 19.2° oriented dish and the nexus to a 13°. > On the nexus I have an image, on the S2 a black screen. Looks like this is OK, see below. > This is what I can see in syslog regarding vdr : ... > Jan 27 09:16:44 pccave vdr: [13657] setting primary device to 1 So your primary device is the full featured nexus, isn't it? [serge pecher] yes it is. A FF device is not able to decode a H.264 stream or when it decodes the H.264 stream according to MPEG2, it won't find any pictures, respectively. So you'll get a black screen. For H.264 playback, you'll need a software device like vdr-xine as primary device. [serge pecher] Ok, but is it able to decode the stream coming from the budget card when tuned on a SD channel (dvb-s) ? I intend in a next phase to use an other machine with a vdr-xine to decode the HD streams. > Jan 27 09:16:46 pccave vdr: [13657] switching to channel 31 > Jan 27 09:16:46 pccave vdr: [13669] transfer thread started (pid=13657, tid=13669) > Jan 27 09:16:46 pccave vdr: [13670] receiver on device 2 thread started (pid=13657, tid=13670) > Jan 27 09:16:46 pccave vdr: [13665] set DVB-S2 > Jan 27 09:16:46 pccave vdr: [13671] TS buffer on device 2 thread started (pid=13657, tid=13671) > Jan 27 09:16:55 pccave vdr: [13665] frontend 1 timed out while tuning to channel 31, tp 112722 This one looks OK: DVB-S2 channels are tuned on VDR device 2 (= /dev/dvb/adapter1; frontend 1 = /dev/dvb/adapter1/frontend0). > Jan 27 09:17:15 pccave vdr: [13657] switching to channel 30 > Jan 27 09:17:15 pccave vdr: [13677] transfer thread started (pid=13657, tid=13677) > Jan 27 09:17:15 pccave vdr: [13678] receiver on device 2 thread started (pid=13657, tid=13678) > Jan 27 09:17:15 pccave vdr: [13679] TS buffer on device 2 thread started (pid=13657, tid=13679) > Jan 27 09:17:22 pccave vdr: [13665] frontend 1 timed out while tuning to channel 30, tp 112722 This one looks OK, too, tuning to the same transponder. > Jan 27 09:17:32 pccave vdr: [13657] switching to channel 1 > Jan 27 09:17:32 pccave vdr: [13662] set DVB-S > Jan 27 09:17:41 pccave vdr: [13662] frontend 0 timed out while tuning to channel 1, tp 110832 This one looks OK too. DVB-S channels shall be tuned on DVB-S capable devices only, and as a last resort, on DVB-S2 devices. But it looks like channel 1 is on ASTRA and therefore you'll get a tuning timeout on device 1 (= /dev/dvb/adapter0; frontend 0 = /dev/dvb/adapter0/frontend0) as it is connected to HOTBIRD. VDR currently assumes that all DVB-S(2) devices are able to deliver all DVB-S(2) channels (actually, it's a bit more complex). You'll need a special channel setup to bind channels to certain devices. [serge pecher] I presume that this is what I have to do, because I would like to look at the ASTRA channels with the DVB-S2 device. How can I achieve that ? > When I "scan" the Astra on device 1, I find a lot of services. What do you mean with "device 1"? VDR's "device 1" is your nexus and /dev/dvb/adapter1 is your S2-3200. [serge pecher] I mean scan -a 1 (so it scans /dev/dvb/adapter1, what I wrongly called device 1). I did modify with a patch found on the net the scan tool for dvb-s2 support. What do you mean with "scan"? Tools like szap use DiSEqC implicitly, so maybe you've to enable DiSEqC in VDR too. [serge pecher] I already tried that without succes, but I will try one more time. [serge pecher] Thanks Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr with one nexus and one S2 tuning problem
Hi, serge pecher schrieb: >> Jan 27 09:17:32 pccave vdr: [13657] switching to channel 1 >> Jan 27 09:17:32 pccave vdr: [13662] set DVB-S >> Jan 27 09:17:41 pccave vdr: [13662] frontend 0 timed out while tuning to >> channel 1, tp 110832 > > This one looks OK too. DVB-S channels shall be tuned on DVB-S > capable devices only, and as a last resort, on DVB-S2 devices. > But it looks like channel 1 is on ASTRA and therefore you'll get > a tuning timeout on device 1 (= /dev/dvb/adapter0; frontend 0 = > /dev/dvb/adapter0/frontend0) as it is connected to HOTBIRD. > > VDR currently assumes that all DVB-S(2) devices are able to > deliver all DVB-S(2) channels (actually, it's a bit more > complex). You'll need a special channel setup to bind channels to > certain devices. > > [serge pecher] I presume that this is what I have to do, because I would > like to look at the ASTRA channels with the DVB-S2 device. > How can I achieve that ? See man 5 vdr and have a look at "Conditional access": > 0001...000F explicitly requires the device with the given number Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.5.14
VDR developer version 1.5.14 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.14.tar.bz2 A 'diff' against the previous developer version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.13-1.5.14.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.5.13: - Fixed the Play function in the pictures plugin. - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Updated the Makefile of the skincurses plugin (thanks to Rolf Ahrenberg). - The new option --localedir can be used to set the locale directory at runtime (based on a patch from Stefan Huelswitt). - Fixed finding new transponders (thanks to Winfried Köhler). - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto. - Removed switching to the next higher or lower channel if the current channel is not available, in order to allow staying on an encrypted channel that takes a while for the CAM to start decrypting. IMPORTANT NOTE: === As of this version, VDR requires the new "multiproto" driver, as available, for instance, from http://jusst.de/hg/multiproto. It also uses additional transponder parameters, so a channels.conf file written with this version will not work with previous versions of VDR. Make sure you run this version in a separate environment, or make backups of your config files in case you want to go back to the previous version! So far, VDR supports DVB-S2 hardware and can tune to DVB-S2 transponders. It doesn't yet handle H.264 video PIDs, so it should be safe to tune to such a transponder even if you don't have a device that understands H.264. I am using this version in my regular VDR (with a FF-DVB-S, Budget-DVB-S and Budget-DVB-T card) and everything that used to work appears to still work fine. I was also able to record the AC3 audio track from ProSiebenHD with my TT-S2-3200 card and replay it on my FF-DVB-S card. I also successfully tested recording encrypted DVB-S channels with the TT-S2-3200, so apparently CAM handling also works with that card. *When reporting problems, please don't reply to this message!* Create a new thread instead, using a descriptive subject! Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl > for a patch that was used to implement this). VDR now requires the > "multiproto" > DVB driver, e.g. from http://jusst.de/hg/multiproto. Would it be possible to make that optional via compile time define? cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
> I guess so, but I'm not going to ;-) > This new driver appears to be stable enough now - at least I've > been using it for a few days now without problems. > The new driver is fine, but what you might find is that new card and features being released into the stock v4l mercurial tree aren't being backported into multiproto - its been fairly static for awhile. Hopefully your move toward multiproto might kickstart a move towards widespread adoption (i.e. integration with the development tree) and then eventually into the kernel itself. Still, I'm pleased that VDR now supports S2 "out of the box", shame it doesn't support h264 by default yet though! ;-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > On 01/27/08 16:25, Ludwig Nussel wrote: > > Klaus Schmidinger wrote: > >> - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald > >> Nissl > >> for a patch that was used to implement this). VDR now requires the > >> "multiproto" > >> DVB driver, e.g. from http://jusst.de/hg/multiproto. > > > > Would it be possible to make that optional via compile time define? > > I guess so, but I'm not going to ;-) > This new driver appears to be stable enough now - at least I've > been using it for a few days now without problems. *sigh* messing with kernel stuff sucks. Does a vdr built with the multiproto headers at least also work on vanilla kernels ie stable dvb drivers? That way one would only need to use different headers for building vdr but no extra kernel modules at run time. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On 01/27/08 16:44, Morfsta wrote: >> I guess so, but I'm not going to ;-) >> This new driver appears to be stable enough now - at least I've >> been using it for a few days now without problems. >> > > The new driver is fine, but what you might find is that new card and > features being released into the stock v4l mercurial tree aren't being > backported into multiproto - its been fairly static for awhile. > > Hopefully your move toward multiproto might kickstart a move towards > widespread adoption (i.e. integration with the development tree) and > then eventually into the kernel itself. I really hope I'll live to see the day when we have *one* DVB driver again. > Still, I'm pleased that VDR now supports S2 "out of the box", shame it > doesn't support h264 by default yet though! ;-) One step at a time... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On 01/27/08 16:54, Ludwig Nussel wrote: > Klaus Schmidinger wrote: >> On 01/27/08 16:25, Ludwig Nussel wrote: >>> Klaus Schmidinger wrote: - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto. >>> Would it be possible to make that optional via compile time define? >> I guess so, but I'm not going to ;-) >> This new driver appears to be stable enough now - at least I've >> been using it for a few days now without problems. > > *sigh* messing with kernel stuff sucks. Does a vdr built with the > multiproto headers at least also work on vanilla kernels ie stable > dvb drivers? That way one would only need to use different headers > for building vdr but no extra kernel modules at run time. I don't know. I just grab the latest driver from http://jusst.de/hg/multiproto and compile it on my SUSE 10.3 system, running the stock SUSE kernel. So just unload all DVB modules that come with the stock kernel and load the ones from the multiproto driver. Works fine for me. Maybe the fact that VDR now requires the multiproto driver will finally make the various driver branches come together to *one* DVB driver again. Well, one can at least dream... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On 01/27/08 16:25, Ludwig Nussel wrote: > Klaus Schmidinger wrote: >> - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald >> Nissl >> for a patch that was used to implement this). VDR now requires the >> "multiproto" >> DVB driver, e.g. from http://jusst.de/hg/multiproto. > > Would it be possible to make that optional via compile time define? I guess so, but I'm not going to ;-) This new driver appears to be stable enough now - at least I've been using it for a few days now without problems. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > On 01/27/08 16:54, Ludwig Nussel wrote: > > Klaus Schmidinger wrote: > >> On 01/27/08 16:25, Ludwig Nussel wrote: > >>> Klaus Schmidinger wrote: > - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald > Nissl > for a patch that was used to implement this). VDR now requires the > "multiproto" > DVB driver, e.g. from http://jusst.de/hg/multiproto. > >>> Would it be possible to make that optional via compile time define? > >> I guess so, but I'm not going to ;-) > >> This new driver appears to be stable enough now - at least I've > >> been using it for a few days now without problems. > > > > *sigh* messing with kernel stuff sucks. Does a vdr built with the > > multiproto headers at least also work on vanilla kernels ie stable > > dvb drivers? That way one would only need to use different headers > > for building vdr but no extra kernel modules at run time. > > I don't know. I just grab the latest driver from http://jusst.de/hg/multiproto > and compile it on my SUSE 10.3 system, running the stock SUSE kernel. > So just unload all DVB modules that come with the stock kernel and load > the ones from the multiproto driver. Works fine for me. Works fine now, breaks tomorrow. We had the dvb kernel module package long enough and I was so glad when the dvb drivers finally went into the upstream kernel. I'm not going to maintain another kernel module package again. I just tried a vdr built with the multiproto headers with normal dvb drivers. Doesn't work. That means vdr 1.5.13 is the last version I can build useful packages for atm. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
* Ludwig Nussel schrieb am 27.01.08, um 17:35 Uhr: > Works fine now, breaks tomorrow. We had the dvb kernel module > package long enough and I was so glad when the dvb drivers finally > went into the upstream kernel. I'm not going to maintain another > kernel module package again. The same applies for Debian, i was very, very happy when we dropped the dvb-modules-package from the archive and i do not intend to create a package for any (unofficial) kernel module again. (Especially one which could conflict with kernel-modules a official distribution-kernel may ship.) In the current state, it would not be possible for Debian to ship a vdr version > 1.5.13 in the official archive. Currently it is not urgent for me as we do not package vdr 1.5.x for the official archive (yet), but i am sure that this change is causing a lot problems for Thomas Günther who provides unofficial packages for 1.5.x. I really hope that either vdr 1.5.x gets a compile-time-switch to build and run with the vanilla kernel-sources or even better that the multiproto-drivers will be merged into the mainline kernel soon. Regards, Thomas -- Thomas Schmidt, Debian VDR Team http://pkg-vdr-dvb.alioth.debian.org/ signature.asc Description: Digital signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Thomas Schmidt wrote: ... > In the current state, it would not be possible for Debian to ship a > vdr version > 1.5.13 in the official archive. But that's acceptable, considering that VDR 1.5.14 is a developer version, not a stable version which is intended to go into a distribution, right? Lets just hope that kernel DVB and VDR 1.6.0 will be compatible when VDR 1.6.0 comes out. :-) Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On 01/27/08 17:46, Thomas Schmidt wrote: > * Ludwig Nussel schrieb am 27.01.08, um 17:35 Uhr: >> Works fine now, breaks tomorrow. We had the dvb kernel module >> package long enough and I was so glad when the dvb drivers finally >> went into the upstream kernel. I'm not going to maintain another >> kernel module package again. > > The same applies for Debian, i was very, very happy when we dropped > the dvb-modules-package from the archive and i do not intend to create > a package for any (unofficial) kernel module again. (Especially one > which could conflict with kernel-modules a official > distribution-kernel may ship.) > > In the current state, it would not be possible for Debian to ship a > vdr version > 1.5.13 in the official archive. > > Currently it is not urgent for me as we do not package vdr 1.5.x for > the official archive (yet), but i am sure that this change is causing a > lot problems for Thomas Günther who provides unofficial packages for > 1.5.x. > > I really hope that either vdr 1.5.x gets a compile-time-switch to > build and run with the vanilla kernel-sources or even better that the > multiproto-drivers will be merged into the mainline kernel soon. The latter would be the reasonable step to take, IMHO. Having these different DVB driver branches is something that should end as soon as possible. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On 28 Jan 2008 Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > On 01/27/08 16:25, Ludwig Nussel wrote: >> Klaus Schmidinger wrote: >>> - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald >>> Nissl >>> for a patch that was used to implement this). VDR now requires the >>> "multiproto" >>> DVB driver, e.g. from http://jusst.de/hg/multiproto. >> >> Would it be possible to make that optional via compile time define? > > I guess so, but I'm not going to ;-) > This new driver appears to be stable enough now - at least I've > been using it for a few days now without problems. I don't know if there are many people left, but I'm still working with a 2.4.x kernel and cannot use the new drivers (neither HG nor multiproto). This way I'm effectively looked out from VDR... I would really appreciate a backward compatibility option. Regards. -- Stefan Huelswitt [EMAIL PROTECTED] | http://www.muempf.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
* Carsten Koch schrieb am 27.01.08, um 17:56 Uhr: > > In the current state, it would not be possible for Debian to ship a > > vdr version > 1.5.13 in the official archive. > > But that's acceptable, considering that VDR 1.5.14 is a developer version, > not a stable version which is intended to go into a distribution, right? Yes, of course, i do not plan to upload a developer version into debian unstable unless a release of vdr 1.6.0 is at least somewhere near the horizon. :) We allready had requests to upload vdr 1.5.x to debian experimental but vdr 1.5.14 is one good argument more for the decision not to do this in the current state of development. > Lets just hope that kernel DVB and VDR 1.6.0 will be compatible > when VDR 1.6.0 comes out. :-) Yes, this would be really helpful. ;-) Regards, Thomas -- Thomas Schmidt, Debian VDR Team http://pkg-vdr-dvb.alioth.debian.org/ signature.asc Description: Digital signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > On 01/27/08 17:46, Thomas Schmidt wrote: > > I really hope that either vdr 1.5.x gets a compile-time-switch to > > build and run with the vanilla kernel-sources or even better that the > > multiproto-drivers will be merged into the mainline kernel soon. > > The latter would be the reasonable step to take, IMHO. > Having these different DVB driver branches is something that > should end as soon as possible. Even then distros and kernels of today won't work with newer vdr versions so an option to use the 'old' kernel interface would certainly be appreciated. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX Products GmbH, Development V_/_ http://www.suse.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] HVR4000(lite) support for multiproto
This patch implements support for HVR4000(lite) into the multiproto tree. It is an update of my patch from 2007-12-15. In contrast to the previous one it should conform better to the multiproto API and supports the "set_params" call. For compatibility to non-multiproto-aware applications like vanilla VDR, the old set_frontend calling scheme is still supported if a module param "legacy=1" is passed to the cx24116 module. The patch includes the latest changes from Gregoire and Morfsta. It has been tested successfully with szap (legacy=1), VDR 1.4.7 (legacy=1), szap2 (legacy=0) and VDR 1.5.13 (legacy=0) with Reinhards recent H.264 patches using a 2.6.23.12-i686 kernel. The problems with newer kernels like Craig mentioned may be resolved, but I'm currently not able to test this aspect. Special thanks to Gregoire for digging out some more lost fragments that were of great help. Regards, Holger multiproto-hvr4k-2008-01-27.patch.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cTS2PES got 2 TS errors, 2 TS continuity errors - Channel Not Available????
>> Intermittantly I try and switch to a channel and I get a "Channel not >> available" message. After switching back and forth between channels, >> finally the channel will select, and everything's ok. > Maybe your CAM needs longer than TS_SCRAMBLING_TIMEOUT (default is 3 > seconds) > to start decrypting. You can try increasing that number in device.c. > > It is also very likely that I am going to remove the two lines > > && !cDevice::SwitchChannel(1) // ...or the next higher available > one... > && !cDevice::SwitchChannel(-1)) // ...or the next lower available > one > > from vdr.c, in order to allow switching to a channel where the CAM needs > quite a long time, for instance to collect new keys because it hasn't > been tuned to an encrypted channel for a while. Might be related to tuning to a channel which hasn't been tuned to for a while. Here's a short sequence that will cause it: -tune to movies1 boquet 1 -channel not available, vdr skips to movies2 boquet 2 -persistent back and forth between movies1 & movies2, after 5th attempt, channel changes to movies1 -change to food boquet3, channel not available and vdr skips to E! boquet1 -persistent back and forth, then changes to food boquet3 -repeat changing to movies1 & movies2 and the above sequence happens again But - if I'm persistent and get movies1(bq1), movies2(bq2) and movies3(bq1) to come up, I can use Up/Down to flick one to the other over and over very quickly. If I leave it on movies1(bq1) for more than a few seconds, I get the problem when trying to change. It doesn't seem to be a problem consistent with specific channels either. I've tried increasing the TS_SCRAMBLING_TIMEOUT to 6 seconds, and it just takes longer for the channel not available message - doesn't stop the problem happenning. Any other ideas? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] HVR4000(lite) support for multiproto
Here is an update for the update, as the last had to suffer a small hg accident. Regards, Holger multiproto-hvr4k-2008-01-27b.patch.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On Sun, 27 Jan 2008 16:58:26 +0100 Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > I don't know. I just grab the latest driver from http://jusst.de/hg/multiproto > and compile it on my SUSE 10.3 system, running the stock SUSE kernel. > So just unload all DVB modules that come with the stock kernel and load > the ones from the multiproto driver. Works fine for me. Well, multiproto doesn't even compile on a current (2.6.24) kernel .. or I am doing something really wrong. -- --- Malte Schröder [EMAIL PROTECTED] ICQ# 68121508 --- signature.asc Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On Sun, Jan 27, 2008 at 08:32:53PM +0100, Malte Schröder wrote: > Well, multiproto doesn't even compile on a current (2.6.24) kernel .. > or I am doing something really wrong. Well, the VDR community is quiete large, then we'll could make things go to a better situation, from my point of view, we'll have to include multiproto into kernel directly. I have tried to compil it againt zen kernels, which are certainly very well suited for multimedia : http://forums.gentoo.org/viewtopic-t-616535-highlight-.html http://forums.gentoo.org/viewtopic-t-641834-postdays-0-postorder-asc-start-0.html http://repo.or.cz/w/linux-2.6/zen-sources.git http://zen-sources.org/ http://zen-sources.org/project/issues I failed... but they are so many people more knwoledged than me... -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] Old DVB API patch for VDR-1.5.14
Hi list,
Asking myself if I want to build kernels and drivers for 4 different PCs
or try my luck with an old DVB API patch for vdr-1.5.14, I've chosen the
latter. The attached patch implements fallback for VDR in case no
multiproto DVB driver headers are available.
I'm not really sure what I've been doing here, as I don't know the DVB
API well enough, but at least my vdr-1.5.14 is running on old DVB
drivers again. The patch is a bit hackish, and could probably be
implemented a bit more cleanly, but its a starting point.
Cheers,
Udo
diff -Naur vdr-1.5.14-orig/channels.c vdr-1.5.14/channels.c
--- vdr-1.5.14-orig/channels.c 2008-01-27 14:59:53.0 +0100
+++ vdr-1.5.14/channels.c 2008-01-27 21:03:04.0 +0100
@@ -11,6 +11,7 @@
#include
#include
#include "device.h"
+#include "dvb_api_emulate.h"
#include "epg.h"
#include "timers.h"
diff -Naur vdr-1.5.14-orig/dvb_api_emulate.h vdr-1.5.14/dvb_api_emulate.h
--- vdr-1.5.14-orig/dvb_api_emulate.h 1970-01-01 01:00:00.0 +0100
+++ vdr-1.5.14/dvb_api_emulate.h2008-01-27 21:03:04.0 +0100
@@ -0,0 +1,106 @@
+/*
+ * dvb_api_emulate.h: The DVB device interface
+ *
+ * See the main source file 'vdr.c' for copyright information and
+ * how to reach the author.
+ *
+ * $Id: $
+ */
+
+#ifndef __DVB_API_EMULATE_H
+#define __DVB_API_EMULATE_H
+
+
+#if DVB_API_VERSION != 3 || DVB_API_VERSION_MINOR != 3
+
+#define DVB_API_EMULATE
+
+enum dvbfe_delsys {
+DVBFE_DELSYS_DVBS = (1 << 0),
+DVBFE_DELSYS_DSS= (1 << 1),
+DVBFE_DELSYS_DVBS2 = (1 << 2),
+DVBFE_DELSYS_DVBC = (1 << 3),
+DVBFE_DELSYS_DVBT = (1 << 4),
+DVBFE_DELSYS_DVBH = (1 << 5),
+DVBFE_DELSYS_ATSC = (1 << 6),
+DVBFE_DELSYS_DUMMY = (1 << 31)
+};
+enum dvbfe_hierarchy {
+DVBFE_HIERARCHY_OFF = (1 << 0),
+DVBFE_HIERARCHY_ON = (1 << 1),
+DVBFE_HIERARCHY_AUTO= (1 << 2)
+};
+enum dvbfe_alpha {
+DVBFE_ALPHA_1 = (1 << 0),
+DVBFE_ALPHA_2 = (1 << 1),
+DVBFE_ALPHA_4 = (1 << 2)
+};
+enum dvbfe_stream_priority {
+DVBFE_STREAM_PRIORITY_HP= (0 << 0),
+DVBFE_STREAM_PRIORITY_LP= (1 << 0)
+};
+enum dvbfe_rolloff {
+DVBFE_ROLLOFF_35= 0,
+DVBFE_ROLLOFF_25= 1,
+DVBFE_ROLLOFF_20= 2,
+DVBFE_ROLLOFF_UNKNOWN = 3
+};
+
+#define DVBFE_SET_PARAMS FE_SET_FRONTEND
+#define DVBFE_INVERSION_OFF INVERSION_OFF
+#define DVBFE_INVERSION_ON INVERSION_ON
+#define DVBFE_INVERSION_AUTO INVERSION_AUTO
+#define DVBFE_BANDWIDTH_5_MHZ BANDWIDTH_AUTO
+#define DVBFE_BANDWIDTH_6_MHZ BANDWIDTH_6_MHZ
+#define DVBFE_BANDWIDTH_7_MHZ BANDWIDTH_7_MHZ
+#define DVBFE_BANDWIDTH_8_MHZ BANDWIDTH_8_MHZ
+#define DVBFE_BANDWIDTH_AUTO BANDWIDTH_AUTO
+#define DVBFE_FEC_NONE FEC_NONE
+#define DVBFE_FEC_1_2 FEC_1_2
+#define DVBFE_FEC_1_3 FEC_AUTO
+#define DVBFE_FEC_1_4 FEC_AUTO
+#define DVBFE_FEC_2_3 FEC_2_3
+#define DVBFE_FEC_2_5 FEC_AUTO
+#define DVBFE_FEC_3_4 FEC_3_4
+#define DVBFE_FEC_3_5 FEC_AUTO
+#define DVBFE_FEC_4_5 FEC_4_5
+#define DVBFE_FEC_5_6 FEC_5_6
+#define DVBFE_FEC_6_7 FEC_6_7
+#define DVBFE_FEC_7_8 FEC_7_8
+#define DVBFE_FEC_8_9 FEC_8_9
+#define DVBFE_FEC_9_10 FEC_AUTO
+#define DVBFE_FEC_AUTO FEC_AUTO
+#define DVBFE_MOD_NONE QAM_AUTO
+#define DVBFE_MOD_QAM4 QAM_AUTO
+#define DVBFE_MOD_QAM16 QAM_16
+#define DVBFE_MOD_QAM32 QAM_32
+#define DVBFE_MOD_QAM64 QAM_64
+#define DVBFE_MOD_QAM128 QAM_128
+#define DVBFE_MOD_QAM256 QAM_256
+#define DVBFE_MOD_QAM512 QAM_AUTO
+#define DVBFE_MOD_QAM1024 QAM_AUTO
+#define DVBFE_MOD_BPSK QAM_AUTO
+#define DVBFE_MOD_QPSK QPSK
+#define DVBFE_MOD_OQPSK QAM_AUTO
+#define DVBFE_MOD_8PSK QAM_AUTO
+#define DVBFE_MOD_16APSK QAM_AUTO
+#define DVBFE_MOD_32APSK QAM_AUTO
+#define DVBFE_MOD_OFDM QAM_AUTO
+#define DVBFE_MOD_COFDM QAM_AUTO
+#define DVBFE_MOD_VSB8 QAM_AUTO
+#define DVBFE_MOD_VSB16 QAM_AUTO
+#define DVBFE_MOD_QAMAUTO QAM_AUTO
+#define DVBFE_MOD_AUTO QAM_AUTO
+#define DVBFE_TRANSMISSION_MODE_2K TRANSMISSION_MODE_2K
+#define DVBFE_TRANSMISSION_MODE_4K TRANSMISSION_MODE_AUTO
+#define DVBFE_TRANSMISSION_MODE_8K TRANSMISSION_MODE_8K
+#define DVBFE_TRANSMISSION_MODE_AUTO TRANSMISSION_MODE_AUTO
+#define DVBFE_GUARD_INTERVAL_1_4 GUARD_INTERVAL_1_4
+#define DVBFE_GUARD_INTERVAL_1_8 GUARD_INTERVAL_1_8
+#define DVBFE_GUARD_INTERVAL_1_16 GUARD_INTERVAL_1_16
+#define DVBFE_GUARD_INTERVAL_1_32 GUARD_INTERVAL_1_32
+#define DVBFE_GUARD_INTERVAL_AUTO GUARD_INTERVAL_AUTO
+
+#endif // if DVB_API_VERSION != 3 || DVB_API_VERSION_MINOR != 3
+
+#endif // ifndef __DVB_API_EMULATE_H
diff -Naur vdr-1.5.14-orig/dvbdevice.c vdr-1.5.14/dvbdevice.c
--- vdr-1.5.14-orig/dvbdevice.c 2008-01-27 15:35:54.0 +0100
+++ vdr-1.5.14/dvbdevice.c 2008-01-27 21:03:04.0 +0100
@@ -192,7 +192,11 @@
bool cDvbTuner::SetFrontend(void)
{
+#ifdef DVB_API_EMULATE
+ dvb_frontend_parameters Frontend;
+#else
dvbfe_params Frontend;
+#endif
memset(&Frontend, 0, sizeof(Frontend));
if
Re: [vdr] [PATCH] Old DVB API patch for VDR-1.5.14
On 28 Jan 2008 Udo Richter <[EMAIL PROTECTED]> wrote: > Asking myself if I want to build kernels and drivers for 4 different PCs > or try my luck with an old DVB API patch for vdr-1.5.14, I've chosen the > latter. The attached patch implements fallback for VDR in case no > multiproto DVB driver headers are available. Thanks a lot. This saves me the time to dig into that by myself (which was the plan for tomorrow). Regards. -- Stefan Huelswitt [EMAIL PROTECTED] | http://www.muempf.de/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] need help with UTF-8 error - vdr: please turn off UTF-8 before starting VDR
Hello, When I run vdr from the command line I get this message: "vdr: please turn off UTF-8 before starting VDR" How do I turn off UTF-8? Why would I want to? Can someone tell me how to fix it? I have just installed it using YUM rpm, and I am running Fedora 7 if that helps. Any help is appreciated, thank you much. Techno ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] H.264 support for VDR-1.5.14
Hi, attached you'll find an updated patch for VDR-1.5.14. This time, the VPID offset 1 stuff has been removed completely. Have a look at this page for more instructions on this concern: http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Installationsanleitung_%28Achtung_Beta%29 Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] vdr-1.5.14-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff.bz2 Description: BZip2 compressed data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] contact to femon plugin developer
On Tue, 15 Jan 2008, Sebastian Dellit wrote: > I hope my idea is simple. many Any users use a braille display and > speech to access the vdr. Is it possible to create a femon skin which > show the information in plain text on the OSD? E. g. the developer of > the lastfm-plugin has include a function. You can change between > graphic and text display. If you select the text version all > informations (title, track etc.) can read with an braille display. The > plugin also use a function to select the refresh rate of the display. > If you select "0" you can always refresh the display manual. The > femon plugin IMHO needs a simular function. I'm not familiar with Braille displays, so how does it detect text in order to translate it to speech? Femon is drawing text with the same OSD methods as the core VDR, so if you can hear VDR's menus, you should be able to hear the femon menus also. The default refresh rate is quite high, but you can tweak it in plugin's setup menu. So the only problem might be the massive amount of infomation shown on current configuration. If I understood you correctly, you'd like to get only essential signal/stream information on a simple menu that can be refreshed on demand? Now the real question is, what kind of information is essential for you? BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Multiproto updated Re: [ANNOUNCE] VDR developer version 1.5.14
Morfsta wrote: >> I guess so, but I'm not going to ;-) >> This new driver appears to be stable enough now - at least I've >> been using it for a few days now without problems. >> > > The new driver is fine, but what you might find is that new card and > features being released into the stock v4l mercurial tree aren't being > backported into multiproto - its been fairly static for awhile. I have pushed out a tree which is now a merged version of v4l-dvb and the multiproto trees and is available at http://jusst.de/hg/multiproto (As of now, insufficient tests, after the merge, please test) A point to note is that, in the build (for me 2.6.21) the stk-webcam in the v4l-dvb tree was broken and hence is broken in the updated multiproto tree as well. You will need to disable the stk-webcam build in that tree, in case you are using an older kernel. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Ludwig Nussel wrote: > Klaus Schmidinger wrote: >> On 01/27/08 16:25, Ludwig Nussel wrote: >>> Klaus Schmidinger wrote: - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald Nissl for a patch that was used to implement this). VDR now requires the "multiproto" DVB driver, e.g. from http://jusst.de/hg/multiproto. >>> Would it be possible to make that optional via compile time define? >> I guess so, but I'm not going to ;-) >> This new driver appears to be stable enough now - at least I've >> been using it for a few days now without problems. > > *sigh* messing with kernel stuff sucks. Does a vdr built with the > multiproto headers at least also work on vanilla kernels ie stable > dvb drivers? That way one would only need to use different headers > for building vdr but no extra kernel modules at run time. > AFAICT, the updated headers can be used along with the old drivers without any issues. If not there's an issue with regards to backward compatibility. Can you pleas point out the errors that which you see, when you are using the updated headers and the old drivers ? Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Klaus Schmidinger wrote: > On 01/27/08 17:46, Thomas Schmidt wrote: >> I really hope that either vdr 1.5.x gets a compile-time-switch to >> build and run with the vanilla kernel-sources or even better that the >> multiproto-drivers will be merged into the mainline kernel soon. > > The latter would be the reasonable step to take, IMHO. > Having these different DVB driver branches is something that > should end as soon as possible. The drivers can be merged in to the kernel after quite some tests. With regards to both the S2 capable drivers there are enough bug reports open. I am not of the opinion of merging drivers while open bug reports still do exist. (You can look at the linux-dvb ML for the same) For both the drivers, many people can say it works for me, but not for everyone. That said, currently the tree is up to v4l-dvb head and the current kernel merge window is open for 2.6.25, which will be open for some few days more. With the current state, it cannot be merged in for 2.6.25. Most probably we might be able to make it for 2.6.26 if all goes well. This requires lot more testing and fixing etc. The current state of different branches (distributed repositories) was the option chosen when Johannes merged the trees and was his decision. Most probably, that will remain the same for quite a long time to come. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
On Jan 27, 2008 9:03 AM, Stefan Huelswitt <[EMAIL PROTECTED]> wrote: > I don't know if there are many people left, but I'm still working > with a 2.4.x kernel and cannot use the new drivers (neither HG > nor multiproto). > This way I'm effectively looked out from VDR... > > I would really appreciate a backward compatibility option. This begs to ask... Why not just upgrade your kernel? There will always be some give & take with updating but that's not necessarily a bad thing. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] need help with UTF-8 error - vdr: please turn off UTF-8 before starting VDR
On Sun, Jan 27 2008, techno wrote: > > When I run vdr from the command line I get this message: > > "vdr: please turn off UTF-8 before starting VDR" > > How do I turn off UTF-8? Hello, With the command "set | grep -i utf" you can see what environment variables have a value with "utf". Those, that begin with "LC_" and the variable LANG have to be unset (example: "unset LC_CTYPE LANG"). > Why would I want to? Because vdr requires it (see the first paragraph in the file "INSTALL" /usr/share/doc/packages/vdr/INSTALL). Cheers, Peter -- http://pmrb.free.fr/contact/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] need help with UTF-8 error - vdr: please turn off UTF-8 before starting VDR
On Sunday 27 January 2008, techno wrote: > Hello, > > When I run vdr from the command line I get this message: > > "vdr: please turn off UTF-8 before starting VDR" > > How do I turn off UTF-8? Why would I want to? > Can someone tell me how to fix it? > > I have just installed it using YUM rpm, and I am running Fedora 7 if that > helps. If you start vdr using the included init script (/etc/init.d/vdr), this and a bunch of other useful things will be taken care of for you automatically. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.14
Manu Abraham wrote: > Ludwig Nussel wrote: > > Klaus Schmidinger wrote: > >> On 01/27/08 16:25, Ludwig Nussel wrote: > >>> Klaus Schmidinger wrote: > - Implemented handling of DVB-S2 (thanks to Marco Schlüßler and Reinhald > Nissl > for a patch that was used to implement this). VDR now requires the > "multiproto" > DVB driver, e.g. from http://jusst.de/hg/multiproto. > >>> Would it be possible to make that optional via compile time define? > >> I guess so, but I'm not going to ;-) > >> This new driver appears to be stable enough now - at least I've > >> been using it for a few days now without problems. > > > > *sigh* messing with kernel stuff sucks. Does a vdr built with the > > multiproto headers at least also work on vanilla kernels ie stable > > dvb drivers? That way one would only need to use different headers > > for building vdr but no extra kernel modules at run time. > > AFAICT, the updated headers can be used along with the old drivers without > any issues. If not there's an issue with regards to backward compatibility. > Can you pleas point out the errors that which you see, when you are using > the updated headers and the old drivers ? I just did a quick test and didn't debug it further. IIRC the only vdr error message was an error from the DVBFE_GET_DELSYS ioctl. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
