Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems
On 22.08.2009 00:51, Simon Baxter wrote: Hi I use xmltv2vdr to process .xml EPG listings and populate VDR. VDR seems to be processing the EPG (via SVDRP) into and across two channels. There's no error in the xmltv2vdr - seems to be a VDR problem. Example: here's a snippet from ./xmltv2vdr.pl -x listings-sky.xml -c test.channels.vibe -s output C C-182-5-504 Vibe;T E 8270 1250904000 3000 0 T Smallville D Clark is amazed when a pesticide magnate somehow convinces Jonathan to sell the family farm to make way for a new plant. e E 8320 1250907000 2700 0 T Smallville D When Clark rescues his classmate from harm during an electrical storm, they are both struck by lightning - resulting in all of Clark's superpowers being transferred. Lex confronts Clark about his powers. e c C C-182-2-212 Prime TV;T E 8300 1250905800 1800 0 T Chequered Flag D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. e but when I do a LSTE at 1250905800 The Chequered Flag program is appearing in Prime and Vibe: 215-C C-182-5-504 Vibe 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-C C-182-10-1004 Prime TV 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-c The channel you entered EPG data for was C-182-2-212 Prime TV;T while the one listed later is C-182-10-1004 Prime TV Are you sure that this entry has not been in there for C-182-5-504 Vibe;T before you ran xmltv2vdr.pl? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems
On 22.08.2009 00:51, Simon Baxter wrote: Hi I use xmltv2vdr to process .xml EPG listings and populate VDR. VDR seems to be processing the EPG (via SVDRP) into and across two channels. There's no error in the xmltv2vdr - seems to be a VDR problem. Example: here's a snippet from ./xmltv2vdr.pl -x listings-sky.xml -c test.channels.vibe -s output C C-182-5-504 Vibe;T E 8270 1250904000 3000 0 T Smallville D Clark is amazed when a pesticide magnate somehow convinces Jonathan to sell the family farm to make way for a new plant. e E 8320 1250907000 2700 0 T Smallville D When Clark rescues his classmate from harm during an electrical storm, they are both struck by lightning - resulting in all of Clark's superpowers being transferred. Lex confronts Clark about his powers. e c C C-182-2-212 Prime TV;T E 8300 1250905800 1800 0 T Chequered Flag D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. e but when I do a LSTE at 1250905800 The Chequered Flag program is appearing in Prime and Vibe: 215-C C-182-5-504 Vibe 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-C C-182-10-1004 Prime TV 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-c The channel you entered EPG data for was C-182-2-212 Prime TV;T while the one listed later is C-182-10-1004 Prime TV Are you sure that this entry has not been in there for C-182-5-504 Vibe;T before you ran xmltv2vdr.pl? Klaus I think I've now fixed this... I did have these multiple entries in the xmltv2vdr.channels.conf file : Prime TV;T:594000:C0M64:C:6900:1312+1212:1412=eng:0:606:212:182:2:0:prime.sky.co.nz Prime TV_A:189250:C0:C:0:301:300:305:A1:2134:0:1036:0:prime.sky.co.nz Prime TV;T:602000:C0M64:C:6900:1302+1202:1402=eng:0:606:302:182:3:0:prime.sky.co.nz Prime TV;T:578000:C0M64:C:6900:0:0:0:0:1004:182:10:0:prime.sky.co.nz Prime TV;T:618000:C0M64:C:6900:5041:5042:0:606:504:182:5:0:prime.sky.co.nz Vibe;T:57:C0M64:C:6900:1304+1204:1404=eng:0:606:504:182:5:0:vibe.sky.co.nz ...because my cable provider is currently transmitting prime on multiple transponders. (PS the Prime TV_A entry is received via a PVR-500 card) question - the last Prime entry and the Vibe entry have the same service ID 504. Should my provider be using this overlap? This is probably where my mistake was - I've now excluded the last Prime TV entry in my xmltv2vdr processing. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 SVDRP EPG processing problems
On 22.08.2009 23:03, Simon Baxter wrote: On 22.08.2009 00:51, Simon Baxter wrote: Hi I use xmltv2vdr to process .xml EPG listings and populate VDR. VDR seems to be processing the EPG (via SVDRP) into and across two channels. There's no error in the xmltv2vdr - seems to be a VDR problem. Example: here's a snippet from ./xmltv2vdr.pl -x listings-sky.xml -c test.channels.vibe -s output C C-182-5-504 Vibe;T E 8270 1250904000 3000 0 T Smallville D Clark is amazed when a pesticide magnate somehow convinces Jonathan to sell the family farm to make way for a new plant. e E 8320 1250907000 2700 0 T Smallville D When Clark rescues his classmate from harm during an electrical storm, they are both struck by lightning - resulting in all of Clark's superpowers being transferred. Lex confronts Clark about his powers. e c C C-182-2-212 Prime TV;T E 8300 1250905800 1800 0 T Chequered Flag D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. e but when I do a LSTE at 1250905800 The Chequered Flag program is appearing in Prime and Vibe: 215-C C-182-5-504 Vibe 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-C C-182-10-1004 Prime TV 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-c The channel you entered EPG data for was C-182-2-212 Prime TV;T while the one listed later is C-182-10-1004 Prime TV Are you sure that this entry has not been in there for C-182-5-504 Vibe;T before you ran xmltv2vdr.pl? Klaus I think I've now fixed this... I did have these multiple entries in the xmltv2vdr.channels.conf file : Prime TV;T:594000:C0M64:C:6900:1312+1212:1412=eng:0:606:212:182:2:0:prime.sky.co.nz Prime TV_A:189250:C0:C:0:301:300:305:A1:2134:0:1036:0:prime.sky.co.nz Prime TV;T:602000:C0M64:C:6900:1302+1202:1402=eng:0:606:302:182:3:0:prime.sky.co.nz Prime TV;T:578000:C0M64:C:6900:0:0:0:0:1004:182:10:0:prime.sky.co.nz Prime TV;T:618000:C0M64:C:6900:5041:5042:0:606:504:182:5:0:prime.sky.co.nz Vibe;T:57:C0M64:C:6900:1304+1204:1404=eng:0:606:504:182:5:0:vibe.sky.co.nz ...because my cable provider is currently transmitting prime on multiple transponders. (PS the Prime TV_A entry is received via a PVR-500 card) question - the last Prime entry and the Vibe entry have the same service ID 504. Should my provider be using this overlap? This is probably where my mistake was - I've now excluded the last Prime TV entry in my xmltv2vdr processing. Using the same Sid for two different channels on the same transponder is certainly not a good idea ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.6.0 SVDRP EPG processing problems
Hi I use xmltv2vdr to process .xml EPG listings and populate VDR. VDR seems to be processing the EPG (via SVDRP) into and across two channels. There's no error in the xmltv2vdr - seems to be a VDR problem. Example: here's a snippet from ./xmltv2vdr.pl -x listings-sky.xml -c test.channels.vibe -s output C C-182-5-504 Vibe;T E 8270 1250904000 3000 0 T Smallville D Clark is amazed when a pesticide magnate somehow convinces Jonathan to sell the family farm to make way for a new plant. e E 8320 1250907000 2700 0 T Smallville D When Clark rescues his classmate from harm during an electrical storm, they are both struck by lightning - resulting in all of Clark's superpowers being transferred. Lex confronts Clark about his powers. e c C C-182-2-212 Prime TV;T E 8300 1250905800 1800 0 T Chequered Flag D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. e but when I do a LSTE at 1250905800 The Chequered Flag program is appearing in Prime and Vibe: 215-C C-182-5-504 Vibe 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-C C-182-10-1004 Prime TV 215-E 8300 1250905800 1800 0 FF 215-T Chequered Flag 215-D Czech Moto GP Highlights - Moto GP returns after its summer break with the Czech GP at Brno and Valentino Rossi holding a slim lead over rivals Jorge Lorenzo and Casey Stoner. 215-e 215-c Any ideas why this is happening??? -Simon ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Vdr-1.6.0 and mplayer 1.0rc2-4.3.2 : cpu usage ?
Hello, I am trying to view HD movies with vdr-1.6.0 and mplayer 1.0rc2-4.3.2. Of course, because I am using Nexus output, vdr has to resample the files to SD (720x576). Even if my vdrbox has a E4500 Core2Duo and 2GB RAM, 1080p movies are jerky (sound and image). After more tests, I noticed a different behaviour, according I run mplayer alone, or from vdr : mplayer alone - the two cores were used at the same level. mplayer via vdr - one core is at 100% and the second is about 40% Is there any way to tune vdr to run mplayer using hte 2 cores ? Did I missed something ? Thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 / mplayer / spdif Nexus = pb with DTS tracks
On Mon, Feb 2, 2009 at 2:26 PM, kafifi kaf...@orange.fr wrote: Hello, I am using vdr-1.6.0 and mplayer with Nexus FF card and it's spdif output. When I run some 720p_AC3.avi movies, my HC ampli receives 5.1 audio without problem. But with movies with DTS audio tracks, vdr+mplayer give only PCM in stereo mode. There is an issue with DTS passthrough. When I try mplayer **without vdr**, DTS is working : Mplayer -ao mpegpes afm hwac3 movie.avi My mplayer.sh.conf has theses lines : USEAC3=true AC3AOUT=-ao mpegpes -afm hwac3 Did I missed something ? Do you know how could I fix this issue ? I'm not an expert in that since I didn't get to receiver connection yet, but I think there is also hwdts codec. I think the correct switch is -ac hwdts. Thank you. == Here is the log logger: *** Starting mplayer.sh Version 0.8.7 logger: *** DEBUG: Variable CFGFIL has value /DATA/configVDR/mplayer.sh.conf logger: *** DEBUG: Variable USEAC3 has value true logger: *** DEBUG: Variable AC3AOUT has value -ao mpegpes -afm hwac3 logger: *** DEBUG: Variable TV_ASPECT has value 16/9 logger: *** DEBUG: Variable PAL has value true logger: *** DEBUG: Variable NTSC has value false logger: *** DEBUG: Variable USE_SPEED has value true logger: *** DEBUG: Variable DETC_FILTER has value ivtc=1 logger: *** DEBUG: Variable MPLAYER has value /usr/bin/mplayer logger: *** DEBUG: Variable VOP has value lavc=5000 logger: *** DEBUG: Variable VO has value mpegpes:card=1 logger: *** DEBUG: Variable AO has value mpegpes:card=1 logger: *** DEBUG: Variable CACHE has value 8192 logger: *** DEBUG: Variable CACHESTR has value -cache 8192 logger: *** DEBUG: Variable FRAMEDROP has value true logger: *** DEBUG: Variable FDSTR has value -framedrop logger: *** DEBUG: Variable LIRCRC has value logger: *** DEBUG: Variable LIRCSTR has value logger: *** DEBUG: Variable SUBTITLE has value -subpos 80 -sub-bg-color 0 -sub-bg-alpha 30 logger: *** DEBUG: Variable REMOTE has value -slave -nolirc logger: *** Use Option USERDEF at your own risk! logger: *** DEBUG: Variable USERDEF has value -quiet logger: *** DEBUG: Variable XResPAL has value 352 480 528 544 688 704 720 logger: *** DEBUG: Variable XResNTSC has value 352 480 512 640 704 720 logger: *** DEBUG: Variable SLOW_CPU has value false logger: *** DEBUG: *** Option DVDFiles not set correctly! You will not be able to play VCD/DVD logger: *** DEBUG: Variable DVDFiles has value logger: *** DEBUG: *** Option DVD not set correctly! You will not be able to play VCD/DVD logger: *** DEBUG: Variable DVD has value logger: *** DEBUG: Variable DVDLANG has value fr logger: *** DEBUG: Variable DVDOPTIONS has value -aop list=volume:volume=170 logger: *** DEBUG: Variable VCDOPTIONS has value logger: *** DEBUG: Variable MPEG_DIRECT has value true logger: *** DEBUG: Variable SUFFIX has value .mkv logger: *** DEBUG: Variable MPLAYER_V1 has value true logger: *** DEBUG: Calling getvidxy function to analyze source video stream ... logger: *** DEBUG: OutputFromMPLAYER: ID_VIDEO_ID=0 ID_VID_0_NAME=Cliffhanger (1993) ID_AUDIO_ID=0 ID_AID_0_NAME=DTS 5.1 768 kbps ID_AID_0_LANG=eng ID_FILENAME=/VIDEO/DIVX/Cliffhanger (1993) - 720p x264 DTS US.mkv ID_DEMUXER=mkv ID_VIDEO_FORMAT=avc1 ID_VIDEO_BITRATE=0 ID_VIDEO_WIDTH=1280 ID_VIDEO_HEIGHT=532 ID_VIDEO_FPS=23.976 ID_VIDEO_ASPECT=2.4060 ID_AUDIO_FORMAT=8193 ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=6 ID_LENGTH=6762.71 ID_VIDEO_CODEC=ffh264 ID_AUDIO_BITRATE=768000 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=2 ID_AUDIO_CODEC=dts logger: *** DEBUG: MPLAYER_RETURN: 0 logger: *** DEBUG: parsed output for ORIG_X: 1280 logger: *** DEBUG: parsed output for ORIG_Y: 532 logger: *** DEBUG: parsed output for ORIG_FPS: 23.976 logger: *** DEBUG: parsed output for ORIG_ASPECT: 2.4060 logger: *** DEBUG: parsed output for VIDEO_FORMAT: avc1 logger: *** DEBUG: parsed output for AUDIO_CODEC: dts logger: *** INFO: Source Video has Resolution of 1280 x 532 ... logger: *** DEBUG: Film logger: *** DEBUG: Variable MAX_X has value 1024 logger: *** DEBUG: Variable NEW_Y has value 425 logger: *** INFO: For Sqare Pixels we would scale to 1024 x 425 ... logger: *** DEBUG: Variable XResTEMP has value 352 480 528 544 688 704 720 logger: *** DEBUG: Variable AnzahlVonXResTEMP has value 7 logger: *** DEBUG: Variable NEW_X has value 720 logger: *** DEBUG: setting REAL_Y = FULL_Y logger: *** DEBUG: Variable CMDLINE has value /usr/bin/mplayer -vo mpegpes:card=1 -ao mpegpes:card=1 -vf scale=720:425,expand=720:576:-1:-1:1,lavc=5000:25 -speed 1.04 -framedrop -cache 8192 -slave -nolirc -subpos 80 -sub-bg-color 0 -sub-bg-alpha 30 -quiet MPlayer 1.0rc2-4.3.2 (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (Family: 6, Model: 15, Stepping: 13) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled
Re: [vdr] vdr-1.6.0 / mplayer / spdif Nexus = pb with DTS tracks
I've tried this switch as well, unfortunately it doesn't work :-( Karim _ De : vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] De la part de Alex Betis Envoyé : lundi 2 février 2009 13:40 À : VDR Mailing List Objet : Re: [vdr] vdr-1.6.0 / mplayer / spdif Nexus = pb with DTS tracks On Mon, Feb 2, 2009 at 2:26 PM, kafifi kaf...@orange.fr wrote: Hello, I am using vdr-1.6.0 and mplayer with Nexus FF card and it's spdif output. When I run some 720p_AC3.avi movies, my HC ampli receives 5.1 audio without problem. But with movies with DTS audio tracks, vdr+mplayer give only PCM in stereo mode. There is an issue with DTS passthrough. When I try mplayer **without vdr**, DTS is working : Mplayer -ao mpegpes afm hwac3 movie.avi My mplayer.sh.conf has theses lines : USEAC3=true AC3AOUT=-ao mpegpes -afm hwac3 Did I missed something ? Do you know how could I fix this issue ? I'm not an expert in that since I didn't get to receiver connection yet, but I think there is also hwdts codec. I think the correct switch is -ac hwdts. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.6.0 / mplayer / spdif Nexus = pb with DTS tracks
Hello, I am using vdr-1.6.0 and mplayer with Nexus FF card and it's spdif output. When I run some 720p_AC3.avi movies, my HC ampli receives 5.1 audio without problem. But with movies with DTS audio tracks, vdr+mplayer give only PCM in stereo mode. There is an issue with DTS passthrough. When I try mplayer **without vdr**, DTS is working : Mplayer -ao mpegpes afm hwac3 movie.avi My mplayer.sh.conf has theses lines : USEAC3=true AC3AOUT=-ao mpegpes -afm hwac3 Did I missed something ? Do you know how could I fix this issue ? Thank you. == Here is the log logger: *** Starting mplayer.sh Version 0.8.7 logger: *** DEBUG: Variable CFGFIL has value /DATA/configVDR/mplayer.sh.conf logger: *** DEBUG: Variable USEAC3 has value true logger: *** DEBUG: Variable AC3AOUT has value -ao mpegpes -afm hwac3 logger: *** DEBUG: Variable TV_ASPECT has value 16/9 logger: *** DEBUG: Variable PAL has value true logger: *** DEBUG: Variable NTSC has value false logger: *** DEBUG: Variable USE_SPEED has value true logger: *** DEBUG: Variable DETC_FILTER has value ivtc=1 logger: *** DEBUG: Variable MPLAYER has value /usr/bin/mplayer logger: *** DEBUG: Variable VOP has value lavc=5000 logger: *** DEBUG: Variable VO has value mpegpes:card=1 logger: *** DEBUG: Variable AO has value mpegpes:card=1 logger: *** DEBUG: Variable CACHE has value 8192 logger: *** DEBUG: Variable CACHESTR has value -cache 8192 logger: *** DEBUG: Variable FRAMEDROP has value true logger: *** DEBUG: Variable FDSTR has value -framedrop logger: *** DEBUG: Variable LIRCRC has value logger: *** DEBUG: Variable LIRCSTR has value logger: *** DEBUG: Variable SUBTITLE has value -subpos 80 -sub-bg-color 0 -sub-bg-alpha 30 logger: *** DEBUG: Variable REMOTE has value -slave -nolirc logger: *** Use Option USERDEF at your own risk! logger: *** DEBUG: Variable USERDEF has value -quiet logger: *** DEBUG: Variable XResPAL has value 352 480 528 544 688 704 720 logger: *** DEBUG: Variable XResNTSC has value 352 480 512 640 704 720 logger: *** DEBUG: Variable SLOW_CPU has value false logger: *** DEBUG: *** Option DVDFiles not set correctly! You will not be able to play VCD/DVD logger: *** DEBUG: Variable DVDFiles has value logger: *** DEBUG: *** Option DVD not set correctly! You will not be able to play VCD/DVD logger: *** DEBUG: Variable DVD has value logger: *** DEBUG: Variable DVDLANG has value fr logger: *** DEBUG: Variable DVDOPTIONS has value -aop list=volume:volume=170 logger: *** DEBUG: Variable VCDOPTIONS has value logger: *** DEBUG: Variable MPEG_DIRECT has value true logger: *** DEBUG: Variable SUFFIX has value .mkv logger: *** DEBUG: Variable MPLAYER_V1 has value true logger: *** DEBUG: Calling getvidxy function to analyze source video stream ... logger: *** DEBUG: OutputFromMPLAYER: ID_VIDEO_ID=0 ID_VID_0_NAME=Cliffhanger (1993) ID_AUDIO_ID=0 ID_AID_0_NAME=DTS 5.1 768 kbps ID_AID_0_LANG=eng ID_FILENAME=/VIDEO/DIVX/Cliffhanger (1993) - 720p x264 DTS US.mkv ID_DEMUXER=mkv ID_VIDEO_FORMAT=avc1 ID_VIDEO_BITRATE=0 ID_VIDEO_WIDTH=1280 ID_VIDEO_HEIGHT=532 ID_VIDEO_FPS=23.976 ID_VIDEO_ASPECT=2.4060 ID_AUDIO_FORMAT=8193 ID_AUDIO_BITRATE=0 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=6 ID_LENGTH=6762.71 ID_VIDEO_CODEC=ffh264 ID_AUDIO_BITRATE=768000 ID_AUDIO_RATE=48000 ID_AUDIO_NCH=2 ID_AUDIO_CODEC=dts logger: *** DEBUG: MPLAYER_RETURN: 0 logger: *** DEBUG: parsed output for ORIG_X: 1280 logger: *** DEBUG: parsed output for ORIG_Y: 532 logger: *** DEBUG: parsed output for ORIG_FPS: 23.976 logger: *** DEBUG: parsed output for ORIG_ASPECT: 2.4060 logger: *** DEBUG: parsed output for VIDEO_FORMAT: avc1 logger: *** DEBUG: parsed output for AUDIO_CODEC: dts logger: *** INFO: Source Video has Resolution of 1280 x 532 ... logger: *** DEBUG: Film logger: *** DEBUG: Variable MAX_X has value 1024 logger: *** DEBUG: Variable NEW_Y has value 425 logger: *** INFO: For Sqare Pixels we would scale to 1024 x 425 ... logger: *** DEBUG: Variable XResTEMP has value 352 480 528 544 688 704 720 logger: *** DEBUG: Variable AnzahlVonXResTEMP has value 7 logger: *** DEBUG: Variable NEW_X has value 720 logger: *** DEBUG: setting REAL_Y = FULL_Y logger: *** DEBUG: Variable CMDLINE has value /usr/bin/mplayer -vo mpegpes:card=1 -ao mpegpes:card=1 -vf scale=720:425,expand=720:576:-1:-1:1,lavc=5000:25 -speed 1.04 -framedrop -cache 8192 -slave -nolirc -subpos 80 -sub-bg-color 0 -sub-bg-alpha 30 -quiet MPlayer 1.0rc2-4.3.2 (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (Family: 6, Model: 15, Stepping: 13) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. PLAYING /VIDEO/DIVX/Cliffhanger (1993) - 720p x264 DTS US.mkv [mkv] Track ID 1: video (V_MPEG4/ISO/AVC) Cliffhanger (1993), -vid 0 [mkv] Track ID 2: audio (A_DTS) DTS 5.1 768 kbps, -aid 0, -alang eng [mkv] Will play video track 1. Matroska file format detected. VIDEO: [avc1] 1280x532 24bpp
[vdr] vdr 1.6.0 device selection order for recordings
Hello, I just upgraded from vdr 1.4.7 to vdr 1.6.0 (from the e-tobi.net experimental repository). That has changed the order in which devices are selected for recording significantly. Now, the only card with the CAM is selected first when recording non-encrypted channels, preventing later timers from recording encrypted channels. This is my hardware setup: DVB1: full-featured card (Hauppauge WinTV DVB-C rev 2.X) DVB2: budget card with CI and CAM (TerraTec Cinergy 1200 DVB-C) DVB3: budget card (TerraTec Cinergy 1200 DVB-C) As a test, I started tree recordings on non-encrypted channels, one after the other. With vdr 1.4.7, these recordings use DVB3, DVB1, and DVB2, sparing the card with the CAM as long as possible. With vdr 1.6.0, the recordings use DVB2 (!), DVB3, and DVB1, but using the the card with the CAM first. So one recording of a non-encrypted channels blocks all encrypted channels. I'm running a pretty standard Debian etch system with kernel 2.6.18-6-686. The root of the vdr 1.6.0 system started as a mere copy of the vdr 1.4.7 system's root, so there shouldn't be too many differences. Is it a problem with my setup or a problem in vdr 1.6.0? What should I do have vdr 'save the CAM for last'? Thanks in advance, Malte ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.6.0 device selection order for recordings
On Tuesday 16 September 2008, Malte Forkel wrote: Hello, I just upgraded from vdr 1.4.7 to vdr 1.6.0 (from the e-tobi.net experimental repository). That has changed the order in which devices are selected for recording significantly. Now, the only card with the CAM is selected first when recording non-encrypted channels, preventing later timers from recording encrypted channels. This is my hardware setup: DVB1: full-featured card (Hauppauge WinTV DVB-C rev 2.X) DVB2: budget card with CI and CAM (TerraTec Cinergy 1200 DVB-C) DVB3: budget card (TerraTec Cinergy 1200 DVB-C) As a test, I started tree recordings on non-encrypted channels, one after the other. With vdr 1.4.7, these recordings use DVB3, DVB1, and DVB2, sparing the card with the CAM as long as possible. With vdr 1.6.0, the recordings use DVB2 (!), DVB3, and DVB1, but using the the card with the CAM first. So one recording of a non-encrypted channels blocks all encrypted channels. I think I ran into a similar problem earlier myself. I have only two cards; one DVB-C TT budget (without CI/CAM) and one DVB-C Hauppauge FF with CI/CAM, and a DXR3 as the primary device. I haven't run into this problem in a while, but I'm not sure why - it might be that I swapped the cards' PCI slots or maybe I just haven't had a scenario where this would bite in a while. But anyway, I agree that VDR should save the CAM for last. And as a nice addition to that, perhaps even change the card used for a recording on the fly if that's what it takes to get all needed programs recorded, for example: Timer 1: 20:00-21:00, non-encrypted Timer 2: 20:30-21:30, non-encrypted (different MUX/$something than timer 1) Timer 3: 21:00-22:00, encrypted Card A: no CAM (can in theory do timers 1 and 2) Card B: CAM (can in theory do timers 1, 2 and 3) So, card A starts recording timer 1. Then, card B starts recording timer 2 (because it's on a different $something than timer 1, so card A can't take care of it simultaneously with timer 1). When timer 3 starts, timer 2 would be changed on the fly to continue recording on card A, and card B would start recording timer 3. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
On 05/08/08 12:12, Simon Baxter wrote: OK - I'm getting this: SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.05, 1.01) GetDevice 20 0 1 -1 no device found any ideas? If it makes any difference, I'm running vdr-1.6.0 with a budget TT-1500-C (with Alpha Multicrypt) and a FF TT-2300-C (also with Alpha Multicrypt). The card failing on this channel is the FF one (other card is tied up recording on another transponder) only seems to be failing with a single channel - other encrypted channels within the same boquet work fine works: UKTV;T:674000:C0M64:C:6900:1310+1210:1410=eng:0:606:810:182:8:0 doesn't work: Sky Movies;T:674000:C0M64:C:6900:1301+8190:1401=eng,1501=enm:0:606:801:182:8:0 Have tried the 1.6.0-1 patch, still get: SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.05, 1.01) GetDevice 20 0 1 -1 no device found with this channel Here what you could try: - swap the CAMs - use only one CAM at a time - try the CAMs with either of the DVB cards Hi again The problem is following the TT-2300-C card, not the cam or smartcard. And it's fine on the TT-1500 Budget card. It's really weird. It's only the Movies channel affected, and each time I tune to it get about 1 second of picture then NO SIGNAL. The NO SIGNAL coincides with the GetDevice message. Any ideas? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
On 05/08/08 12:12, Simon Baxter wrote: OK - I'm getting this: SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.05, 1.01) GetDevice 20 0 1 -1 no device found any ideas? If it makes any difference, I'm running vdr-1.6.0 with a budget TT-1500-C (with Alpha Multicrypt) and a FF TT-2300-C (also with Alpha Multicrypt). The card failing on this channel is the FF one (other card is tied up recording on another transponder) only seems to be failing with a single channel - other encrypted channels within the same boquet work fine works: UKTV;T:674000:C0M64:C:6900:1310+1210:1410=eng:0:606:810:182:8:0 doesn't work: Sky Movies;T:674000:C0M64:C:6900:1301+8190:1401=eng,1501=enm:0:606:801:182:8:0 Have tried the 1.6.0-1 patch, still get: SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.05, 1.01) GetDevice 20 0 1 -1 no device found with this channel Here what you could try: - swap the CAMs - use only one CAM at a time - try the CAMs with either of the DVB cards Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
When recording one channel and attempting to watch another in the same transport stream, or trying to switch to another transport stream (and hence card) I get channel not available messages. After switching back and forth to other transport streams, usually I can overcome this problem. But occasionally I it won't play any channels in one specific transport stream or another. You could add some debug outputs to cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) to find out why it thinks that channel 9 is not available. Klaus OK - I'm getting this: SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.05, 1.01) GetDevice 20 0 1 -1 no device found any ideas? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
OK - I'm getting this: SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.05, 1.01) GetDevice 20 0 1 -1 no device found any ideas? If it makes any difference, I'm running vdr-1.6.0 with a budget TT-1500-C (with Alpha Multicrypt) and a FF TT-2300-C (also with Alpha Multicrypt). The card failing on this channel is the FF one (other card is tied up recording on another transponder) only seems to be failing with a single channel - other encrypted channels within the same boquet work fine works: UKTV;T:674000:C0M64:C:6900:1310+1210:1410=eng:0:606:810:182:8:0 doesn't work: Sky Movies;T:674000:C0M64:C:6900:1301+8190:1401=eng,1501=enm:0:606:801:182:8:0 Have tried the 1.6.0-1 patch, still get: SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.05, 1.01) GetDevice 20 0 1 -1 no device found with this channel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
On 05/02/08 19:26, Simon Baxter wrote:
You could add some debug outputs to
cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView)
to find out why it thinks that channel 9 is not available.
Can someone help me out here?How do I do this?
Try the attached patch.
Klaus
--- device.c 2008/04/12 14:12:14 2.2
+++ device.c 2008/05/03 10:49:26
@@ -372,6 +372,7 @@
cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView)
{
+ printf(GetDevice %d %d %d %d\n, Channel-Number(), Priority, LiveView, avoidDevice ? avoidDevice-CardIndex() : -1);//XXX
cDevice *AvoidDevice = avoidDevice;
avoidDevice = NULL;
// Collect the current priorities of all CAM slots that can decrypt the channel:
@@ -391,7 +392,9 @@
}
}
if (!NumUsableSlots)
+{printf(no usable CAM slots!\n);//XXX
return NULL; // no CAM is able to decrypt this channel
+}//XXX
}
bool NeedsDetachReceivers = false;
@@ -432,6 +435,7 @@
imp = 1; imp |= NumUsableSlots ? 0 : device[i]-HasCi(); // avoid cards with Common Interface for FTA channels
imp = 1; imp |= device[i]-HasDecoder(); // avoid full featured cards
imp = 1; imp |= NumUsableSlots ? !ChannelCamRelations.CamDecrypt(Channel-GetChannelID(), j + 1) : 0; // prefer CAMs that are known to decrypt this channel
+ printf(j = %d, i = %d, imp = %08X, Impact = %08X\n, j, i, imp, Impact);//XXX
if (imp Impact) {
// This device has less impact than any previous one, so we take it.
Impact = imp;
@@ -446,6 +450,7 @@
break; // no CAM necessary, so just one loop over the devices
}
if (d) {
+ printf(device %d\n, d-CardIndex());//XXX
if (NeedsDetachReceivers)
d-DetachAllReceivers();
if (s) {
@@ -460,6 +465,7 @@
else if (d-CamSlot() !d-CamSlot()-IsDecrypting())
d-CamSlot()-Assign(NULL);
}
+ else printf(no device found\n);//XXX
return d;
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
Klaus Schmidinger kirjoitti 2.5.2008 kello 17.03: On 04/27/08 12:49, Tero Siironen wrote: ... I don't know if this is same problem or not but I'm having similar symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot tune to that channel, while 1.4.7 works. As can be seen from the log, the receiving starts from couple of seconds but stops right after giving this channel not available message. My system has DVB-C 2.1 FF card and Satelco Easywatch budget card. All the other encrypted channels works ok, but this one channel has problems with VDR 1.6.0. Your CAM seems to come and go. Please try the 1.6.0-1 maintenance patch from ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff which increases the time between the CAM status checks. Doesn't help, log is pretty similar still and picture shows now and then for couple of seconds May 2 23:03:36 localhost vdr: [4340] VDR version 1.6.0-1 started May 2 23:03:36 localhost vdr: [4340] codeset is 'ISO-8859-1' - known May 2 23:03:36 localhost vdr: [4340] found 23 locales in ./locale May 2 23:03:36 localhost vdr: [4340] loading /video/setup.conf May 2 23:03:36 localhost vdr: [4340] loading /video/sources.conf May 2 23:03:36 localhost vdr: [4340] loading /video/channels.conf May 2 23:03:36 localhost vdr: [4340] loading /video/timers.conf May 2 23:03:36 localhost vdr: [4340] loading /video/svdrphosts.conf May 2 23:03:36 localhost vdr: [4340] loading /video/remote.conf May 2 23:03:36 localhost vdr: [4340] loading /video/keymacros.conf May 2 23:03:36 localhost vdr: [4340] reading EPG data from /video/ epg.data May 2 23:03:37 localhost vdr: [4341] video directory scanner thread started (pid=4340, tid=4341) May 2 23:03:37 localhost vdr: [4342] video directory scanner thread started (pid=4340, tid=4342) May 2 23:03:37 localhost vdr: [4340] probing /dev/dvb/adapter0/ frontend0 May 2 23:03:37 localhost vdr: [4344] CI adapter on device 0 thread started (pid=4340, tid=4344) May 2 23:03:37 localhost vdr: [4340] probing /dev/dvb/adapter1/ frontend0 May 2 23:03:37 localhost vdr: [4342] video directory scanner thread ended (pid=4340, tid=4342) May 2 23:03:37 localhost vdr: [4345] tuner on device 1 thread started (pid=4340, tid=4345) May 2 23:03:37 localhost vdr: [4346] section handler thread started (pid=4340, tid=4346) May 2 23:03:37 localhost vdr: [4348] CI adapter on device 1 thread started (pid=4340, tid=4348) May 2 23:03:37 localhost vdr: [4340] found 2 video devices May 2 23:03:37 localhost vdr: [4340] setting primary device to 1 May 2 23:03:37 localhost vdr: [4349] tuner on device 2 thread started (pid=4340, tid=4349) May 2 23:03:37 localhost vdr: [4350] section handler thread started (pid=4340, tid=4350) May 2 23:03:37 localhost vdr: [4340] assuming manual start of VDR May 2 23:03:37 localhost vdr: [4340] SVDRP listening on port 2001 May 2 23:03:37 localhost vdr: [4340] loading /video/themes/classic- default.theme May 2 23:03:37 localhost vdr: [4340] remote control LIRC - keys known May 2 23:03:37 localhost vdr: [4351] LIRC remote control thread started (pid=4340, tid=4351) May 2 23:03:37 localhost vdr: [4344] CAM 1: module present May 2 23:03:38 localhost vdr: [4341] video directory scanner thread ended (pid=4340, tid=4341) May 2 23:03:39 localhost vdr: [4340] switching to channel 1 May 2 23:03:39 localhost vdr: [4348] CAM 3: no module present May 2 23:03:39 localhost vdr: [4344] CAM 2: no module present May 2 23:03:39 localhost vdr: [4346] channel 4 (Nelonen) event Pe 02.05.2008 22:55-23:05 'IS Urheilu-uutiset' status 4 May 2 23:03:39 localhost vdr: [4346] channel 2 (YLE TV2) event Pe 02.05.2008 22:25-00:50 'Jääkiekon MM 2008: Kanada - Slovenia' status 4 May 2 23:03:39 localhost vdr: [4346] channel 6 (Sub) event Pe 02.05.2008 22:10-23:05 'Bones' status 4 May 2 23:03:39 localhost vdr: [4346] channel 3 (MTV3) event Pe 02.05.2008 22:36-01:10 'Windtalkers' status 4 May 2 23:03:39 localhost vdr: [4346] changing pids of channel 1 from 512+512:650=deu:0:2321 to 512+512:650=deu:1027=fin:2321 May 2 23:03:39 localhost vdr: [4340] retuning due to modification of channel 1 May 2 23:03:39 localhost vdr: [4340] switching to channel 1 May 2 23:03:39 localhost vdr: [4352] live subtitle thread started (pid=4340, tid=4352) May 2 23:03:39 localhost vdr: [4353] receiver on device 1 thread started (pid=4340, tid=4353) May 2 23:03:39 localhost vdr: [4354] TS buffer on device 1 thread started (pid=4340, tid=4354) May 2 23:03:40 localhost vdr: [4346] changing pids of channel 2 from 513+513:660=fin,661=sve:0:2321 to 513+513:660=fin,661=sve:2027=fin:2321 May 2 23:03:40 localhost vdr: [4346] changing pids of channel 3 from 305+305:561=fin:0:817 to 305+305:561=fin:1073=fin:817 May 2 23:03:40 localhost vdr: [4346] changing pids of channel 5 from 514+514:670=esl:0:2321 to 514+514:670=esl:3028=sve,3027=fin:2321 May 2 23:03:41 localhost vdr: [4346] changing pids
Re: [vdr] vdr-1.6.0 channel not available
On 05/03/08 16:24, Tero Siironen wrote: Klaus Schmidinger kirjoitti 2.5.2008 kello 17.03: On 04/27/08 12:49, Tero Siironen wrote: ... I don't know if this is same problem or not but I'm having similar symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot tune to that channel, while 1.4.7 works. As can be seen from the log, the receiving starts from couple of seconds but stops right after giving this channel not available message. My system has DVB-C 2.1 FF card and Satelco Easywatch budget card. All the other encrypted channels works ok, but this one channel has problems with VDR 1.6.0. Your CAM seems to come and go. Please try the 1.6.0-1 maintenance patch from ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff which increases the time between the CAM status checks. Doesn't help, log is pretty similar still and picture shows now and then for couple of seconds Looks like there are no more unexpected CAM resets, so the reason for the channel not available must be something else. Maybe the CAM doesn't decrypt? You could add some debug output to cDevice::Action() to see whether the TS packets are getting descrambled. Maybe the TS_SCRAMBLING_TIMEOUT needs to be increased. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
Klaus Schmidinger kirjoitti 3.5.2008 kello 19.06: On 05/03/08 16:24, Tero Siironen wrote: Klaus Schmidinger kirjoitti 2.5.2008 kello 17.03: On 04/27/08 12:49, Tero Siironen wrote: ... I don't know if this is same problem or not but I'm having similar symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot tune to that channel, while 1.4.7 works. As can be seen from the log, the receiving starts from couple of seconds but stops right after giving this channel not available message. My system has DVB-C 2.1 FF card and Satelco Easywatch budget card. All the other encrypted channels works ok, but this one channel has problems with VDR 1.6.0. Your CAM seems to come and go. Please try the 1.6.0-1 maintenance patch from ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff which increases the time between the CAM status checks. Doesn't help, log is pretty similar still and picture shows now and then for couple of seconds Looks like there are no more unexpected CAM resets, so the reason for the channel not available must be something else. Maybe the CAM doesn't decrypt? You could add some debug output to cDevice::Action() to see whether the TS packets are getting descrambled. Maybe the TS_SCRAMBLING_TIMEOUT needs to be increased. I will try to debug it more. The same channel works with VDR 1.4.7 so the CAM works. Also with 1.6.0-1 all other encrypted channels that I've access works with that CAM, so there is something in that one channel which causes problems with 1.6.0-1. But I will report again when I get some more data. -- Tero ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
On 04/27/08 12:49, Tero Siironen wrote: ... I don't know if this is same problem or not but I'm having similar symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot tune to that channel, while 1.4.7 works. As can be seen from the log, the receiving starts from couple of seconds but stops right after giving this channel not available message. My system has DVB-C 2.1 FF card and Satelco Easywatch budget card. All the other encrypted channels works ok, but this one channel has problems with VDR 1.6.0. Here's the channels.conf entry: EuroNews;GlobeCast:306000:C0M128:C:6875:2221:2232=eng,2233=deu,2231=fra,2234=ita,2235=esl,2236=por,2237=rus,2238:768:B00:214:0:10:0 and here's the syslog: Apr 27 13:31:53 localhost vdr: [10238] cTimeMs: using monotonic clock (resolution is 999848 ns) Apr 27 13:31:53 localhost vdr: [10238] VDR version 1.6.0 started ... Apr 27 13:31:53 localhost vdr: [10251] CAM 1: module present ... Apr 27 13:31:55 localhost vdr: [10251] CAM 1: no module present Apr 27 13:31:55 localhost vdr: [10251] CAM 1: module present ... Apr 27 13:31:57 localhost vdr: [10251] CAM 1: no module present Apr 27 13:31:57 localhost vdr: [10251] CAM 1: module present ... Apr 27 13:31:59 localhost vdr: [10251] CAM 1: no module present Apr 27 13:31:59 localhost vdr: [10251] CAM 1: module present Apr 27 13:32:02 localhost vdr: [10251] CAM 1: module ready Apr 27 13:32:05 localhost vdr: [10251] CAM 1: Conax 4.00e, 01, 0B00, 04B1 Apr 27 13:32:09 localhost vdr: [10251] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted ... Apr 27 13:33:32 localhost vdr: [10251] CAM 1: module reset Apr 27 13:33:32 localhost vdr: [10251] CAM 1: module present Apr 27 13:33:32 localhost vdr: [10238] switching to channel 1 Apr 27 13:33:32 localhost vdr: [10238] CAM 1: unassigned ... Apr 27 13:33:33 localhost vdr: [10251] CAM 1: module ready Apr 27 13:33:36 localhost vdr: [10251] CAM 1: Conax 4.00e, 01, 0B00, 04B1 Apr 27 13:33:41 localhost vdr: [10251] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted Your CAM seems to come and go. Please try the 1.6.0-1 maintenance patch from ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.6.0-1.diff which increases the time between the CAM status checks. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
On 04/24/08 09:08, Simon Baxter wrote: Hello I have 2x DVB-C cards with Alphacrypt multi-cams. A TT-1500-C budget card and a TT-2300-C FF card and run vdr-xine. When recording one channel and attempting to watch another in the same transport stream, or trying to switch to another transport stream (and hence card) I get channel not available messages. After switching back and forth to other transport streams, usually I can overcome this problem. But occasionally I it won't play any channels in one specific transport stream or another. What's the best way to diagnose this? How do I enable debugging to see more info than is displayed in messages: Apr 24 18:53:56 callin vdr: [7375] switching to channel 8 Apr 24 18:53:56 callin vdr: [30940] transfer thread started (pid=7375, tid=30940) Apr 24 18:53:57 callin vdr: [30939] femon receiver thread ended (pid=7375, tid=30939) Apr 24 18:53:57 callin vdr: [30941] femon receiver thread started (pid=7375, tid=30941) Apr 24 18:53:58 callin vdr: [30940] setting audio track to 1 (0) Apr 24 18:54:04 callin vdr: [7375] switching to channel 9 Apr 24 18:54:04 callin vdr: [30940] transfer thread ended (pid=7375, tid=30940) Apr 24 18:54:04 callin vdr: [7375] buffer stats: 47564 (2%) used Apr 24 18:54:04 callin vdr: [7375] info: Channel not available! Apr 24 18:54:04 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:22 callin vdr: [7375] switching to channel 1 Apr 24 18:54:22 callin vdr: [30942] transfer thread started (pid=7375, tid=30942) Apr 24 18:54:22 callin vdr: [30936] TS buffer on device 2 thread ended (pid=7375, tid=30936) Apr 24 18:54:22 callin vdr: [30935] buffer stats: 84600 (4%) used Apr 24 18:54:22 callin vdr: [30935] receiver on device 2 thread ended (pid=7375, tid=30935) Apr 24 18:54:22 callin vdr: [30943] receiver on device 2 thread started (pid=7375, tid=30943) Apr 24 18:54:22 callin vdr: [30944] TS buffer on device 2 thread started (pid=7375, tid=30944) Apr 24 18:54:23 callin vdr: [30945] femon receiver thread started (pid=7375, tid=30945) Apr 24 18:54:23 callin vdr: [30942] setting audio track to 1 (0) Apr 24 18:54:26 callin vdr: [7375] switching to channel 9 Apr 24 18:54:26 callin vdr: [30942] transfer thread ended (pid=7375, tid=30942) Apr 24 18:54:26 callin vdr: [7375] buffer stats: 194204 (9%) used Apr 24 18:54:26 callin vdr: [7375] info: Channel not available! Apr 24 18:54:26 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:42 callin vdr: [7375] switching to channel 21 You could add some debug outputs to cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) to find out why it thinks that channel 9 is not available. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
You could add some debug outputs to cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) to find out why it thinks that channel 9 is not available. Can someone help me out here?How do I do this? Thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 channel not available
Simon Baxter kirjoitti 24.4.2008 kello 10.08: Hello I have 2x DVB-C cards with Alphacrypt multi-cams. A TT-1500-C budget card and a TT-2300-C FF card and run vdr-xine. When recording one channel and attempting to watch another in the same transport stream, or trying to switch to another transport stream (and hence card) I get channel not available messages. After switching back and forth to other transport streams, usually I can overcome this problem. But occasionally I it won't play any channels in one specific transport stream or another. What's the best way to diagnose this? How do I enable debugging to see more info than is displayed in messages: Apr 24 18:53:56 callin vdr: [7375] switching to channel 8 Apr 24 18:53:56 callin vdr: [30940] transfer thread started (pid=7375, tid=30940) Apr 24 18:53:57 callin vdr: [30939] femon receiver thread ended (pid=7375, tid=30939) Apr 24 18:53:57 callin vdr: [30941] femon receiver thread started (pid=7375, tid=30941) Apr 24 18:53:58 callin vdr: [30940] setting audio track to 1 (0) Apr 24 18:54:04 callin vdr: [7375] switching to channel 9 Apr 24 18:54:04 callin vdr: [30940] transfer thread ended (pid=7375, tid=30940) Apr 24 18:54:04 callin vdr: [7375] buffer stats: 47564 (2%) used Apr 24 18:54:04 callin vdr: [7375] info: Channel not available! Apr 24 18:54:04 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:22 callin vdr: [7375] switching to channel 1 Apr 24 18:54:22 callin vdr: [30942] transfer thread started (pid=7375, tid=30942) Apr 24 18:54:22 callin vdr: [30936] TS buffer on device 2 thread ended (pid=7375, tid=30936) Apr 24 18:54:22 callin vdr: [30935] buffer stats: 84600 (4%) used Apr 24 18:54:22 callin vdr: [30935] receiver on device 2 thread ended (pid=7375, tid=30935) Apr 24 18:54:22 callin vdr: [30943] receiver on device 2 thread started (pid=7375, tid=30943) Apr 24 18:54:22 callin vdr: [30944] TS buffer on device 2 thread started (pid=7375, tid=30944) Apr 24 18:54:23 callin vdr: [30945] femon receiver thread started (pid=7375, tid=30945) Apr 24 18:54:23 callin vdr: [30942] setting audio track to 1 (0) Apr 24 18:54:26 callin vdr: [7375] switching to channel 9 Apr 24 18:54:26 callin vdr: [30942] transfer thread ended (pid=7375, tid=30942) Apr 24 18:54:26 callin vdr: [7375] buffer stats: 194204 (9%) used Apr 24 18:54:26 callin vdr: [7375] info: Channel not available! Apr 24 18:54:26 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:42 callin vdr: [7375] switching to channel 21 Hi, I don't know if this is same problem or not but I'm having similar symptoms with one encrypted channel. With plain VDR 1.6.0 I cannot tune to that channel, while 1.4.7 works. As can be seen from the log, the receiving starts from couple of seconds but stops right after giving this channel not available message. My system has DVB-C 2.1 FF card and Satelco Easywatch budget card. All the other encrypted channels works ok, but this one channel has problems with VDR 1.6.0. Here's the channels.conf entry: EuroNews;GlobeCast:306000:C0M128:C:6875:2221:2232=eng,2233=deu, 2231=fra,2234=ita,2235=esl,2236=por,2237=rus,2238:768:B00:214:0:10:0 and here's the syslog: Apr 27 13:31:53 localhost vdr: [10238] cTimeMs: using monotonic clock (resolution is 999848 ns) Apr 27 13:31:53 localhost vdr: [10238] VDR version 1.6.0 started Apr 27 13:31:53 localhost vdr: [10238] codeset is 'ISO-8859-1' - known Apr 27 13:31:53 localhost vdr: [10238] found 23 locales in ./locale Apr 27 13:31:53 localhost vdr: [10238] loading /video/setup.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/sources.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/channels.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/timers.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/svdrphosts.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/remote.conf Apr 27 13:31:53 localhost vdr: [10238] loading /video/keymacros.conf Apr 27 13:31:53 localhost vdr: [10238] reading EPG data from /video/ epg.data Apr 27 13:31:53 localhost vdr: [10248] video directory scanner thread started (pid=10238, tid=10248) Apr 27 13:31:53 localhost vdr: [10249] video directory scanner thread started (pid=10238, tid=10249) Apr 27 13:31:53 localhost vdr: [10249] video directory scanner thread ended (pid=10238, tid=10249) Apr 27 13:31:53 localhost vdr: [10248] video directory scanner thread ended (pid=10238, tid=10248) Apr 27 13:31:53 localhost vdr: [10238] probing /dev/dvb/adapter0/ frontend0 Apr 27 13:31:53 localhost vdr: [10251] CI adapter on device 0 thread started (pid=10238, tid=10251) Apr 27 13:31:53 localhost vdr: [10238] probing /dev/dvb/adapter1/ frontend0 Apr 27 13:31:53 localhost vdr: [10252] tuner on device 1 thread started (pid=10238, tid=10252) Apr 27 13:31:53 localhost vdr: [10253] section handler
[vdr] vdr-1.6.0 channel not available
Hello I have 2x DVB-C cards with Alphacrypt multi-cams. A TT-1500-C budget card and a TT-2300-C FF card and run vdr-xine. When recording one channel and attempting to watch another in the same transport stream, or trying to switch to another transport stream (and hence card) I get channel not available messages. After switching back and forth to other transport streams, usually I can overcome this problem. But occasionally I it won't play any channels in one specific transport stream or another. What's the best way to diagnose this? How do I enable debugging to see more info than is displayed in messages: Apr 24 18:53:56 callin vdr: [7375] switching to channel 8 Apr 24 18:53:56 callin vdr: [30940] transfer thread started (pid=7375, tid=30940) Apr 24 18:53:57 callin vdr: [30939] femon receiver thread ended (pid=7375, tid=30939) Apr 24 18:53:57 callin vdr: [30941] femon receiver thread started (pid=7375, tid=30941) Apr 24 18:53:58 callin vdr: [30940] setting audio track to 1 (0) Apr 24 18:54:04 callin vdr: [7375] switching to channel 9 Apr 24 18:54:04 callin vdr: [30940] transfer thread ended (pid=7375, tid=30940) Apr 24 18:54:04 callin vdr: [7375] buffer stats: 47564 (2%) used Apr 24 18:54:04 callin vdr: [7375] info: Channel not available! Apr 24 18:54:04 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:22 callin vdr: [7375] switching to channel 1 Apr 24 18:54:22 callin vdr: [30942] transfer thread started (pid=7375, tid=30942) Apr 24 18:54:22 callin vdr: [30936] TS buffer on device 2 thread ended (pid=7375, tid=30936) Apr 24 18:54:22 callin vdr: [30935] buffer stats: 84600 (4%) used Apr 24 18:54:22 callin vdr: [30935] receiver on device 2 thread ended (pid=7375, tid=30935) Apr 24 18:54:22 callin vdr: [30943] receiver on device 2 thread started (pid=7375, tid=30943) Apr 24 18:54:22 callin vdr: [30944] TS buffer on device 2 thread started (pid=7375, tid=30944) Apr 24 18:54:23 callin vdr: [30945] femon receiver thread started (pid=7375, tid=30945) Apr 24 18:54:23 callin vdr: [30942] setting audio track to 1 (0) Apr 24 18:54:26 callin vdr: [7375] switching to channel 9 Apr 24 18:54:26 callin vdr: [30942] transfer thread ended (pid=7375, tid=30942) Apr 24 18:54:26 callin vdr: [7375] buffer stats: 194204 (9%) used Apr 24 18:54:26 callin vdr: [7375] info: Channel not available! Apr 24 18:54:26 callin vdr: [7375] ERROR: attempt to open OSD while it is already open - using dummy OSD! Apr 24 18:54:42 callin vdr: [7375] switching to channel 21 Thanks___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR 1.6.0 and subtitle
Hi all I did upgrade my vdr from 1.4.7 to 1.6.0 (packages are from ubuntu hardy repository)and notice that the vdr do not displays subtitles. I am using xineliboutput as output device. I found out from linuxtv.fi that one should have channels PID automatically updated, but that didn't help in my case. With subtitle button I can select different subtitles but they are not shown in the screen. Everything seems to working except that subtitles aren't shown. When I change to the channel with subtitles it is shown info: DVD Subtitles text in the screen. Has anyone any suggestions how to solve this? Best regards, Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.6.0 and subtitle
Matti Ropo wrote: Hi all I did upgrade my vdr from 1.4.7 to 1.6.0 (packages are from ubuntu hardy repository)and notice that the vdr do not displays subtitles. I am using xineliboutput as output device. I found out from linuxtv.fi that one should have channels PID automatically updated, but that didn't help in my case. With subtitle button I can select different subtitles but they are not shown in the screen. Everything seems to working except that subtitles aren't shown. When I change to the channel with subtitles it is shown info: DVD Subtitles text in the screen. Has anyone any suggestions how to solve this? You should upgrade xineliboutput, preferably from cvs. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.6.0 and subtitle
Petri Helin wrote: Matti Ropo wrote: Hi all I did upgrade my vdr from 1.4.7 to 1.6.0 (packages are from ubuntu hardy repository)and notice that the vdr do not displays subtitles. I am using You should upgrade xineliboutput, preferably from cvs. This did solve the problem. Thank you. -Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Am 27.03.2008 um 21:01 schrieb Reinhard Nissl: I'd say it's suggested. At least it is part of my H.264 patches. What does the sync early patch do? Ciao, Dominique ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Dominique Simon schrieb: I'd say it's suggested. At least it is part of my H.264 patches. What does the sync early patch do? Vanilla VDR waits for an I frame before it passes video (and audio) data on to output devices. Further more, audio data is still not passed on from that time, because VDR takes some time to decide which audio track shall get selected. The sync early patch addresses these issues. Audio and video packets are passed on a soon as they make up a valid frame. The result is that you can already hear the audio track before the video appears on screen. This is because video decoding can only start with an I frame. Any frames before the I frame won't appear on screen. But passing these frames to the output device has the benefit that PTS' (presentation time stamp) for these frames are passed on to the output device which needs this information to synchronize audio and video. As a result, audio and video will be in sync already when the first image appears on screen. That's why the patch got called sync early. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.6.0
OK I now have the following set up: - hush with VIA Epia M1 - Fedora Core 8 up to date except libX11* - xine-lib 1.2 from hg today 27/03/2008 - vdr 1.6.0 - vdr-xine 0.8.2 - femon 1.2.4 - vdradmin-am-3.6.1 *In order to use xine with xxmc hardware acceleration I have downgraded libX11 to the version from Fedora Core 7 - bug libX11 with xcb support xine still locks up if I change desktops to check my mail or if I try to use the right click configuration menu when running with vdr. Fine when running xine with other media files. I am now able to use pulseaudio in xine - recent updates of alsa and pulseaudio probably fixed the issues I was having. Sound can still be crappy when watching an avi file... Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Boguslaw Juza schrieb: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
On Thu, 27 Mar 2008, Reinhard Nissl wrote: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Did you create H.264 patches for VDR-1.6.0? Boguslaw Juza ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Boguslaw Juza schrieb: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Did you create H.264 patches for VDR-1.6.0? No. The patches for 1.5.8 should still work. What I recall, 1.6.0 did only complete translation. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.6.0 and syncearly
Hi! Is the syncearly patch needed for new vdr? Boguslaw Juza ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.6.0 - when ?
Klaus when will you plan to release the vdr developer version with support of the multiproto + h.264 + ts recording ? It will be the vdr 1.6.0 ? Igor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.6.0 - when ?
Please read the following carefully: Date: Sun, 17 Feb 2008 15:46:42 +0100 From: Klaus Schmidinger [EMAIL PROTECTED] Subject: [vdr] [ANNOUNCE] VDR developer version 1.5.15 NOTE: = This is the final step towards a stable version 1.6.0. Please report any bugs as soon as possible, so that I can prepare a release candidate next weekend. If nothing unexpected happens, I plan to release version 1.6.0 on March 2. The changes since version 1.5.14: - Revoked the switch to the multiproto driver in order to make a new stable version before making this big switch and forcing all users to install a driver that is not yet in the kernel source. The removed code will reappear in version 1.7.0. István -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
