[vdr] Looking for Medion MD4688 remote code for VDR
Hi, My Medion MD 4688 remote (from Aldi) has lost its codes because the batteries were dead :-( Obviously, I had not written the codes on the back label of the remote control. I have looked at this ML archives and found some codes (308, 336), but they are not working. I am not using LIRC, but the RC input of a WinTV DVB-S REV 1.3, and this is my remote.conf file : remote-event0._Setup /proc/av7110_ir 8000 20 remote-event0.Up 000100010003 remote-event0.Down 000100010009 remote-event0.Menu 000100010004 remote-event0.Ok 000100010006 remote-event0.Back 00010001000A remote-event0.Left 000100010005 remote-event0.Right 000100010007 remote-event0.Red000100010001 remote-event0.Green 000100010002 remote-event0.Yellow 000100010023 remote-event0.Blue 00010001000E remote-event0.0 00010001001E remote-event0.1 000100010026 remote-event0.2 000100010027 remote-event0.3 000100010028 remote-event0.4 00010001001A remote-event0.5 00010001003E remote-event0.6 000100010017 remote-event0.7 000100010018 remote-event0.8 000100010019 remote-event0.9 00010001002C remote-event0.Play 000100010031 remote-event0.Pause 00010001003D remote-event0.Stop 000100010021 remote-event0.Record 000100010024 remote-event0.FastFwd000100010037 remote-event0.FastRew000100010036 remote-event0.Power 00010001000D remote-event0.Channel+ 000100010035 remote-event0.Channel- 000100010034 remote-event0.User1 00010001000C remote-event0.User2 000100010015 remote-event0.User3 00010001003B remote-event0.User4 00010001000B Any suggestions for the MD4688 code ? Thanks, Jean-Claude ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Newbie: Pinnacle PCTV tuner kit rev 1.7 good for VDR ?
Hi. I am new to this vdr mailinglist. I have been admiring the VDR project for a long time. And now am looking seriously into building one. I am having trouble finding a DVB-C PCI card in the city where i live. There is this one: Pinnacle PCTV TUNER KIT I could not find a type number. On the card is the text REV 1.7 It is a PCI card. On the box are two pictures of DVB-T and DVB-C And it has a TV input and TV output, according to the picture on the box. Its price has been marked of from 60 - 70 euro to 57 euro. Guess the model is on its way out. Can not find any useful info on it on the internet. What are the capabilities of this card ? Does anyone know if this card can be used with VDR ? Thanks :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Newbie: Pinnacle PCTV tuner kit rev 1.7 good for VDR ?
On Tuesday 08 April 2008 09:18, vroemm wrote: Pinnacle PCTV TUNER KIT I could not find a type number. On the card is the text REV 1.7 It is a PCI card. On the box are two pictures of DVB-T and DVB-C And it has a TV input and TV output, according to the picture on the box. Its price has been marked of from 60 - 70 euro to 57 euro. Guess the model is on its way out. A bit more info on this card: It is a small card with the big silvery square on it. It looks roughly like these cards on http://www.bttv-gallery.de/ Pinnacle PCTV Stereo (Nov.2003) saa7134 MINITV-DVB-T-51015697-1.1 http://www.bttv-gallery.de/pinnacle_pctv_stereo_jpg_MINITV-DVB-T-51015697-1_1_saa7134.jpg Pinnacle PCTV MediaCenter 300i (PAL) http://www.bttv-gallery.de/img08177fz.jpg_pinnacle_300i_11bd_002d_a.jpg Which pinnacle card has been sold as tuner kit ? Thanks. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Femon and new API.
Helo.
I'am tring to port femon to new api and no succes.
1. Questions.
Is all new api implemented iet in multiproto?
New version of api is 3.3 pr 4.3?
Is there any documentation ?
2. My tests and work.
I put this code :
enum dvbfe_status {
DVBFE_HAS_SIGNAL= (1 0),/* something above
noise floor */
DVBFE_HAS_CARRIER = (1 1),/* Signal found
*/
DVBFE_HAS_VITERBI = (1 2),/* FEC is stable
*/
DVBFE_HAS_SYNC = (1 3),/* SYNC found
*/
DVBFE_HAS_LOCK = (1 4),/* OK ..
*/
DVBFE_TIMEDOUT = (1 5),/* no lock in last ~2
s */
DVBFE_STATUS_DUMMY = (1 31)
};
#define DVBFE_READ_STATUS _IOR('o', 87,
enum dvbfe_status)
enum dvbfe_statistics_avail {
DVBFE_BER = (1 0), /*!
bit error rate */
DVBFE_SIGNAL_STRENGTH = (1 1), /*!
signal strength */
DVBFE_SNR = (1 2), /*!
signal to nois ratio */
DVBFE_UNCORRECTED_BLOCKS = (1 3) /*!
number of uncorrected blocks */
};
struct dvbfe_statistics {
enum dvbfe_statistics_avail avail;
/*! describes the available information */
__u32 ber;/*!
bit error rate, if avaible */
__u16 signal_strength;/*!
signal strength, if available */
__u16 snr;/*!
signal to noise ratio, if avaible */
__u32 uncorrected_blocks; /*!
number of uncorrected blocks, if avaible */
};
#define DVBFE_READ_STATIISTICS _IOR('o', 88,
struct dvbfe_statistics)
in /linux/include/linux/dvb/frontend.h from
multiproto.
and then i modified femontools.c like this:
return NULL;
CHECK(ioctl(fe, DVBFE_GET_INFO, value));
CHECK(ioctl(fe, DVBFE_READ_STATUS, status));
CHECK(ioctl(fe, DVBFE_READ_STATIISTICS, signal));
//CHECK(ioctl(fe, DVBFE_READ_SNR, snr));
//CHECK(ioctl(fe, DVBFE_READ_BER, ber));
//CHECK(ioctl(fe, DVBFE_READ_UNCORRECTED_BLOCKS,
unc));
close(fe);
info =
cString::sprintf(CARD:%d\nTYPE:%d\nNAME:%s\nSTAT:%02X\nSGNL:%04X\nSNRA:%04X\nBERA:%08X\nUNCB:%08X,
cardIndex, value.type, value.name, status, signal,
snr, ber, unc);
if (cFemonOsd::Instance())
info =
cString::sprintf(%s\nVIBR:%.0f\nAUBR:%.0f\nDDBR:%.0f,
*info, cFemonOsd::Instance()-GetVideoBitrate(),
cFemonOsd::Instance()-GetAudioBitrate(),
cFemonOsd::Instance()-GetDolbyBitrate());
if (channel)
info = cString::sprintf(%s\nCHAN:%s, *info,
*channel-ToText());
return info;
}
cString getFrontendName(int cardIndex)
{
struct dvbfe_info value;
cString dev = cString::sprintf(FRONTEND_DEVICE,
cardIndex, 0);
int fe = open(dev, O_RDONLY | O_NONBLOCK);
if (fe 0)
return NULL;
CHECK(ioctl(fe, DVBFE_GET_INFO, value));
close(fe);
return (cString::sprintf(%s on device #%d,
value.name, cardIndex));
}
cString getFrontendStatus(int cardIndex)
{
dvbfe_status value;
cString dev = cString::sprintf(FRONTEND_DEVICE,
cardIndex, 0);
int fe = open(dev, O_RDONLY | O_NONBLOCK);
if (fe 0)
return NULL;
CHECK(ioctl(fe, DVBFE_READ_STATUS, value));
close(fe);
return (cString::sprintf(Status %s:%s:%s:%s:%s on
device #%d, (value DVBFE_HAS_LOCK) ? LOCKED :
-, (value DVBFE_HAS_SIGNAL) ? SIGNAL : -,
(value DVBFE_HAS_CARRIER) ? CARRIER : -, (value
DVBFE_HAS_VITERBI) ? VITERBI : -, (value
DVBFE_HAS_SYNC) ? SYNC : -, cardIndex));
}
uint16_t getSignal(int cardIndex)
{
uint16_t value = 0;
cString dev = cString::sprintf(FRONTEND_DEVICE,
cardIndex, 0);
int fe = open(dev, O_RDONLY | O_NONBLOCK);
if (fe 0)
return (value);
CHECK(ioctl(fe, FE_READ_SIGNAL, value));
close(fe);
return (value);
}
is this ok?
a litle bit of help?
You rock. That's why Blockbuster's offering you one month of Blockbuster Total
Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
On 04/08/08 10:25, Tuomas Jormola wrote:
Hi,
I forgot to post this earlier, but in the attachment you'll find logs of
this issue on my system. I modified the code like this:
eModuleStatus cCamSlot::ModuleStatus(void)
{
cMutexLock MutexLock(mutex);
eModuleStatus ms = ciAdapter ? ciAdapter-ModuleStatus(slotIndex) :
msNone;
isyslog(CAM DEBUG: ms: %d resetTime: %d, ms, resetTime);
if (resetTime) {
if (ms = msReset) {
isyslog(CAM DEBUG: ms le msReset);
if (time(NULL) - resetTime MODULE_RESET_TIMEOUT) {
isyslog(CAM DEBUG: return msReset);
return msReset;
}
}
isyslog(CAM DEBUG: resetTime zero);
resetTime = 0;
}
return ms;
}
btw. it looks like a bug crept into Arthur's code below. After
if (time(NULL) - resetTime MODULE_RESET_TIMEOUT)
if this if expression evaluates true, only the debug message is printed,
and return msReset is executed always due to missing brackets.
While you are right about this, I don't think that it even got there,
because resetTime was actually 0 when the switch from 3 (ready) to
2 (present) occurred:
Apr 7 09:06:41 vdr vdr: [4862] ms: 3
Apr 7 09:06:41 vdr vdr: [4862] resetTime1: 0
Apr 7 09:06:41 vdr vdr: [4862] ms: 2
Intendation of the closing brackets of the if blocks in the original
piece of code seem to be incorrect, which makes it difficult to spot
things like this.
Closing brackets are of course indented, since they are part of
the block. But I guess this is a philosophical argument, so let's not
get into this ;-)
Klaus
Tuomas Jormola
On 7 Apr 2008, at 19:12, Klaus Schmidinger wrote:
On 04/07/08 08:34, Arthur Konovalov wrote:
Well,
I'm not big guru of debugging.
I made following changes to mentioned part of code:
eModuleStatus cCamSlot::ModuleStatus(void)
{
cMutexLock MutexLock(mutex);
eModuleStatus ms = ciAdapter ? ciAdapter-ModuleStatus(slotIndex) :
msNone;
isyslog(ms: %d, ms); //AKO
isyslog(resetTime1: %d, resetTime); //AK
if (resetTime) {
isyslog(resetTime2: %d, resetTime); //AK
if (ms = msReset) {
isyslog(resetTime3: %d, resetTime); //AK
if (time(NULL) - resetTime MODULE_RESET_TIMEOUT)
isyslog(resetTime4: %d, resetTime); //AK
return msReset;
}
resetTime = 0;
}
return ms;
}
Log file attached. I suspect that additional instructions are welcome.
At this point...
Apr 7 09:06:41 vdr vdr: [4862] ms: 3
Apr 7 09:06:41 vdr vdr: [4862] resetTime1: 0
Apr 7 09:06:41 vdr vdr: [4862] ms: 2
...the module status changed from 3 (ready) to 2 (present).
The module status is retrieved from the driver in
cDvbCiAdapter::ModuleStatus():
eModuleStatus cDvbCiAdapter::ModuleStatus(int Slot)
{
ca_slot_info_t sinfo;
sinfo.num = Slot;
if (ioctl(fd, CA_GET_SLOT_INFO, sinfo) != -1) {
if ((sinfo.flags CA_CI_MODULE_READY) != 0)
return msReady;
else if ((sinfo.flags CA_CI_MODULE_PRESENT) != 0)
return msPresent;
}
else
esyslog(ERROR: can't get info of CAM slot %d on device %d: %m,
Slot, device-DeviceNumber());
return msNone;
}
So for some reason the sinfo.flags doesn't seem to have the
CA_CI_MODULE_READY
flag set any longer.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput: viewing 16:9 content on 4:3 output device
Dear all, I have lurked a while on this list but until now have not had reason to post. I am unable to configure xineliboutput to my liking. I don't imagine I am the only one with this issue, but I have not been able to find a solution, either by trial and error or by googling. I would appreciate to hear how other people configure their vdr boxes. My output device is a 4:3 analog TV. Watching a 4:3 stream is fine in the sense that the full real estate of the TV is used. Watching a 16:9 stream results in (depending on various settings I have tried) either the stream 'compressed' vertically to maintain the 16:9 ratio (with black bars top and bottom), or a vertically 'stretched' image that loses the 16:9 ratio but fills the entire TV screen. What I would like is to maintain the stream 16:9 ratio but by by cropping the left and right sections of the stream that fall 'outside' the TV, so the full real estate of the TV is used, at the expense of losing some stream information. I have played with various xineliboutput settings, all through the OSD plugin setup menu. My current settings are roughly: LOCAL FRONTEND: Using Xv and set to fullscreen and stretched-to-window video. Aspect ratio set to 4:3 (although PanScan and CenterCutOut looked promising but don't do what I thought they might). VIDEO: aspect ratio set to automatic. Anything else seems to force the aspect ratio to that value. Software scaling does not seem to be the route to follow either. Autocrop 4:3 letterbox to 16:9 is disabled, but also looked promising, but I could not obtain the bahaviour I desire. So (finally) a direct question: how do people with 4:3 output devices and vdr with xineliboutput configure their boxes? Some brief details of my system: I am using vdr 1.6.0, a recent-ish (last few days) xineliboutput CVS version running under X (i.e. vdr-sxfe) on a NVIDIA 6150 device with the binary NVIDIA module (TV-out at 720x576) watching DVB-S streams (thanks to a NOVA-S-Plus and a HVR4000 with multiproto, for what that is worth), all connected to a 4:3 aspect ratio TV. I thought this would be a quick question but I have managed to write an epic! Sorry about that. Best wishes, Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: viewing 16:9 content on 4:3 output device
On 8 Apr 2008, at 16:43, Ian Bates wrote: What I would like is to maintain the stream 16:9 ratio but by by cropping the left and right sections of the stream that fall 'outside' the TV, so the full real estate of the TV is used, at the expense of losing some stream information. This setting is most often called crop mode. The specific setting you're after is often called pan-and-scan. I can't say how to achieve the desired output with xineliboutput though, since I use softdevice. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Announce] vdr-streamdev-0.3.4 and CVS branch
Am 07.04.2008 um 18:08 schrieb Frank Schmirler: streamdev-0.3.4 is finally available from http://streamdev.vdr-developer.org . Nice to see that development goes on! Thanks for the new Version. Ciao, Dominique ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
I am making some experiment with Oxine. I did also try Freevo. I find Oxine much lighter and much easier to configure. sp I can't get oxine compiled - get stuck at: checking for cdio_open in -lcdio... no configure: error: *** Please install libcdio first! *** [EMAIL PROTECTED] oxine]# rpm -qa | grep libcdio libcdio-0.78.2-2.fc6 ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Install headers, add pkgconfig file
On Wednesday 12 March 2008, Ville Skyttä wrote:
On Wednesday 12 March 2008, clemens kirchgatterer wrote:
On Tue, Mar 11, 2008 at 3:46 PM, Joerg Pulz [EMAIL PROTECTED]
wrote:
Out of this four cases (there are probably more, one for every Linux
distribution on this planet), tell me which is the most reasonable
default?
the most reasonable default is simply to put vdr.pc in
[$(DESTDIR)/]$(PREFIX)/lib/pkgconfig. for cases that this is not
appropriate, there is $PKG_CONFIG_PATH.
Agreed. The second revision of the patch is attached; compared to the
first one this also installs the *.pc file to the first (colon separated)
component of $PKG_CONFIG_PATH, or to $(PREFIX)/lib/pkgconfig if
$PKG_CONFIG_PATH is not set in the environment. Unless I've missed
something, as far as I'm concerned this is good enough to go in.
Here's the third revision, after a bit more testing. As a result of that,
there were a couple of minor bug fixes, most notable of which was to the
install-includes target.
--- Makefile.orig 2008-02-29 23:43:03.0 +0200
+++ Makefile 2008-04-04 20:18:51.0 +0300
@@ -19,6 +19,7 @@
PREFIX ?= /usr/local
MANDIR = $(PREFIX)/share/man
BINDIR = $(PREFIX)/bin
+INCLUDEDIR = $(PREFIX)/include
LOCDIR = ./locale
LIBS = -ljpeg -lpthread -ldl -lcap -lrt -lfreetype -lfontconfig
INCLUDES = -I/usr/include/freetype2
@@ -32,6 +33,8 @@
DOXYGEN = /usr/bin/doxygen
DOXYFILE = Doxyfile
+PCDIR ?= $(firstword $(subst :, , ${PKG_CONFIG_PATH}:$(PREFIX)/lib/pkgconfig))
+
-include Make.config
SILIB= $(LSIDIR)/libsi.a
@@ -75,7 +78,7 @@
DEFINES += -DVFAT
endif
-all: vdr i18n
+all: vdr i18n vdr.pc
# Implicit rules:
@@ -101,6 +104,23 @@
$(SILIB):
$(MAKE) -C $(LSIDIR) all
+# pkg-config file:
+
+vdr.pc: Makefile
+ echo bindir=$(BINDIR) $@
+ echo includedir=$(INCLUDEDIR) $@
+ echo configdir=$(CONFDIR) $@
+ echo videodir=$(VIDEODIR) $@
+ echo plugindir=$(PLUGINLIBDIR) $@
+ echo localedir=$(LOCDIR) $@
+ echo apiversion=$(APIVERSION) $@
+ echo $@
+ echo Name: VDR $@
+ echo Description: Video Disk Recorder $@
+ echo URL: http://www.cadsoft.de/vdr/; $@
+ echo Version: $(VDRVERSION) $@
+ echo Cflags: $(CXXFLAGS) -I$${includedir} $@
+
# Internationalization (I18N):
PODIR = po
@@ -161,7 +181,8 @@
# Install the files:
-install: install-bin install-conf install-doc install-plugins install-i18n
+install: install-bin install-conf install-doc install-plugins install-i18n \
+ install-includes install-pc
# VDR binary:
@@ -192,6 +213,20 @@
@mkdir -p $(DESTDIR)$(PLUGINLIBDIR)
@cp --remove-destination $(PLUGINDIR)/lib/lib*-*.so.$(APIVERSION) $(DESTDIR)$(PLUGINLIBDIR)
+# Headers:
+
+install-includes: include-dir
+ @mkdir -p $(DESTDIR)$(INCLUDEDIR)
+ @cp -pLR include/vdr include/libsi $(DESTDIR)$(INCLUDEDIR)
+
+# pkg-config file:
+
+install-pc: vdr.pc
+ if [ -n $(PCDIR) ] ; then \
+ mkdir -p $(DESTDIR)$(PCDIR) ; \
+ cp vdr.pc $(DESTDIR)$(PCDIR) ; \
+ fi
+
# Source documentation:
srcdoc:
@@ -204,7 +239,7 @@
clean:
$(MAKE) -C $(LSIDIR) clean
- -rm -f $(OBJS) $(DEPFILE) vdr core* *~
+ -rm -f $(OBJS) $(DEPFILE) vdr vdr.pc core* *~
-rm -rf $(LOCALEDIR) $(PODIR)/*.mo $(PODIR)/*.pot
-rm -rf include
-rm -rf srcdoc
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote:
At this point...
Apr 7 09:06:41 vdr vdr: [4862] ms: 3
Apr 7 09:06:41 vdr vdr: [4862] resetTime1: 0
Apr 7 09:06:41 vdr vdr: [4862] ms: 2
...the module status changed from 3 (ready) to 2 (present).
The module status is retrieved from the driver in cDvbCiAdapter::ModuleStatus():
eModuleStatus cDvbCiAdapter::ModuleStatus(int Slot)
{
ca_slot_info_t sinfo;
sinfo.num = Slot;
if (ioctl(fd, CA_GET_SLOT_INFO, sinfo) != -1) {
if ((sinfo.flags CA_CI_MODULE_READY) != 0)
return msReady;
else if ((sinfo.flags CA_CI_MODULE_PRESENT) != 0)
return msPresent;
}
else
esyslog(ERROR: can't get info of CAM slot %d on device %d: %m, Slot,
device-DeviceNumber());
return msNone;
}
So for some reason the sinfo.flags doesn't seem to have the CA_CI_MODULE_READY
flag set any longer.
Please take a look to the test code in attachment, provided by Christoph
Pfister. With it I got the following output:
[EMAIL PROTECTED]:/video/vdr/cam# ./test
0.08: 3
0.000161: 0
0.014133: 1
1.694142: 3
And explanation:
After a reset CAM is absent for a very short time (14ms == less than
a scheduler tick) and then it takes ~1.7s to become ready again. (The
intervall between reset and status query seems to be a bit bigger in vdr
- so we only see the 3--1 change == 3--2 in vdr numbers).
It's an endless loop: cam detection -- cam reset -- cam not
present/ready for a short while -- vdr thinks cam has been physically
removed -- cam detection -- cam reset etc.
Big thanks to Christoph for assistance.
Is it realistic to hope for a workaround/solution for this kind of CAMs
(Technotrend CX at my case)?
Regards,
AK
#include fcntl.h
#include linux/dvb/ca.h
#include stdio.h
#include string.h
#include sys/ioctl.h
#include sys/time.h
#include unistd.h
int cam_status(int fd)
{
ca_slot_info_t info;
memset(info, 0, sizeof(info));
info.num = 0;
if (ioctl(fd, CA_GET_SLOT_INFO, info) != 0) {
printf(error: couldn't get slot info\n);
return -1;
}
return info.flags;
}
struct timeval start_time;
void print_status(int status)
{
struct timeval time;
gettimeofday(time, NULL);
int dsec = time.tv_sec - start_time.tv_sec;
int dusec = time.tv_usec - start_time.tv_usec;
if (dusec 0) {
dusec += 100;
dsec -= 1;
}
printf(%i.%06i: %i\n, dsec, dusec, status);
}
int main()
{
int fd = open(/dev/dvb/adapter0/ca0, O_RDWR);
if (fd 0) {
printf(error: couldn't open ca handle\n);
return 1;
}
gettimeofday(start_time, NULL);
int status = cam_status(fd);
print_status(status);
if (ioctl(fd, CA_RESET, (1 0)) != 0) {
printf(error: couldn't reset cam\n);
return 1;
}
int i;
for (i = 0; i 200; ++i) {
int new_status = cam_status(fd);
if (status != new_status) {
status = new_status;
print_status(status);
}
usleep(1);
}
return 0;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] How can VDR record with timer if behind a decoder ?
Hi. There is something i do not understand. Here is how i though it works: My TV provider, Casema in the netherlands, delivers digital TV via a decoder with a sort of credit card. Normally you use the remote control of this decoder to choose the tv prog to watch. Thus decoder sends only the selected digital channel to the DVB-C TV card in the computer. This was told to me by a sales person today. If this is true, how then can VDR select the different digital programs with the timers in VDR set by you ? Then somehow all digital channels have to be send to the DVB-C TV card. Or does VDR not work with decoders with such a credit card restriction ? I hope someone can explain this to me. If feel a bit stupid right now, i hope this falls under the saying There are no stupid questions :-) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: viewing 16:9 content on 4:3 output device
Hi, On Tue, 8 Apr 2008, Ian Bates wrote: One more remark, if as I believe from the comments in the code above, that the '16:9 crop to 4:3' behaviour is not implemented in xineliboutput, am I the only one suffering from the lack of this feature? Am I the only one still using a 4:3 TV? I don't think so, what do other people do when viewing 16:9 material on a 4:3 device, other than put up with the black bars? This is exactly what I'm doing - I'm accepting the black bars at the bottom and the top, dreaming about the screen I'm going to buy at some point in the future, along with being happy for other xineliboutput-users having already a 16:9 screen. Patrick. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
On 04/08/08 21:10, Arthur Konovalov wrote:
Klaus Schmidinger wrote:
At this point...
Apr 7 09:06:41 vdr vdr: [4862] ms: 3
Apr 7 09:06:41 vdr vdr: [4862] resetTime1: 0
Apr 7 09:06:41 vdr vdr: [4862] ms: 2
...the module status changed from 3 (ready) to 2 (present).
The module status is retrieved from the driver in
cDvbCiAdapter::ModuleStatus():
eModuleStatus cDvbCiAdapter::ModuleStatus(int Slot)
{
ca_slot_info_t sinfo;
sinfo.num = Slot;
if (ioctl(fd, CA_GET_SLOT_INFO, sinfo) != -1) {
if ((sinfo.flags CA_CI_MODULE_READY) != 0)
return msReady;
else if ((sinfo.flags CA_CI_MODULE_PRESENT) != 0)
return msPresent;
}
else
esyslog(ERROR: can't get info of CAM slot %d on device %d: %m,
Slot, device-DeviceNumber());
return msNone;
}
So for some reason the sinfo.flags doesn't seem to have the
CA_CI_MODULE_READY
flag set any longer.
Please take a look to the test code in attachment, provided by Christoph
Pfister. With it I got the following output:
[EMAIL PROTECTED]:/video/vdr/cam# ./test
0.08: 3
0.000161: 0
0.014133: 1
1.694142: 3
And explanation:
After a reset CAM is absent for a very short time (14ms == less than
a scheduler tick) and then it takes ~1.7s to become ready again. (The
intervall between reset and status query seems to be a bit bigger in vdr
- so we only see the 3--1 change == 3--2 in vdr numbers).
It's an endless loop: cam detection -- cam reset -- cam not
present/ready for a short while -- vdr thinks cam has been physically
removed -- cam detection -- cam reset etc.
Big thanks to Christoph for assistance.
Is it realistic to hope for a workaround/solution for this kind of CAMs
(Technotrend CX at my case)?
Since this apparently happens also without VDR, I guess it will have to
be fixed in the driver.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: viewing 16:9 content on 4:3 output device
Patrick Boettcher wrote: Hi, On Tue, 8 Apr 2008, Ian Bates wrote: One more remark, if as I believe from the comments in the code above, that the '16:9 crop to 4:3' behaviour is not implemented in xineliboutput, am I the only one suffering from the lack of this feature? Am I the only one still using a 4:3 TV? I don't think so, what do other people do when viewing 16:9 material on a 4:3 device, other than put up with the black bars? This is exactly what I'm doing - I'm accepting the black bars at the bottom and the top, dreaming about the screen I'm going to buy at some point in the future, along with being happy for other xineliboutput-users having already a 16:9 screen. I would say the correct term is not accepting but acknowledging... Makes no sense to me why someone would like to cut 25% from the picture. And what about programmes in 2.39:1 aspect ratio? Should those be cut too so that they fit to 4:3 ratio and lose 44% of the image in the process? Anyway, mplayer can do that, try something like mplayer -vf crop=507:544,scale=720:544 http://your_server:37890. Although that will cut also programmes sent in 4:3 aspect ratio. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Looking for Medion MD4688 remote code for VDR
Jean-Claude Repetto wrote: My Medion MD 4688 remote (from Aldi) has lost its codes because the batteries were dead :-( I am not using LIRC, but the RC input of a WinTV DVB-S REV 1.3, and this is my remote.conf file : remote-event0._Setup /proc/av7110_ir 8000 20 remote-event0.Up 000100010003 [..] remote-event0.User4 00010001000B Any suggestions for the MD4688 code ? I'm not exactly sure how the remote.conf translates to MD5 codes, but I think it might be code 376. Has some similarities. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
[ sorry for breaking thread - but people don't seem to honor CC ] On 04/08/08 22:49, Klaus Schmidinger wrote: snip And explanation: After a reset CAM is absent for a very short time (14ms == less than a scheduler tick) and then it takes ~1.7s to become ready again. (The intervall between reset and status query seems to be a bit bigger in vdr - so we only see the 3--1 change == 3--2 in vdr numbers). It's an endless loop: cam detection -- cam reset -- cam not present/ready for a short while -- vdr thinks cam has been physically removed -- cam detection -- cam reset etc. Big thanks to Christoph for assistance. Is it realistic to hope for a workaround/solution for this kind of CAMs (Technotrend CX at my case)? Since this apparently happens also without VDR, I guess it will have to be fixed in the driver. No. If you issue a reset, you have to deal with its consequences. And one obvious consequence is that the cam is unusable for a certain time (and thus reports not-ready). Klaus Christoph ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How can VDR record with timer if behind a decoder ?
vroemm wrote: There is something i do not understand. Here is how i though it works: My TV provider, Casema in the netherlands, delivers digital TV via a decoder with a sort of credit card. Normally you use the remote control of this decoder to choose the tv prog to watch. Thus decoder sends only the selected digital channel to the DVB-C TV card in the computer. This was told to me by a sales person today. I don't know the details in the Netherlands, but he was probably wrong. You don't use the original decoder if you a DVB-C card. You should get a DVB-C card with a CI and a CAM and put the smartcard into the CAM - see http://www.linuxtv.org/vdrwiki/index.php/Common_interface. Searching for Casema DVB-C VDR, I also found http://groups.msn.com/CentrumVrienden/audiovideo.msnw?action=get_messagemview=0ID_Message=166LastModified=4675596259283298739. That article is a bit old, perhaps you find a newer one if you use some Dutch words in your search. Regards... Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
On 9 Apr 2008, at 00:26, Klaus Schmidinger wrote: On 04/08/08 23:17, Tuomas Jormola wrote: On 8 Apr 2008, at 23:49, Klaus Schmidinger wrote: Since this apparently happens also without VDR, I guess it will have to be fixed in the driver. Well, the funny thing is that VDR 1.4.7 with exactly the same kernel and hardware does not give any symptoms at all. On startup CAM is initialized quickly just fine. VDR 1.4 didn't permanently monitor the module status. Well, as an end user I don't really care what the two versions do differently behind the scenes. Net effect for me is that with VDR 1.4 my CAM is working and with VDR 1.6 it's unusable. So to me VDR 1.6 is broken, what ever the technical reason might be. Tuomas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR as a set top box
On Tuesday 08 April 2008, Simon Baxter wrote: checking for cdio_open in -lcdio... no configure: error: *** Please install libcdio first! *** [EMAIL PROTECTED] oxine]# rpm -qa | grep libcdio libcdio-0.78.2-2.fc6 yum install libcdio-devel Ah idiot error! Now I have a new error against both the current Oxine snapshot, and from svn ./autogen.sh --enable-vdr snip checking for strrchr... yes checking for strstr... yes checking for strtol... yes configure: creating ./config.status config.status: creating Makefile config.status: error: cannot find input file: Makefile.in ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
