Re: [vdr] Plugin compiler arguments / Make.config
On 28.10.2009 20:44, Udo Richter wrote: On 28.10.2009 09:01, Andreas Mair wrote: I wonder why no other plugin authors shared there opinion and how they fix it. As I understand it every plugin must be changed whenever VDR introduces changes in that area and if the VDR compiling user doesn't use (and adopt) Make.config. I guess this one got lost in the summer break... My preferred solution to this would be if all plugins would include some global configuration into their makefiles for setting global default parameters for VDR and plugins. The best order would be to call such a Make.global before calling an existing Make.config, so that Make.config can still override these rules. Until then, the only way is to add some version dependent defines before calling Make.config. At some point in the past I said that I won't interfere with that whole Makefile, Make.config, Make.whatever stuff any more, because whatever we change, there will likely be somebody who wants it different ;-) So if you agree on a patch, just send it. By the way: The current newplugin script also doesn't add largefile defines in case that no Make.config exists. Added for version 1.7.11. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] CAM auto resetting - feature request??
On 01.09.2009 23:38, Simon Baxter wrote: I was afraid that might be the suggestion! It seems pretty random when the CAM will crash. It is possible it's only on certain channels, and only one of the CAMs - it only happens very rarely So you have 2 identical CAMs (Alphacrypt) (with the same firmware?), and exactly one of them sometimes fails, right? Have you tried swapping the two CAMs? This should tell us whether the problem is with the CAM or with the CI adapter. Klaus I've discovered this happens to both CAMs, so it's either not a hardware issue, or both CAMs are affected. Managed to capture the following logs prior to the CAM dropping from AlphaCrypt to CAM Ready (with no decrypting) Sep 2 08:17:21 freddy vdr: [27702] switching to channel 11 Sep 2 08:17:21 freddy vdr: [1150] transfer thread ended (pid=27702, tid=1150) Sep 2 08:17:21 freddy vdr: [27702] buffer stats: 110356 (5%) used Sep 2 08:17:21 freddy vdr: [6564] transfer thread started (pid=27702, tid=6564) Sep 2 08:17:21 freddy vdr: [1152] TS buffer on device 1 thread ended (pid=27702, tid=1152) Sep 2 08:17:21 freddy vdr: [1151] buffer stats: 75388 (3%) used Sep 2 08:17:21 freddy vdr: [1151] receiver on device 1 thread ended (pid=27702, tid=1151) Sep 2 08:17:21 freddy vdr: [6565] receiver on device 1 thread started (pid=27702, tid=6565) Sep 2 08:17:21 freddy vdr: [6566] TS buffer on device 1 thread started (pid=27702, tid=6566) Sep 2 08:17:23 freddy vdr: [6564] setting audio track to 1 (0) Sep 2 08:17:34 freddy vdr: [27702] switching to channel 1 Sep 2 08:17:34 freddy vdr: [6564] transfer thread ended (pid=27702, tid=6564) Sep 2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS continuity errors Sep 2 08:17:34 freddy vdr: [27702] cTS2PES got 0 TS errors, 2 TS continuity errors Sep 2 08:17:34 freddy vdr: [27702] buffer stats: 63544 (3%) used Sep 2 08:17:34 freddy vdr: [6567] transfer thread started (pid=27702, tid=6567) Sep 2 08:17:34 freddy vdr: [6566] TS buffer on device 1 thread ended (pid=27702, tid=6566) Sep 2 08:17:34 freddy vdr: [6565] buffer stats: 62980 (3%) used Sep 2 08:17:34 freddy vdr: [6565] receiver on device 1 thread ended (pid=27702, tid=6565) Sep 2 08:17:34 freddy vdr: [6568] receiver on device 1 thread started (pid=27702, tid=6568) Sep 2 08:17:34 freddy vdr: [6569] TS buffer on device 1 thread started (pid=27702, tid=6569) Sep 2 08:17:38 freddy vdr: [6567] transfer thread ended (pid=27702, tid=6567) Sep 2 08:17:38 freddy vdr: [6569] TS buffer on device 1 thread ended (pid=27702, tid=6569) Sep 2 08:17:38 freddy vdr: [6568] buffer stats: 193828 (9%) used Sep 2 08:17:38 freddy vdr: [6568] receiver on device 1 thread ended (pid=27702, tid=6568) Sep 2 08:17:39 freddy vdr: [27702] switching to channel 1 Sep 2 08:17:39 freddy vdr: [27702] buffer stats: 116748 (5%) used Sep 2 08:17:39 freddy vdr: [27702] info: Channel not available! Sep 2 08:17:41 freddy vdr: [27702] switching to channel 9 Sep 2 08:17:41 freddy vdr: [6570] transfer thread started (pid=27702, tid=6570) Sep 2 08:17:41 freddy vdr: [6570] setting audio track to 1 (0) Sep 2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on device 0: Input/output error Sep 2 08:17:54 freddy vdr: [27707] ERROR: can't write to CI adapter on device 0: Input/output error Sep 2 08:17:55 freddy vdr: [27707] ERROR: can't write to CI adapter on device 0: Input/output error Sep 2 08:17:55 freddy kernel: dvb_ca adapter 0: DVB CAM detected and initialised successfully This looks more like a driver bug to me. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] No Audio on ATSC Qam256 or OTA..
On 02.08.2009 19:22, Alex Lasnier wrote:
Klaus Schmidinger wrote:
On 07/30/09 01:05, Rob Davis wrote:
Stile wrote:
On Tue, Jun 23, 2009 at 12:43 PM, Rob Davisr...@davis-family.info
wrote:
Alex Lasnier wrote:
Rob Davis wrote:
I have it normally connected to Comcast cable which should pipe
through
a bunch of FTV channels using QAM256. These I can see and hear in
kaffeine with AC97 audio. However, in VDR it appears to change the
pids
automatically so that the audio stops working. If I manually change
VDR
to not auto update and put the APID in then it squeeks rather than
works. However, streaming to mplayer using streamdev seems to work.
(It
does the same this with OTA channels too - although I can only get 4
with a portable antenna.)
ATSC uses only AC-3 audio, so the Apid should be 0 and the Dpid
needs to
be set appropriately. Since the sound squeaks, whatever value you
have
set for the Apid should be the Dpid.
For example,
WIFR-Wx:495000:M256:C:0:1984:0;Dpid:0:0:2:0:0:0
Perfect... Thanks
Is there a way to keep auto update on, but stop Comcast from sending
wrong pids? It keeps settings all audio options to 0 and some vpids
too?
The streamtype for those AC3 PIDs is 0x81. Adding this to pat.c will
add the digital PIDs correctly.
--- pat.c~2009-06-22 12:28:08.0 -0400
+++ pat.c2009-06-22 13:32:48.461538560 -0400
@@ -432,6 +432,9 @@
}
}
break;
+case 0x81: // AC3 DPIDs
+ Dpids[NumDpids++] = stream.getPid();
+ break;
//default: printf(PID: %5d %5d %2d %3d %3d\n,
pmt.getServiceId(), stream.getPid(), stream.getStreamType(),
pmt.getVersionNumber(), Channel-Number());//XXX
}
for (SI::Loop::Iterator it; (d =
(SI::CaDescriptor*)stream.streamDescriptors.getNext(it,
SI::CaDescriptorTag)); ) {
Perfect. I wonder if this could go in the atscepg patch?
Can you try if this also works if you insert the line
case 0x81: // AC3 DPIDs
after the line
//XXX case 8: // STREAMTYPE_13818_DSMCC
instead? I'm asking because I'd like to see whether there are
also language descriptors available...
Klaus
Yes, language descriptors are present. However, ATSC also uses 0x81 as
the AC3 descriptor tag. So we need another
case 0x81:
after
case SI::AC3DescriptorTag:
In case this is still current, can you please send me a (tested) patch?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR frontend device: Xtreamer
On 12/06/2009 04:18 PM, Theunis Potgieter wrote: 2009/12/1 alexw al...@undercover.mine.nu mailto:al...@undercover.mine.nu On 11/29/2009 04:13 PM, Theunis Potgieter wrote: 2009/11/27 alexwal...@undercover.mine.nu mailto:al...@undercover.mine.nu: Hi, I do. Do you use an Xtreamer device as a frontend, what are you using to achive this? I am using a PCH-A110 device with vdr-ui running on a separate server (for better integration). Channels are served using the standard streamdev plugin. The only drawback is the necessity to quit (close) the running stream and go back to the vdr-ui selection page each time you want to change to another channel. I have managed to build a jsp playlist with all VDR channels, but channel change is not quick enough to bring a good `surfing` experience with this method. Using xineliboutput you can watch the `live` stream and change channel without quitting the player but the mono pmt parser fails sometime to get the new pids (tested with soft and hard demuxerm. m2ts and pes container). I am convinced that this is the best way to have an acceptable switching time between 2 channels reusing existing player with low key/remote dev (directfb keyb app to redirect remote key to VDR app). I tried this with vdr-1.7.9 and as soon as I switch the channel the Xtreamer device stops. I still need to press stop and play again. Are you using the cvs version of the plugin? If not, you should give it a try. There is a fix which send a new PMT with relevant pids each time a channel is performed. You can verify using a tool like dvbsnoop. If the screen is still black, it is a problem of the PCH player. Even if the new channel is not playing, going back to previous one must show the proper picture. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR frontend device: Xtreamer
Has anybode DLNA capable televisions for example from samsung or sony? It would be interesting to know would be easy to use those with vdr for watching live tv and recordings. Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] LCD with vdr-1.7.x ?
Hello, graphlcd seems to not having been updated for a really long time... Is there something else (I like to use my Logitech G15 LCD keyboard). Thank you very much, -- Grégoire Favre, Chemin de Mallieu 15, 1009 Pully, +41 21 550 61 93 prof - Gymnase de Chamblandes, Avenue des Désertes 29, 1009 Pully sip - 310...@sip.freesip.ch / gsm - +41 78 765 65 00 http://www.gycham.vd.ch/~greg / netvoip.ch : +41 21 544 77 44 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
