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
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
[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] 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] 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 Booth 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
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] 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: > What you are missing without the rotor plugin is the ability to move your > rotor > hunting for new positions or re-aligning the dish. Exactly. It's a main problem. > xdipo can help there, it is > a stand alone program. Can I run it without leavig vdr? I have command line utility to manipulate rotor, but with running vdr resources are busy. BR, AK ___ 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] open dvb-s2 channel on Hotbird - Eurosport HD Promo
Igor wrote: > I never have seen the command [E0 00 00] - what's mean ? From Diseqc bus specification: E0 Command from Master, No reply required, First transmission 00 Any Device (Master to all devices) 00 Reset DiSEqC microcontroller I suppose it means Reset All Diseqc Devices. Another thing is for what it there... Arthur ___ 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: > 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] 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: Clien
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
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: 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
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) Ap
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: > 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: > 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 #include #include #include #include #include #include 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
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: [1097
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: [2
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), zo
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, 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] [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] 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; i___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Rotor patch for 1.5.12
[EMAIL PROTECTED] wrote: I am looking for the patch to compile the rotor plugin together with vdr-1.5.12. Does anyone achieved to compile it with 1.5.12 I had success with attached patch. Regards, AK diff -ur rotor-0.1.4/filter.c rotor-0.1.4_vdr-1.5.10/filter.c --- rotor-0.1.4/filter.c2007-10-14 11:37:13.0 +0200 +++ rotor-0.1.4_vdr-1.5.10/filter.c 2007-10-15 22:56:43.0 +0200 @@ -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 -ur rotor-0.1.4/menu.c rotor-0.1.4_vdr-1.5.10/menu.c --- rotor-0.1.4/menu.c 2007-10-14 11:37:12.0 +0200 +++ rotor-0.1.4_vdr-1.5.10/menu.c 2007-10-15 22:55:27.0 +0200 @@ -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; i___ 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
Reinhard Nissl wrote: > vdr-xine-0.7.11 doesn't support multiple OSDs but it shouldn't crash. > 0.7.12 is on the way. I've run a 1 hour test yesterday on TV5MONDE > EUROPE, as mentioned in this mailing list. vdr-xine-0.7.12 crashing without notice on YLE channels with subtitles as well. I discovered that TV5 Monde transmitted on local cable network too, but I didn't seen any subtitles yet on this chhnnel, only SPID's. Is there any fixed time when subtitles presents on TV5? Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
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. 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
Re: [vdr] [ANNOUNCE] H.264 updates for VDR-1.5.9
> Reinhard Nissl wrote: > the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer. Hi, I trying to compile vdr-1.5.9 with h264 patches but vdr-xine-0.7.10 plugin give me error: xineDevice.c: In member function 'int PluginXine::cXineDevice::PlayCommon3(const uchar*, int, int64_t)': xineDevice.c:1387: error: cannot call member function 'int cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object xineDevice.c: In function 'bool PluginXine::getPTS(const uchar*, int, int64_t&, bool, bool, double&, double&, double&, double&, double*)': xineDevice.c:2017: error: cannot call member function 'int cRemux::ScanVideoPacket(const uchar*, int, int, uchar&)' without object make[1]: *** [xineDevice.o] Error 1 Is there any solution? Please help me. 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
Re: [vdr] dvbtextsubs 0.2
listnisse wrote: > But no, I am looking for the package that extract ttxtsubs from vdr > recordings. One possible solution is ProjectX package. It can demux teletext subs to text file. Regards, AK ___ 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)
Arthur Konovalov wrote: Pekka Virtanen wrote: The problem is most likely caused by the fact that the PIDs for subtitles are different than at the time the recording started. Current implementation doesn't detect if PIDs change during recording. I don't think so. Tried manual recording in the middle of program as well. I discovered that only "primary" language saved with recording. For example if set primary language to "eesti" and secondary to "suomi" and record YLE2 channel so result will be without subtitles. If set primary to "suomi" - subtitles saved. Br, AK ___ 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)
Pekka Virtanen wrote: The problem is most likely caused by the fact that the PIDs for subtitles are different than at the time the recording started. Current implementation doesn't detect if PIDs change during recording. I don't think so. Tried manual recording in the middle of program as well. Br, AK ___ 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: Streamdev and subtitles and HD
Anssi Hannula wrote: 1) DVB Subtitles sent in the HTTP datastream: http://users.tkk.fi/~rahrenbe/vdr/vdr-streamdev-cvs-subtitles.diff.gz Forbidden: You don't have permission to access /~rahrenbe/vdr/vdr-streamdev-cvs-subtitles.diff.gz on this server 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
[vdr] missing dvb subtitles in records
Hi. I noticed that dvb subtitles not recorded with video. Can anyone confirm that it works? My environment: Slackware-11.0, kernel 1.6.19, vdr-1.4.4-3 with vdr-1.4.4-liemikuutio-1.13.diff, vdr-1.4.4-subtitles-0.4.0-and-ttxtsubs-0.0.5.diff Recorded teletext subtitles are ok. Tried on YLE1 and YLE2 channels (for me these only available channels with both subtitles types). ProjectX demux not detect dvb subtitles too. Or I missed something? Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: mplayer plugin -> no sound on vdr-1.4.4 ?
Soeren Sonnenburg wrote: does anyone else observer that the mplayer plugin does no longer give sound output with vdr 1.4.4 ? Could it be that the sound device is somehow still locked/occupied by vdr ? I am using the latest vdr-mp3/mplayer (0.9.15) and it used to work with 1.4.1 ... so what changed ? I had this problem playing avi files with ac3 sound via DVB using latest mplayer plugin and mplayer.sh-0.8.6 script. Problem solved by modify mplayer.sh.conf file. Line: AC3AOUT="-ac hwac3" changed to: AC3AOUT="-ao mpegpes -ac hwac3" Regards, AK ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Simultaneous streams with DVB-C USB (1.1)
Hello all! Recently added Technotrend TT Connect C-1200 USB device to vdr (1.4.3-1). All went fine, but one problem occurs. If switch channel during recording on same mux frequency, picture become disturbed (both: recorded and watched) due to limited USB DVB device bandwidth (from card spec: 7 Mbit/s). My questions are: -is it any possibility to not allow change channel during recording on USB device? -most important- how to force vdr switch to exactly timer-recording channel (even if it is on same mux frecuency)? As workaround I make 1 minute timer before actual recoding to different mux frequency, but it's nasty solution. Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr