Re: [vdr] UPnP/DLNA server plugin?
2008/5/1 Gavin Hamill <[EMAIL PROTECTED]>: > On Thu, 2008-05-01 at 21:20 +0300, Teemu Suikki wrote: > > > > I tried loading streamdev urls like http://vdr:3000/TS/3 with PS3 > > browser.. It does understand that it's some sort of stream, but I > > think it mistakes it as mp3 audio for some reason. Perhaps it would > > help if the url would end with .mpg or something. > > > > I don't have a PS3 - but could you try using URLs with 'PES' or 'PS' in > the URL rather than TS? It might like those more :) > > Especially if it wants '.mpg' extensions, then PS should be exactly what > it wants to hear.. > > Certainly UPnP would be a wonderful goal for streamdev's next > development cycle. I have tried PES, PS, TS, no difference there. :) PS3 can play PS and TS files nicely, so both streams should work as well.. What format exactly are .vdr files, are they PES? PS3 doesn't play them directly, but transcoding to PS or TS works. -- Teemu Suikki http://www.z-power.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] random freezes when using multiple vdr instances
Klaus Schmidinger schrieb: > On 04/30/08 09:24, Matthias Kortstiege wrote: > >> Hello, >> >> since the upgrade to VDR version 1.6.0 the entire system will randomly >> freeze when using multiple instances of VDR. This issue could be >> reproduced by using the commandline switch -D to specify the DVB devices. >> >> Unfortunately there are no logs which could identify the problem .. it >> only freezes. >> >> Example: >> * vdr = "-D 0 -D 1" >> * vdrdevel = "-D 2 -D 3" >> >> I am running the very latest version from e-tobi (multipatch). vdrdevel >> is the same version as vdr, but repacked by using the buildpackage >> option SPECIAL_VDR_SUFFIX=devel. Using the older 1.5.13 setup with the >> same hardware (4x cinergy c ~ mantis) is working like charm. >> > > Does this mean that version 1.5.13 worked, but 1.5.14 doesn't? > > Klaus > Did not tested it with other versions. I've updated from 1.5.13 to 1.6.0. Could this be an issue of the mantis dvb modules (jusst.de/hg/mantis) and ca changes made to vdr in version 1.6.0 ? Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.0 & multiproto & hvr4000 -> multiproto_plus
On Fri, May 02, 2008 at 12:03:48AM +0200, gimli wrote: > Hi, > > sorry, took a little bit longer to find time for made the patch. > This patch is against multiproto_plus + > HVR-4000-multiproto_plus-2008-04-25.diff. > With this combination i'm able to tune all HDTV channels on Astra 19.2E. > My Hardware is a WinTV Nova HD S2. With this new patch, there is no change for me, which is fine, because everything was already working so it don't break anything here :-) I attach an all in one patch just to be easier to follow, and as you wrote it to VDR's ml, I sent a copy there also. Steven and Manu : could it be included into multiproto_plus ? Thanks you very much, -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre HVR-4000-multiproto_plus-2008-05-02.diff.bz2 Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.0 & multiproto & hvr4000 -> multiproto_plus
Gregoire Favre wrote: > On Fri, May 02, 2008 at 12:03:48AM +0200, gimli wrote: >> Hi, >> >> sorry, took a little bit longer to find time for made the patch. >> This patch is against multiproto_plus + >> HVR-4000-multiproto_plus-2008-04-25.diff. >> With this combination i'm able to tune all HDTV channels on Astra 19.2E. >> My Hardware is a WinTV Nova HD S2. > > With this new patch, there is no change for me, which is fine, because > everything was already working so it don't break anything here :-) > > I attach an all in one patch just to be easier to follow, and as you > wrote it to VDR's ml, I sent a copy there also. > > Steven and Manu : could it be included into multiproto_plus ? after this patch the multiproto_plus does not compile against my older kernel (suse 10.2 stock kernel 2.6.18) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.0 & multiproto & hvr4000 -> multiproto_plus
On Fri, May 02, 2008 at 01:15:45PM +0200, Lars Bläser wrote: > after this patch the multiproto_plus does not compile against my older > kernel (suse 10.2 stock kernel 2.6.18) Have you replaced linux/include/linux/compiler.h with the one from your kernel ? (in multiproto_plus dir) if that's going to be included, this shouldn't be in of course. -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] How to use VDR2VDR for h264 streaming?
On Tue, 29 Apr 2008 15:23:58 +0200, YUP wrote > is it possible to use vdr-stream plugin to stream from one > VDR (server) to another VDR( client) h264 encoded stream in the same > way as it is implemented in VDR-2-VDR with mpeg2? Some time ago the VTP part of streamdev-server has been extended to support extern remux. The streamdev-client could select externremux by issuing a "CAPS EXTERN" instead of the standard "CAPS TSPIDS" (you will need to modify the source). Of course the client VDR needs to support h264 - patches are available - and externremux has to emit an h264 TS stream. That's the theory. Your mileage may vary. Probably noone even tried the CAPS EXTERN part. Good luck ;) Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] random freezes when using multiple vdr instances
On 05/02/08 09:54, Matthias Kortstiege wrote: > Klaus Schmidinger schrieb: >> On 04/30/08 09:24, Matthias Kortstiege wrote: >> >>> Hello, >>> >>> since the upgrade to VDR version 1.6.0 the entire system will randomly >>> freeze when using multiple instances of VDR. This issue could be >>> reproduced by using the commandline switch -D to specify the DVB devices. >>> >>> Unfortunately there are no logs which could identify the problem .. it >>> only freezes. >>> >>> Example: >>> * vdr = "-D 0 -D 1" >>> * vdrdevel = "-D 2 -D 3" >>> >>> I am running the very latest version from e-tobi (multipatch). vdrdevel >>> is the same version as vdr, but repacked by using the buildpackage >>> option SPECIAL_VDR_SUFFIX=devel. Using the older 1.5.13 setup with the >>> same hardware (4x cinergy c ~ mantis) is working like charm. >>> >> Does this mean that version 1.5.13 worked, but 1.5.14 doesn't? >> >> Klaus >> > Did not tested it with other versions. I've updated from 1.5.13 to 1.6.0. > Could this be an issue of the mantis dvb modules (jusst.de/hg/mantis) > and ca changes made to vdr in version 1.6.0 ? In order to further track down the problem, please verify that version 1.5.13 works, and then try 1.5.14, 1.5.15 etc., until you find a version that doesn't work. Do all tests with exactly the same driver, so that a driver problem can be ruled out. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr@linuxtv.org
On 04/28/08 07:23, Igor wrote: > Hi > > > when I want to switch on dvb-s2 channels ( > > > Apr 28 09:18:32 localhost vdr: [4188] switching to channel 2782 > Apr 28 09:18:32 localhost vdr: [4535] transfer thread ended (pid=4188, > tid=4535) > Apr 28 09:18:32 localhost vdr: [4188] buffer stats: 0 (0%) used > Apr 28 09:18:32 localhost vdr: [4756] transfer thread started (pid=4188, > tid=4756) > Apr 28 09:18:32 localhost vdr: [4537] TS buffer on device 1 thread ended > (pid=4188, tid=4537) > Apr 28 09:18:32 localhost vdr: [4536] buffer stats: 0 (0%) used > Apr 28 09:18:32 localhost vdr: [4536] receiver on device 1 thread ended > (pid=4188, tid=4536) > Apr 28 09:18:32 localhost vdr: [4757] receiver on device 1 thread started > (pid=4188, tid=4757) > Apr 28 09:18:32 localhost vdr: [4758] TS buffer on device 1 thread started > (pid=4188, tid=4758) > Apr 28 09:18:40 localhost vdr: [4197] frontend 0 timed out while tuning to > channel 2782, tp 111914 > Apr 28 09:18:40 localhost vdr: [4197] ERROR (dvbdevice.c,302): Invalid > argument > Apr 28 09:18:40 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: > fepriv->state=2 > Apr 28 09:18:50 localhost vdr: [4197] ERROR (dvbdevice.c,302): Invalid > argument > Apr 28 09:18:50 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: > fepriv->state=2 > Apr 28 09:19:00 localhost vdr: [4197] ERROR (dvbdevice.c,302): Invalid > argument > Apr 28 09:19:00 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: > fepriv->state=2 > Apr 28 09:19:10 localhost vdr: [4197] ERROR (dvbdevice.c,302): Invalid > argument > Apr 28 09:19:10 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: > fepriv->state=2 > Apr 28 09:19:20 localhost vdr: [4197] ERROR (dvbdevice.c,302): Invalid > argument > Apr 28 09:19:20 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: > fepriv->state=2 > Apr 28 09:19:30 localhost vdr: [4197] ERROR (dvbdevice.c,302): Invalid > argument > Apr 28 09:19:30 localhost kernel: dvb_frontend_ioctl: FESTATE_RETUNE: > fepriv->state=2 > Apr 28 09:19:41 localhost vdr: [4197] frontend 0 timed out while tuning to > channel 2782, tp 111914 Please post the channels.conf line of that channel. 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/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] Upgrading from 1.4.7 to 1.7.0 : enabling #define
On 04/25/08 18:34, Pierre-Yves Paranthoen (PERSO) wrote: > I increased the values in ci.c. A bit better but, still no decryption > and channel not available : > > #define MODULE_CHECK_INTERVAL 1 // ms > #define MODULE_RESET_TIMEOUT5 // s > gives under 1.7.0 : > > > Apr 25 18:29:04 localhost vdr: [7317] CAM 2: module ready > Apr 25 18:29:11 localhost vdr: [7317] CAM 2: doesn't reply to QUERY - > only a single channel can be decrypted > Apr 25 18:29:11 localhost vdr: [7313] switching to channel 2 > Apr 25 18:29:11 localhost vdr: [7313] CAM 2: assigned to device 1 > Apr 25 18:29:11 localhost vdr: [7328] transfer thread started (pid=7313, > tid=7328) > Apr 25 18:29:11 localhost vdr: [7329] receiver on device 1 thread > started (pid=7313, tid=7329) > Apr 25 18:29:11 localhost vdr: [7330] TS buffer on device 1 thread > started (pid=7313, tid=7330) > Apr 25 18:29:11 localhost vdr: [7313] setting watchdog timer to 20 seconds > Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 71 10 01 01 13 01 20 14 03 00 83 00 > Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 70 10 01 01 13 01 20 14 03 03 0B 00 > Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 72 10 01 01 13 01 20 14 03 02 26 10 > Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 6F 10 01 01 13 01 20 14 03 03 28 20 > Apr 25 18:29:12 localhost vdr: [7319] CAM: 88C0 212012 8801 0100 1 - 09 > 89 01 00 F5 8C 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 88 33 15 FF 00 > 00 0C 00 00 00 00 06 24 99 F5 8B 33 11 FF 00 00 0E 02 00 00 00 02 24 > 99 F5 8A A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E5 EC 00 86 FF 00 00 00 > Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 DF 10 01 01 13 01 20 14 03 00 83 00 > Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 DD 10 01 01 13 01 20 14 03 03 0B 00 > Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 E0 10 01 01 13 01 20 14 03 02 26 10 > Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 DE 10 01 01 13 01 20 14 03 03 28 20 > Apr 25 18:29:13 localhost vdr: [7319] CAM: 88C0 212012 8802 0100 1 - 09 > 89 01 00 F5 F9 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 F5 33 15 FF 00 > 00 0C 00 00 00 00 06 24 99 F5 F4 33 11 FF 00 00 0E 02 00 00 00 02 24 > 99 F5 F8 A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E6 59 00 86 FF 00 00 00 > Apr 25 18:29:14 localhost vdr: [7323] EPGSearch: timer conflict check > started > Apr 25 18:29:14 localhost vdr: [7323] EPGSearch: timer conflict check > finished > Apr 25 18:29:18 localhost vdr: [7313] max. latency time 1 seconds > Apr 25 18:29:53 localhost vdr: [7322] connect from 192.168.3.245, port > 53838 - accepted > Apr 25 18:29:59 localhost vdr: [7328] transfer thread ended (pid=7313, > tid=7328) > Apr 25 18:30:00 localhost vdr: [7313] switching to channel 3 > Apr 25 18:30:00 localhost vdr: [7313] buffer stats: 5640 (0%) used > Apr 25 18:30:00 localhost vdr: [7330] TS buffer on device 1 thread ended > (pid=7313, tid=7330) > Apr 25 18:30:00 localhost vdr: [7329] buffer stats: 5264 (0%) used > Apr 25 18:30:00 localhost vdr: [7334] transfer thread started (pid=7313, > tid=7334) > Apr 25 18:30:00 localhost vdr: [7329] receiver on device 1 thread ended > (pid=7313, tid=7329) > Apr 25 18:30:00 localhost vdr: [7335] receiver on device 1 thread > started (pid=7313, tid=7335) > Apr 25 18:30:00 localhost vdr: [7336] TS buffer on device 1 thread > started (pid=7313, tid=7336) > Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 71 10 01 01 13 01 20 14 03 00 83 00 > Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 70 10 01 01 13 01 20 14 03 03 0B 00 > Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 72 10 01 01 13 01 20 14 03 02 26 10 > Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0500 0 - 09 > 0F 05 00 F9 6F 10 01 01 13 01 20 14 03 03 28 20 > Apr 25 18:30:00 localhost vdr: [7319] CAM: 88C0 212012 8801 0100 1 - 09 > 89 01 00 F5 8C 33 17 FF 40 00 00 00 08 00 80 44 24 99 F5 88 33 15 FF 00 > 00 0C 00 00 00 00 06 24 99 F5 8B 33 11 FF 00 00 0E 02 00 00 00 02 24 > 99 F5 8A A8 21 FF 20 00 01 00 00 00 04 4E 24 99 E5 EC 00 86 FF 00 00 00 > Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 DF 10 01 01 13 01 20 14 03 00 83 00 > Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 DD 10 01 01 13 01 20 14 03 03 0B 00 > Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 E0 10 01 01 13 01 20 14 03 02 26 10 > Apr 25 18:30:01 localhost vdr: [7319] CAM: 88C0 212012 8802 0500 0 - 09 > 0F 05 00 F9 DE 10 01 01 13 01 20 14 03 03 28 20 > Apr 25 18:30:01 localhost vdr: [7
Re: [vdr] DVB-subtitles on VDR-1.6.0-1 stay on screen for too long
On 04/24/08 14:23, Harri Kukkonen wrote: > Harri Kukkonen wrote: >> Hi, >> >> after upgrading to from to VDR 1.6.0 I have noticed that the >> DVB-subtitles stay on screen for about one second too long. The >> difference is noticeable compared to 1.4.7 with subtitles-plugin. >> Problem exists on both live-viewing and record-viewing. I use >> Fujitsu-Siemens DVB-C FF-card as output. >> >> In addition I compared recordings of a same program from Finnish Yle TV1 >> and TV1+ (TV1 has DVB-subtitles, TV1+ is same channel with subtitles >> "burned in" to video), and subtitles stayed on the dvb-subtitled >> recording about one second longer compared to the "burned in" video >> version. Subtitles start time seemed to be same on both versions. I can >> provide both recordings for testing if needed. >> >> > I uploaded samples (90MB) to rapidshare: > http://rapidshare.com/files/110035063/dvbsubtest.tar.bz2.html > > In the file are 2 two minute recordings, from TV1 with dvb-subtitles and > TV1+ with burned in subtitles. There are good examples of the problem at > 0:15 and 0:30. The timeouts are given in "seconds", and can be seen when the line static bool DebugConverter = false; is set to "true" in dvbsubtitle.c. From what I can see in your example, the timing appears right to me (although I haven't used a stopwatch, just counted "twentyone", "twentytwo", etc). Maybe you can do some more precise measurements, but as it stands now I have the feeling that the "burned in" subtitles are shown too shortly. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Judder with interlaced channels
I have some problems with interlaced channels on SD & HDTV. Judder and jitter and its good visible when I using a SD channel with a ticker-tape. If I tune to Discovery HD 1080i its shaking and stutter around but 720P channel like National Geographic HD are smooth. I don't know where to look at. My configurations : 1.) DualCore AMD , 2GB memory, Suse 10.3, vdr 1.6.0, regular dvb drivers from suse dvd and tt budget 1500-ci (cam=aston 1.07) 2.) SingleCore AMD, 1GB memory, Suse 10.3 vdr 1.7.0 multiproto dvb drivers incl, some patches and tt budget 3200-ci (cam=aston 1.07) Booth systems has the same problem and its not related to lnb or signal. I have check it with my humax hdci 2000 and picture is very good and smooth movements. After record some channels and ftp it to a windows system or apple its visible to in for example Media Player or Media Player Classic. With streamdev the same. Suggestions? Please help me out. Jean-Paul ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.0 & multiproto & hvr4000 -> multiproto_plus
Gregoire Favre wrote: > On Fri, May 02, 2008 at 01:15:45PM +0200, Lars Bläser wrote: > >> after this patch the multiproto_plus does not compile against my older >> kernel (suse 10.2 stock kernel 2.6.18) > > Have you replaced linux/include/linux/compiler.h with the one from your > kernel ? (in multiproto_plus dir) if that's going to be included, this > shouldn't be in of course. your patch included the compiler.h, after replacing it with the right one the drivers are build your patch also created a .config.old in v4l and the cx88 modules are not build (the .config created during make does only contain inaktive lines for cx88 modules), i modified the .config manual and started make again ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
[EMAIL PROTECTED] wrote: > Hi, > > I'm using vdr-1.6 and xineliboutput from cvs. > I'm using it with freevo and vdr is controlled through > xine-ui/vdr-sxfe by stdin. > For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui. > Every so often when i change between channels xine-ui/vdr-sxfe stops > displaying video+osd. I have to quit it and start it again. (but > commands are still sent to vdr, if i press "up" 2 times while > xine-ui/vdr-sxfe has stopped displaying anything, I can see vdr > receiving the "up" events) > > I haven't tried to reverse patches, or to reproduce it without using stdin > (--stdctl/--slave). > Before I do so, I'm just asking if anybody has encountered this issue > already. > > Cheers. > For a temporary solution you could revert file xine_input_vdr.c to version 1.127: cvs update -C -r 1.127 xine_input_vdr.c It has been reported to cure the kind of behaviour you have been experiencing. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7.0 & multiproto & hvr4000 -> multiproto_plus
On Fri, May 02, 2008 at 06:12:53PM +0200, Lars Bläser wrote: > > Have you replaced linux/include/linux/compiler.h with the one from your > > kernel ? (in multiproto_plus dir) if that's going to be included, this > > shouldn't be in of course. > > your patch included the compiler.h, after replacing it with the right > one the drivers are build > your patch also created a .config.old in v4l and the cx88 modules are > not build (the .config created during make does only contain inaktive > lines for cx88 modules), i modified the .config manual and started make > again OK, here's one without compiler.h and without .config.old (by the way, I don't understand why make distclean didn't remove it...). Good new, such way the patch is even smaller, so it would be really good to have it included finally into the repo :-) Any objection to the inclusion ? -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre HVR-4000-multiproto_plus-2008-05-02.diff.bz2 Description: Add full HVR-4000 support into multiproto_plus ___ 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
[vdr] A signal strength problem?
Hi I'm running vdr-1.6.0 with 2 dvb-c cards and CIs. I'm having occasional audio/video problems and getting these messages: May 3 05:06:04 callin vdr: [12239] PES packet shortened to 2208 bytes (expected: 2944 bytes) May 3 05:06:04 callin vdr: [12239] 3 cRepacker messages suppressed May 3 05:06:04 callin vdr: [12239] cAudioRepacker(0xC0): skipped 464 bytes to sync on next audio frame May 3 05:06:11 callin vdr: [12239] PES packet shortened to 1840 bytes (expected: 2944 bytes) May 3 05:06:14 callin vdr: [12239] PES packet shortened to 2760 bytes (expected: 2944 bytes) May 3 05:07:04 callin vdr: [12239] 16 cRepacker messages suppressed May 3 05:07:04 callin vdr: [12239] cAudioRepacker(0xC0): skipped 288 bytes to sync on next audio frame May 3 05:07:10 callin vdr: [12239] PES packet shortened to 1472 bytes (expected: 2944 bytes) May 3 05:07:14 callin vdr: [12239] PES packet shortened to 1472 bytes (expected: 2944 bytes) May 3 05:07:34 callin vdr: [12239] 7 cRepacker messages suppressed May 3 05:07:34 callin vdr: [12239] cAudioRepacker(0xC0): skipped 192 bytes to sync on next audio frame May 3 05:07:41 callin vdr: [12239] PES packet shortened to 2760 bytes (expected: 2944 bytes) May 3 05:08:05 callin vdr: [12239] 3 cRepacker messages suppressed May 3 05:08:05 callin vdr: [12239] cAudioRepacker(0xC0): skipped 240 bytes to sync on next audio frame May 3 05:08:44 callin vdr: [12239] cAudioRepacker(0xC0): skipped 204 bytes while syncing on next audio frame May 3 05:09:14 callin vdr: [12239] 3 cRepacker messages suppressed May 3 05:09:14 callin vdr: [12239] cAudioRepacker(0xC0): skipped 396 bytes while syncing on next audio frame May 3 05:09:34 callin vdr: [12239] PES packet shortened to 2024 bytes (expected: 2944 bytes) May 3 05:09:34 callin vdr: [12239] 1 cRepacker messages suppressed May 3 05:09:34 callin vdr: [12239] cAudioRepacker(0xC0): skipped 424 bytes to sync on next audio frame Am I right in thinking this looks like signal strength problems? FEMON reports STR at 71%, SNR 7% and 0 for BER and UNC on card 0 and STR 37%, SNR 6%, BER/UNC=0 on card 1 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
> [EMAIL PROTECTED] wrote: >> Hi, >> >> I'm using vdr-1.6 and xineliboutput from cvs. >> I'm using it with freevo and vdr is controlled through >> xine-ui/vdr-sxfe by stdin. >> For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui. Can you tell me more on how this works? Are you running a standard freevo rpm, or built from source? How does the xineliboutput work with freevo, is there any HOWTO? How is this stdin key mapping working? Thanks Simon ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Petri Helin <[EMAIL PROTECTED]> writes: > For a temporary solution you could revert file xine_input_vdr.c to > version 1.127: > > cvs update -C -r 1.127 xine_input_vdr.c > > It has been reported to cure the kind of behaviour you have been > experiencing. I'll do that. Cheers. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Judder with interlaced channels
On Fri, May 2, 2008 at 4:40 PM, <[EMAIL PROTECTED]> wrote: > I have some problems with interlaced channels on SD & HDTV. Judder and > jitter and its good visible when I using a SD channel with a > ticker-tape. If I tune to Discovery HD 1080i its shaking and stutter > around but 720P channel like National Geographic HD are smooth. I > don't know where to look at. > HDTV on VDR is still an evolving science. What are you using? Xine or Xinelibout? Are you using FFMPEG or CoreAVC? What de-interlacing options are you using? Basically we need more info! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] OT: ITV HD Testing on Eurobird but receivable with VDR
Hi, For those of you interested in picking up strange test broadcasts, ITV HD is currently testing on Eurobird 1 @ 28.5E. Apparently the channel is currently broadcasting in H.222 (MPEG4 in an MPEG2 stream?), but can be picked up if you are using VDR+XINE+COREAVC. Most set top box satellite receivers can't pull in this channel at the moment. Presently they are showing a loop of HD images of London at 1920x1088i. I had to manually enter the information: 11428H / 27500 VPID: 3401 DPID: 3402 SPID: 54207 Anyway, if you are into picking up strange new test broadcasts (particularly HD) with your VDR box then enjoy. Cheers, Morfsta ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
"Simon Baxter" <[EMAIL PROTECTED]> writes: >> [EMAIL PROTECTED] wrote: >>> Hi, >>> >>> I'm using vdr-1.6 and xineliboutput from cvs. >>> I'm using it with freevo and vdr is controlled through >>> xine-ui/vdr-sxfe by stdin. >>> For instance I send "hitk Up" to vdr-sxfe or "EventUp" to xine-ui. > > Can you tell me more on how this works? Are you running a standard freevo > rpm, or built from source? How does the xineliboutput work with freevo, is > there any HOWTO? I'm using freevo-1.x from svn. I'm using debian and ubuntu. I'm installing kaa and freevo in /usr/local/stow and using stow to make it available through the standard paths. (cd /usr/src/kaa; python setup.py install --prefix /usr/local/stow/kaa; cd /usr/local/stow; stow kaa; ldconfig; cd /usr/src/freevo; python setup.py install --prefix /usr/local/stow/free; cd /usr/local/stow; stow free) I then install vdrpylib (although i don't use it) And I use a modified freevo-vdr plugin. (but i can't remember where to get it) > How is this stdin key mapping working? The freevo-vdr plugin catches and maps freevo events to vdr actions that it passes through stdin. (vdr can be controlled through xine when you use vdr or xineliboutput) Sorry my english is not helping this evening. Just run xine --stdctl 'xvdr://url/...#need_stuff' and type 'eventup' (or vdr-sxfe --slave with 'hitk up') Anyway if you're are interested i can give you the modified plugin i'm using. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
> I'm using freevo-1.x from svn. > I'm using debian and ubuntu. I'm installing kaa and freevo in > /usr/local/stow and using stow to make it available through the > standard paths. > (cd /usr/src/kaa; python setup.py install --prefix > /usr/local/stow/kaa; cd /usr/local/stow; stow kaa; ldconfig; cd > /usr/src/freevo; python setup.py install --prefix > /usr/local/stow/free; cd /usr/local/stow; stow free) > > I then install vdrpylib (although i don't use it) > And I use a modified freevo-vdr plugin. (but i can't remember where to > get it) > >> How is this stdin key mapping working? > > The freevo-vdr plugin catches and maps freevo events to vdr actions > that it passes through stdin. > (vdr can be controlled through xine when you use vdr or xineliboutput) > > Sorry my english is not helping this evening. > Just run xine --stdctl 'xvdr://url/...#need_stuff' and type 'eventup' > (or vdr-sxfe --slave with 'hitk up') > > Anyway if you're are interested i can give you the modified plugin i'm > using. Sounds interesting - I've been looking at reskinning my vdr box. Have been using vdr natively with vdr-xine - but need plugins for dvd, mp3, mplayer etc to get features I need. Also the OSD is quite limited and looking a bit dated :) If you could share your modified plugin - that'd be great ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
Petri Helin <[EMAIL PROTECTED]> writes: > For a temporary solution you could revert file xine_input_vdr.c to > version 1.127: > > cvs update -C -r 1.127 xine_input_vdr.c > > It has been reported to cure the kind of behaviour you have been > experiencing. btw, vdr-sxfe is also affected. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cvs xineliboutput
[EMAIL PROTECTED] wrote: > Petri Helin <[EMAIL PROTECTED]> writes: > >> For a temporary solution you could revert file xine_input_vdr.c to >> version 1.127: >> >> cvs update -C -r 1.127 xine_input_vdr.c >> >> It has been reported to cure the kind of behaviour you have been >> experiencing. > > btw, vdr-sxfe is also affected. > Reverting xine_input_vdr.c, recompiling (make plugins) and reinstalling vdr-sxfe should fix that. -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr