Re: [vdr] sub-titles on Arte
26.02.2015 0:25, Peter Münster kirjutas: Hi, There must be something wrong with my VDR-setup, I never see sub-titles on Arte. This is my channel.conf line: arte HD;ARD:11493:HC23M5O35P0S1:S19.2E:22000:5111=27:5112=deu@3,5113=fra@3,5117=mis@3;5116=mul@106:5114;5115=deu,5118=fra,5119=deu:0:10302:1:1019:0 How could I get sub-titles for this channel please? TIA for any hints, I've tried to zap to this channel and I got subtitles. See screenshots in attachment. VDR-2.2.0 in use. br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sub-titles on Arte
26.02.2015 22:53, Peter Münster kirjutas: On Thu, Feb 26 2015, Arthur wrote: No. But regarding to the mediainfo there no real german subtitles in the transport stream. Maybe they only declared, but not transmitted? I don't know. My parents have a normal TV device and they see German subtitles. I would like to know how to get them with VDR... Ah so. Then you probably have to ask Klaus to check what is wrong with this. br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sub-titles on Arte
26.02.2015 22:28, Peter Münster kirjutas: On Thu, Feb 26 2015, Arthur wrote: I've tried to zap to this channel and I got subtitles. See screenshots in attachment. VDR-2.2.0 in use. Thanks. Indeed, now I get also French subtitles. Do you get the German subtitles? I don't... No. But regarding to the mediainfo there no real german subtitles in the transport stream. Maybe they only declared, but not transmitted? General ID : 32776 (0x8008) Complete name: \\vdr\video\The_Code_(4~6)_Fernsehserie_Australien\2015-02-26.22.35.255-0.rec\1.ts Format : MPEG-TS File size: 138 MiB Duration : 1mn 30s Overall bit rate mode: Variable Overall bit rate : 12.8 Mbps Video ID : 5111 (0x13F7) Menu ID : 132 (0x84) Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.0 Format settings, CABAC : Yes Format settings, ReFrames: 4 frames Codec ID : 27 Duration : 1mn 30s Bit rate : 11.1 Mbps Width: 1 280 pixels Height : 720 pixels Display aspect ratio : 16:9 Frame rate : 50.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth: 8 bits Scan type: Progressive Bits/(Pixel*Frame) : 0.241 Stream size : 119 MiB (87%) Audio #1 ID : 5112 (0x13F8) Menu ID : 132 (0x84) Format : MPEG Audio Format version : Version 1 Format profile : Layer 2 Codec ID : 3 Duration : 1mn 30s Bit rate mode: Constant Bit rate : 192 Kbps Channel(s) : 2 channels Sampling rate: 48.0 KHz Compression mode : Lossy Delay relative to video : -1s 369ms Stream size : 2.07 MiB (2%) Language : German Audio #2 ID : 5113 (0x13F9) Menu ID : 132 (0x84) Format : MPEG Audio Format version : Version 1 Format profile : Layer 2 Codec ID : 3 Duration : 1mn 30s Bit rate mode: Constant Bit rate : 192 Kbps Channel(s) : 2 channels Sampling rate: 48.0 KHz Compression mode : Lossy Delay relative to video : -1s 369ms Stream size : 2.07 MiB (2%) Language : French Audio #3 ID : 5116 (0x13FC) Menu ID : 132 (0x84) Format : AC-3 Format/Info : Audio Coding 3 Mode extension : CM (complete main) Format settings, Endianness : Big Codec ID : 6 Duration : 1mn 30s Bit rate mode: Constant Bit rate : 448 Kbps Channel(s) : 6 channels Channel positions: Front: L C R, Side: L R, LFE Sampling rate: 48.0 KHz Bit depth: 16 bits Compression mode : Lossy Delay relative to video : -1s 289ms Stream size : 4.82 MiB (4%) Language : Multiple languages Audio #4 ID : 5117 (0x13FD) Menu ID : 132 (0x84) Format : MPEG Audio Format version : Version 1 Format profile : Layer 2 Codec ID : 3 Duration : 1mn 30s Bit rate mode: Constant Bit rate : 192 Kbps Channel(s
Re: [vdr] Restart of frontend
14.02.2015 23:17, Lucian Muresan kirjutas: On 14.02.2015 19:53, VDR User wrote: At yavdr we use this feature to start X and vdr in parallel and attach softhddevice when X is ready. And you can restart X when softhddevice is detached. Do you happen to know approx. how much startup time is saved doing this? Another case where one would want to use that way to start softhddevice is to be able to leave VDR running even when detaching softhddevice output to switch to xbmc/kodi or anything else, to be able to let VDR do recordings if necessary, or quickly switch back (of course, on a HTPC setup all from the remote control). Regards, Lucian It's exactly case that I have. A. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Duplicate channels
Lugupidamisega, Arthur 2.02.2015 23:22, Arthur kirjutas: 25.01.2015 13:21, Klaus Schmidinger kirjutas: On 23.01.2015 16:43, Adam Juraszek wrote: On Fri, Jan 23, 2015 at 11:23 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: On 22.01.2015 15:51, Adam Juraszek wrote: Hello, I have a few months old system with vdr 2.0.6. VDR is used only as a backend for xbmc (via xvdr plugin). Everything works fine except for a few lags which I tracked to VDR creating new channels every now and then. When I checked the channels I noticed there are duplicates (there are 36374 channels and many of them are there about 500 times). I wouldn't be surprised if vdr would suffer performance problem with such number of channels. See the setup.conf (not changed in months), syslog and part of channels (got by LSTC command) and stats: https://gist.github.com/juriad/2b635ef475a6ddf829ab Why VDR creates duplicate channels? Is there problem with my configuration or is it a bug in vdr? What other information shall I provide? Looks like VDR doesn't find an existing channel in its Channels list when it encounters a new version of the SDT. At the moment I have no idea how that could happen. Is this a plain vanilla, unpatched version 2.0.6 of VDR? Klaus Yes, it is unpatched version (just checked diff againts vdr-2.0.6.tar.bz2). I tried to use gdb to see what is happening. Anyway, the backtrace of call of method cChannels::NewChannel is: #0 cChannels::NewChannel (this=0x76b800 Channels, Transponder=0xf992a0, Name=Name@entry=0x7f74ce78fdf0 CT 1 HD, ShortName=ShortName@entry=0x7f74ce790df0 , Provider=Provider@entry=0x7f74ce791df0 Towercom, Nid=Nid@entry=3, Tid=3234, Sid=4901, Rid=0) at channels.c:1013 #1 0x004d64ee in cSdtFilter::Process (this=0xf9aa40, Pid=optimized out, Tid=optimized out, Data=optimized out, Length=optimized out) at sdt.c:105 #2 0x004d727c in cSectionHandler::Action (this=0xfa41e0) at sections.c:211 #3 0x004f8b23 in cThread::StartThread (Thread=0xfa41e0) at thread.c:262 #4 0x7f74d79920a4 in start_thread (arg=0x7f74ce794700) at pthread_create.c:309 #5 0x7f74d63acccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 I tried to create a core-dump but gdb failed to do so. Maybe you can add some debug output when a channel named CT 1 HD is encountered in the SDT and then searched for in the Channels list. Since the channel apparently *is* in the list, the search for it seems to fail at some point. We need to find out the reason for that. Klaus Is there any progress? Maybe my problem related to this too. I just jumped from vdr-2.1.6 to the 2.1.8 and now I have many false OBSOLETE channels. For example, i have channel (svdrpsend printout): 875 TV11:11804:hM2O0S0:S4.8E:27500:6001=2:6002=@3:6006:90F,93E:6000:86:8:0 but this and any other channels on that transponder marked as OBSOLETE: Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'TV11,;' on S4.8E transponder 111804 with id 86-8-6000-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'TV 2 Filmkanalen,;Viasat' on S4.8E transponder 111804 with id 86-8-6010-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'Ticket,;' on S4.8E transponder 111804 with id 86-8-6020-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'MTV NO,;' on S4.8E transponder 111804 with id 86-8-6040-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'Viasat History,;' on S4.8E transponder 111804 with id 86-8-6050-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'Viasat Sport Baltic,;' on S4.8E transponder 111804 with id 86-8-6060-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'Sjuan,;' on S4.8E transponder 111804 with id 86-8-6080-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'TV4 Film,;' on S4.8E transponder 111804 with id 86-8-6090-0 Feb 2 22:14:50 akovdr vdr: [5269] creating new channel 'Viasat Nature East,;' on S4.8E transponder 111804 with id 86-8-6030-0 Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 822 from 'Viasat Sport Baltic,;' to 'Viasat Sport Baltic OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 875 from 'TV11,;' to 'TV11 OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 876 from 'TV 2 Filmkanalen,;' to 'TV 2 Filmkanalen OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 877 from 'Viasat History,;' to 'Viasat History OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 878 from 'Sjuan,;' to 'Sjuan OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 879 from 'TV4 Film,;' to 'TV4 Film OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 880 from 'Viasat Nature East,;' to 'Viasat Nature East OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269] changing name of channel 888 from 'MTV NO,;' to 'MTV NO OBSOLETE,;OBSOLETE ' Feb 2 22:14:50 akovdr vdr: [5269
Re: [vdr] Duplicate channels
,;' to 'Ticket OBSOLETE,;OBSOLETE ' At the same time this problem not occurred with DVB-C channels. 250 2 ETV2:266000:C0M256:C:6875:300=2:310=est@3,311=est@3:0:B00:1004:16:1:0 In the DVB settings UpdateChannels = 4 selected. br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1-2 second gaps in recordings from Finnish YLE channels
Is it possible to set to not update pids only for certain channels, not globally? YLE channels in this case. 12.10.2014 22:17, Mikko Tuumanen kirjutas: In at least some of the recordings I've made from the Finnish YLE- channels there is a small gap at the start of the actual program and VDR has chosen to record the rest of the program in a new file. I'm guessing that the problem has something to do with subtitles and/or audio tracks, but I'm certainly no expert. http://www.linuxtv.org/pipermail/vdr/2005-March/000873.html When pids of a recorded channel are changed, vdr stops recording and (a few seconds) later starts it again with the new pids. A long time ago I tried to do a quick hack to fix this. I tried to add the new pids to the running recording instead of stopping. I didn't care about removing the old pids, because with Yle channels the removed pids are not given to some other channels, but just not sent at all. It turned out that adding the pids wasn't that easy. It seemed quite difficult to dig the necessary information out of vdr immediately. I have no idea if that has changed in recent years. There might be a workaround for this problem: http://www.digita.fi/files/459/PID-arvot_A.pdf Put all pids from that pdf to channels.conf and change vdr settings to not update pids. ___ 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
[vdr] SNR bar depends from UNC [vdr-2.1.6]
I've noticed strange effect with the SNR bar. Every time when UNC counter increased SNR bar becomes more and more red. In the same time hex and percent values are fine. Combined screenshot from femon plugin: http://www.pictureshack.ru/images/95487_unc.jpg It's not plugin depended. The same behavior can be observed on standard VDR's channel LCARS skin info bar. Why UNC occurred, it's a different story. Currently I can't explain why viewing some (not all!) HD channels lead to the UNC (disturbance are visible too). Is it bitrate or something else, I don't know. It seems only 1080i suffer, not 720p and BER stays always on zero. If somebody have any method to debug and find reason of this, I will be thankful for sharing. My configuration: DD Cine S2 v6.5 (endriss media_buid), kernel 3.12.17, vdr-2.1.6, last softhddevice and GeForce GT520 HDMI for output. -- br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SNR bar depends from UNC [vdr-2.1.6]
14.06.2014 17:52, Klaus Schmidinger kirjutas: On 14.06.2014 16:40, Arthur Konovalov wrote: I've noticed strange effect with the SNR bar. Every time when UNC counter increased SNR bar becomes more and more red. In the same time hex and percent values are fine. Combined screenshot from femon plugin: http://www.pictureshack.ru/images/95487_unc.jpg It's not plugin depended. The same behavior can be observed on standard VDR's channel LCARS skin info bar. Why UNC occurred, it's a different story. Currently I can't explain why viewing some (not all!) HD channels lead to the UNC (disturbance are visible too). Is it bitrate or something else, I don't know. It seems only 1080i suffer, not 720p and BER stays always on zero. If somebody have any method to debug and find reason of this, I will be thankful for sharing. It would appear that UNC is a static counter that is simply counted up with every uncorrected error, and is only reset to 0 on a channel switch. I don't know about femon, but the way VDR uses this counter to produce its signal quality measure is int b = 100 - (Unc * 10 + (Ber / 256) * 5); So if the value of Unc increases, the signal quality decreases. Maybe we should only take Unc into account if it has been counted up within the past few seconds? If anybody can suggest a proper way of doing this, please speak up. Why just don't use values from device without additional calculation? root@akovdr:~# femon -a2 -H FE: STV090x Multistandard (DVBS) status SCVYL | signal 75% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 75% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK status SCVYL | signal 75% | snr 76% | ber 0 | unc 0 | FE_HAS_LOCK -- br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR test series about frame detector
15.01.2014 19:45, Eike kirjutas: Hello again, there have been several problems with linking with different VDR versions. Here are updated steps that should fix them: make rm vdr.o g++ -c framedetectortest.cpp g++ -o framedetectortest *.o libsi/libsi.a -lfontconfig -lfreetype -lpthread -ldl -ljpeg -lrt Ciao, Eike Hi, Cable operator Starman, Estonia: On the different channels both 5 and 6 exists. It seems that on the local channels it's 6 and in the retransmitted from sat channels - 5 (for example Showtime). With some records I have got like this: framedetectorte[20894]: segfault at 0 ip b73a75c5 sp bfc2a650 error 4 in libc-2.17.so[b7338000+185000] -- br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deactivate a Tuner
15.08.2013 18:37, Brian-Imap kirjutas: On 8/14/2013 10:16 PM, Arthur wrote: 14.08.2013 19:01, Brian-Imap kirjutas: On 8/11/2013 11:43 AM, Brian-Imap wrote: On 8/8/2013 10:22 PM, Lars Hanisch wrote: Am 08.08.2013 16:23, schrieb Brian-Imap: On 8/7/2013 9:58 PM, Lars Hanisch wrote: Hi, Am 07.08.2013 21:04, schrieb Brian-Imap: Hi, I now a have a 4 Tuner Cine S2 setup that I want to run with 3 cables, I want to keep the fourth cable for a test VDR. Reading about this I only see how to do it together with the Dynamite Plugin, is that correct that I must use that Plugin to get it to work for VDR? I am currently running a plain VDR setup on Ubuntu, with very few plugins and had no need for the Dynamite Plugin up till now. You don't really need dynamite. If you want to omit the fourth tuner (in kernel count order), you can start vdr with the -D parameter (see vdr --help). vdr -D0 -D1 -D2 other parameters as usual Regards, Lars. Cheers Brian ___ 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 Hi Lars, OK I knew about this, but I thought that the Card/Tuners numbers could change from boot to boot. Are you saying that they will not change? If it's one bridge with 4 tuners, I doubt their order will change. You may want to read about device bonding, where you split one cable on two tuners so they share polarisation and band, but may be tuned to different transponders. But I'm a cable user, I don't know much about it, just that there are some people out there who use it successfully. :) Regards, Lars. Cheers Brian ___ 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 Hi, thanks for the tips, unfotunately I ended up needing to keep using a FF Card for a short while. So I followed the CT tip and added a TT C-2300 Cable FF card that is not connected to cable at all. That part seems to work really well. Using the -D parameter in VDR I limited VDR to using the first 4 DVB Devices and this is what it gave me: Aug 11 11:09:31 localhost vdr: [936] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) Aug 11 11:09:31 localhost vdr: [936] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DVB-C) Aug 11 11:09:31 localhost vdr: [936] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) Aug 11 11:09:31 localhost vdr: [936] frontend 4/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) So tuners 1-3 of the Cine S2 and Duoflex are now in use. DBV device 1 provides nothing but MPEG output. I guess I'll keep an eye on the DVB device ordering for a while to see how it goes. Cheers Brian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Hi, well the DVB device numbering is not consistent: VDR-Test-Cellar(SDA2): 15:25 [995] frontend 3/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 15:25 [995] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 15:25 [995] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DVB VDR-Test-Cellar(SDA2): 15:25 [995] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 3/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 2/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DV VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 1/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 3/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DV VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 1/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 19:16 [1015] frontend 3/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 19:16 [1015] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK (STV090x Multistandard) VDR-Test-Cellar(SDA2): 19:16 [1015] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (ST STV0297 DV VDR-Test-Cellar(SDA2): 19:16 [1015] frontend
Re: [vdr] RFC: one or many positioners?
21.04.2013 15:54, Klaus Schmidinger kirjutas: The question I have now is: will it be enough to have *one* single positioner in any given setup, or are there actually users who have more than one positioner? Hi and thanks for bringing this feature to the job list! One is enough for me. -- br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Call for translations for VDR version 2.0.0: one more string needed
4.03.2013 16:30, Klaus Schmidinger kirjutas: While implementing an option to turn on/off sorting folders first in the Recordings menu, one more string was necessary and needs to be translated: Always sort folders first The patch for this new option can be found at http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1130105-feature-request-sortierreihenfolge-verzeichnisse-zuerst-im-osd-unter-aufnahmen/#post1130105 but it would suffice if you could just send me (or post here) the translation of the string shown above. Thanks Klaus Estonian translation: Sorteerida kaustad alati ette -- br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.33
8.12.2012 17:28, Klaus Schmidinger kirjutas:
On 08.12.2012 13:18, Wolfgang Rohdewald wrote:
On Saturday 08 December 2012 12:38:30 Klaus Schmidinger wrote:
- In order to be able to play TS recordings from other sources, in
which there is
more than one PMT PID in the PAT, 'int
cPatPmtParser::PatPmt(void)' has been changed
to 'bool cPatPmtParser::IsPatPmt(int Pid)'.
there is one more change you did not mention:
int PmtPid(void) const { return pmtPid; }
has been removed.
this breaks xineliboutput.
Sorry, that was a typing mistake. It should have been
- In order to be able to play TS recordings from other sources, in which
there is
more than one PMT PID in the PAT, 'int cPatPmtParser::PmtPid(void)'
has been changed
to 'bool cPatPmtParser::IsPmtPid(int Pid)'.
Klaus
Xine-plugin is broken too.
Is it possible to provide patch for fixing plugin compiling?
br,
A
--
br,
Arthur
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Fix for recording problem in VDR 1.7.20
30.08.2011 0:02, Dirk Vornheder kirjutas: Patch for remux.c doesn't fix the problem if i use my Hauppauge PVR-cards 500 ! With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. Aug 29 22:07:44 pcneu vdr: [20700] record /video0/ZIB_2/2011-08-29.21.57.13-0.rec Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2/2011-08-29.21.57.13-0.rec Aug 29 22:07:44 pcneu vdr: [20700] recording to '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/1.ts' Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2/2011-08-29.21.57.13-0.rec Aug 29 22:07:44 pcneu vdr: [21580] recording thread started (pid=20700, tid=21580) Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread started (pid=20700, tid=21581) Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 - accepted Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread started (pid=20700, tid=21582) Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of payload - buffering Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Can you please provide a 1 minute VDR recording from that device (made with the most recent developer version that works for you) and tell me where to download it? I doesn't know a ftp server where i can upload the 111 mb file. You can use any of filesharing providers. Rapidshare, for example. It allows up to 200MB file. A. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.19 recording issue
7.08.2011 12:51, Klaus Schmidinger kirjutas: On 06.07.2011 16:40, Arthur Konovalov wrote: On 6.07.2011 10:40, mike_booth76 wrote: Have you found a fix for this yet Arthur. I have the same problem but we seem to be the only two...Mike Hi! Actually I awaiting some actions or response from Klaus, because my C++ programming knowledge is very limited. The only real problem I see at the moment is the one causing distortions when switching from one file to the next during replay. This is apparently caused by a wrong index entry being generated at that point. I'm currently working on fixing that... Klaus It seems that with 1.7.20 my reported problem is gone. Thanks! br, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.19 recording issue
21.07.2011 18:56, VDR User kirjutas: On Thu, Jul 21, 2011 at 1:41 AM, Mike Boothmike_boot...@iprimus.com.au wrote: I've got round the problem of noty being able to play recordings made with vdr-1.7.19 by removing recorder.c recorder.h recording.c recording.h and remux.c remux.h and replacing them with the same files from vdr-1.7.18. Not very elegant but seems to work with new recordings and in the absebce of anything else You experience this problem with vanilla VDR? Or are you adding patches that may not have been updated to work properly with VDR-1.7.19? I've been using VDR-1.7.19, have made tons of recordings, and had no problems what-so-ever playing them back or playing back older recordings from previous versions. It seems overlapped thread name. I've posted with the same name own different problem: http://www.linuxtv.org/pipermail/vdr/2011-June/024938.html br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.19 recording issue
On 6.07.2011 10:40, mike_booth76 wrote: Have you found a fix for this yet Arthur. I have the same problem but we seem to be the only two...Mike Hi! Actually I awaiting some actions or response from Klaus, because my C++ programming knowledge is very limited. br, A ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.19 recording issue
Hello! At least one problematic channel on local cable network with recording problem discoverd using vdr-1.7.19. I have successfully recorded movie from Showtime channel by timer: Jun 27 03:59:00 akovdr vdr: [13440] switching device 4 to channel 20 Jun 27 03:59:00 akovdr vdr: [13440] actuator: switch to channel 20 Jun 27 03:59:00 akovdr vdr: [13440] timer 2 (20 0359-0450 'Langev taevas: Ela ja õpi (Falling Skies') start Jun 27 03:59:00 akovdr vdr: [13440] Title: 'Langev taevas: Ela ja õpi (Falling Skies Live and Learn, USA 2011)' Subtitle: '---' Jun 27 03:59:00 akovdr vdr: [13440] record /video/Langev_taevas#3A_Ela_ja_õpi_(Falling_Skies/2011-06-27.03.59.20-0.rec Jun 27 03:59:00 akovdr vdr: [13440] creating directory /video/Langev_taevas#3A_Ela_ja_õpi_(Falling_Skies Jun 27 03:59:00 akovdr vdr: [13440] creating directory /video/Langev_taevas#3A_Ela_ja_õpi_(Falling_Skies/2011-06-27.03.59.20-0.rec Jun 27 03:59:07 akovdr vdr: [13440] SpinUpDisk took 7.33 seconds Jun 27 03:59:07 akovdr vdr: [13440] recording to '/video/Langev_taevas#3A_Ela_ja_õpi_(Falling_Skies/2011-06-27.03.59.20-0.rec/1.ts' Jun 27 03:59:07 akovdr vdr: [16714] recording thread started (pid=13440, tid=16714) Jun 27 03:59:07 akovdr vdr: [16715] ecmhandler 3 filter thread started (pid=13440, tid=16715) Jun 27 03:59:07 akovdr vdr: [16716] receiver on device 4 thread started (pid=13440, tid=16716) Jun 27 03:59:07 akovdr vdr: [16717] TS buffer on device 4 thread started (pid=13440, tid=16717) Jun 27 03:59:07 akovdr vdr: [16718] logger 3 filter thread started (pid=13440, tid=16718) Jun 27 03:59:09 akovdr vdr: [16714] unknown frame delta (-1543570764), assuming 25.00 fps Jun 27 04:00:46 akovdr vdr: [13459] channel 20 (Showtime) event E 27.06.2011 04:00-05:00 'Langev taevas: Ela ja õpi (Falling Skies Live and Learn, USA 2011)' status 4 Jun 27 04:50:00 akovdr vdr: [16714] recording thread ended (pid=13440, tid=16714) Jun 27 04:50:00 akovdr vdr: [13440] buffer stats: 145136 (2%) used Jun 27 04:50:00 akovdr vdr: [13440] timer 2 (20 0359-0450 'Langev taevas: Ela ja õpi (Falling Skies') stop Jun 27 04:50:00 akovdr vdr: [16717] TS buffer on device 4 thread ended (pid=13440, tid=16717) Jun 27 04:50:00 akovdr vdr: [16716] buffer stats: 122952 (2%) used Jun 27 04:50:00 akovdr vdr: [16716] receiver on device 4 thread ended (pid=13440, tid=16716) Jun 27 04:50:01 akovdr vdr: [13440] cleaning up schedules data Jun 27 04:51:23 akovdr vdr: [13440] deleting timer 2 (20 0359-0450 'Langev taevas: Ela ja õpi (Falling Skies') Jun 27 04:55:15 akovdr vdr: [16715] ecmhandler 3 filter thread ended (pid=13440, tid=16715) Jun 27 04:55:15 akovdr vdr: [16718] logger 3 filter thread ended (pid=13440, tid=16718) But trying to replay this recording fails. It just doesn't start: Jun 27 12:20:56 akovdr vdr: [17860] replay /video/Langev_taevas#3A_Ela_ja_õpi_(Falling_Skies/2011-06-27.03.59.20-0.rec Jun 27 12:20:56 akovdr vdr: [17860] playing '/video/Langev_taevas#3A_Ela_ja_õpi_(Falling_Skies/2011-06-27.03.59.20-0.rec/1.ts' Jun 27 12:20:56 akovdr vdr: [17928] ttxtsubs player thread ended (pid=17860, tid=17928) Jun 27 12:20:56 akovdr vdr: [17860] buffer stats: 0 (0%) used Jun 27 12:20:56 akovdr vdr: [17860] ttxtsubs: teletext subtitles replayer started with initial page 000 Jun 27 12:20:56 akovdr vdr: [17929] ttxtsubs player thread started (pid=17860, tid=17929) Jun 27 12:20:56 akovdr vdr: [17930] dvbplayer thread started (pid=17860, tid=17930) Jun 27 12:20:56 akovdr vdr: [17930] resuming replay at index 0 (0:00:00.01) Jun 27 12:20:56 akovdr vdr: [17931] non blocking file reader thread started (pid=17860, tid=17931) Jun 27 12:20:56 akovdr vdr: [17927] TS buffer on device 3 thread ended (pid=17860, tid=17927) Jun 27 12:20:56 akovdr vdr: [17926] buffer stats: 99640 (2%) used Jun 27 12:20:56 akovdr vdr: [17926] receiver on device 3 thread ended (pid=17860, tid=17926) Jun 27 12:20:56 akovdr vdr: [17931] non blocking file reader thread ended (pid=17860, tid=17931) Jun 27 12:20:56 akovdr vdr: [17930] dvbplayer thread ended (pid=17860, tid=17930) Jun 27 12:20:57 akovdr vdr: [17929] ttxtsubs player thread ended (pid=17860, tid=17929) Jun 27 12:20:57 akovdr vdr: [17860] buffer stats: 0 (0%) used After reverting to the vdr-1.7.18 this recording still not playable with vdr. In the same time VLC media player doesn't have any problem with it and no problems with recording-playback on the another channels. Making a new record on the same channel with vdr-1.7.18 works normally. How to determine where problem is in 1.7.19 and how to fix it? I can upload recording sample somewhere if it helps. br, A ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request for rotor/actuator support integration to vdr
On 22.01.2011 20:31, Timothy D. Lenz wrote: VDR being a euro program where FTA sat is far more common should have really good support built in. I agree and awaiting too native rotor support in the vdr core. br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Order of adapters
JJussi wrote: Hi! This is maybe more Linux question than VDR... I have 3xPCI-DVB adapters and 1xUSB-DVB adapter. Where I can see what /dev/dvb/adapterX is connected to which physical devices.. And how I can made so that USB-adapter is (always) last in line... adapter3 OR VDR uses that adapter as a last resource! You can try to set DVB adapters order by udev rule. More info: http://osdir.com/ml/linux-media/2009-01/msg00145.html http://www.mythtv.org/wiki/Device_Filenames_and_udev ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput - choppy problem
Halim Sahin wrote: Have installed the xinelib-1.2-vdpau branch? ... You can download the right xinelib with vdpau support from hg with this command: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2-vdpau Default xine-lib-1.2 branch has already incorporated vdpau support and mentioned address just symlinked to it. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reelchannelscan rotor plugin don't compile with vdr 1.7.13
Goga777 wrote: hi can someone to create the patch for reelchannelscan and rotor plugin for correct compilation with vdr 1.7.13 arvdr:/usr/src/vdr-1.7.13/PLUGINS/src/reelchannelscan# make all g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='reelchannelscan' -DVDRDIR=\../../..\ -DBOOST_IOSTREAMS_NO_LIB -DNDEBUG -D__KERNEL_STRICT_NAMES -I../s2-liplianin/linux/include -I../../../include -I../../../s2-liplianin/linux/include scan.c scan.c: In member function ‘void cScan::ScanDVB_S(cTransponder*, cChannel*)’: scan.c:523: error: ‘class cChannel’ has no member named ‘Modulation’ scan.c:523: error: ‘class cChannel’ has no member named ‘CoderateH’ make: *** [scan.o] Ошибка 1 arvdr:/usr/src/vdr-1.7.13/PLUGINS/src/rotor# make all g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='rotor' -I../s2-liplianin/linux/include -I../../..//include -I../s2-liplianin/linux/include rotor.c rotor.c: In member function ‘virtual bool cPluginRotor::Start()’: rotor.c:96: error: no matching function for call to ‘cDiseqcs::Get(int, int, char)’ ../../..//include/vdr/diseqc.h:63: note: candidates are: cDiseqc* cDiseqcs::Get(int, int, int, char) rotor.c:96: error: no matching function for call to ‘cDiseqcs::Get(int, int, char)’ ../../..//include/vdr/diseqc.h:63: note: candidates are: cDiseqc* cDiseqcs::Get(int, int, int, char) rotor.c:96: error: no matching function for call to ‘cDiseqcs::Get(int, int, char)’ ../../..//include/vdr/diseqc.h:63: note: candidates are: cDiseqc* cDiseqcs::Get(int, int, int, char) rotor.c:96: error: no matching function for call to ‘cDiseqcs::Get(int, int, char)’ ../../..//include/vdr/diseqc.h:63: note: candidates are: cDiseqc* cDiseqcs::Get(int, int, int, char) make: *** [rotor.o] Ошибка 1 And this too: make[1]: Entering directory `/usr/local/src/vdr-1.7.13/PLUGINS/src/rotor-0.1.5' g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D__KERNEL_STRICT_NAMES -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DPLUGIN_NAME_I18N='rotor' -I/usr/local/src/s2/linux/include -I../../..//include -I/usr/local/src/s2/linux/include rotor.c g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -D__KERNEL_STRICT_NAMES -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DPLUGIN_NAME_I18N='rotor' -I/usr/local/src/s2/linux/include -I../../..//include -I/usr/local/src/s2/linux/include menu.c menu.c: In constructor ‘cMainMenuRotor::cMainMenuRotor()’: menu.c:142: error: ‘class cChannel’ has no member named ‘Polarization’ menu.c:142: error: ‘class cChannel’ has no member named ‘Polarization’ make[1]: *** [menu.o] Error 1 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ANNOUNCE vdr-ttxtsubs 0.2.0 for VDR 1.7.12
Tobi wrote: This release brings an update and major refactorings of the VDR patch for VDR 1.7.12. Good job! Please report any bugs, ideas or feature requests to the project site (no registration required for this!) I just applied new feature request #271 (Estonian translation files). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] rotor plugin puzzling question
Goga777 wrote: I couldn't apply a patch /usr/src/vdr/PLUGINS/src/rotor-0.1.5# cat patch1 | patch -p0 --dry-run patching file rotor.c patch: malformed patch at line 6: (diseqc=Diseqcs.Get(source-Code(),12000,'v')) || if ((diseqc=Diseqcs.Get(source-Code(),12000,'h')) || (diseqc=Diseqcs.Get(source-Code(),12000,'v')) || (diseqc=Diseqcs.Get(source-Code(),12000,'l')) || (diseqc=Diseqcs.Get(source-Code(),12000,'r'))) There only one line and it wrapped to 4 parts. You should join these parts to one line. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Lot of dashes in console
Joachim Wilke wrote: I have the same problem. Whenever VDR records a channel I also see lots of these dashes. When replaying such a recording the replay isn't smooth at these points. All of my recordings are effected by this. Has anyone a clue what the real problem is? Do You have FF card as primary device too? I suppose that this is problem reason (HW, driver?). By switching to xine output (xine-0.9.3 plugin) console stays clean and records are fine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Lot of dashes in console
Hi!
I observed that periodically appears lot of dashes in the console running my
vdr-1.7.9.
Probably this comes from this code in transfer.c:
if (cPlayer::IsAttached()) {
// Transfer Mode means live tv, so there's no point in doing any additional
// buffering here. The TS packets *must* get through here! However, every
// now and then there may be conditions where the packet just can't be
// handled when offered the first time, so that's why we try several times:
for (int i = 0; i 100; i++) {
if (PlayTs(Data, Length) 0)
return;
fprintf(stderr, -);//XXX just for testing - remove when stable
cCondWait::SleepMs(10);
}
esyslog(ERROR: TS packet not accepted in Transfer Mode);
}
In syslog sometimes the following can be found:
Sep 27 10:14:07 vdr vdr: [4806] ERROR: TS packet not accepted in Transfer Mode
Sep 27 11:22:02 vdr vdr: [5035] ERROR: TS packet not accepted in Transfer Mode
Sep 27 16:06:19 vdr vdr: [5168] ERROR: TS packet not accepted in Transfer Mode
Sep 27 20:52:02 vdr vdr: [5362] ERROR: TS packet not accepted in Transfer Mode
What does this mean? Is it TS handling problem in vdr or hardware related?
How bad is it and how to find the cause of this?
Can it be reason why sometimes recordings are corrupted?
I have 1 FF Nexus DVB-S (primary output device) and 2 DVB-C PCI cards on P4 HT
2.4GHz PC.
AK
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
Klaus Schmidinger wrote: I first have to debug the fast forwarding in SF2 recordings problem. Not only SF2 (if You meant Schweizer Fernsehen). I discovered that with recordings from local cable operator fast forwarding not working too. Old 1.6.0's .vdr recordings are fine with 1.7.9. Output via FF card. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.7 crashes during starting wiith rotor plugin
Goga777 wrote: what's rotor-0.1.4S2API ? does it patched rotor plugin ? Yes, it patched for S2API. Found at: http://ubuntuforums.org/showthread.php?t=1126258 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.7 crashes during starting wiith rotor plugin
Bikalexander wrote: Please try this version, I did not had to test it: http://www.vdr-settings.com/hg/vdr-plugins/ http://www.vdr-settings.com/hg/vdr-plugins/archive/tip.tar.bz2 Thank You, but no luck. Crashes too. Content of this repository almost same as I have. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.7 crashes during starting wiith rotor plugin
marti...@embl.de wrote: Lacking that, you can visit my howto http://ubuntuforums.org/showthread.php?t=1126258 and download the patched rotor plugin from there. Do not patch it anymore, just enable ROTOR = 1 in your Make.config (with the extensions patch) and it will compile ok and run on startup. Compiled from scratch. But again, I have: r...@akovdr2# ./vdr -l 3 -w 60 -c /usr/local/etc/vdr -E /usr/local/etc/vdr -L /usr/local/vdr/PLUGINS/lib -P rotor -P 'xine -r -q' *** glibc detected *** ./vdr: munmap_chunk(): invalid pointer: 0x082babf4 *** === Backtrace: = /lib/libc.so.6(cfree+0x1bc)[0xb7ca513c] /usr/local/vdr/PLUGINS/lib/libvdr-rotor.so.1.7.7(_ZN12cPluginRotor5StartEv+0x275)[0xb7b1b8c5] ./vdr(_ZN14cPluginManager12StartPluginsEv+0x3f)[0x80e564f] ./vdr(main+0x15da)[0x811692a] /lib/libc.so.6(__libc_start_main+0xe0)[0xb7c4c390] ./vdr[0x808bee1] Is there important version of kernel, dvb driver or gcc? I have kernel 2.6.27.7, dvd driver from endriss repository, gcc-4.2.4. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Where do you live and what kind of broadcast do you receive?
Country: Estonia Transmission: DVB-C, DVB-T, DVB-S Encoding: MPEG-2 for DVB-C and DVB-S, H264 for DVB-T Few for DVB-T HD (H264) and DVB-C HD (MPEG-2 and H264). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] rotor and vdr
Ales Jurik wrote: Original patch from Seppo (vdr-1.5.16): http://www.mail-archive.com/vdr@linuxtv.org/msg05864.html Patches for 1.6.0 and 1.7.0 (could be used up to 1.7.4): http://www.linuxtv.org/pipermail/vdr/2008-September/017637.html Do You have any additional hints? It doesn't compiles with vdr-1.7.4 :( AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] only single channel handled by CAM and no teletext on encrypted channels.
Simon Siemonsma wrote: System: Distribution: Gentoo (amd64) vdr version: 1.6.0_p2 single card Technotrend budget T1500 with CI cart. CAM: Conax cam by Smit. Output on OSD: 7 Setup - 5 CAM - 1 Conax Conditional Access - 9 About Conax CA Number of sessions: 5 Output of cat /var/log/messages | grep vdr | grep CAM: [20686] CAM 1: assigned to device 1 [21000] CAM 1: module present [21000] CAM 1: module ready [21000] CAM 1: Conax Conditional Access, 01, CAFE, BABE [21000] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted To me this doesn't look correct. 5 sessions according to the CAM menu and only a single channel can be decripted. I saw something on the mailinglist dated april. However I didn't understand how it was solved. Probable because there was also another problem. It was solved by adding 2 and change 1 lines in ci.c file. However it is dirty hack, but it works for me and problem forgotten. Links: http://www.linuxtv.org/pipermail/vdr/2008-April/016525.html http://www.linuxtv.org/pipermail/vdr/attachments/20080415/d4fbfbe8/attachment.txt I don't how helpful it will be in Your case. I was sure that my Technisat CAM can do multiple decriptions. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] int. no A or V on new C-1501 card
Simon Baxter wrote: I can't get any signal strength on some channels - have posted to the linux-dvb list for this. I haven't signal on two frequencies: 322 and 386 MHz But when I do get a channel tuned ok, the audio starts/stops/starts/stops/starts - and sometimes just starts/stops and then stays off. I'm running vdr-xine 0.8.2. On working channels this card works fine for me, no audio issues. Running DVB-S FF card as primary device. Should I be changing to the multi-proto drivers - there's no h264 or HD on my cable provider yet. I don't know, but I'm using multiproto drivers (I have DVB-S2 card on my system). Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xine-Lib failed with external-ffmpeg option?
H. Onur wrote: hi, i get this message when compiling xine-lib with external ffmpeg and latest ffmpeg svn. xineplug_post_planar_la-pp.lo -MD -MP -MF .deps/xineplug_post_planar_la-pp.Tpo -c pp.c -fPIC -DPIC -o .libs/xineplug_post_planar_la-pp.o pp.c:31:27: error: postprocess.h: No such file or directory pp.c:57: error: 'PP_QUALITY_MAX' undeclared here (not in a function) pp.c:77: error: expected specifier-qualifier-list before 'pp_context_t' pp.c: In function 'set_parameters': pp.c:88: error: 'post_plugin_pp_t' has no member named 'lock' I solved this error with dirty hack: commented out HAVE_FFMPEG_AVUTIL_H in include/configure.h. xine-lib-1.2 hg. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No frontend on VP-2040
Peter Fassberg wrote: Hej! Vad har du för roligt projekt på gång som behöver 6 st kort? :-) Jag har planerat ett streamingprojekt men jag får tyvärr aldrig någon tid över till att komma igång. Sorry, we usually don't understand here in list på svenska :) Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Thousands of M in xine-vdr console
I have a question/problem, maybe someone can explain it. I'm using vdr with xine plugin and run it in console. Sometimes in console appears many-many M characters and it stops only after disconnect xine player (Shift-S). After new connect (Enter) all works again. What is it and how to eliminate this behavior? AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiple decryption with TechniCrypt CW CAM
Arthur Konovalov wrote:
Klaus Schmidinger wrote:
Can you narrow down which of these three changes is actually necessary
to make it work?
I can repeat tests tomorrow, but I recall that this (it was first change):
state = 4; // normal operation
+ repliesToQuery = true; //AK
}
and this (next change, because first doesn't help and I saw replays to
query: Slot 1: == Ca Pmt Reply (3) 1144 01 82 2210=82 2211=82):
dbgprotocol(\n);
}
+ state = 6; //AK
break;
was necessary in this case.
Confirmed, only with those 2 changes multiple decryption works.
#define QUERY_WAIT_TIME 3000 // ms to wait before sending a query
Will try tomorrow.
Doesn't help.
Added syslog debug entries like this:
if (l = 2){
ok = CA_ENABLE(caepl) == CAEI_POSSIBLE;
dsyslog(AK: CA_ENABLE(caepl): %d, ok: %d, CA_ENABLE(caepl),ok);
}
while (l 2) {
uint16_t pid = ((uint16_t)(*d) 8) | *(d + 1);
unsigned char caees = *(d + 2);
dbgprotocol( %d=%02X, pid, caees);
d += 3;
l -= 3;
dsyslog(AK: CA_ENABLE(caees): %d, ok: %d,
CA_ENABLE(caees),ok);
if (CA_ENABLE(caees) != CAEI_POSSIBLE){
ok = false;
dsyslog(AK: ok set to false. state: %d, state);
}
}
if (ok){
dsyslog(AK: ok true!);
state = 6; // descrambling possible
}
}
}
}
dbgprotocol(\n);
}
dsyslog(AK: state: %d, state);
break;
And syslog (with 'repliesToQuery = true;' only):
Apr 16 11:00:35 vdr vdr: [17443] switching to channel 136
Apr 16 11:00:36 vdr vdr: [17447] AK: CA_ENABLE(caees): 2, ok: 1
Apr 16 11:00:36 vdr vdr: [17447] AK: ok set to false. state: 5
Apr 16 11:00:36 vdr vdr: [17447] AK: CA_ENABLE(caees): 2, ok: 0
Apr 16 11:00:36 vdr vdr: [17447] AK: ok set to false. state: 5
Apr 16 11:00:36 vdr vdr: [17447] AK: state: 5
Apr 16 11:00:36 vdr vdr: [17443] info: Channel not available!
It seems that 'if (CA_ENABLE(caees) != CAEI_POSSIBLE)' is reason of fault and
'state' always stay false.
Unfortunately I don't understand this logic here :/
Arthur
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiple decryption with TechniCrypt CW CAM
Klaus Schmidinger wrote:
Does the log really end at that point?
If there is no Ca Pmt Reply then the CAM doesn't reply to
the query.
That is, no reply in this point.
Because I got second confirmation from TechniSat Support about multiple
decryption possibility, I made small test changes in ci.c file (ci.diff).
After that multiple decryption works! I know, this is not right solution, but
now it proved that CAM works in principle. Why it doesn't reply to query at vdr
startup, i don't know, but later it does (log.txt).
Any ideas for an elegant solution?
Arthur
--- ci.c.orig 2008-04-15 14:55:59.0 +0300
+++ ci.c2008-04-15 14:58:41.0 +0300
@@ -771,6 +771,7 @@
}
dbgprotocol(\n);
}
+ state = 6; //AK
break;
default: esyslog(ERROR: CAM %d: conditional access support: unknown
tag %06X, Tc()-CamSlot()-SlotNumber(), Tag);
}
@@ -789,6 +790,7 @@
else if (state == 3 timer.TimedOut()) {
dsyslog(CAM %d: doesn't reply to QUERY - only a single channel can be
decrypted, Tc()-CamSlot()-SlotNumber());
state = 4; // normal operation
+ repliesToQuery = true; //AK
}
}
@@ -1888,7 +1890,7 @@
}
}
-#define QUERY_REPLY_WAIT 100 // ms to wait between checks for a reply
+#define QUERY_REPLY_WAIT 300 // ms to wait between checks for a reply //AK
bool cCamSlot::CanDecrypt(const cChannel *Channel)
{
[EMAIL PROTECTED]:~# runvdr
Slot 1: reset...ok.
Slot 1: module present
Slot 1: module ready
Slot 1: creating connection 0/1
-
MakePrimaryDevice: 1
=
SetVideoFormat: 0
SetVolumeDevice: 200
Slot 1: create connection 0/1
1: -- 00 01 82 01 01
1: -- 00 01 83 01 01 80 02 01 00
. . . . . . . . .
Slot 1: connection created 0/1
Slot 1: receive data 0/1
1: -- 00 01 81 01 01
1: -- 00 01 A0 07 01 91 04 00 01 00 41 80 02 01 00
. . . . . . . . . . A . . . .
Slot 1: open session 00010041
Slot 1: new Resource Manager (session id 1)
1: -- 00 01 A0 0A 01 92 07 00 00 01 00 41 00 01
Slot 1: == Profile Enq (1)
1: -- 00 01 A0 09 01 90 02 00 01 9F 80 10 00
Slot 1: receive data 0/1
1: -- 00 01 81 01 01
1: -- 00 01 A0 09 01 90 02 00 01 9F 80 11 00 80 02 01 00
. . . . . . . . . . . . . . . . .
Slot 1: == Profile (1)
Slot 1: == Profile Change (1)
1: -- 00 01 A0 09 01 90 02 00 01 9F 80 12 00
Slot 1: receive data 0/1
1: -- 00 01 81 01 01
1: -- 00 01 A0 09 01 90 02 00 01 9F 80 10 00 80 02 01 00
. . . . . . . . . . . . . . . . .
Slot 1: == Profile Enquiry (1)
Slot 1: == Profile (1)
1: -- 00 01 A0 1D 01 90 02 00 01 9F 80 11 14 00 01 00 41 00 02 00 41 00
03 00 41 00 24 00 41 00 40 00 41
Slot 1: receive data 0/1
1: -- 00 01 81 01 01
1: -- 00 01 A0 07 01 91 04 00 02 00 41 80 02 01 00
. . . . . . . . . . A . . . .
Slot 1: open session 00020041
Slot 1: new Application Information (session id 2)
1: -- 00 01 A0 0A 01 92 07 00 00 02 00 41 00 02
Slot 1: == Application Info Enq (2)
1: -- 00 01 A0 09 01 90 02 00 02 9F 80 20 00
Slot 1: receive data 0/1
1: -- 00 01 81 01 01
1: -- 00 01 A0 1E 01 90 02 00 02 9F 80 21 15 01 00 00 03 3D 0F 54 53 44
20 43 72 79 70 74 20 43 6F 6E 61 78 80 02 01 00
. . . . . . . . . . . ! . . . . . = . T S D
C r y p t C o n a x . . . .
Slot 1: == Application Info (2)
Slot 1: receive data 0/1
1: -- 00 01 81 01 01
1: -- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00
. . . . . . . . . . A . . . .
Slot 1: open session 00030041
Slot 1: new Conditional Access Support (session id 3)
1: -- 00 01 A0 0A 01 92 07 00 00 03 00 41 00 03
Slot 1: == Ca Info Enq (3)
1: -- 00 01 A0 09 01 90 02 00 03 9F 80 30 00
Slot 1: receive data 0/1
1: -- 00 01 81 01 01
1: -- 00 01 A0 0B 01 90 02 00 03 9F 80 31 02 0B 00 80 02 01 00
. . . . . . . . . . . 1 . . . . . . .
Slot 1: == Ca Info (3) 0B00
Slot 1: == Ca Pmt (3) 3 3
1: -- 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03
Slot 1: == Ca Pmt (3) 4 1
1: -- 00 01 A0 1A 01 90 02 00 03 9F 80 32 11 04 04 42 01 00 01 01 02 08
C0 00 00 04 08 C1 00 00
SetAudioChannelDevice: 0
SetDigitalAudioDevice: 0
SetAudioChannelDevice: 0
SetVolumeDevice: 200
SetPlayMode: 1
frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00)
SetPlayMode: 0
Slot 1: == Ca Pmt (3) 5 1
1: -- 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 04 42 01 00 07 01 09 04
0B 00 E3 EC
Slot 1: == Ca Pmt (3) 4 1
1: -- 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 04 42 01 00 07 01 09 04
0B 00 E3 EC 02 08 C0 00 00 04 08 C1 00 00
SetAudioChannelDevice: 0
SetDigitalAudioDevice: 0
SetAudioChannelDevice: 0
SetPlayMode: 1
video: synced early
vdr-xine: Client connecting ...
vdr-xine: Client connected
Re: [vdr] Multiple decryption with TechniCrypt CW CAM
Klaus Schmidinger wrote: Can you narrow down which of these three changes is actually necessary to make it work? I can repeat tests tomorrow, but I recall that this (it was first change): state = 4; // normal operation + repliesToQuery = true; //AK } and this (next change, because first doesn't help and I saw replays to query: Slot 1: == Ca Pmt Reply (3) 1144 01 82 2210=82 2211=82): dbgprotocol(\n); } + state = 6; //AK break; was necessary in this case. #define QUERY_REPLY_TIMEOUT 5000 // ms to wait for a reply to a query (change 2000 to 5000 in this line). If this doesn't help, try Previously tried with 6000, negative. #define QUERY_WAIT_TIME 3000 // ms to wait before sending a query Will try tomorrow. Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote: Meanwhile I increased constant MODULE_CHECK_INTERVAL to 300 ms and now syslog looks much better. At any rate, if this really fixes the problem for you (please let us know whether it actually work in the long run) I guess it shouldn't be wrong to generally set this timeout to 300ms - or maybe even more? It seems stable with 300ms with my CAM, but for reliability reason I set it to 500ms. Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Multiple decryption with TechniCrypt CW CAM
Klaus Schmidinger wrote: Please start a new thread for a new topic ( I've at least changed the subject). Yes, You are right. Sorry. Please activate the DumpTPDUDataTransfer and DebugProtocol switches in ci.c and check whether VDR receives a reply to its QUERY. Honestly, I don't understand what info is exchanged. :/ File attached. Arthur Slot 1: reset...ok. Slot 1: module present Slot 1: module ready Slot 1: creating connection 0/1 Slot 1: create connection 0/1 1: -- 00 01 82 01 01 1: -- 00 01 83 01 01 80 02 01 00 . . . . . . . . . Slot 1: connection created 0/1 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 07 01 91 04 00 01 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00010041 Slot 1: new Resource Manager (session id 1) 1: -- 00 01 A0 0A 01 92 07 00 00 01 00 41 00 01 Slot 1: == Profile Enq (1) 1: -- 00 01 A0 09 01 90 02 00 01 9F 80 10 00 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 09 01 90 02 00 01 9F 80 11 00 80 02 01 00 . . . . . . . . . . . . . . . . . Slot 1: == Profile (1) Slot 1: == Profile Change (1) 1: -- 00 01 A0 09 01 90 02 00 01 9F 80 12 00 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 09 01 90 02 00 01 9F 80 10 00 80 02 01 00 . . . . . . . . . . . . . . . . . Slot 1: == Profile Enquiry (1) Slot 1: == Profile (1) 1: -- 00 01 A0 1D 01 90 02 00 01 9F 80 11 14 00 01 00 41 00 02 00 41 00 03 00 41 00 24 00 41 00 40 00 41 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 07 01 91 04 00 02 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00020041 Slot 1: new Application Information (session id 2) 1: -- 00 01 A0 0A 01 92 07 00 00 02 00 41 00 02 Slot 1: == Application Info Enq (2) 1: -- 00 01 A0 09 01 90 02 00 02 9F 80 20 00 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 1E 01 90 02 00 02 9F 80 21 15 01 00 00 03 3D 0F 54 53 44 20 43 72 79 70 74 20 43 6F 6E 61 78 80 02 01 00 . . . . . . . . . . . ! . . . . . = . T S D C r y p t C o n a x . . . . Slot 1: == Application Info (2) Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00030041 Slot 1: new Conditional Access Support (session id 3) 1: -- 00 01 A0 0A 01 92 07 00 00 03 00 41 00 03 Slot 1: == Ca Info Enq (3) 1: -- 00 01 A0 09 01 90 02 00 03 9F 80 30 00 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 0B 01 90 02 00 03 9F 80 31 02 0B 00 80 02 01 00 . . . . . . . . . . . 1 . . . . . . . Slot 1: == Ca Info (3) 0B00 Slot 1: == Ca Pmt (3) 3 3 1: -- 00 01 A0 10 01 90 02 00 03 9F 80 32 07 03 00 00 01 00 01 03 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote:
Since cCamSlot::Reset() is the only place where resetTime is set to
a non-zero value, and you had lines like resetTime1: 1207548401 in
your syslog_1 file, apparently the tc[i]-Process() call in
cCamSlot::Process() must have failed.
Yes, reset came from this procedure.
I added some printouts (look at attached diff).
How to see reason why this Reset() is called?
Arthur
--- ci.c.orig 2008-04-11 21:20:00.0 +0300
+++ ci.c2008-04-11 23:37:16.0 +0300
@@ -1625,6 +1625,7 @@
for (int i = 1; i = MAX_CONNECTIONS_PER_CAM_SLOT; i++) {
if (tc[i]) {
if (!tc[i]-Process()) {
+ isyslog(CAM DEBUG: Reset calling i=%d, tc[i]=%d, i, tc[i]); //AK
Reset();
return;
}
@@ -1681,16 +1682,20 @@
bool cCamSlot::Reset(void)
{
+ isyslog(CAM DEBUG: Reset called); //AK
cMutexLock MutexLock(mutex);
ChannelCamRelations.Reset(slotNumber);
DeleteAllConnections();
if (ciAdapter) {
dbgprotocol(Slot %d: reset..., slotNumber);
+ isyslog(CAM DEBUG: Slot %d: reset..., slotNumber); //AK
if (ciAdapter-Reset(slotIndex)) {
resetTime = time(NULL);
dbgprotocol(ok.\n);
+isyslog(CAM DEBUG: ok); //AK
return true;
}
+ isyslog(CAM DEBUG: failed); //AK
dbgprotocol(failed!\n);
}
return false;
@@ -1700,11 +1705,15 @@
{
cMutexLock MutexLock(mutex);
eModuleStatus ms = ciAdapter ? ciAdapter-ModuleStatus(slotIndex) : msNone;
+ isyslog(CAM DEBUG: ms: %d resetTime: %d, ms, resetTime); //AK
if (resetTime) {
if (ms = msReset) {
-if (time(NULL) - resetTime MODULE_RESET_TIMEOUT)
+ isyslog(CAM DEBUG: ms le msReset); //AK
+if (time(NULL) - resetTime MODULE_RESET_TIMEOUT) {
+ isyslog(CAM DEBUG: return msReset); //AK
return msReset;
}
+}
resetTime = 0;
}
return ms;
Apr 11 23:40:31 akovdr2 vdr: [6914] cTimeMs: using monotonic clock (resolution
is 4000250 ns)
Apr 11 23:40:31 akovdr2 vdr: [6914] VDR version 1.6.0 started
Apr 11 23:40:31 akovdr2 vdr: [6914] codeset is 'UTF-8' - known
Apr 11 23:40:31 akovdr2 vdr: [6914] found 23 locales in
/usr/local/src/vdr-1.6.0/locale
Apr 11 23:40:31 akovdr2 vdr: [6914] loading plugin:
/usr/local/vdr/PLUGINS/lib/libvdr-xine.so.1.6.0
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/setup.conf
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/sources.conf
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/diseqc.conf
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/channels.conf
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/timers.conf
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/svdrphosts.conf
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/remote.conf
Apr 11 23:40:31 akovdr2 vdr: [6914] loading /usr/local/etc/vdr/keymacros.conf
Apr 11 23:40:31 akovdr2 vdr: [6915] video directory scanner thread started
(pid=6914, tid=6915)
Apr 11 23:40:31 akovdr2 vdr: [6915] video directory scanner thread ended
(pid=6914, tid=6915)
Apr 11 23:40:31 akovdr2 vdr: [6916] video directory scanner thread started
(pid=6914, tid=6916)
Apr 11 23:40:31 akovdr2 vdr: [6916] video directory scanner thread ended
(pid=6914, tid=6916)
Apr 11 23:40:31 akovdr2 vdr: [6914] reading EPG data from
/usr/local/etc/vdr/epg.data
Apr 11 23:40:31 akovdr2 vdr: [6914] probing /dev/dvb/adapter0/frontend0
Apr 11 23:40:31 akovdr2 vdr: [6914] CAM DEBUG: Reset called
Apr 11 23:40:31 akovdr2 vdr: [6914] CAM DEBUG: Slot 1: reset...
Apr 11 23:40:31 akovdr2 vdr: [6914] CAM DEBUG: ok
Apr 11 23:40:31 akovdr2 vdr: [6918] CI adapter on device 0 thread started
(pid=6914, tid=6918)
Apr 11 23:40:31 akovdr2 vdr: [6918] CAM DEBUG: ms: 2 resetTime: 1207946431
Apr 11 23:40:31 akovdr2 vdr: [6918] CAM 1: module present
Apr 11 23:40:31 akovdr2 vdr: [6918] CAM DEBUG: ms: 2 resetTime: 0
Apr 11 23:40:31 akovdr2 vdr: [6919] tuner on device 1 thread started (pid=6914,
tid=6919)
Apr 11 23:40:31 akovdr2 vdr: [6920] section handler thread started (pid=6914,
tid=6920)
Apr 11 23:40:31 akovdr2 vdr: [6914] found 1 video device
Apr 11 23:40:31 akovdr2 vdr: [6914] initializing plugin: xine (0.8.2): Software
based playback using xine
Apr 11 23:40:31 akovdr2 vdr: [6921] XineRemote control thread started
(pid=6914, tid=6921)
Apr 11 23:40:31 akovdr2 vdr: [6921] Entering cXineRemote thread
Apr 11 23:40:31 akovdr2 vdr: [6914] setting primary device to 2
Apr 11 23:40:31 akovdr2 vdr: [6914] assuming manual start of VDR
Apr 11 23:40:31 akovdr2 vdr: [6914] SVDRP listening on port 2001
Apr 11 23:40:31 akovdr2 vdr: [6914] setting current skin to sttng
Apr 11 23:40:31 akovdr2 vdr: [6914] loading
/usr/local/etc/vdr/themes/sttng-default.theme
Apr 11 23:40:31 akovdr2 vdr: [6914] starting plugin: xine
Apr 11 23:40:31 akovdr2 vdr: [6924] KBD remote control thread started
(pid=6914, tid=6924)
Apr 11 23:40:31 akovdr2 vdr: [6914
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote: Well, actually it's only one place there where false is returned, and that's when the alive timer times out, which is apparently after the 2 seconds between the resets you're observing, see #define TC_ALIVE_TIMEOUT 2000 One possible test would be to increase this time and see whether this increases the distance between resets - or makes them go away at all. Depending on the result of this test we'll see how to continue. Meanwhile I increased constant MODULE_CHECK_INTERVAL to 300 ms and now syslog looks much better. Currently I have not display (ssh session only) and can't verify final result. Is it possible that is OK now? Arthur Apr 12 00:00:03 akovdr2 vdr: [7372] cTimeMs: using monotonic clock (resolution is 4000250 ns) Apr 12 00:00:03 akovdr2 vdr: [7372] VDR version 1.6.0 started Apr 12 00:00:03 akovdr2 vdr: [7372] codeset is 'UTF-8' - known Apr 12 00:00:03 akovdr2 vdr: [7372] found 23 locales in /usr/local/src/vdr-1.6.0/locale Apr 12 00:00:03 akovdr2 vdr: [7372] loading plugin: /usr/local/vdr/PLUGINS/lib/libvdr-xine.so.1.6.0 Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/setup.conf Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/sources.conf Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/diseqc.conf Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/channels.conf Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/timers.conf Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/svdrphosts.conf Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/remote.conf Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/keymacros.conf Apr 12 00:00:03 akovdr2 vdr: [7373] video directory scanner thread started (pid=7372, tid=7373) Apr 12 00:00:03 akovdr2 vdr: [7373] video directory scanner thread ended (pid=7372, tid=7373) Apr 12 00:00:03 akovdr2 vdr: [7374] video directory scanner thread started (pid=7372, tid=7374) Apr 12 00:00:03 akovdr2 vdr: [7374] video directory scanner thread ended (pid=7372, tid=7374) Apr 12 00:00:03 akovdr2 vdr: [7372] reading EPG data from /usr/local/etc/vdr/epg.data Apr 12 00:00:03 akovdr2 vdr: [7372] probing /dev/dvb/adapter0/frontend0 Apr 12 00:00:03 akovdr2 vdr: [7372] CAM DEBUG: Reset called Apr 12 00:00:03 akovdr2 vdr: [7372] CAM DEBUG: Slot 1: reset... Apr 12 00:00:03 akovdr2 vdr: [7372] CAM DEBUG: ok Apr 12 00:00:03 akovdr2 vdr: [7376] CI adapter on device 0 thread started (pid=7372, tid=7376) Apr 12 00:00:03 akovdr2 vdr: [7376] CAM 1: module present Apr 12 00:00:03 akovdr2 vdr: [7377] tuner on device 1 thread started (pid=7372, tid=7377) Apr 12 00:00:03 akovdr2 vdr: [7378] section handler thread started (pid=7372, tid=7378) Apr 12 00:00:03 akovdr2 vdr: [7372] found 1 video device Apr 12 00:00:03 akovdr2 vdr: [7372] initializing plugin: xine (0.8.2): Software based playback using xine Apr 12 00:00:03 akovdr2 vdr: [7379] XineRemote control thread started (pid=7372, tid=7379) Apr 12 00:00:03 akovdr2 vdr: [7379] Entering cXineRemote thread Apr 12 00:00:03 akovdr2 vdr: [7372] setting primary device to 2 Apr 12 00:00:03 akovdr2 vdr: [7372] assuming manual start of VDR Apr 12 00:00:03 akovdr2 vdr: [7372] SVDRP listening on port 2001 Apr 12 00:00:03 akovdr2 vdr: [7372] setting current skin to sttng Apr 12 00:00:03 akovdr2 vdr: [7372] loading /usr/local/etc/vdr/themes/sttng-default.theme Apr 12 00:00:03 akovdr2 vdr: [7372] starting plugin: xine Apr 12 00:00:03 akovdr2 vdr: [7382] KBD remote control thread started (pid=7372, tid=7382) Apr 12 00:00:03 akovdr2 vdr: [7372] ERROR: remote control XineRemote not ready! Apr 12 00:00:03 akovdr2 vdr: [7372] remote control KBD - keys known Apr 12 00:00:03 akovdr2 kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Apr 12 00:00:03 akovdr2 vdr: [7376] CAM 1: module ready Apr 12 00:00:05 akovdr2 vdr: [7376] CAM 1: TSD Crypt Conax, 01, , 033D Apr 12 00:00:11 akovdr2 vdr: [7376] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted Apr 12 00:00:11 akovdr2 vdr: [7372] setting watchdog timer to 30 seconds Apr 12 00:00:11 akovdr2 vdr: [7372] switching to channel 1 Apr 12 00:00:11 akovdr2 vdr: [7383] transfer thread started (pid=7372, tid=7383) Apr 12 00:00:11 akovdr2 vdr: [7384] receiver on device 1 thread started (pid=7372, tid=7384) Apr 12 00:00:11 akovdr2 vdr: [7385] TS buffer on device 1 thread started (pid=7372, tid=7385) Apr 12 00:00:17 akovdr2 vdr: [7372] max. latency time 1 seconds Apr 12 00:00:20 akovdr2 vdr: [7377] frontend 0 timed out while tuning to channel 1, tp 112187 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Now I have next question/problem. From Technisat support I have the following answer: Our CAM TechniCrypt CW is able to do multiple parallel decryptions since the software version 26.1.5.0.11 I have this firmware: Conax CA About 0. Quit menu 1. Software version: 26.1.5.0.11 2. Interface version: 0x40 3. Smart card number: 014 6900 0921 - 3 4. Number of sessions: 5 5. Language: 44 6. CA_SYS_ID: 0x0B00 SE But line from syslog says: CAM 1: doesn't reply to QUERY - only a single channel can be decrypted Is it possible to verify is it true or is there misunderstanding somewhere? Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote: So does this mean that with the small test.c program the module status is continuously going on and off, without VDR even being involved? No. It just exit. Can you post more than the above 4 lines from ./test (like 20 or so)? test* test.c [EMAIL PROTECTED]:/video/vdr/cam# ./test 0.08: 3 0.000161: 0 0.014133: 1 1.694142: 3 [EMAIL PROTECTED]:/video/vdr/cam# ./test 0.08: 3 0.000193: 0 0.012121: 1 1.692260: 3 [EMAIL PROTECTED]:/video/vdr/cam# ./test 0.09: 3 0.87: 0 0.013873: 1 1.694011: 3 If the communication with the CAM fails, how should VDR continue to work with it? I don't know, but Kaffeine works. Sorry, nothing personal, just remark for clarity that success is possible with same hardware. Regards, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote:
Please change the line
for (i = 0; i 200; ++i) {
so that it loop 2000 times. That should cover a longer time.
I see. Set to 4000.
Additionally added before 'return 0;':
printf(end: );
print_status(status);
Now it loops about 50 seconds :
[EMAIL PROTECTED]:/video/vdr/cam# ./test
0.10: 3
0.88: 0
0.012613: 1
1.692749: 3
end: 48.004572: 3
Arthur
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR continuously initializing CAM
Klaus Schmidinger wrote: The problem is that this malfunction happens on *your* system, not on *mine*. So I'm afraid I can't be of too much help in debugging this. What about ssh console to my PC? I'm really don't want to abandon VDR!! Regards, AK ___ 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
Re: [vdr] VDR continuously initializing CAM
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.
AK
Klaus Schmidinger wrote:
Looks like the lastModuleStatus for some reason falls back
to msReset.
Please dd some debug output to
cCamSlot::ModuleStatus() to see what's going on around
ciAdapter-ModuleStatus(slotIndex) and resetTime.
Maybe resetTime should be handled in milliseconds, using
a cTimeMs...
Apr 7 09:06:37 vdr vdr: [4862] cTimeMs: using monotonic clock (resolution is
4000250 ns)
Apr 7 09:06:37 vdr vdr: [4862] VDR version 1.6.0 started
Apr 7 09:06:37 vdr vdr: [4862] codeset is 'UTF-8' - known
Apr 7 09:06:37 vdr vdr: [4862] found 23 locales in
/usr/local/src/vdr-1.6.0/locale
Apr 7 09:06:37 vdr vdr: [4862] loading plugin:
/usr/local/src/vdr-1.6.0-vanilla/PLUGINS/lib/libvdr-xine.so.1.6.0
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/setup.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/sources.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/diseqc.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/channels.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/timers.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/commands.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/reccmds.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/svdrphosts.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/remote.conf
Apr 7 09:06:37 vdr vdr: [4862] loading /usr/local/etc/vdr/keymacros.conf
Apr 7 09:06:37 vdr vdr: [4863] video directory scanner thread started
(pid=4862, tid=4863)
Apr 7 09:06:37 vdr vdr: [4864] video directory scanner thread started
(pid=4862, tid=4864)
Apr 7 09:06:37 vdr vdr: [4862] reading EPG data from
/usr/local/etc/vdr/epg.data
Apr 7 09:06:37 vdr vdr: [4863] video directory scanner thread ended (pid=4862,
tid=4863)
Apr 7 09:06:37 vdr vdr: [4864] video directory scanner thread ended (pid=4862,
tid=4864)
Apr 7 09:06:38 vdr vdr: [4862] probing /dev/dvb/adapter0/frontend0
Apr 7 09:06:38 vdr vdr: [4866] tuner on device 1 thread started (pid=4862,
tid=4866)
Apr 7 09:06:38 vdr vdr: [4867] section handler thread started (pid=4862,
tid=4867)
Apr 7 09:06:38 vdr vdr: [4862] probing /dev/dvb/adapter1/frontend0
Apr 7 09:06:38 vdr vdr: [4869] CI adapter on device 1 thread started
(pid=4862, tid=4869)
Apr 7 09:06:38 vdr kernel: DVB: TDA10021(1): _tda10021_writereg, writereg
error (reg == 0x01, val == 0x6a, ret == -121)
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 1207548398
Apr 7 09:06:38 vdr vdr: [4869] resetTime2: 1207548398
Apr 7 09:06:38 vdr vdr: [4869] CAM 1: module present
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:38 vdr vdr: [4869] ms: 2
Apr 7 09:06:38 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] ms: 2
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] ms: 2
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr kernel: dvb_ca adapter 1: DVB CAM detected and initialised
successfully
Apr 7 09:06:39 vdr vdr: [4869] ms: 3
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] CAM 1: module ready
Apr 7 09:06:39 vdr vdr: [4869] ms: 3
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] ms: 3
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] ms: 3
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] ms: 3
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] ms: 3
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:39 vdr vdr: [4869] ms: 3
Apr 7 09:06:39 vdr vdr: [4869] resetTime1: 0
Apr 7 09:06:40 vdr vdr:
Re: [vdr] VDR continuously initializing CAM
Tuomas Jormola wrote: I upgraded my VDR setup from 1.4.7 to 1.5.17. After the upgrade I've begun to see these CAM initialization and TS continuity error messages in the syslog (see the attached file). I'm using Technotrend 1500 DVB-C card with CI and Conax CAM and card from local cable operator. No answer so far... Same error here. I have similar configuration. I'm using vdr-1.6.0 with xine plugin, kernel 2.6.24.3, multiproto drivers, Terratec Cinergy 1200 DVB-C with CI and Technisat Conax CAM (TechniCAM CX). It is impossible to watch either FTA or crypted channels with iserted CAM. At the same time, all this works with kaffeine and with gnutv from dvb-apps I can access CAM menu. AK Mar 30 15:24:24 vdr vdr: [10975] cTimeMs: using monotonic clock (resolution is 4000250 ns) Mar 30 15:24:24 vdr vdr: [10975] VDR version 1.6.0 started Mar 30 15:24:24 vdr vdr: [10975] codeset is 'UTF-8' - known Mar 30 15:24:25 vdr vdr: [10975] found 23 locales in /usr/local/src/vdr-1.6.0/locale Mar 30 15:24:25 vdr vdr: [10975] loading plugin: /usr/local/src/vdr-1.6.0-vanilla/PLUGINS/lib/libvdr-xine.so.1.6.0 Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/setup.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/sources.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/diseqc.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/channels.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/timers.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/commands.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/reccmds.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/svdrphosts.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/remote.conf Mar 30 15:24:25 vdr vdr: [10975] loading /usr/local/etc/vdr/keymacros.conf Mar 30 15:24:25 vdr vdr: [10976] video directory scanner thread started (pid=10975, tid=10976) Mar 30 15:24:25 vdr vdr: [10977] video directory scanner thread started (pid=10975, tid=10977) Mar 30 15:24:25 vdr vdr: [10975] reading EPG data from /usr/local/etc/vdr/epg.data Mar 30 15:24:25 vdr vdr: [10976] video directory scanner thread ended (pid=10975, tid=10976) Mar 30 15:24:25 vdr vdr: [10977] video directory scanner thread ended (pid=10975, tid=10977) Mar 30 15:24:25 vdr vdr: [10975] probing /dev/dvb/adapter0/frontend0 Mar 30 15:24:25 vdr vdr: [10979] CI adapter on device 0 thread started (pid=10975, tid=10979) Mar 30 15:24:25 vdr kernel: DVB: TDA10021(0): _tda10021_writereg, writereg error (reg == 0x01, val == 0x6a, ret == -121) Mar 30 15:24:25 vdr vdr: [10979] CAM 1: module present Mar 30 15:24:26 vdr kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Mar 30 15:24:26 vdr vdr: [10979] CAM 1: module ready Mar 30 15:24:27 vdr vdr: [10980] tuner on device 1 thread started (pid=10975, tid=10980) Mar 30 15:24:27 vdr vdr: [10981] section handler thread started (pid=10975, tid=10981) Mar 30 15:24:27 vdr vdr: [10975] found 1 video device Mar 30 15:24:27 vdr vdr: [10975] initializing plugin: xine (0.8.2): Software based playback using xine Mar 30 15:24:27 vdr vdr: [10982] XineRemote control thread started (pid=10975, tid=10982) Mar 30 15:24:27 vdr vdr: [10982] Entering cXineRemote thread Mar 30 15:24:27 vdr vdr: [10975] setting primary device to 2 Mar 30 15:24:27 vdr vdr: [10975] assuming manual start of VDR Mar 30 15:24:27 vdr vdr: [10975] SVDRP listening on port 2001 Mar 30 15:24:27 vdr vdr: [10975] starting plugin: xine Mar 30 15:24:27 vdr vdr: [10985] KBD remote control thread started (pid=10975, tid=10985) Mar 30 15:24:27 vdr vdr: [10975] ERROR: remote control XineRemote not ready! Mar 30 15:24:27 vdr vdr: [10975] remote control KBD - keys known Mar 30 15:24:28 vdr vdr: [10979] CAM 1: module present Mar 30 15:24:30 vdr kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Mar 30 15:24:30 vdr vdr: [10979] CAM 1: module ready Mar 30 15:24:32 vdr vdr: [10979] CAM 1: module present Mar 30 15:24:33 vdr kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Mar 30 15:24:33 vdr vdr: [10979] CAM 1: module ready Mar 30 15:24:36 vdr vdr: [10979] CAM 1: module present Mar 30 15:24:37 vdr kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Mar 30 15:24:37 vdr vdr: [10979] CAM 1: module ready Mar 30 15:24:39 vdr vdr: [10979] CAM 1: module present Mar 30 15:24:41 vdr kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Mar 30 15:24:41 vdr vdr: [10979] CAM 1: module ready Mar 30 15:24:43 vdr vdr: [10979] CAM 1: module present Mar 30 15:24:44 vdr kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Mar 30 15:24:44 vdr vdr: [10979] CAM 1: module ready Mar 30 15:24:47 vdr vdr: [10979] CAM 1: module present Mar 30 15:24:48 vdr kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully Mar 30 15:24:48 vdr vdr: [10979] CAM 1: module ready Mar 30 15:24:51 vdr vdr:
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Klaus Schmidinger wrote: Please try commenting out the line repliesToQuery = true; in VDR/ci.c. Does it work then? Can't test it anymore, I gave CAM away. Next week will get new. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Klaus Schmidinger wrote: Looks like your CAM can handle multiple parallel decryptions. So I ran the test with a CAM that can do that here, too, but the result was the same as ever - works just fine. I give up. May be this is really my CAM's problem because of big silence regarding this issue... As temporary workaround I added another (USB DVB-C) card, so now it is possible to record FTA and watch *any* other channel at the same time. Which kind of CAM are you using? Dilog Conax Cam. Second hand, maybe defective? But with vdr-1.4.x worked. Really confused. I'll try replace it in near future. Thanks for Your patience. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Klaus Schmidinger wrote: Please run the tests with the original, *unpatched* version 1.5.14 (or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to be part of version 1.6.0) and use as few plugins as possible (best would be without *any* plugins). Here we are... Clean vdr-1.5.13 with 2 budget cards (DVB-T and DVB-C with CI) and xine-0.8.1 plugin. AK Feb 11 21:51:09 vdr vdr: [27875] VDR version 1.5.13 started Feb 11 21:51:09 vdr vdr: [27875] codeset is 'UTF-8' - known Feb 11 21:51:09 vdr vdr: [27875] found 22 locales in /usr/local/src/vdr-1.5.13/locale Feb 11 21:51:09 vdr vdr: [27875] loading plugin: /usr/local/vdr/PLUGINS/lib/libvdr-xine.so.1.5.13 Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/setup.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/sources.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/diseqc.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/channels.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/timers.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/commands.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/reccmds.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/svdrphosts.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/remote.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/keymacros.conf Feb 11 21:51:09 vdr vdr: [27876] video directory scanner thread started (pid=27875, tid=27876) Feb 11 21:51:09 vdr vdr: [27876] video directory scanner thread ended (pid=27875, tid=27876) Feb 11 21:51:09 vdr vdr: [27877] video directory scanner thread started (pid=27875, tid=27877) Feb 11 21:51:09 vdr vdr: [27877] video directory scanner thread ended (pid=27875, tid=27877) Feb 11 21:51:09 vdr vdr: [27875] reading EPG data from /usr/local/etc/vdr/epg.data Feb 11 21:51:09 vdr vdr: [27879] tuner on device 1 thread started (pid=27875, tid=27879) Feb 11 21:51:09 vdr vdr: [27880] section handler thread started (pid=27875, tid=27880) Feb 11 21:51:10 vdr vdr: [27882] tuner on device 2 thread started (pid=27875, tid=27882) Feb 11 21:51:10 vdr vdr: [27883] section handler thread started (pid=27875, tid=27883) Feb 11 21:51:10 vdr vdr: [27875] initializing plugin: xine (0.8.1): Software based playback using xine Feb 11 21:51:10 vdr vdr: [27884] XineRemote control thread started (pid=27875, tid=27884) Feb 11 21:51:10 vdr vdr: [27884] Entering cXineRemote thread Feb 11 21:51:10 vdr vdr: [27875] setting primary device to 3 Feb 11 21:51:10 vdr vdr: [27875] assuming manual start of VDR Feb 11 21:51:10 vdr vdr: [27875] SVDRP listening on port 2001 Feb 11 21:51:10 vdr vdr: [27875] starting plugin: xine Feb 11 21:51:10 vdr vdr: [27890] KBD remote control thread started (pid=27875, tid=27890) Feb 11 21:51:10 vdr vdr: [27875] remote control KBD - keys known Feb 11 21:51:12 vdr vdr: [27886] CAM 1: module ready Feb 11 21:51:13 vdr vdr: [27886] CAM 1: replies to QUERY - multi channel decryption possible Feb 11 21:51:13 vdr vdr: [27875] switching to channel 112 Feb 11 21:51:13 vdr vdr: [27891] transfer thread started (pid=27875, tid=27891) Feb 11 21:51:13 vdr vdr: [27892] receiver on device 2 thread started (pid=27875, tid=27892) Feb 11 21:51:13 vdr vdr: [27893] TS buffer on device 2 thread started (pid=27875, tid=27893) Feb 11 21:51:13 vdr vdr: [27875] setting watchdog timer to 60 seconds Feb 11 21:51:14 vdr vdr: [27891] setting audio track to 1 (0) Feb 11 21:51:15 vdr vdr: [27875] max. latency time 1 seconds Feb 11 21:51:33 vdr vdr: [27875] switching device 2 to channel 112 Feb 11 21:51:33 vdr vdr: [27875] timer 1 (112 2151-2201 'TITLE EPISODE') start Feb 11 21:51:33 vdr vdr: [27875] Title: 'Kohtumine Fockeritega (Meet The Focker, USA 2004)' Subtitle: '(null)' Feb 11 21:51:33 vdr vdr: [27875] record /video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec Feb 11 21:51:33 vdr vdr: [27875] creating directory /video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec Feb 11 21:51:33 vdr vdr: [27875] recording to '/video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec/001.vdr' Feb 11 21:51:33 vdr vdr: [27894] file writer thread started (pid=27875, tid=27894) Feb 11 21:51:33 vdr vdr: [27895] recording thread started (pid=27875, tid=27895) Feb 11 21:51:33 vdr vdr: [27875] info: Recording started Feb 11 21:51:39 vdr vdr: [27875] max. latency time 7 seconds Feb 11 21:52:03 vdr vdr: [27875] CAM 1: assigned to device 2 Feb 11 21:52:03 vdr vdr: [27875] switching to channel 113 Feb 11 21:52:03 vdr vdr: [27891] transfer thread ended (pid=27875, tid=27891) Feb 11 21:52:03 vdr vdr: [27875] buffer stats: 184052 (8%) used Feb 11 21:52:03 vdr vdr: [27896] transfer thread started (pid=27875, tid=27896) Feb 11 21:52:07 vdr vdr: [27896] transfer thread ended (pid=27875, tid=27896) Feb 11 21:52:07 vdr vdr: [27875] switching to channel 113 Feb 11 21:52:07 vdr vdr:
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Klaus Schmidinger wrote: Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM. Sorry for delay, busy weekend... I enabled debug outputs in ci.c and made 2 attempts: -crypted channel recording (ok files) -FTA recording and try to switch to crypted channel (bad files) stdout and syslog files attached. vdr-1.5.14 used. Regards, AK Feb 11 11:20:17 vdr vdr: [23935] switching to channel 114 Feb 11 11:20:17 vdr vdr: [23958] transfer thread started (pid=23935, tid=23958) Feb 11 11:20:17 vdr vdr: [23959] receiver on device 2 thread started (pid=23935, tid=23959) Feb 11 11:20:17 vdr vdr: [23960] TS buffer on device 2 thread started (pid=23935, tid=23960) Feb 11 11:20:17 vdr vdr: [23935] setting watchdog timer to 60 seconds Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: switching to MPEG1/2 mode Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: operating in MPEG1/2 mode Feb 11 11:20:20 vdr vdr: [23935] max. latency time 1 seconds Feb 11 11:20:24 vdr vdr: [23935] CAM 1: assigned to device 2 Feb 11 11:20:24 vdr vdr: [23935] switching to channel 113 Feb 11 11:20:24 vdr vdr: [23958] transfer thread ended (pid=23935, tid=23958) Feb 11 11:20:24 vdr vdr: [23935] buffer stats: 175592 (8%) used Feb 11 11:20:24 vdr vdr: [23960] TS buffer on device 2 thread ended (pid=23935, tid=23960) Feb 11 11:20:24 vdr vdr: [23959] buffer stats: 59220 (2%) used Feb 11 11:20:24 vdr vdr: [23959] receiver on device 2 thread ended (pid=23935, tid=23959) Feb 11 11:20:24 vdr vdr: [23961] transfer thread started (pid=23935, tid=23961) Feb 11 11:20:25 vdr vdr: [23963] receiver on device 2 thread started (pid=23935, tid=23963) Feb 11 11:20:25 vdr vdr: [23964] TS buffer on device 2 thread started (pid=23935, tid=23964) Feb 11 11:20:25 vdr vdr: [23951] ttxtsubs: No teletext subtitles on channel. Feb 11 11:20:25 vdr vdr: [23961] cVideoRepacker: switching to MPEG1/2 mode Feb 11 11:20:25 vdr vdr: [23961] cVideoRepacker: operating in MPEG1/2 mode Feb 11 11:20:34 vdr vdr: [23935] switching device 2 to channel 113 Feb 11 11:20:34 vdr vdr: [23935] timer 1 (113 1120-1420 'TITLE EPISODE') start Feb 11 11:20:34 vdr vdr: [23935] Title: 'NHL On the Fly: Final; Ice Hockey Sports' Subtitle: '(null)' Feb 11 11:20:34 vdr vdr: [23935] record /video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports/2008-02-11.11.20.50.99.rec Feb 11 11:20:34 vdr vdr: [23935] creating directory /video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports Feb 11 11:20:34 vdr vdr: [23935] creating directory /video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports/2008-02-11.11.20.50.99.rec Feb 11 11:20:35 vdr vdr: [23935] recording to '/video/NHL_On_the_Fly#3A_Final;_Ice_Hockey_Sports/2008-02-11.11.20.50.99.rec/001.vdr' Feb 11 11:20:35 vdr vdr: [23966] file writer thread started (pid=23935, tid=23966) Feb 11 11:20:35 vdr vdr: [23967] recording thread started (pid=23935, tid=23967) Feb 11 11:20:35 vdr vdr: [23935] info: Recording started =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.02.11 10:52:52 =~=~=~=~=~=~=~=~=~=~=~= [EMAIL PROTECTED]:/var/log# cd /var/log/runvdr - MakePrimaryDevice: 1 = SetVideoFormat: 0 SetVolumeDevice: 40 Slot 1: module ready Slot 1: creating connection 0/1 Slot 1: create connection 0/1 1: -- 00 01 82 01 01 1: -- 00 01 83 01 01 80 02 01 00 . . . . . . . . . Slot 1: connection created 0/1 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00030041 Slot 1: new Conditional Access Support (session id 1) 1: -- 00 01 A0 0A 01 92 07 00 00 03 00 41 00 01 Slot 1: == Ca Info Enq (1) 1: -- 00 01 A0 09 01 90 02 00 01 9F 80 30 00 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 0B 01 90 02 00 01 9F 80 31 02 0B 00 80 02 01 00 . . . . . . . . . . . 1 . . . . . . . Slot 1: == Ca Info (1) 0B00 Slot 1: == Ca Pmt (1) 3 3 1: -- 00 01 A0 10 01 90 02 00 01 9F 80 32 07 03 00 00 01 00 01 03 Slot 1: receive data 0/1 1: -- 00 01 81 01 01 1: -- 00 01 A0 0D 01 90 02 00 01 9F 80 33 04 00 00 00 81 80 02 01 00 . . . . . . . . . . . 3 . . . . . . . . . Slot 1: == Ca Pmt Reply (1) 0 00 81 - ** TUNING TO FTA CHANNEL (ch 114) *** GetDevice 114 0 1 - 'Star!:17:M64:C:6900:2040:2041=eng:2042:0:1142:1:12:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E 018C4C64 i = 2 A B X 1 Z SetAudioChannelDevice: 0 SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 SetVolumeDevice: 40 SetPlayMode: 1 frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00) [v] vdr-xine: Client connecting ... vdr-xine: Client connected! frame: (0, 0)-(720, 576), zoom: (1,00, 1,00) [vaAVM]buffered 19,5 frames (v:28,7, a:19,5) frame: (0, 0)-(704, 576), zoom: (1,00, 1,00) buffered 19,2 frames (v:29,0, a:19,2) frame: (0, 0)-(704, 576), zoom: (1,00,
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Klaus Schmidinger wrote: I just read your original posting again, and there you described the problem the other way round. So I also tested recording the FTA channel and then switching to the encrypted channel, but this also works fine here. So I'm afraid I don't know what's causing this for you. Very strange. I noticed that message channel on available apperars momentarily after switching to another channel. It seems like vdr not trying to decode anything. May be You can provide some lines to vdr code for debugging reason of message channel not available? I have interest to solve this problem ;) Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14
Morfsta wrote: Nope, it's all compiled - just doublechecked with fresh source: - vdr-1.5.14 vdr-rotor-0.1.4-vdr-1.5.14.tgz vdr-1.5.14-h264-other-rotor.diff vdr-1.5.14-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff ./vdr -Protor vdr: ./PLUGINS/lib/libvdr-rotor.so.1.5.14: undefined symbol: _ZN7cDevice13SwitchChannelEPK8cChannelPS_ Could be the mismatch between device.c and device.h in eSetChannelResult SetChannel. I don't know. Hi! Do You solved this problem? I have same situation. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.14
Morfsta wrote: Nope, I had to roll back to an earlier version of rotor that I patched myself. Cool. Can You share it? I can't live without rotor. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-rotor support patches for VDR-1.5.14
lucian orasanu wrote: I say that i will be tester, so rotor patcheches aply fine and compile only in this order. 1. Rotor patch vdr-1.5.14-h264-other-rotor.diff to vdr-rotor-0.1.4-vdr-1.5 2. Rotor patch vdr-1.5.14-h264-other-rotor.diff to vdr. I tried same order, but got error: g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DREMOTE_KBD -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE -DVIDEODIR=\/video\ -DCONFDIR=\/video\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\/usr/local/src/vdr-1.5.14/locale\ -I/usr/include/freetype2 -I/usr/local/src/multiproto/linux/include device.c device.c:780: error: prototype for ‘eSetChannelResult cDevice::SetChannel(const cChannel*, bool)’ does not match any in class ‘cDevice’ device.h:253: error: candidate is: eSetChannelResult cDevice::SetChannel(const cChannel*, bool, cDevice*) device.c: In member function ‘eSetChannelResult cDevice::SetChannel(const cChannel*, bool)’: device.c:800: error: call of overloaded ‘SetChannel(const cChannel*, bool)’ is ambiguous device.h:253: note: candidates are: eSetChannelResult cDevice::SetChannel(const cChannel*, bool, cDevice*) device.c:780: note: eSetChannelResult cDevice::SetChannel(const cChannel*, bool) make: *** [device.o] Error 1 AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Klaus Schmidinger wrote: On 02/03/08 12:06, Matthias Schniedermeyer wrote: Is the CAM Handling regarding multiple parallel recodings (on the same channel) fixed? Have you tried version 1.5 yet? It can do multiple parallel recordings with the same CAM (if the CAM supports this). I still have problem with it. Recording on crypted channel is not possible when watching FTA DVB-C on the same frequency. Same situation works fine on vdr-1.4.x environment. Regards, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Straw poll: stable version 1.6.0 now?
Petri Helin wrote: If the h.264 support is left out, it's a no. Same here. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Rotor patch for 1.5.12
serge pecher wrote:
Did you had to adapt manually the patch, because when i try this patch on
vdr 1.5.12 everything is rejected ?
Previosly mentioned patch applied to attached version of rotor plugin.
I suspect that I found it in vdr-portal.de
Fresh generated patch attached also.
Regards,
AK
vdr-rotor-0.1.4-vdr1.5.tgz
Description: application/compressed
diff -Nur old/filter.c new/filter.c
--- old/filter.c2006-01-09 22:41:50.0 +0200
+++ new/filter.c2007-10-16 08:21:54.0 +0300
@@ -368,12 +368,15 @@
int Ppid = pmt.getPCRPid();
int Apids[MAXAPIDS + 1] = { 0 };
int Dpids[MAXDPIDS + 1] = { 0 };
+int Spids[MAXDPIDS + 1] = { 0 };
#if VDRVERSNUM = 10332
char ALangs[MAXAPIDS + 1][MAXLANGCODE2] = { };
char DLangs[MAXDPIDS + 1][MAXLANGCODE2] = { };
+char SLangs[MAXDPIDS + 1][MAXLANGCODE2] = { };
#else
char ALangs[MAXAPIDS + 1][4] = { };
char DLangs[MAXDPIDS + 1][4] = { };
+char SLangs[MAXDPIDS + 1][4] = { };
#endif
int Tpid = 0;
int NumApids = 0;
@@ -448,7 +451,7 @@
delete d;
}
}
-Menu-SetPids(pmt.getServiceId(),Vpid, Vpid ? Ppid : 0, Apids, ALangs,
Dpids, DLangs, Tpid);
+Menu-SetPids(pmt.getServiceId(),Vpid, Vpid ? Ppid : 0, Apids, ALangs,
Dpids, DLangs, Spids, SLangs, Tpid);
Menu-SetCaIds(pmt.getServiceId(),CaDescriptors-CaIds());
Menu-SetCaDescriptors(pmt.getServiceId(),CaDescriptorHandler.AddCaDescriptors(CaDescriptors));
}
diff -Nur old/menu.c new/menu.c
--- old/menu.c 2007-07-06 23:52:57.0 +0300
+++ new/menu.c 2007-10-16 08:21:54.0 +0300
@@ -406,12 +406,15 @@
channel-SetId(Channel[Num].Nid(),Channel[Num].Tid(),Channel[Num].Sid(),channel-Rid());
int Apids[MAXAPIDS + 1] = { 0 };
int Dpids[MAXDPIDS + 1] = { 0 };
+int Spids[MAXDPIDS + 1] = { 0 };
#if VDRVERSNUM=10332
char ALangs[MAXAPIDS + 1][MAXLANGCODE2] = { };
char DLangs[MAXDPIDS + 1][MAXLANGCODE2] = { };
+char SLangs[MAXDPIDS + 1][MAXLANGCODE2] = { };
#else
char ALangs[MAXAPIDS + 1][4] = { };
char DLangs[MAXDPIDS + 1][4] = { };
+char SLangs[MAXDPIDS + 1][4] = { };
#endif
int CaIds[MAXCAIDS+1] = { 0 };
for (int i=0; i=MAXAPIDS; i++)
@@ -426,7 +429,7 @@
}
for (int i=0; i=MAXCAIDS; i++)
CaIds[i]=Channel[Num].Ca(i);
-
channel-SetPids(Channel[Num].Vpid(),Channel[Num].Ppid(),Apids,ALangs,Dpids,DLangs,Channel[Num].Tpid());
+
channel-SetPids(Channel[Num].Vpid(),Channel[Num].Ppid(),Apids,ALangs,Dpids,DLangs,Spids,SLangs,Channel[Num].Tpid());
channel-SetCaIds(CaIds);
}
else
@@ -456,7 +459,7 @@
}
#if VDRVERSNUM=10332
-void cMenuScan::SetPids(int Sid,int Vpid, int Ppid, int *Apids, char
ALangs[][MAXLANGCODE2], int *Dpids, char DLangs[][MAXLANGCODE2], int Tpid)
+void cMenuScan::SetPids(int Sid,int Vpid, int Ppid, int *Apids, char
ALangs[][MAXLANGCODE2], int *Dpids, char DLangs[][MAXLANGCODE2], int *Spids,
char SLangs[][MAXLANGCODE2], int Tpid)
#else
void cMenuScan::SetPids(int Sid,int Vpid, int Ppid, int *Apids, char
ALangs[][4], int *Dpids, char DLangs[][4], int Tpid)
#endif
@@ -464,7 +467,7 @@
for (int i=0; inum; i++)
if (Sid==Channel[i].Sid())
{
- Channel[i].SetPids(Vpid,Ppid,Apids,ALangs,Dpids,DLangs,Tpid);
+
Channel[i].SetPids(Vpid,Ppid,Apids,ALangs,Dpids,DLangs,Spids,SLangs,Tpid);
display(i);
}
}
diff -Nur old/menu.h new/menu.h
--- old/menu.h 2007-07-06 23:57:42.0 +0300
+++ new/menu.h 2007-10-16 08:21:54.0 +0300
@@ -116,7 +116,7 @@
virtual eOSState ProcessKey(eKeys Key);
void AddChannel(int Num);
void NewChannel(const cChannel *Transponder, const char *Name, const char
*ShortName, const char *Provider, int Nid, int Tid, int Sid);
- void SetPids(int Sid,int Vpid, int Ppid, int *Apids, char
ALangs[][MAXLANGCODE2], int *Dpids, char DLangs[][MAXLANGCODE2], int Tpid);
+ void SetPids(int Sid,int Vpid, int Ppid, int *Apids, char
ALangs[][MAXLANGCODE2], int *Dpids, char DLangs[][MAXLANGCODE2], int *Spids,
char SLangs[][MAXLANGCODE2], int Tpid);
void SetCaIds(int Sid,const int *CaIds);
void SetCaDescriptors(int Sid,int Level);
cChannel* GetChannel(int Sid);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.8.1 plugin
This doesn't directly concern xine plugin, but maybe anybody can help me. Trying to update xine plugin and got xine-ui compile problem like this: gcc -I/usr/local/include -I/usr/include/readline -I../../src/xitk/xine-toolkit -Wall -D_FILE_OFFSET_BITS=64 -Wpointer-arith -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -I/usr/local/include -DNDEBUG -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute -Wstrict-aliasing=2 -o xine-remote xine_remote-network.o -lnsl -lpthread -lreadline ../../src/common/libcommon.a /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `PC' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetflag' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetent' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `UP' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tputs' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgoto' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetnum' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `BC' /usr/lib/gcc/i486-slackware-linux/4.1.2/../../../libreadline.so: undefined reference to `tgetstr' collect2: ld returned 1 exit status make[4]: *** [xine-remote] Error 1 make[4]: Leaving directory `/usr/local/src/xine-ui/src/xitk' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/xine-ui/src/xitk' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/xine-ui/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/xine-ui' make: *** [all] Error 2 Please any hint to solve this. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.5.10 and VDR-1.5.11 recording channel with subtitle
Ville Aakko wrote: OTOH I don't see anyone mentioning anything about emergency exits in the vdr-1.5.11 subtitling problems. Maybe what I encountered was a different problem, after all? I had similar problem, but after upgrade to 1.5.12 it's fine now. AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
Theunis Potgieter wrote: I also have experienced this with DVB-S, however in my situation I experienced it a bit different. I was switched to a radio channel which was FTA, a timer was set to record a channel on the same transponder but is scrambled. The vdr info bar showed it was recording. The directory was created but the file 001.vdr was size 0. It also shows that I cannot tune to this channel . I had to stop the timer/recording and switch to the scrambled channel and enable the timer. But from there on I could jump back to the FTA radio channel. Same happens every time I'm on a FTA channel and a timer starts after I tuned to the channel. Theunis On 17/10/2007, *Arthur Konovalov* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi all! Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. Channel not available! message received. At the same time, when recording scrambled channel, switching to FTA or to other scrambled works. This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation. Klaus, what You can tell about fixing this problem? This is main restriction to switch to vdr-1.5 line. Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.5.10, Subtitles gets out of sync
Tero Siironen wrote: Great that the subtitles are now part of the VDR. Unfortunately, there seems to be some problems still. I tested this new VDR version for some minutes and noticed that some subtitles were shown too late in live tv watching. Testing was done with VDR 1.5.10 without any plugins, TT FF 2.1 DVB-C card and YLE 2 and YLE Teema channels here in Finland. I don't know is there same reason or not, but xine plugin crash within one minute on channels with subtitles (YLE1 for instance). Last syslog entry is: Oct 16 16:40:41 vdr vdr: [25576] subtitleConverter thread started (pid=25486, tid=25576) And xine output: SetPlayMode: 0 SetAudioChannelDevice: 0 SetPlayMode: 1 [vVMSetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 A]buffered 14,2 frames (v:23,3, a:14,2) read(4) returned 0, error 0: Success vdr-xine: Client disconnected! My config: vdr-1.5.10 with femon, remote and xine plugins, KNC1 DVB-C budget card. Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.5.6 not found fontconfig.h in Slackware
Hi, community! Please advise what is best way to fix vdr-1.5.6 compiling on Slackware-11.0. What I got: font.c:12:35: fontconfig/fontconfig.h: No such file or directory font.c: In static member function `static bool cFont::GetAvailableFontNames(cStringList*, bool)': But, [EMAIL PROTECTED]:/usr/local/src/vdr-1.5.6# find / -iname fontconfig.h /usr/X11R6/include/fontconfig/fontconfig.h Package fontconfig-2.4.2-i486-2_slack11.0 installed. I wish to update Estonian OSD texts. Regards, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: Problem with multiple audio channels and DVB subtitles in recordings (YLE Teema)
Ville Aakko wrote: Wathing the program in real-time has no problems, there I can see the subtitles without problems. Only the recordings have problems. I have similar issue with YLE1 and YLE2. Sometimes subtitles saved, sometimes not. ProjectX shows same: no subtitles- no DVB stream. And vice versa. At moment using vdr-1.4.6-1, subtitles-0.5, and ttxtsubs-0.0.5-LHE plugins patched with vdr-1.4.4-subtitles-0.4.0-and-ttxtsubs-0.0.5.diff. Br, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: missing dvb subtitles in records
Ville Aakko wrote: I have a similar setup and yes, DVB subtitles are recorded. I don't use ttxtsubs at all (only the DVB ones). I know that it sounds stupid, but after upgrading to 1.4.5 subtitles recording works flawlessly. Maybe just because of restart. I have : - Gentoo - kernel 2.6.19 - probably you too ;) Of course, silly typo (1.6.19- hyvää Luoja!). :) I strongly recommend using Gentoo for VDR. I hope, this is not necessary. Slack is fine too. ;) Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
