Re: [vdr] silly question
Le vendredi 28 mars 2008 à 19:28 +, Andy Carter a écrit : Check Setup-DVB-Update channels and select your preferred option Thanks! It has been a long time since I went in there... =:-D Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Upgrading to VDR-1.6.0 and CAM : does not decrypt anymore
Hi, I'm a VDR user for a few years now. I was using vdr-1.4.7 until today and wanted to upgrade to the 1.6.0 version. I just compiled and installed the 1.6.0 version over the previous running one. I noticed that VDR was modifying the channels.conf by tagging encrypted channels. I also remarked a random detection of tha cam module. It gives sometimes the correct model of the cam, sometimes not. The result of course is VDR is not decoding encrypted channels anymore. Is there a so huge difference on CAM handling between those two version that i missed a special parameter ? Any help really really appriciated. Thanks regards Pierre PS : my setup : vdr-1.6.0 - dvb-s drivers from 2.6.20 kernel with dvb-ttpci-01.fw-2622 under a Hauppauge WINTV NEXUS S - ASTON CAM with valid subscription card from CanalSat (France ASTRA 19.2) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Deinterlace / Motion Compensation
Hi! I have a quesion to LCD TV owners. Most of the new LCD TVs have a motion compensation feature. Is it deinterlacing the picture? I'm going to buy Sony40, to connect to PC via DVI/HDMI with 720p or 1080p and run VDR with vdr-xine. Now Im using nvidia xxmc and the deinterlace is ugly. With LCD TV it'll be visible much more, so I need better deinterlacing - so I'm wondering if TV hw motion compensation will do it... Boguslaw Juza ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
alexw wrote: On Friday 28 March 2008 14:52:38 alexw wrote: On Thursday 27 March 2008 18:22:35 Artur Skawina wrote: VDR User wrote: On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina [EMAIL PROTECTED] wrote: I have a similar setup, just with 100M ethernet instead of wifi and NFS instead of samba. wifi could be a problem, but if you're able to watch the same channel live you should also be able to view a recording. Takes a lot more bandwidth to record playback then just to record so the fact that live tv is fine doesn't amount to much I don't think. I was referring to playing a finished recording and playing a file that is currently being extended by the server vdr -- alexw said that doesn't work well for him. It should, unless the disk and/or fs can't handle the two data streams concurrently, while keeping the latency low enough. I'm assuming the vdr server in powerful enough to handle the load, yes. My setup is a little bit more complicated as it is using a share drive on both machine. The two local disks are only CF. The file server is compose of 4x SATA II 500GB in raid 5 (total ~1.5 TB available) piloted by a promise controller and a fully idle 3 GHz P4 CPU. The throughput or the sustained write/read access is not a bottleneck. Here is a quick ASCII art drawing: /-- 100M --[AP]~ WIFI 54Mb ~[vdr client/FF]-[TV] [switch]--- 100M ---[CIFS/fileserver] \-- 100M -- [vdr server/B2C2]-DVB-S+DVB-T This evening I will test the provided patch. Using the patch provided by Artur, playing a finished/ongoing recording is smoother than before. Thank you for testing (and for enabling the extra logging). Does smoother than before mean that there is some improvement, but the playback still isn't perfect? The fact that the recorder hangs on to the last 4M of the stream and the data is appended in large chunks can cause problems when timeshifting by just a few seconds -- the player could try to access the not yet written data. This should only happen at the very end of an ongoing recording, within 4M of EOF (depending on the bitrate usually a couple of seconds after the live program arrived). Sometimes the player stops in the middle of a recording due to a zero size request. Here is the log: vdr: [3836] dvbplayer thread started (pid=3643, tid=3836) vdr: [3836] resuming replay at index 1950 (0:01:18.01) vdr: [3837] non blocking file reader thread started (pid=3643, tid=3837) vdr: [3836] SetBrokenLink: no GOP header found in video packet vdr: [3836] setting audio track to 1 (0) vdr: [3836] playing '/var/vdr/video/SERVER/recording/2008-03-28.18.58.50.50.rec/001.vdr' unexpect stop of replay vdr: [3837] non blocking file reader thread ended (pid=3643, tid=3837) vdr: [3836] dvbplayer thread ended (pid=3643, tid=3836) - vdr: [5618] WANT: fd: 25 1068536495 .. 1068722913 SIZE: 186418 vdr: [5618] READ: fd: 25 1068536495 .. 1068666704 SIZE: 130209 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1068666704 .. 1068983331 SIZE: 316627 vdr: [5618] READ: fd: 25 1068666704 .. 1068680058 SIZE: 13354 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068680058 .. 1068690344 SIZE: 10286 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068690344 .. 1068721839 SIZE: 31495 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068721839 .. 1069246127 SIZE: 524288 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1069246127 .. 1070294703 SIZE: 1048576 vdr: [5618] READ: fd: 25 1069246127 .. 1069246127 SIZE: 0 jump: 0 ra: 12582912 vdr: [5618] non blocking file reader thread ended (pid=5563, tid=5618) vdr: [5617] dvbplayer thread ended (pid=5563, tid=5617) Weird, cUnbufferedFile::Read(Size=0). I'll try to reproduce this. - vdr: [5627] READ: fd: 25 1188203807 .. 1188214024 SIZE: 10217 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188214024 .. 1188226152 SIZE: 12128 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188226152 .. 1188267411 SIZE: 41259 jump: 0 ra: 12582912 vdr: [5627] WANT: fd: 25 1188267411 .. 1188503927 SIZE: 236516 vdr: [5627] READ: fd: 25 1188267411 .. 1188278781 SIZE: 11370 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188278781 .. 1188292400 SIZE: 13619 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188292400 .. 1188335024 SIZE: 42624 jump: 0 ra: 12582912 vdr: [5627] WANT: fd: 25 1188335024 .. 1188589175 SIZE: 254151 vdr: [5627] READ: fd: 25 1188335024 .. 1188344461 SIZE: 9437 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188344461 .. 1188365793 SIZE: 21332 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188365793 .. 1188459990 SIZE: 94197 jump: 0 ra: 12582912 vdr: [5627] WANT: fd: 25 1188459990 .. 1188777569 SIZE: 317579 vdr: [5627] READ: fd: 25 1188459990 .. 1188473626 SIZE: 13636
Re: [vdr] HELP, no text in OSD anymore
C.Scheeder wrote: i have a BIG Problem since this morning. ithought before i install vdr-1.6 it would be wise to update my debian-sid to the aktual packages. But thta was a BAD Idea, after it all texts in VDR's OSD vanished. Please check, if you have installed any fonts in /usr/share/fonts/truetype. The package ttf-bitstream-vera and/or ttf-freefont should be installed. If they are, try updating your font-cache: dpkg-reconfigure fontconfig fc-cache -f -vv Please also check VDR's font configuration: cat /var/lib/vdr/setup.conf | grep ^Font Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
Artur Skawina a écrit : alexw wrote: On Friday 28 March 2008 14:52:38 alexw wrote: On Thursday 27 March 2008 18:22:35 Artur Skawina wrote: VDR User wrote: On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina [EMAIL PROTECTED] wrote: I have a similar setup, just with 100M ethernet instead of wifi and NFS instead of samba. wifi could be a problem, but if you're able to watch the same channel live you should also be able to view a recording. Takes a lot more bandwidth to record playback then just to record so the fact that live tv is fine doesn't amount to much I don't think. I was referring to playing a finished recording and playing a file that is currently being extended by the server vdr -- alexw said that doesn't work well for him. It should, unless the disk and/or fs can't handle the two data streams concurrently, while keeping the latency low enough. I'm assuming the vdr server in powerful enough to handle the load, yes. My setup is a little bit more complicated as it is using a share drive on both machine. The two local disks are only CF. The file server is compose of 4x SATA II 500GB in raid 5 (total ~1.5 TB available) piloted by a promise controller and a fully idle 3 GHz P4 CPU. The throughput or the sustained write/read access is not a bottleneck. Here is a quick ASCII art drawing: /-- 100M --[AP]~ WIFI 54Mb ~[vdr client/FF]-[TV] [switch]--- 100M ---[CIFS/fileserver] \-- 100M -- [vdr server/B2C2]-DVB-S+DVB-T This evening I will test the provided patch. Using the patch provided by Artur, playing a finished/ongoing recording is smoother than before. Thank you for testing (and for enabling the extra logging). Does smoother than before mean that there is some improvement, but the playback still isn't perfect? The fact that the recorder hangs on to the last 4M of the stream and the data is appended in large chunks can cause problems when timeshifting by just a few seconds -- the player could try to access the not yet written data. This should only happen at the very end of an ongoing recording, within 4M of EOF (depending on the bitrate usually a couple of seconds after the live program arrived). The playback is really improved, especially when doing timeshift recording. I will try to identify the reason why I am having (sporadic) freezes. Sometimes the player stops in the middle of a recording due to a zero size request. Here is the log: vdr: [3836] dvbplayer thread started (pid=3643, tid=3836) vdr: [3836] resuming replay at index 1950 (0:01:18.01) vdr: [3837] non blocking file reader thread started (pid=3643, tid=3837) vdr: [3836] SetBrokenLink: no GOP header found in video packet vdr: [3836] setting audio track to 1 (0) vdr: [3836] playing '/var/vdr/video/SERVER/recording/2008-03-28.18.58.50.50.rec/001.vdr' unexpect stop of replay vdr: [3837] non blocking file reader thread ended (pid=3643, tid=3837) vdr: [3836] dvbplayer thread ended (pid=3643, tid=3836) - vdr: [5618] WANT: fd: 25 1068536495 .. 1068722913 SIZE: 186418 vdr: [5618] READ: fd: 25 1068536495 .. 1068666704 SIZE: 130209 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1068666704 .. 1068983331 SIZE: 316627 vdr: [5618] READ: fd: 25 1068666704 .. 1068680058 SIZE: 13354 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068680058 .. 1068690344 SIZE: 10286 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068690344 .. 1068721839 SIZE: 31495 jump: 0 ra: 12582912 vdr: [5618] READ: fd: 25 1068721839 .. 1069246127 SIZE: 524288 jump: 0 ra: 12582912 vdr: [5618] WANT: fd: 25 1069246127 .. 1070294703 SIZE: 1048576 vdr: [5618] READ: fd: 25 1069246127 .. 1069246127 SIZE: 0 jump: 0 ra: 12582912 vdr: [5618] non blocking file reader thread ended (pid=5563, tid=5618) vdr: [5617] dvbplayer thread ended (pid=5563, tid=5617) Weird, cUnbufferedFile::Read(Size=0). I'll try to reproduce this. Sometimes it take a long time to occur, sometimes not. - vdr: [5627] READ: fd: 25 1188203807 .. 1188214024 SIZE: 10217 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188214024 .. 1188226152 SIZE: 12128 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188226152 .. 1188267411 SIZE: 41259 jump: 0 ra: 12582912 vdr: [5627] WANT: fd: 25 1188267411 .. 1188503927 SIZE: 236516 vdr: [5627] READ: fd: 25 1188267411 .. 1188278781 SIZE: 11370 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188278781 .. 1188292400 SIZE: 13619 jump: 0 ra: 12582912 vdr: [5627] READ: fd: 25 1188292400 .. 1188335024 SIZE: 42624 jump: 0 ra: 12582912 vdr: [5627] WANT: fd: 25 1188335024 .. 1188589175 SIZE: 254151 vdr: [5627] READ: fd: 25 1188335024 .. 1188344461 SIZE: 9437
Re: [vdr] Deinterlace / Motion Compensation
Boguslaw Juza wrote: Hi! I have a quesion to LCD TV owners. Most of the new LCD TVs have a motion compensation feature. Is it deinterlacing the picture? I'm going to buy Sony40, to connect to PC via DVI/HDMI with 720p or 1080p and run VDR with vdr-xine. Now Im using nvidia xxmc and the deinterlace is ugly. With LCD TV it'll be visible much more, so I need better deinterlacing - so I'm wondering if TV hw motion compensation will do it... TVs de-interlace would matter with interlaced output but I suppose field/frame accurate scaled and original way interlaced e.g. 1080i output is not possible with Nvidia and X.org. I'm using progressive 1080p50 output for 576i50 DVB-T/S video. Libxine handles de-interlacing, and Xv driver in Xorg the scaling with graphics hardware. The magic spell from xinelibout config is xineliboutput.Video.DeinterlaceOptions = method=Greedy,cheap_mode=0,pulldown=none,framerate_mode=full,judder_correction=0, use_progressive_frame_flag=1,chroma_filter=1,enabled=1 The result is IMHO pretty good with a 50 Hz X.org mode where syncronization to vertical refresh is usually close to perfect. De-interlacing consumes more CPU than 576i MPEG-2 video decoding. Advertised techniques for frame rate interpolation to 100/120 Hz perhaps matter more for typical Blu-Ray low rate 24p videos than 50/60p progressive video from PC. I haven't seen those in action so I'm only guessing. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DXR3 and subtitles in 1.5.x
En/na Rolf Ahrenberg ha escrit: Also, skinsoppalusikka doesn't update the palette of channel logos, if Well, IMO the skin isn't responsible of palette updates, but the real problem might be in the osd implemantation of DXR3 plugin. channel logo *must* be disabled for the dxr3. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
