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] 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] 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] 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: [7319] CAM: 88C0 212012 8802 0100 1 - 09 89 01 00 F5 F9 33 17 FF 40 00 00 00 08 00 80
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.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
[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
