Re: [vdr] Streamdev to Streamdev with PVRInput card

[L. Hanisch]

Hi,

Am 08.06.2011 22:25, schrieb Rainer Blickle:

Hi Rob,

I also don't think its a pvrinput problem because:
streamdev doesn't query for a new device if the current and the next
channel has the same transponder. This is checked via the following
define:

channels.h:#define ISTRANSPONDER(f1, f2)  (abs((f1) - (f2))<  4) //XXX

All the channels in channel.conf have the same frequency, so streamdev
only changes the receivers but doesn't query for a device.
I havent understand exactly what you are doing. Do you use an analogue
input (like scart) of the pvr500 card and the channel switch script
changes the channel of another device ? If so, i could imagine the
frequency in channels.conf doesn't matter and you could simply modify
the frequencies.


 The frequency matters since he is using the tuner input.

Lars.




Regards, Rainer

2011/6/8 Rob Davis:



I have a PVR500 with the PVRInput plugin running on my Backend.

I am using an old Hauppauge FF DVB-s card just as a frontend on another

low powered system in order to throw the PVRInput channels to the
kitchen.  On the backend it's all working, however, switching between
channels doesn't quite work, as the streamdev server will give the
client the same channel over and over again regardless of what it
requested, unless the device changes (ie, if I go from /dev/video1 to
/dev/video2 it'll change channel).

how do you force switching the video device?


i hacked device.c.. But don't tell anyone.. :-)






An example of the channel list is:


2-WTTW PBS_Affiliate
ntsc;WTTW:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30020:32:32:0
3-WREX NBC_Affiliate
ntsc;WREX:67250:TV|NTSC:V:0:301+101=2:300=@4:305:0:30030:48:48:0 4-WTVO

ABC_Affiliate

ntsc;WTVO:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30040:64:64:0
5-WIFR CBS_Affiliate
ntsc;WIFR:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30050:80:80:0
6-WQRF Fox_Affiliate
ntsc;WQRF:67250:TV|NTSC:V:0:301+101=2:300=@4:0:0:30060:96:96:0



But, obviously all on the same line.  I think this is probably an issue

with streamdev rather than pvrinput as it works with Vomp happily.


I need it to detach and change channel in order to trigger the external

channel changer script.



pvrinput does its channel settings (this includes executing the
externchannelswitch-script) inside its function OpenDvr() while the encoder
is still stopped.
The settings will only be done if the bool ChannelSettingsDone is false.

This

bool is always false at first plugin start. I guess this is the reason

why your channel settings were done once:



Jun  7 19:13:24 oac vdr: [8795] entering cPvrDevice::OpenDvr: Dvr of

/dev/video1 (PVR500#1) is closed

Jun  7 19:13:24 oac vdr: [8795] entering cPvrDevice::CloseDvr: Dvr of

/dev/video1 (PVR500#1) is closed

Jun  7 19:13:24 oac vdr: [8795] cPvrDevice::ResetBuffering(): tsBuffer

prefill = 314524 for /dev/video1 (PVR500#1)

Jun  7 19:13:24 oac vdr: [8795] channel is television.
Jun  7 19:13:24 oac vdr: [8795] OpenDvr: calling
/etc/vdr/plugins/pvrinput/externchannelswitch.sh 30040 4 1 67250 Jun  7

19:13:25 oac vdr: [8795] OpenDvr: returned from

/etc/vdr/plugins/pvrinput/externchannelswitch.sh 30040 4 1 67250 Jun  7

19:13:25 oac vdr: [8795] OpenDvr: sleeping for 3 seconds... Jun  7
19:13:28 oac vdr: [8795] OpenDvr: waking up

Jun  7 19:13:28 oac vdr: [8795] SetVBImode(525, 0) on /dev/video1


When leaving OpenDvr, the bool is set to true.
It will only become false again during runtime, if vdr calls the

pvrinput- function SetChannelDevice() and determines the needed
settings.


And this is your problem. There are no debug messages from pvrinput's

SetChannelDevice() or ProvidesChannel(), so vdr never calls  these
pvrinput

functions - although a channel switch for a pvrinput device is requested.

But why? I have no idea. It works for you with vomp. It worked for me

with streamdev when I tested this last year. But I had only
streamdev-server running and used vlc to switch channels.


Maybe a streamdev developer reads this and has an idea or can explain

possible

interactions between streamdev-client, vdr and a receiving device.



I think this is a streamdev issue not a pvrinput one, as if I change from
channel 5 to 6 on the remote streamdev client it will continue to display
channel 5.  If both my tuners are busy then it will lock to channel 5 on
my backend if I test it with xineliboutput.  Not lock to channel 6.  I had
a look at the http::// streamdev playlist settings and it sees different
channel pids.  Streamdev to vlc would work as it breaks the streamdev
connection when you change channel.  But streamdev-server to
streamdev-client doesn't seem to break the connection, just request a
second channel as it releases the first.






___
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] Fix for recording problem in VDR 1.7.20

[L. Hanisch]

Hi,

Am 30.08.2011 19:40, schrieb Dirk Vornheder:

The upload to Sigi's FTP-Server has finished.

The filename is problemvdr1720pvr3sat1.ts !


 Since it's not impossible that the TS generated by pvrinput may be incorrect, which version of ivtv and pvrinput do 
you use?


Lars.




Dirk


___
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] Diseqc problems with VDR1.7.19

[L. Hanisch]

Hi,

Am 25.07.2011 21:18, schrieb Udo Richter:

Am 25.07.2011 13:12, schrieb Hawes, Mark:

I’ve done some further investigation and as far as I can tell the
problem appears to be with the value returned by cDiseqc::Codes in
diseqc.c.

The following trace from 1.7.19 shows the problem:

Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01



The identical trace from 1.7.18 which works correctly looks like this:

Received from diseqc->Codes(n) a pointer 137333125 to : E0 10 38 F4
[..]
Received from diseqc->Codes(n) a pointer 137333125 to : E0 31 6B 01
[..]
Received from diseqc->Codes(n) a pointer 137333125 to : E1 31 6B 01




Without further trying, my wild guess is that the bug is in the
following code fragment of const char *cDiseqc::Codes(const char *s) const:


   int n = strtol(t,&p, 16);
   if (!errno&&  p != t&&  0<= n&&  n<= 255) {
  if (parsing) {
 codes[NumCodes++] = uchar(n);
 numCodes = NumCodes;


My guess is that it must be "if (!parsing)" instead. The switch seems to
be true for syntax checking from cDiseqc::Parse() (the conf file
parser), and false otherwise. The way it is, the values in codes[] only
change when called from the file parser, and then stay at the last code
sequence that has been parsed forever.


 Since I'm working on the unicable patch and try to wrap my brain around the whole diseqc stuff, I'm not sure if the 
implementation is designed for more than one code sequence per line.

 But it's a guess as well.

Lars.




Cheers,

Udo

___
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] Fix for recording problem in VDR 1.7.20

[L. Hanisch]

Am 02.09.2011 16:08, schrieb Klaus Schmidinger:

On 30.08.2011 19:40, Dirk Vornheder wrote:

Am 29.08.2011 22:49, schrieb Klaus Schmidinger:

On 29.08.2011 22:30, Dirk Vornheder wrote:




On 19.08.2011 18:43, Klaus Schmidinger wrote:

There have been some reports about recording problems with VDR 1.7.20
on some HD channels.
This patch should fix this.

Klaus


--- remux.c 2011/08/15 09:50:14 2.58
+++ remux.c 2011/08/19 15:33:26
@@ -974,8 +974,10 @@
payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
if (payloadUnitOfFrame != 0 && independentFrame)
payloadUnitOfFrame = 0;
- if (payloadUnitOfFrame)
+ if (payloadUnitOfFrame) {
+ newPayload = false;
newFrame = false;
+ }
}
if (framesPerPayloadUnit <= 1)
scanning = false;


Would the log messages look like this without above patch?

Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
payload - buffering
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
buffer (23312 > 940) - dropped 23124 bytes
...


Those were the reports I got from users.

Klaus



Patch for remux.c doesn't fix the problem if i use my Hauppauge
PVR-cards 500 !

With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.

Aug 29 22:07:44 pcneu vdr: [20700] record
/video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory
/video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] recording to
'/video0/ZIB_2/2011-08-29.21.57.13-0.rec/1.ts'
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory
/video4/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
(pid=20700, tid=21580)
Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
started (pid=20700, tid=21581)
Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
- accepted
Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
started (pid=20700, tid=21582)
Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
payload - buffering
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
type buffer (2444 > 940) - dropped 2444 bytes
...


Can you please provide a 1 minute VDR recording from that device (made
with the most recent
developer version that works for you) and tell me where to download it?

Klaus



The upload to Sigi's FTP-Server has finished.

The filename is problemvdr1720pvr3sat1.ts !


Apparently in this file every TS packet that starts a new PES packet
has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this
should only be set for TS packets that contain the beginning of an
actual payload unit (which may consist of several PES packets).

So I would assume that the TS data is in error.


 I will take a look at the PS-to-TS-code of pvrinput. When I wrote/adjust it I didn't know anything of TS and I had to 
learn a lot in a short time. Esp. adding PCR etc.


 Thanks!
Lars.



Klaus

___
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] Fix for recording problem in VDR 1.7.20

[L. Hanisch]

Am 02.09.2011 19:57, schrieb Andreas Regel:

Am 02.09.2011 16:08, schrieb Klaus Schmidinger:

On 30.08.2011 19:40, Dirk Vornheder wrote:

Am 29.08.2011 22:49, schrieb Klaus Schmidinger:

On 29.08.2011 22:30, Dirk Vornheder wrote:




On 19.08.2011 18:43, Klaus Schmidinger wrote:

There have been some reports about recording problems with VDR
1.7.20
on some HD channels.
This patch should fix this.

Klaus


--- remux.c 2011/08/15 09:50:14 2.58
+++ remux.c 2011/08/19 15:33:26
@@ -974,8 +974,10 @@
payloadUnitOfFrame = (payloadUnitOfFrame + 1) %
-framesPerPayloadUnit;
if (payloadUnitOfFrame != 0 && independentFrame)
payloadUnitOfFrame = 0;
- if (payloadUnitOfFrame)
+ if (payloadUnitOfFrame) {
+ newPayload = false;
newFrame = false;
+ }
}
if (framesPerPayloadUnit <= 1)
scanning = false;


Would the log messages look like this without above patch?

Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
payload - buffering
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
buffer (23312 > 940) - dropped 23124 bytes
...


Those were the reports I got from users.

Klaus



Patch for remux.c doesn't fix the problem if i use my Hauppauge
PVR-cards 500 !

With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.

Aug 29 22:07:44 pcneu vdr: [20700] record
/video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory
/video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] recording to
'/video0/ZIB_2/2011-08-29.21.57.13-0.rec/1.ts'
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory
/video4/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
(pid=20700, tid=21580)
Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
started (pid=20700, tid=21581)
Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
- accepted
Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
started (pid=20700, tid=21582)
Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
payload - buffering
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
type buffer (2444 > 940) - dropped 2444 bytes
...


Can you please provide a 1 minute VDR recording from that device (made
with the most recent
developer version that works for you) and tell me where to download it?

Klaus



The upload to Sigi's FTP-Server has finished.

The filename is problemvdr1720pvr3sat1.ts !


Apparently in this file every TS packet that starts a new PES packet
has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this
should only be set for TS packets that contain the beginning of an
actual payload unit (which may consist of several PES packets).

So I would assume that the TS data is in error.


 Would that mean that the PUSI bit should only be set in packets where a 
picture start code is contained?


I would say this is the expected behaviour as one PES packet normally is one 
payload unit. The MPEG2 standard only
defines that when the PUSI bit is set a PES packet shall start in the payload 
of the TS packet. There is no other
limitation.


 I just know what Wikipedia tells me... :-)

Lars.



Andreas


___
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] [ANNOUNCE] vdr-pvrinput

[L. Hanisch]

Hi,

Am 15.09.2011 14:47, schrieb Joerg Bornkessel:



Hi all,



The plugin for integrating analog MPEG2 cards by Hauppauge (et
al.) into the vdr has a new home.



http://projects.vdr-developer.org/projects/show/plg-pvrinput



It's adapted to the latest changes of vdr (>= 1.7.13). For older
versions the plugin-param-patch is still needed. Take a
look at the README to adjust your channels.conf to the matching syntax of your 
vdr.



http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/README
http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/HISTORY


Latest available Version
vdr-pvrinput-2011-02-12.tgz
is still broken on

=linux-headers-2.6.38




In file included from pvrinput.c:1:
common.h:9:28: error: linux/videodev.h: No such file or directory
In file included from common.c:1:
common.h:9:28: error: linux/videodev.h: No such file or directory
make: *** [common.o] Error 1
make: *** Waiting for unfinished jobs
make: *** [pvrinput.o] Error 1




 You're right, but it's already fixed in the git repository
 http://projects.vdr-developer.org/git/vdr-plugin-pvrinput.git/

 I guess it's time for a new release since I also added the new 
"GetSignalStrength" method of the latest vdr.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-pvrinput

[L. Hanisch]

Hi,

Am 15.09.2011 14:47, schrieb Joerg Bornkessel:

Latest available Version
vdr-pvrinput-2011-02-12.tgz
is still broken on

=linux-headers-2.6.38


 I just released a new tarball:
 
http://projects.vdr-developer.org/attachments/download/668/vdr-pvrinput-2011-08-18.tgz

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] ERROR: video data stream broken

[L. Hanisch]

Hi,

Am 19.09.2011 14:13, schrieb Steffen Barszus:

You might want to check dynamite plugin. If you have different drivers
for the different cards you can let it reload that specific driver.
If you just want to kick out that tuner until the next reboot (or
whatever), thats possible too.


 That's true for devices which deliver no data for a while in the GetTSPacket method. But if it's the epg-scan, just 
the demux device is used (if I'm right). Then the "GetTSWatchdog" won't be triggered.


Lars.




2011/9/19 Dominic Evans:

On 19 September 2011 12:17, Dominic Evans  wrote:

I've recently started seeing quite a few instances of a vdr throwing
this error (ERROR: video data stream broken) and then initiating an
emergency exit.


fyi, looking in the logs, this does seem to happen whilst VDR is
rapidly switching between transponders presumably during an EPG scan
or whilst checking for new channels/transponders.

___
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



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] add dummy osd to vdr plugin dummydevice

[L. Hanisch]

Hi Petri, hello list,

 https://github.com/flensrocker/vdr-plugin-dummydevice/tarball/v-osd0

 I added a dummy osd to the dummydevice to avoid messages from vdr like
 "ERROR: no OSD provider available - using dummy OSD!"

 It's useful for headless server mode without any other OSD provider.

 Thanks for yor plugin!

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [PATCH] for cards like Cine-C/T with multiple frontends but only one shared demux/dvr

[L. Hanisch]

Hi,

 Since the driver doesn't allow to create only the frontend of the desired delivery type, here's a patch for 
cDvbDevice. If there's no demux/dvr device with the frontend number it looks for one with a lower number.

 Now it's possible to use "-D 0" for DVB-C or "-D 1" for DVB-T (change device 
numbers to your setup).

 Of course the dynamite-plugin can also be used. Just set "dynamite_attach=no" at the unwanted frontend with a udev 
rule (please look at the dynamite README).


 It's not really tested, since I have not such a card, but the patch is almost 
trivial. Feedback is welcome.

 I hope the dvb/v4l developers will someday agree on a standard layout for 
hybrid tuners...

Regards,
Lars.
diff --git a/dvbdevice.c b/dvbdevice.c
index a97f274..459bf9a 100644
--- a/dvbdevice.c
+++ b/dvbdevice.c
@@ -781,7 +781,7 @@ const char *DeliverySystems[] = {
 cDvbDevice::cDvbDevice(int Adapter, int Frontend)
 {
   adapter = Adapter;
-  frontend = Frontend;
+  demux = dvr = frontend = Frontend;
   ciAdapter = NULL;
   dvbTuner = NULL;
   frontendType = SYS_UNDEFINED;
@@ -804,6 +804,26 @@ cDvbDevice::cDvbDevice(int Adapter, int Frontend)
   // We only check the devices that must be present - the others will be 
checked before accessing them://XXX
 
   if (fd_frontend >= 0) {
+ // workaround vor Cine-C/T-cards which creates multiple mutually 
exclusive frontends with only one demux/dvr
+ while ((demux >= 0) && !Exists(DEV_DVB_DEMUX, adapter, demux))
+   demux--;
+ if (demux < 0) {
+demux = frontend;
+esyslog("frontend %d/%d has no demux device", adapter, frontend);
+}
+ else if (demux != frontend)
+isyslog("frontend %d/%d will use demux%d", adapter, frontend, demux);
+
+ while ((dvr >= 0) && !Exists(DEV_DVB_DVR, adapter, dvr))
+   dvr--;
+ if (dvr < 0) {
+dvr = frontend;
+esyslog("frontend %d/%d has no dvr device", adapter, frontend);
+}
+ else if (dvr != frontend)
+isyslog("frontend %d/%d will use dvr%d", adapter, frontend, dvr);
+ // end workaround
+
  if (ioctl(fd_frontend, FE_GET_INFO, &frontendInfo) >= 0) {
 switch (frontendInfo.type) {
   case FE_QPSK: frontendType = (frontendInfo.caps & 
FE_CAN_2G_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
@@ -869,7 +889,12 @@ int cDvbDevice::DvbOpen(const char *Name, int Adapter, int 
Frontend, int Mode, b
 
 bool cDvbDevice::Exists(int Adapter, int Frontend)
 {
-  cString FileName = DvbName(DEV_DVB_FRONTEND, Adapter, Frontend);
+  return Exists(DEV_DVB_FRONTEND, Adapter, Frontend);
+}
+
+bool cDvbDevice::Exists(const char *Name, int Adapter, int Frontend)
+{
+  cString FileName = DvbName(Name, Adapter, Frontend);
   if (access(FileName, F_OK) == 0) {
  int f = open(FileName, O_RDONLY);
  if (f >= 0) {
@@ -952,7 +977,7 @@ bool cDvbDevice::SetPid(cPidHandle *Handle, int Type, bool 
On)
  memset(&pesFilterParams, 0, sizeof(pesFilterParams));
  if (On) {
 if (Handle->handle < 0) {
-   Handle->handle = DvbOpen(DEV_DVB_DEMUX, adapter, frontend, O_RDWR | 
O_NONBLOCK, true);
+   Handle->handle = DvbOpen(DEV_DVB_DEMUX, adapter, demux, O_RDWR | 
O_NONBLOCK, true);
if (Handle->handle < 0) {
   LOG_ERROR;
   return false;
@@ -987,7 +1012,7 @@ bool cDvbDevice::SetPid(cPidHandle *Handle, int Type, bool 
On)
 
 int cDvbDevice::OpenFilter(u_short Pid, u_char Tid, u_char Mask)
 {
-  cString FileName = DvbName(DEV_DVB_DEMUX, adapter, frontend);
+  cString FileName = DvbName(DEV_DVB_DEMUX, adapter, demux);
   int f = open(FileName, O_RDWR | O_NONBLOCK);
   if (f >= 0) {
  dmx_sct_filter_params sctFilterParams;
@@ -1131,7 +1156,7 @@ void cDvbDevice::SetTransferModeForDolbyDigital(int Mode)
 bool cDvbDevice::OpenDvr(void)
 {
   CloseDvr();
-  fd_dvr = DvbOpen(DEV_DVB_DVR, adapter, frontend, O_RDONLY | O_NONBLOCK, 
true);
+  fd_dvr = DvbOpen(DEV_DVB_DVR, adapter, dvr, O_RDONLY | O_NONBLOCK, true);
   if (fd_dvr >= 0)
  tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(2), CardIndex() + 1);
   return fd_dvr >= 0;
diff --git a/dvbdevice.h b/dvbdevice.h
index e1842b7..1eb8cf2 100644
--- a/dvbdevice.h
+++ b/dvbdevice.h
@@ -106,6 +106,7 @@ protected:
   static cString DvbName(const char *Name, int Adapter, int Frontend);
   static int DvbOpen(const char *Name, int Adapter, int Frontend, int Mode, 
bool ReportError = false);
 private:
+  static bool Exists(const char *Name, int Adapter, int Frontend);
   static bool Exists(int Adapter, int Frontend);
  ///< Checks whether the given adapter/frontend exists.
   static bool Probe(int Adapter, int Frontend);
@@ -116,7 +117,7 @@ public:
  ///< Must be called before accessing any DVB functions.
  ///< \return True if any devices are available.
 protected:
-  int adapter, frontend;
+  int adapter, frontend, demux, dvr;
 private:
   dvb_frontend_info frontendInfo;
   int numProvidedSystems;
_

Re: [vdr] femon request; historic data

[L. Hanisch]

Am 11.11.2011 08:05, schrieb Füley István:

2011.11.11. 3:14 keltezéssel, Torgeir Veimo írta:

Am wondering if it would be hard to enhance the femon plugin to show a
graph of signal quality and correction statistics?

Basically, a histogram with STR, SNR, BER and UNC, so that one doesn't
have to oogle the screen constantly to see how signal quality changes.

Even better if it was possible to trigger such monitoring without the
femon display showing.



I think this would be possible with a small script getting the current femon 
status via svdrp (plug femon sgnl/snra) and
put this data into an rrd database, from where you can easily generate nice 
looking graphs. You should run the script at
let's say every 5 minutes or so using crontab.

I'm doing the same for logging my system health status.
http://fuley.ro/cgi-bin/sensord.cgi


 Just a little "advertising" for my dbus2vdr plugin:
 https://github.com/flensrocker/vdr-plugin-dbus2vdr

 With this, you can get data from plugins with dbus calls which wouldn't block the svdrp service and are executed in 
its own thread.


 dbus-send --system --type=method_call --dest=de.tvdr.vdr \
--print-reply /Plugins/ \
de.tvdr.vdr.plugin.SVDRPCommand string:'command' string:'parameter'

 From python is calling a dbus method a lot easier (I heard), but haven't tried 
it own my own.

 Don't forget to configure the system bus so the calling user is allowed to access it for the vdr-dbus-service, for an 
example please look at

 
https://github.com/flensrocker/vdr-plugin-dbus2vdr/blob/master/etc/de.tvdr.vdr.conf

Regards,
Lars.



István


___
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 and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

[L. Hanisch]

Am 15.11.2011 11:52, schrieb Steffen Barszus:

2011/11/15 Hawes, Mark:

What i got from previous discussions on linux-media is, that if the
device nodes are created within one adapter, an application needs to
assume that
the devices can not be used concurrently and needs to close
one "device node group" before opening the other one.


This suggests a constraint in the current design of the way VDR handles
the detection and use of DVB devices in that it cannot handle so called
'hybrid' cards where two (or more!) frontends are attached via a single
adaptor without restarting VDR and identifying which frontend to use.

As already mentioned I wish to use both cards on my system and I'd be
interested and happy to help in developing a patch to overcome this
constraint. However I would need some VDR architectural guidance to
suggest how this might be done with minimal disruption to the current
DVB device handling. Any direction would be much appreciated.


What i said above is AFAIK more or less undocumented up to now. But it
seems to be a consensus between most driver developers now.

Yes vdr needs to change to handle this devices properly based on the
previous assumptions, i think soneone else can be more helpful than me
;).


 I'm just preparing a test environment for extending the vdr to use multi-frontend devices. Good to know that there are 
drivers which behaves different in creating device nodes. The Cine-C/T cards for example creates only one demux/dvr node 
and two frontends. Soon I will have my hands on such a device. If I can get a patch working for this card it's only a 
small step to support the HVR 4000, two.


 I have already dealt with vdr devices and have some knowledge about the concepts. I developed the dynamite plugin 
which extends vdr with some device hotplugging capabilities. It also requires patching the vdr. But with this you can 
use both devices without restarting vdr and affecting timers and recordings. But for now there's no automatism so that 
the right device for the watched/recorded channel is attached. Please have a look at the README if you're interested. If 
you have questions, just ask.


 http://projects.vdr-developer.org/projects/plg-dynamite
 https://github.com/flensrocker/vdr-plugin-dynamite

 If you want to develop something on your own, start reading device.[hc] and 
dvbdevice.[hc] at the vdr source.
 I definitly will try to develop a "multi-frontend-patch" but spare time is always rare. I will reserve one evening per 
week for this. And I hope to finish it till christmas. ;-)


 If you have ideas please let me know. I'm looking for some inspiration for storing the different frontend capabilities 
at the cDvbDevice and how to maintain the different cDvbTuner objects. My experience while working on dynamite will help 
me in particular since I invested some time on closing/reopening the file handles at the right places. Hotplugging 
"single frontend" devices seems to be a good first step towards the solution of this problem.


Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

[L. Hanisch]

Am 15.11.2011 23:29, schrieb Hawes, Mark:


  http://projects.vdr-developer.org/projects/plg-dynamite
  https://github.com/flensrocker/vdr-plugin-dynamite


I had a look at the readme. The approach of making all devices hot
pluggable is an interesting one and provides for a flexible solution.
How important it is to get plugins to adapt to the approach is still
unclear to me. Presumably if they are in the plugin list prior to the
dynamite plugin they will be 'immune' as they will declare their own
devices to the pool first.


 This is right. But just like the cDvbDeviceProbe there's a cDynamicDeviceProbe class which plugins can use to add 
hotplugging features to their devices. pvrinput is an example for this.



While the approach has its merits I believe that it is probably overkill
in this case. I believe that VDR should be able to cater for hybrid
cards natively alongside existing cards with more conventional adapter
layouts and any patch should ultimately have that as its goal.


 What I tried to communicate is, that I have some work done which is part of the problem: closing the handles and the 
right places. I will try to reuse some of the code to extend the cDvbDevice for multiple frontends.

 Difficult to explain, please let me do some code first. ;-)

 I will post it on the list when I have something to show.


As I see it there are two possible approaches: try to bolt on support
for hybrid cards as exception cases to the current code, or redesign the
handling of the devices from the ground up to also cater for the more
exotic adapter layouts. There could be a third 'hybrid' solution which
sits somewhere between the two.


 I think there are cards which have a digital and an analog tuner. But they are only interesting if they support 
hardware encoding of the analog material like the Hauppauge PVRx50 cards. I don't think it would be needed to support 
such cards (iow the analog part of those cards). But one should keep this at the back of one's head.



The comment above from Steffen seems to make some sense ' if the device
nodes are created within one adapter an application needs to assume that
the devices cannot be used concurrently and needs to close one "device
node group" before opening the other one'. As I understand it this would
mean that VDR should register all front ends on initialisation and then
only try to open them when required. If another frontend is found to be
open on the same device hierarchy a decision is then made to see if it
can be closed, e.g. no recordings on it etc. If it can't then the
attempt to switch channel fails with 'Channel not available". I may be
simplifying things a bite here but that is as I see it. Happy to be
corrected.


 Yes, that's the way I want to try to go.

Lars.



Mark.

___
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



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

[L. Hanisch]

Am 16.11.2011 00:08, schrieb Klaus Schmidinger:

That is also my understanding of multi frontend devices.
If an "adapter" has several "frontends" only one of them can
be active at any given time. This has nothing to do with
any "explosives" (excuse the pun ;-) and will be implemented
in the core VDR code as time permits. Right now I'm cleaning up
the "lnb sharing" (aka "device bonding") stuff and will hopefully
find more time for VDR development by the end of the year (and
thereafter).


 If you don't mind I would try to prefabricate something.
 On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be 
better than having multiple cDvbDevices which must interact somehow with each other.


 And I excuse the pun... ;-)

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

[L. Hanisch]

Am 16.11.2011 23:26, schrieb Klaus Schmidinger:

On 16.11.2011 19:16, L. Hanisch wrote:

Am 16.11.2011 00:08, schrieb Klaus Schmidinger:

That is also my understanding of multi frontend devices.
If an "adapter" has several "frontends" only one of them can
be active at any given time. This has nothing to do with
any "explosives" (excuse the pun ;-) and will be implemented
in the core VDR code as time permits. Right now I'm cleaning up
the "lnb sharing" (aka "device bonding") stuff and will hopefully
find more time for VDR development by the end of the year (and
thereafter).


If you don't mind I would try to prefabricate something.
On a first guess: would you combine the multiple frontends of an adapter in one 
cDvbDevice? I think this would be
better than having multiple cDvbDevices which must interact somehow with each 
other.


Sure there will be one cDvbDevice per adapter for a multi-frontend device
where only one frontend can be active at any time.
If (like on the TT-S2 6400) there are several frontends that can be
active simultaneously, then there shall be separate adapters for each
frontend, and thus a separate cDvbDevice for each adapter.


 Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and 
sym-linked the devices within one adapter. I have no ca-devices in this setup.

 Switching between C and T channels works here, but it's not really tested with 
timers/recordings etc.

 I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think 
about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now.



Note, though, that support for such devices will most likely not
go into VDR for version 2. I'm trying to wrap things up in order
to make a stable version 2, and after that will address new things
like this.


 I'm fine with this and looking forward to it. A new stable release would be 
fine! Xmas is next door... :)

Lars.
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c 
b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
index ff3f953..e7fb935 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
@@ -26,7 +26,8 @@
 int cDvbHdFfDevice::devHdffOffset = -1;
 
 cDvbHdFfDevice::cDvbHdFfDevice(int Adapter, int Frontend)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
 {
   spuDecoder = NULL;
   audioChannel = 0;
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h 
b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
index 4dcfb6a..62540da 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
@@ -17,12 +17,13 @@
 
 class cDvbHdFfDevice : public cDvbDevice {
 private:
+  int frontend;
   int fd_osd, fd_audio, fd_video;
 protected:
   virtual void MakePrimaryDevice(bool On);
 public:
   static bool Probe(int Adapter, int Frontend);
-  cDvbHdFfDevice(int Adapter, int Frontend);
+  cDvbHdFfDevice(int Adapter, int Frontend = 0);
   virtual ~cDvbHdFfDevice();
   virtual bool HasDecoder(void) const;
 
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c 
b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
index 17f842b..68031b5 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
@@ -24,7 +24,8 @@
 int cDvbSdFfDevice::devVideoOffset = -1;
 
 cDvbSdFfDevice::cDvbSdFfDevice(int Adapter, int Frontend, bool OutputOnly)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
 {
   spuDecoder = NULL;
   digitalAudio = false;
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h 
b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
index bd74cde..c060859 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
@@ -16,6 +16,7 @@
 
 class cDvbSdFfDevice : public cDvbDevice {
 private:
+  int frontend;
   int fd_osd, fd_audio, fd_video, fd_stc;
   bool outputOnly;
 protected:
diff --git a/dvbci.c b/dvbci.c
index 5289bbd..66dddc8 100644
--- a/dvbci.c
+++ b/dvbci.c
@@ -10,15 +10,18 @@
 #include "dvbci.h"
 #include 
 #include 
-#include "device.h"
+#include "dvbdevice.h"
 
 // --- cDvbCiAdapter -
 
-cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
+cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd, int Adapter, int Ca)
 {
   device = Device;
   SetDescription("CI adapter on device %d", device->DeviceNumber());
   fd = Fd;
+  adapter = Adapter;
+  ca = Ca;
+  OpenCa();
   ca_caps_t Caps;
   if (ioctl(fd, CA_GET_CAP, &Caps) == 0) {
  if ((Caps.slot_type & CA_CI_LINK) != 0) {
@@ -41,10 +44,29 @@ cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
 cDvbCiAdapter::~cDvbCiAdapter()
 {
   Cancel(3);
+  CloseCa();
+}
+
+bool cDvbCiAdapter::OpenCa(void)
+

Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

[L. Hanisch]

Hi,

Am 17.11.2011 11:02, schrieb Hawes, Mark:

Hi Lars,

Thanks for the patch.
Basically, it seems to work for the HVR 4000. Both front ends are
detected successfully, and both can be used. I'm using it with the
xineliboutput plugin and it seems to co-exist OK.


 Nice to hear.


Starting a recording on one prevents a channel switch to the other with
the "Channel not available message". However, when doing so the screen
goes black and its necessary to retune the recorded channel to get the
picture back. Not a big issue, more an annoyance.


 Ok, I will try to reproduce this. It may be (since the device hasn't changed) vdr is thinking that it's showing an 
available channel or something like this.



I'll be playing with it in the next couple of days including introducing
a SD premium card into the mix to see what happens. Is there anything in
particular that you would like me to try?


 I haven't made too much thoughts about tests. Maybe we can work on a checklist 
together.

 use cases:
- live viewing with switching channels between frontends
- timer recording starts while viewing live tv on the other frontend
- timer conflicts with different priorities on the different frontends
- streamdev-client/-server?
- ...?

 It looks like the HVR 4000 has no CI. At the moment I don't have access to 
cards with decryption hardware, too.
 And I'm not too familiar with this part of the vdr (ci/cam etc.).

Lars.



Thanks,

Mark.
-Original Message-
From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf
Of L. Hanisch
Sent: Thursday, 17 November 2011 9:59 AM
To: vdr@linuxtv.org
Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers
broken - adapter0/frontend1 busy" in linux-media list )

Am 16.11.2011 23:26, schrieb Klaus Schmidinger:

On 16.11.2011 19:16, L. Hanisch wrote:

Am 16.11.2011 00:08, schrieb Klaus Schmidinger:

That is also my understanding of multi frontend devices.
If an "adapter" has several "frontends" only one of them can be
active at any given time. This has nothing to do with any
"explosives" (excuse the pun ;-) and will be implemented in the core



VDR code as time permits. Right now I'm cleaning up the "lnb
sharing" (aka "device bonding") stuff and will hopefully find more
time for VDR development by the end of the year (and thereafter).


If you don't mind I would try to prefabricate something.
On a first guess: would you combine the multiple frontends of an
adapter in one cDvbDevice? I think this would be better than having

multiple cDvbDevices which must interact somehow with each other.


Sure there will be one cDvbDevice per adapter for a multi-frontend
device where only one frontend can be active at any time.
If (like on the TT-S2 6400) there are several frontends that can be
active simultaneously, then there shall be separate adapters for each
frontend, and thus a separate cDvbDevice for each adapter.


   Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived
yet I tested with a DVB-T and DVB-C stick and sym-linked the devices
within one adapter. I have no ca-devices in this setup.
   Switching between C and T channels works here, but it's not really
tested with timers/recordings etc.

   I don't have a FF card, so the patches for the plugins are more of
"remove compiler warnings" only. One have to think about cDvbDeviceProbe
and the parameters. A frontend argument doesn't make much sense now.


Note, though, that support for such devices will most likely not go
into VDR for version 2. I'm trying to wrap things up in order to make
a stable version 2, and after that will address new things like this.


   I'm fine with this and looking forward to it. A new stable release
would be fine! Xmas is next door... :)

Lars.


___
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 and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

[L. Hanisch]

Am 18.11.2011 19:03, schrieb Klaus Schmidinger:

On 16.11.2011 23:59, L. Hanisch wrote:

Am 16.11.2011 23:26, schrieb Klaus Schmidinger:

On 16.11.2011 19:16, L. Hanisch wrote:

Am 16.11.2011 00:08, schrieb Klaus Schmidinger:

That is also my understanding of multi frontend devices.
If an "adapter" has several "frontends" only one of them can
be active at any given time. This has nothing to do with
any "explosives" (excuse the pun ;-) and will be implemented
in the core VDR code as time permits. Right now I'm cleaning up
the "lnb sharing" (aka "device bonding") stuff and will hopefully
find more time for VDR development by the end of the year (and
thereafter).


If you don't mind I would try to prefabricate something.
On a first guess: would you combine the multiple frontends of an adapter in one 
cDvbDevice? I think this would be
better than having multiple cDvbDevices which must interact somehow with each 
other.


Sure there will be one cDvbDevice per adapter for a multi-frontend device
where only one frontend can be active at any time.
If (like on the TT-S2 6400) there are several frontends that can be
active simultaneously, then there shall be separate adapters for each
frontend, and thus a separate cDvbDevice for each adapter.


Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I 
tested with a DVB-T and DVB-C stick and
sym-linked the devices within one adapter. I have no ca-devices in this setup.
Switching between C and T channels works here, but it's not really tested with 
timers/recordings etc.

I don't have a FF card, so the patches for the plugins are more of "remove compiler 
warnings" only. One have to think
about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much 
sense now.


Note, though, that support for such devices will most likely not
go into VDR for version 2. I'm trying to wrap things up in order
to make a stable version 2, and after that will address new things
like this.


I'm fine with this and looking forward to it. A new stable release would be 
fine! Xmas is next door... :)


I've received an email from Manu Abraham, informing
me that he intends to change the driver in such a way that there will always
be only *one* frontend, even if it can handle multiple delivery systems.
So every frontend an adapter will provide will always be useable independent
of all other frontends of that adapter.
Personally, I like this method more than having separate frontends for
each delivery system, and having to manage access between them.

Just wanted to let you know that the official implementation in VDR
(most likely after version 2.0) will go a different way than your patch.


 I followed the discussion on linux-media. But since it's a new ioctl some kind of backport would be needed and also a 
workaround for drivers which doesn't provide the new ioctl.
 One frontend per adapter would be very nice. And in case of dual tuner cards I would expect two adapters since they 
are independent from each other. If they are combined in one adapter they cannot be distinguished from "old" adapters 
with mutually exclusive frontends - and things would be dirtier as is. :)


 In the meantime I will polish my patch a bit and rework on the changes which breaks existing plugins. It was just a 
first try anyway.


Lars.



Klaus

___
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

[vdr] [PATCH v2] multi-frontend-support for vdr 1.7.21

[L. Hanisch]

Hi,

 Here's version 2 of my multi-frontend-patch. It's still "dirty", since it changes the constructor of cDvbDevice which 
will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they 
might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm 
using. Maybe there have to be some virtual functions like "BeforeFrontendSwitch" and "AfterFrontendSwitch" so the 
plugins are even able to know about it.


 Assumption for this patch:
 All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are 
cards with multiple frontends which can be used simultaneously I'd like to hear about it.


 Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my 
patch can easily be converted to use that.

 I'm still working on this patch, it's not finished yet... :-)

 Have fun,

Lars.
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
index ff3f953..e7fb935 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.c
@@ -26,7 +26,8 @@
 int cDvbHdFfDevice::devHdffOffset = -1;
 
 cDvbHdFfDevice::cDvbHdFfDevice(int Adapter, int Frontend)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
 {
   spuDecoder = NULL;
   audioChannel = 0;
diff --git a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
index 4dcfb6a..62540da 100644
--- a/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
+++ b/PLUGINS/src/dvbhddevice/dvbhdffdevice.h
@@ -17,12 +17,13 @@
 
 class cDvbHdFfDevice : public cDvbDevice {
 private:
+  int frontend;
   int fd_osd, fd_audio, fd_video;
 protected:
   virtual void MakePrimaryDevice(bool On);
 public:
   static bool Probe(int Adapter, int Frontend);
-  cDvbHdFfDevice(int Adapter, int Frontend);
+  cDvbHdFfDevice(int Adapter, int Frontend = 0);
   virtual ~cDvbHdFfDevice();
   virtual bool HasDecoder(void) const;
 
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
index 17f842b..68031b5 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.c
@@ -24,7 +24,8 @@
 int cDvbSdFfDevice::devVideoOffset = -1;
 
 cDvbSdFfDevice::cDvbSdFfDevice(int Adapter, int Frontend, bool OutputOnly)
-:cDvbDevice(Adapter, Frontend)
+:cDvbDevice(Adapter)
+,frontend(Frontend)
 {
   spuDecoder = NULL;
   digitalAudio = false;
diff --git a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
index bd74cde..c060859 100644
--- a/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
+++ b/PLUGINS/src/dvbsddevice/dvbsdffdevice.h
@@ -16,6 +16,7 @@
 
 class cDvbSdFfDevice : public cDvbDevice {
 private:
+  int frontend;
   int fd_osd, fd_audio, fd_video, fd_stc;
   bool outputOnly;
 protected:
diff --git a/dvbci.c b/dvbci.c
index 5289bbd..5db673e 100644
--- a/dvbci.c
+++ b/dvbci.c
@@ -10,15 +10,32 @@
 #include "dvbci.h"
 #include 
 #include 
-#include "device.h"
+#include "dvbdevice.h"
 
 // --- cDvbCiAdapter -
 
-cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
+cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd, int Adapter, int Ca)
 {
   device = Device;
   SetDescription("CI adapter on device %d", device->DeviceNumber());
   fd = Fd;
+  adapter = Adapter;
+  ca = Ca;
+  gotCaps = false;
+  GetCaps();
+}
+
+cDvbCiAdapter::~cDvbCiAdapter()
+{
+  Cancel(3);
+  CloseCa();
+}
+
+void cDvbCiAdapter::GetCaps(void)
+{
+  if (gotCaps || (fd < 0))
+ return;
+  gotCaps = true;
   ca_caps_t Caps;
   if (ioctl(fd, CA_GET_CAP, &Caps) == 0) {
  if ((Caps.slot_type & CA_CI_LINK) != 0) {
@@ -38,13 +55,31 @@ cDvbCiAdapter::cDvbCiAdapter(cDevice *Device, int Fd)
  esyslog("ERROR: can't get CA capabilities on device %d", device->DeviceNumber());
 }
 
-cDvbCiAdapter::~cDvbCiAdapter()
+bool cDvbCiAdapter::OpenCa(void)
 {
-  Cancel(3);
+  if (fd >= 0)
+ return true;
+  fd = cDvbDevice::DvbOpen(DEV_DVB_CA, adapter, ca, O_RDWR);
+  if (fd < 0) {
+ esyslog("ERROR: can't open ca %d/%d", adapter, ca);
+ return false;
+ }
+  GetCaps();
+  return true;
+}
+
+void cDvbCiAdapter::CloseCa(void)
+{
+  if (fd < 0)
+ return;
+  close(fd);
+  fd = -1;
 }
 
 int cDvbCiAdapter::Read(uint8_t *Buffer, int MaxLength)
 {
+  if (fd < 0)
+ return 0;
   if (Buffer && MaxLength > 0) {
  struct pollfd pfd[1];
  pfd[0].fd = fd;
@@ -61,6 +96,8 @@ int cDvbCiAdapter::Read(uint8_t *Buffer, int MaxLength)
 
 void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
 {
+  if (fd < 0)
+ return;
   if (Buffer && Length > 0) {
  if (safe_write(fd, Buffer, Length) != Length)
 esyslog("ERROR: can't write to CI adapter on device %d: %m", device->DeviceNumber());
@@ -69,6 +106,8 @@ void cDvbCiAdapter::Write(const uint8_t *Buffer, int Length)
 
 bool cDvbCiAdapter::Reset(i

Re: [vdr] Hauppauge PVR-HD and IPTV plugin

[L. Hanisch]

Hi,

Am 08.02.2010 16:53, schrieb Rob Davis:

Hi, I have a Hauppauge PVR-HD which works but creating an h264 ts stream
from a set HD component inputs and does quite a nice job of it.
The ts stream is available on /dev/video0 and a simple cat /dev/video0
 >file.ts will create a watchable high quality dump..


 Is it a cx18-based card? There a plans to integrate support for the 
native TS-capability of those cards in the pvrinput-plugin, but it will 
take some time. If you mind you can send me off-list a sample video (up 
to 4MB with the cat-method). I'm just working on repacking the program 
stream of ivtv-based cards with valid PAT, PMT and PCR, a pass through 
of a valid TS shouldn't be that hard. But I don't promise anything since 
I haven't such a card. Particulary if its controls are too different 
from the ivtv-ones.


regards,
Lars.



I have got this working with freevo (after a little hacking) but would
prefer to get the input into vdr as I can then watch it around the house
through streaming.

Using vdr-iptv I can get some of the way, but not all of it.. Playing
around with different options I get either jerky video or ffmpeg just
stops transcoding after a few seconds, and I'm not sure why...

I can put a 2 minute ts stream somewhere if it would help but I think it
will decode a file before decoding from /dev/video0

Hauppuage-test;IPTV:1000:IPTV|S0P0|EXT|hauppauge.sh|951:P:0:256:257:0:0:1000:1:1:0




more /tmp/iptvstream

Script started 951 4321
Getting new URL
/dev/video0
Change Channel to 951 on Cable Box
starting with node: 1
node 1: vendor_id = 0x24a0 model_id = 0xea05
AV/C Command: 951 = Op1=0x00487C29 Op2=0x00487C25 Op3=0x00487C21
Streamsvideo.sh PID is 14632
Streamdev Plugin 951 /dev/video0
pid of ffmpeg.streamdev 14639
14632
FFmpeg version SVN-r21686, Copyright (c) 2000-2010 Fabrice Bellard, et
al.
built on Feb 7 2010 22:27:31 with gcc 4.3.3
configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib
--mandir=/usr/share/man --enable-static --enable-shared
--cc=i686-pc-linux-gnu-gcc --d
isable-debug --disable-ffplay --enable-libx264 --enable-libxvid
--disable-indev=oss --disable-indev=jack --disable-outdev=oss
--enable-x11grab --enable-pth
reads --disable-altivec --cpu=athlon-fx --enable-gpl --enable-version3
--enable-postproc --enable-avfilter --enable-avfilter-lavf
--disable-stripping --ena
ble-hardcoded-tables --disable-doc
libavutil 50. 9. 0 / 50. 9. 0
libavcodec 52.52. 0 / 52.52. 0
libavformat 52.51. 0 / 52.51. 0
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 1.17. 0 / 1.17. 0
libswscale 0.10. 0 / 0.10. 0
libpostproc 51. 2. 0 / 51. 2. 0
[mpegts @ 0x807a3a0]max_analyze_duration reached
[mpegts @ 0x807a3a0]Estimating duration from bitrate, this may be
inaccurate

Seems stream 0 codec frame rate differs from container frame rate:
119.88 (12/1001) -> 59.94 (6/1001)
Input #0, mpegts, from '/dev/video0':
Duration: N/A, start: 0.387044, bitrate: 169 kb/s
Program 1
Stream #0.0[0x1011]: Video: h264, yuv420p, 1280x720 [PAR 1:1 DAR
16:9], 59.92 fps, 59.94 tbr, 90k tbn, 119.88 tbc
Stream #0.1[0x1100]: Audio: aac, 48000 Hz, 2 channels, s16, 169 kb/s
[mpegts @ 0x85f2a80]calculated bitrate 2293687 bps, muxrate 2293687
bps, sdt every 762, pat/pmt every 152 pkts
Output #0, mpegts, to 'udp://127.0.0.1:4321?pkt_size=32712':
Stream #0.0, 1/9: Video: mpeg2video, yuv420p, 1280x720 [PAR 1:1
DAR 16:9], 1/25, q=2-31, 2000 kb/s, 90k tbn, 25 tbc
Stream #0.1, 1/9: Audio: mp2, 48000 Hz, 2 channels, s16, 192 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
Press [q] to stop encoding
[h264 @ 0x808eb00]no picture
[mpegts @ 0x85f2a80]dts < pcr, TS is invalidme=1.25
bitrate=3297.2kbits/s dup=0 drop=42 frame= 146 fps= 29 q=12.2 size=
1843kB time=5.76 bitrate=2645.8kbits/s dup=0 drop=178 frame= 178 fps=
29 q=11.7 size= 2178kB time=7.03 bitrate=2537.3kbits/s dup=0 drop=244


Then it just freezes...

Any ideas?



___
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] Hauppauge PVR-HD and IPTV plugin

[L. Hanisch]

Hi Rob,

Am 08.02.2010 21:28, schrieb Rob Davis:

On 08/02/10 12:58, L. Hanisch wrote:

Hi,

Am 08.02.2010 16:53, schrieb Rob Davis:

Hi, I have a Hauppauge PVR-HD which works but creating an h264 ts stream
from a set HD component inputs and does quite a nice job of it.
The ts stream is available on /dev/video0 and a simple cat /dev/video0
  >file.ts will create a watchable high quality dump..


  Is it a cx18-based card? There a plans to integrate support for the
native TS-capability of those cards in the pvrinput-plugin, but it will
take some time. If you mind you can send me off-list a sample video (up
to 4MB with the cat-method). I'm just working on repacking the program
stream of ivtv-based cards with valid PAT, PMT and PCR, a pass through
of a valid TS shouldn't be that hard. But I don't promise anything since
I haven't such a card. Particulary if its controls are too different
from the ivtv-ones.

regards,
Lars.



I spoke to Marin a little about this.. In terms of controls.. There are
none that need worrying about... It doesn't have a tuner.  It would be
useful to have a way to control an external channel changer (which
Martin nicely put in for my other pvr-500 card (for SD channels off the
cable box)..


 I see, I helped him with getting it into the plugin.


The linux module is pvrhd.  Once loaded, along comes a /dev/video0
device.  A cat or mplayer command on this work well.


 I did some google search on the PVR-HD and found the module name 
"hdpvr" in the mythtv-wiki and in my ubuntu modules directory.
 What says "cat /sys/class/video4linux/video0/name" and "cat 
/sys/class/video4linux/video0/uevent"?



The ts stream is dependant on what is fed to it.  Ie, if your source is
1080i, then you'll get a 1080i stream, if 720p then that's what you get..


 Ok, "no controls" is a good thing, if the plugin only has to read from 
the device and hand the packets over to vdr, we can give it a try.



There was a quick sample on the internet, but I can also manually record
something for you if you want it.. Just not sure where to leave it..


 I would like to see some small piece of video (about 4MB) to inspect 
the TS structure (till now I've only dealt with MPEG2-PS/TS), my inbox 
has no problem with an attachment of such size. Just cat some seconds to 
a file and send it to me (perhaps you have to truncate it with dd if 
it's growing to fast but make sure I get the beginning of the file ;-)). 
At the next weekend I can try to integrate support for it.
 In particular I'm interested if the PAT and PMT is present or if I 
have to build them with the cPatPmtGenerator of vdr 1.7.1 and up. Will 
it be a problem for you to upgrade to 1.7.x (x >= 1)?


regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Hauppauge PVR-HD and pvrinput plugin (was: Re: Hauppauge PVR-HD and IPTV plugin)

[L. Hanisch]

Hi Rob,

Am 08.02.2010 21:28, schrieb Rob Davis:

There was a quick sample on the internet, but I can also manually record
something for you if you want it.. Just not sure where to leave it..


 I received your sample and it looks like a valid TS with PAT, PMT and 
PCR, so the plugin has nothing else to do as to pass it through to the 
vdr (hopefully).
 As pvrinput is setting a lot of controls for the cx23415/16 based 
cards, I'm not sure, which is the best way. Either integrate it in 
pvrinput (and leave the controls as is if a hdpvr is accessed) or make a 
new "hdpvrinput"-plugin. In the next days I will study the source as I'm 
new to the pvrinput-plugin but I'm confident I can make it work.


 Please provide the output of

v4l2-ctl --info --list-ctrls-menus --device=/dev/video0

 after a fresh load of the module. That should give me the needed 
parameters/values to distinguish the cards inside the plugin.

 The next weekend is dedicated to you. ;-)

regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] H264 syncearly patch

[L. Hanisch]

Hi,

Am 15.02.2010 00:20, schrieb Reinhard Nissl:

Hi,

Am 14.02.2010 23:49, schrieb Rob Davis:

I am in the process of moving from 1.6.0 to 1.7.12 to test the pvrinput
plug with a Hauppauge-PVR-HD.
With 1.6.0 and the h264-syncearly patch I got  a nice picture but no
audio..

With 1.7.12 I can get audio but no picture.  I thought h264 support was
built in already to 1.7.12, but I maybe wrong.  If not, where can I find
an up to date patch for this?

The old 1.7.0-h264-syncearly patch doesn't seem to work cleanly..


In 1.6.x, cVideoRepacker was responsible to detect H.264 vs.
MPEG2 (cannot tell why audio doesn't work in your case).

In 1.7.x, cChannel provides this information (vtype). So it looks
like pvrinput doesn't provide the information or channels in a
way that vtype gets set to H.264.


 Since I'm the one who is working on supporting the HD PVR with pvrinput:
 Could you point me to some documentation, what kind of information the plugin 
has to provide?
 Simultaneously I'll try to search on my own, but if somebody knows it already, 
it'll be quicker...

regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] H264 syncearly patch

[L. Hanisch]

Am 15.02.2010 07:58, schrieb L. Hanisch:

Hi,

Am 15.02.2010 00:20, schrieb Reinhard Nissl:

Hi,

Am 14.02.2010 23:49, schrieb Rob Davis:

I am in the process of moving from 1.6.0 to 1.7.12 to test the pvrinput
plug with a Hauppauge-PVR-HD.
With 1.6.0 and the h264-syncearly patch I got a nice picture but no
audio..

With 1.7.12 I can get audio but no picture. I thought h264 support was
built in already to 1.7.12, but I maybe wrong. If not, where can I find
an up to date patch for this?

The old 1.7.0-h264-syncearly patch doesn't seem to work cleanly..


In 1.6.x, cVideoRepacker was responsible to detect H.264 vs.
MPEG2 (cannot tell why audio doesn't work in your case).

In 1.7.x, cChannel provides this information (vtype). So it looks
like pvrinput doesn't provide the information or channels in a
way that vtype gets set to H.264.


Since I'm the one who is working on supporting the HD PVR with pvrinput:
Could you point me to some documentation, what kind of information the
plugin has to provide?
Simultaneously I'll try to search on my own, but if somebody knows it
already, it'll be quicker...


 These are the PAT and PMT packets of the HD PVR:

first packet:
47 40 00 10 00 00 B0 11 00 00 C1 00 00 00 00 E0
1F 00 01 E1 00 23 5A AB 82 FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF

second packet:
47 41 00 10 00 02 B0 2D 00 01 C1 00 00 F0 01 F0
0C 05 04 48 44 4D 56 88 04 0F FF 04 05 1B F0 11
F0 0A 05 08 48 44 4D 56 FF 1B 44 3F 0F F1 00 F0
00 61 39 12 E1 FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF

sixth packet:
47 41 00 11 00 02 B0 2D 00 01 C1 00 00 F0 01 F0
0C 05 04 48 44 4D 56 88 04 0F FF 04 05 1B F0 11
1. stream type ^
F0 0A 05 08 48 44 4D 56 FF 1B 44 3F 0F F1 00 F0
 2. stream type ^
00 61 39 12 E1 FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF

 If I'm right, there are two streams in the PMT:

 stream type 0x1b with pid 0x1011
 stream type 0x0f with pid 0x1100

 So it's reporting h.264 video if I'm understanding cPatFilter::Process.

 A full sample of the ts can be downloaded from here:

 http://home.versanet.de/~lhanisch/pvrhd.ts

 It was recorded with "cat /dev/video0 > pvrhd.ts".

 So what's going wrong? Any hints would be appreciated.

regards,
Lars

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] H264 syncearly patch

[L. Hanisch]

Hi,

 Seems, that we've got it to work with this channel:

HD PVR:1:PVRINPUT|COMPONENT:P:0:4113+4097=27:0;4352:0:0:2919:1:0:0

 You'll need at least pvrinput-1.7.0-rc8, but it's not released yet...
 If there's someone else who would like to test it, mail me.

Lars.

Am 15.02.2010 08:39, schrieb L. Hanisch:

Am 15.02.2010 07:58, schrieb L. Hanisch:

Hi,

Am 15.02.2010 00:20, schrieb Reinhard Nissl:

Hi,

Am 14.02.2010 23:49, schrieb Rob Davis:

I am in the process of moving from 1.6.0 to 1.7.12 to test the pvrinput
plug with a Hauppauge-PVR-HD.
With 1.6.0 and the h264-syncearly patch I got a nice picture but no
audio..

With 1.7.12 I can get audio but no picture. I thought h264 support was
built in already to 1.7.12, but I maybe wrong. If not, where can I find
an up to date patch for this?

The old 1.7.0-h264-syncearly patch doesn't seem to work cleanly..


In 1.6.x, cVideoRepacker was responsible to detect H.264 vs.
MPEG2 (cannot tell why audio doesn't work in your case).

In 1.7.x, cChannel provides this information (vtype). So it looks
like pvrinput doesn't provide the information or channels in a
way that vtype gets set to H.264.


Since I'm the one who is working on supporting the HD PVR with pvrinput:
Could you point me to some documentation, what kind of information the
plugin has to provide?
Simultaneously I'll try to search on my own, but if somebody knows it
already, it'll be quicker...


These are the PAT and PMT packets of the HD PVR:

first packet:
47 40 00 10 00 00 B0 11 00 00 C1 00 00 00 00 E0
1F 00 01 E1 00 23 5A AB 82 FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF

second packet:
47 41 00 10 00 02 B0 2D 00 01 C1 00 00 F0 01 F0
0C 05 04 48 44 4D 56 88 04 0F FF 04 05 1B F0 11
F0 0A 05 08 48 44 4D 56 FF 1B 44 3F 0F F1 00 F0
00 61 39 12 E1 FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF

sixth packet:
47 41 00 11 00 02 B0 2D 00 01 C1 00 00 F0 01 F0
0C 05 04 48 44 4D 56 88 04 0F FF 04 05 1B F0 11
1. stream type ^
F0 0A 05 08 48 44 4D 56 FF 1B 44 3F 0F F1 00 F0
2. stream type ^
00 61 39 12 E1 FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF

If I'm right, there are two streams in the PMT:

stream type 0x1b with pid 0x1011
stream type 0x0f with pid 0x1100

So it's reporting h.264 video if I'm understanding cPatFilter::Process.

A full sample of the ts can be downloaded from here:

http://home.versanet.de/~lhanisch/pvrhd.ts

It was recorded with "cat /dev/video0 > pvrhd.ts".

So what's going wrong? Any hints would be appreciated.

regards,
Lars

___
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] analogtv plugin with HVR-1800

[L. Hanisch]

Am 18.02.2010 18:54, schrieb Timothy D. Lenz:

As anyone tried using the analogtv plugin with an HVR-1800 on
vdr-1.7.12? And does it interfere with the atsc plugin since both would
be using the same tuner? I've been told that analog mode does work with
this card with tvtime, so I was thinking of giving it a try. The card is
supposed to be able to tune both atsc and ntsc, plus it has video/audio
inputs.


 This is a hybrid tuner, right? Since the vdr and the analogtv doesn't coordinate their access on the device, I doubt 
it will work.
 Also it has build in a MPEG2 encoder, the right plugin would be pvrinput, but currently, the HVR-1800 is not 
supported. Recently I added support for the HD PVR, but I don't know how complicated it would be, to support the 
HVR-1800 as well. Especially because of the hybrid tuner. The two vdr devices "dvbdevice" and "pvrdevice" has to share 
the same hardware. There's no infrastructure for this at the moment...


Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13

[L. Hanisch]

Hi,

Am 28.02.2010 16:07, schrieb Klaus Schmidinger:

- Plugins can now define new sources. In order to implement this, the following
   changes were made:
   + The transponder parameter string is no longer interpreted by cChannel, but 
rather
 stored as is and used only by the respective device. That way plugins can 
use a
 channel's parameter string to store arbitrary data (see vdr.5).
   + The new class cSourceParam can be used by plugins to define new sources, 
and to
 implement OSD items that will be used in the channel editor for editing 
the source
 specific parameters of a channel (see dvbdevice.c for an example of how 
this is
 done for the default DVB devices).
   + Purely numerical values are no longer accepted in the 'source' parameter 
of a
 channel.
   This obsoletes the PLUGINPARAM patch.


 Is it right, that the sources have to be unique across the different plugins, at least at one installation? Where can 
I "register" for an "official" source-character? Who would document the assigned sources and where?
 'C', 'S' and 'T' are used by dvbdevice, 'P' was used by the plugin-param-patch. Since it was used for e.g. iptv and 
pvrinput, I guess these plugins shall use different ones now, since they have different syntax?


 On my first thought I considered to take 'A' for 'analog', but since there is something like "ATSC" (and I know 
nothing about it, if it's supported by vdr or is covered by dvbdevice or whatever), perhaps I should use another one?

 So I think it would be better to take *'V' = 'analog video'*, since pvrinput 
is basically an interface to v4l-devices.

 What are you thinking?

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13

[L. Hanisch]

Am 03.03.2010 20:35, schrieb VDR User:

On Wed, Mar 3, 2010 at 10:47 AM, L. Hanisch  wrote:

  On my first thought I considered to take 'A' for 'analog', but since there
is something like "ATSC" (and I know nothing about it, if it's supported by
vdr or is covered by dvbdevice or whatever), perhaps I should use another
one?
  So I think it would be better to take *'V' = 'analog video'*, since
pvrinput is basically an interface to v4l-devices.


"ATSC is a set of standards developed by the Advanced Television
Systems Committee for digital television transmission. ATSC replaced
much of the analog NTSC television system[1]  in the United
States[2][3]  on June 12, 2009 and will replace NTSC by August 31,
2011 in Canada[4]  and December 31, 2021 in Mexico."

Yes, I think you should take ATSC into consideration unless you want
to ignore North America. ;)


 That was never my intention... :-)

 I knew ATSC is an american standard for television, but I do not know with which devices it can be received with 
linux. Is it part of v4l or of dvb (or somehow both of them)? Are there patches for vdr which exposes a new kind of 
device or is it an extension of the existing dvbdevice?


 Anyway I would like to claim the source identifier 'V' for pvrinput. Just for 
the records...

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] streamdev-server and pvrinput: TS-mode streaming is not working

[L. Hanisch]

Hi,

 I'm trying to get TS-mode-streaming working with pvrinput and streamdev-server 
but have no luck.
 pvrinput is sending a valid TS now including PAT, PMT and PCR packets (PCR is 
derived from the SCR of the PS).
 But streamdev-server does not receive any PAT and PMT so it will not send them to the client (vlc in my tests). So vlc 
doesn't display anything, because it doesn't know anything about the sent PIDs.

 The entry in channels.conf contains the right PIDs.

 I inserted debug-logs in livestreamer.c at
cStreamdevLiveReceiver::Receive: all video, audio and PCR packets are received

 and
cStreamdevPatFilter::Process: no packet at all comes here...

 I'm using vdr 1.7.13 and streamdev from cvs.

 vlc can play the recorded files if I open them directly and it doesn't complain about anything, so I think, the 
stream, pvrinput delivers, is "valid enough".


 What am I missing?

 Looking at cReceiver::AddPid, a receiver is not able to set the PID 0 (which is the PAT-PID), but PAT packets should 
be processed through a filter, right? But I don't think I understand the class-tree of the various filters and receivers 
in streamdev...


 Can anyone with a deeper knowledge of this all please enlighten me?

 BTW: PES-streaming does work (as it always has).

Thanks!
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] streamdev-server and pvrinput: TS-mode streaming is not working

[L. Hanisch]

Hi,

Am 11.03.2010 23:17, schrieb Rolf Ahrenberg:

What am I missing?
Looking at cReceiver::AddPid, a receiver is not able to set the PID 0
(which is the PAT-PID), but PAT packets should be processed through a
filter, right?


IIRC, you'll need to implement section filtering into your input plugin
(implement virtual OpenFilter() and CloseFilter() methods and start/stop
the actual handling by calling
StartSectionHandler()/StopSectionHandler(). You can take a look at the
IPTV plugin, how this can be handled in non-DVBAPI environment.


 Thank you, I'll will give this a try.

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Recording DVB-T HD infrance

[L. Hanisch]

Hi,

Am 15.03.2010 21:06, schrieb Eric Valette:

Hi list,

I'm been fighting over Saturday to get vdr working on my netop (atom 330
+ Ion) but I must admit I loose the battle. With debian vdr 1.6.0 SD TV
works fine but HD TV (TF1 HD, ARTE HD, FRANCE 2 HD, M6HD) channels
fails. Theses channels use mpeg4 for video + and eac3 (except ARTE HD)
for audio as described here
 in french

I installed then vdr 1.7.13, and then got only the video stream but
still no audio. As I had similar problem with mplayer/xine and it was
fixed but manually editing the channels.conf (unfortunately not the same
format as vdr), I think I have the same kind of problem but can find a
way to correctly fix channels.conf.

below are extract the working mplayer channels.conf and the
channels.conf generated w_scan used for vdr. Plus the mplayer info when
correctly decoding and playing the stream.

Please CC when replying as I'm not suscribed

--- working mplayer/xine/vlc
TF1
HD:60200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:110+120:110+130:1281

France 2
HD:60200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:210+220:210+230:1282

M6HD:60200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:310+320:310+330:1283


- w_scan generated vdr channels.conf

TF1 HD;MR5:602000:B8M64:T:27500:120=27:0:0:0:1281:8442:5:0


 Try:
TF1 HD;MR5:602000:B8M64:T:27500:120=27:0;130:0:0:1281:8442:5:0

 Since it's ac3, the digital audio PID have to be set. The "analog audio" PID has to be 
0, hence "0;130".

Lars.


France 2 HD;MR5:602000:B8M64:T:27500:220=27:0:0:0:1282:8442:5:0
M6HD;MR5:602000:B8M64:T:27500:320=27:0:0:0:1283:8442:5:0

-- here info about the stream by maplyer 

PROGRAM_ID=0 (0x00), PMT_PID: 16(0x10)
PROGRAM_ID=1281 (0x501), PMT_PID: 110(0x6E)
PROGRAM_ID=1282 (0x502), PMT_PID: 210(0xD2)
PROGRAM_ID=1283 (0x503), PMT_PID: 310(0x136)

PROGRAM_ID=0 (0x00), PMT_PID: 16(0x10)
PROGRAM_ID=1281 (0x501), PMT_PID: 110(0x6E)
PROGRAM_ID=1282 (0x502), PMT_PID: 210(0xD2)
PROGRAM_ID=1283 (0x503), PMT_PID: 310(0x136)
VIDEO H264(pid=120) AUDIO A52(pid=130) NO SUBS (yet)! PROGRAM N. 1281
ID_VIDEO_ID=120
ID_AUDIO_ID=130
ID_AID_130_LANG=fra
PROGRAM_ID=0 (0x00), PMT_PID: 16(0x10)
PROGRAM_ID=1281 (0x501), PMT_PID: 110(0x6E)
PROGRAM_ID=1282 (0x502), PMT_PID: 210(0xD2)
PROGRAM_ID=1283 (0x503), PMT_PID: 310(0x136)
PROGRAM_ID=0 (0x00), PMT_PID: 16(0x10)
PROGRAM_ID=1281 (0x501), PMT_PID: 110(0x6E)
PROGRAM_ID=1282 (0x502), PMT_PID: 210(0xD2)
PROGRAM_ID=1283 (0x503), PMT_PID: 310(0x136)
PROGRAM_ID=0 (0x00), PMT_PID: 16(0x10)
PROGRAM_ID=1281 (0x501), PMT_PID: 110(0x6E)
PROGRAM_ID=1282 (0x502), PMT_PID: 210(0xD2)
PROGRAM_ID=1283 (0x503), PMT_PID: 310(0x136)
FPS seems to be: 25.00
ID_FILENAME=dvb://TF1 HD
ID_DEMUXER=mpegts
ID_VIDEO_FORMAT=0x1005
ID_VIDEO_BITRATE=0
ID_VIDEO_WIDTH=1440
ID_VIDEO_HEIGHT=1088
ID_VIDEO_FPS=25.000
ID_VIDEO_ASPECT=0.
ID_AUDIO_FORMAT=8192
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=0
ID_AUDIO_NCH=0
ID_LENGTH=0.00
ID_SEEKABLE=0
ID_CHAPTERS=0
Couldn't open video filter 'ass'.
ASS: cannot add video filter
[ass] Init
[ass] Updating font cache
==
Forced video codec: ffh264vdpau
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264vdpau] vfm: ffmpeg (FFmpeg H.264 (VDPAU))
==
ID_VIDEO_CODEC=ffh264vdpau
==
Forced audio codec: ffeac3
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
ID_AUDIO_BITRATE=256000
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3)
==
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
ID_AUDIO_CODEC=ffac3
[Mixer] No hardware mixing, inserting volume filter.
Starting playback...
PROGRAM_ID=0 (0x00), PMT_PID: 16(0x10)
PROGRAM_ID=1281 (0x501), PMT_PID: 110(0x6E)
PROGRAM_ID=1282 (0x502), PMT_PID: 210(0xD2)
PROGRAM_ID=1283 (0x503), PMT_PID: 310(0x136)
[VD_FFMPEG] Trying pixfmt=0.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
ID_VIDEO_ASPECT=1.7778
VO: [vdpau] 1440x1080 => 1920x1080 H.264 VDPAU acceleration
[VD_FFMPEG] XVMC-accelerated MPEG-2.




___
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] Using different types of device for the same channel

[L. Hanisch]

Hi Rob,

Am 30.03.2010 22:30, schrieb Rob Davis:

Theunis Potgieter wrote:



It could be possible to do it in a similar way as Alternative channel
-patch (http://www.vdr-wiki.de/wiki/index.php/Alternative_channel-patch)
handles alternative channels. But since that patch only works for
recording a channel it would need some work.



Does this patch still work for 1.7.12 or above? My German is not good, but
I can see it was applied to VDR 1.4.x..


 "copperhead" from the vdr-portal has a collection of different patches for the recent vdr. It contains the "alternate 
channel"-patch.


 http://copperhead.vdr-developer.org/patches.html

 You can disable all the other patches at the Make.config.template.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] vdr-pvrinput

[L. Hanisch]

Hi all,

The plugin for integrating analog MPEG2 cards by Hauppauge (et al.) into the 
vdr has a new home.

http://projects.vdr-developer.org/projects/show/plg-pvrinput

It's adapted to the latest changes of vdr (>= 1.7.13). For older versions the plugin-param-patch is still needed. Take a 
look at the README to adjust your channels.conf to the matching syntax of your vdr.


http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/README
http://projects.vdr-developer.org/repositories/entry/plg-pvrinput/HISTORY

I think, it's stable enough to be tested by you. :-)
Use the new home page for documenting bugs you encounter.

A short changelog:

- the generated TS now contains valid PAT, PMT and PCR packets so streaming with streamdev-server now works in TS mode. 
The used PIDs are the same as in the TS of cx18 cards, so the vdr will not alter them in mixed environments.

 vpid: 301+101=2 ; apid: 300 ; tpid: 305
- the Hauppauge HD PVR is now supported but uses different PIDs as the 
cx18/ivtv cards.
 vpid: 4113+4097=27 ; apid: 0;4352
- for radio channels no more video packets are sent. If you use a PVR350 as output device make sure you have a recent 
version of the pvr350-plugin which generates black video on its own.
- if you use a PVRUSB2 make sure you have the latest driver otherwise you can see occasionally no picture after a 
channel switch. The corresponding patch of pvrusb2 will be integrated in kernel 2.6.34.
- if you experience stuttering video on switching channels you can tweak some buffers with some parameters in the 
setup.conf (stop your vdr before editing, of course)


pvrinput.ReadBufferSizeKB = 64 // size of buffer for reader in KB (default: 
64 KB)
pvrinput.TsBufferSizeMB = 3// ring buffer size in MB (default: 3 MB)
pvrinput.TsBufferPrefillRatio = 0  // wait with delivering packets to vdr till 
buffer is filled up to x%

If the default values don't make you happy, please report working values for your setup. Please report also your used 
input and output devices.


The latest versions of w_pvrscan and wirbelscan supports the new vdr 1.7.13 syntax if you don't want to change your 
channels.conf by hand.


 http://wirbel.htpc-forum.de/w_pvrscan/index2.html
 http://wirbel.htpc-forum.de/wirbelscan/index2.html

Here's the announcement in the vdr-portal:
http://www.vdr-portal.de/board/thread.php?threadid=95389


Have fun!
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] vdr-pvrinput

[L. Hanisch]

Hi Klaus,

 It would be great, if you can update the link to the pvrinput-plugin on your 
website

 http://www.tvdr.de/plugins.htm

 to

 http://projects.vdr-developer.org/projects/show/plg-pvrinput

 The current maintainers are Martin Dauskardt, Winfried Köhler and Lars Hanisch.

 Thank you!

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 dvb-t channel mismatch

[L. Hanisch]

Hi,

Am 21.08.2010 22:06, schrieb Stefan Lucke:

reststarting my vdr activities I went into trouble with dvb-t
channels.conf for Berlin. Just took the channels from:
http://www.vdr-wiki.de/wiki/index.php/Channels.conf_DVBT-De-Berlin-Brandenburg

There is the following entry for ARTE:

arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:0:0

I was able to tune and watch tv on this channel, but there was
no EPG available. VDR created the following new entry in channels.conf:

arte;ARD:19150:B7C23D12G8M16T8Y0:T:0:0:0:0:0:2:8468:257:0

Tuning to this VDR generated channel shows now the EPG information,
but no video and no sound :-(.


 What happens with this entry (adding the TID of the vdr-generated entry):

arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:257:0

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-1.7.15 dvb-t channel mismatch

[L. Hanisch]

Hi,

Am 22.08.2010 10:35, schrieb Stefan Lucke:

   What happens with this entry (adding the TID of the vdr-generated entry):

arte;ARD:191500:I999B7C23D12M16T8G8Y0:T:27500:201:202=deu,203=fra:204:0:2:8468:257:0


Thanks that brings EPG data to already present channels entry.
Neither NID nor TID are shown while editing those entries, so I could
not see a difference. Looking at NID I guess it plays it's role too.

From epg.data:


C T-8468-257-2 arte


 The elements of the channel identifier are "Source-NID-TID-SID". If you can't edit them in the OSD, stop your vdr and 
edit the channels.conf with an editor. The last four digits of the entry are "SID:NID:TID:RID".

 -> http://www.vdr-wiki.de/wiki/index.php/Channels.conf

 Or you can try the plugin "wirbelscan", perhaps this will get you the right 
channel entries.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Impact in cDevice::GetDevice

[L. Hanisch]

Hi,

Am 25.08.2010 08:52, schrieb Rainer Blickle:

This impact algorithm has evolved over time and is a very fragile thing.

Looks like only people have very deep insight in this algorithm should
change it.


For alternate channel, wouldn't it be better to try all possible
channels one after the other until one succeeds? I would not expect
GetDevice to return a device for a different channel than requested.


I have two different solutions in mind.

The first one:
Modify the cDevice::GetDevice method. It returns a device able to
provide the same "semantic" channel as requested ("semantic channel" =
channel with the same programme).
Modify the cDevice::SetChannel method. If the requested channel
couldn't be provided by the device, the method will try to provide the
configured alternatives one.
Pros: The user have the epg and the original channel number on the osd
Cons: Modifies the methods in an unexpected way. Plugins and other
parts of the vdr doesn't work anymore.

The second one:
When pressing CH+/- or selecting an channel directly (via 0-9) and the
selected channel is not available, switch the channel explicit to an
alternative one. (explicit = also display the channel number and the
epg of the alternative channel).
Pros: After switching to the new channel, the vdr is in a clean and
consitent state.
Cons: The vdr has switched to complete another channel when using CH+/-.

Checking for timer conflicts won't work correctly in both ways
(without changes), because this algorithm doesn't know about
alternative channels. But it would be much easier to implement this
when using the second approach.


 a third one (just comes to my mind, not deeply thought about):

 Write a device-plugin which provides a new source. Then you will have your own channels. In each channel entry you can 
configure which "real" channels are behind this and the plugin will attach a receiver to the next free "real" device and 
passes through the data. That would be a transparent way for recordings, live tv etc. and you don't have to patch vdr 
(hopefully). You only have to look where to get the epg but I think there's a "copy epg from one channel to 
another"-patch...


Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Understanding AC-3

[L. Hanisch]

Hi,

 Just an additional info for the ones who want to help - the pvrinput-plugin passes through the TS from the HD PVR to 
vdr, there's nothing changed.

 So hopefully the plugin is not the one to blame for... :-)

 I posted a sample PAT and PMT of the HD PVR in february, perhaps it can be 
used to clarify something.

 http://www.linuxtv.org/pipermail/vdr/2010-February/022400.html

Lars.

Am 02.09.2010 15:21, schrieb Rob Davis:

Hi Guy's,

How do you go about understanding AC-3 within a VDR context?
(apart from reading up on it online - which now has my head spinning).

I have a Hauppauge PVR-HD and two ATSC cards. The ATSC cards work as they 
should and with the new atsc/dn patch on
1.7.15 now have the correct dpids.

However, if I turn on add new transponders or update pids, then my Hauppauge 
PVR channels lose their dpid values..

Sep 1 19:10:33 oac vdr: [8186] changing pids of channel 920 from 
4113+4097=27:0;4352=...@106:0:0 to 4113+4097=27:0:0:0

If I keep automatic channel updates off, then xineliboutput and streamdev work 
for these channels, but vdr-vnsi (xbmc)
and vdr-xine don't (no audio)..

I'm assuming vdr parses the ac3 headers in some way and sends information onto 
the playback frontend. How would I go
about seeing what those headers might be and looking into patching pat.c 
accordingly?

I noticed all the comments about e-ac3 and wonder if a similar patch should be 
made for this device.

As an aside, vdr recordings from these channels play back fine in vdr-xine.

So, more specifically, I suppose I would like to know how to find out the 
STREAMTYPE:

I'm pretty sure it falls under this:

case 6: // STREAMTYPE_13818_PES_PRIVATE


But I'd be interested in seeing the flow through this section of pat.c and what 
is happening.. Mainly to see if
something needs to be forced on?

I can create a five second VDR recording if someone wants to see what the TS 
stream looks like.. But I'd be interested
in diagnosing it myself..

Thanks.



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Understanding AC-3

[L. Hanisch]

Am 02.09.2010 19:05, schrieb Rob Davis:

On 02/09/10 11:05, L. Hanisch wrote:

Hi,

Just an additional info for the ones who want to help - the
pvrinput-plugin passes through the TS from the HD PVR to vdr, there's
nothing changed.
So hopefully the plugin is not the one to blame for... :-)

I posted a sample PAT and PMT of the HD PVR in february, perhaps it can
be used to clarify something.



http://www.linuxtv.org/pipermail/vdr/2010-February/022400.html


How do you create the PAT and PMT files and then understand them.
I'm pretty sure that sample file was only mp3 input instead of AC3 digital 
which is what I use now..


 Yes, you may be right. Just 'cat' a sample video into a file and use 'hexdump' 
to format the output.
 One TS packet has a length of 188 bytes, I like 4 lines with 47 bytes.

 This will output the first 6 packets (6 * 188 = 1128):
 hexdump -e '"" 47/1 " %02x" "\n"' -n 1128 test.ts

 If every fourth line starts with the TS sync byte 0x47 you'll know you've done 
that right.

 This will help you understand the first 4 bytes, esp. the PID is the 5 lower bits of the second byte and the 8 bits of 
the third byte:

 http://en.wikipedia.org/wiki/MPEG_transport_stream

 The PAT will always have PID 0, in the PAT will be the PID of the PMT. There may be more than one PMT-PID in the PAT, 
one for each programme.

 http://en.wikipedia.org/wiki/Program_Specific_Information

 After staring some hours at those bytes you'll see the "matrix"... ;-)

Lars.





Lars.

Am 02.09.2010 15:21, schrieb Rob Davis:

Hi Guy's,

How do you go about understanding AC-3 within a VDR context?
(apart from reading up on it online - which now has my head spinning).

I have a Hauppauge PVR-HD and two ATSC cards. The ATSC cards work as
they should and with the new atsc/dn patch on
1.7.15 now have the correct dpids.

However, if I turn on add new transponders or update pids, then my
Hauppauge PVR channels lose their dpid values..

Sep 1 19:10:33 oac vdr: [8186] changing pids of channel 920 from
4113+4097=27:0;4352=...@106:0:0 to 4113+4097=27:0:0:0

If I keep automatic channel updates off, then xineliboutput and
streamdev work for these channels, but vdr-vnsi (xbmc)
and vdr-xine don't (no audio)..

I'm assuming vdr parses the ac3 headers in some way and sends
information onto the playback frontend. How would I go
about seeing what those headers might be and looking into patching
pat.c accordingly?

I noticed all the comments about e-ac3 and wonder if a similar patch
should be made for this device.

As an aside, vdr recordings from these channels play back fine in
vdr-xine.

So, more specifically, I suppose I would like to know how to find out
the STREAMTYPE:

I'm pretty sure it falls under this:

case 6: // STREAMTYPE_13818_PES_PRIVATE


But I'd be interested in seeing the flow through this section of pat.c
and what is happening.. Mainly to see if
something needs to be forced on?

I can create a five second VDR recording if someone wants to see what
the TS stream looks like.. But I'd be interested
in diagnosing it myself..

Thanks.



___
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] Developer versions

[L. Hanisch]

The next developer version of VDR will contain full True-Color OSD support.

^


Will this be a 1.8 release, or still in the 1.7 development train?


 I guess it would still be a 1.7.x.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [1.7.16] problem with GetClippedNumProvidedSystems

[L. Hanisch]

Hi,

 I get log messages like:
ERROR: device 1 supports 7 modulation systems but cDevice::GetDevice() currently only supports 4 delivery systems which 
should be fixed


 It's a Satelco EasyWatch (DVB-C):
 frontend 0/0 provides DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Philips 
TDA10023 DVB-C")

 But AvailableBits is 4, MaxNumProvidedSystems computes to 15 and NumProvidedSystems is 7 if I write them with isyslog 
to the log.

 Is it a fault of gcc 4.4.3?
 Has anyone any idea? I just don't know what to do with this...

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [1.7.16] problem with GetClippedNumProvidedSystems

[L. Hanisch]

Hi Rainer,

Am 24.01.2011 11:36, schrieb Rainer Blickle:

Hi Lars,

from my point of view this is not a problem and no fault of gcc 4.4.3.

Why ?: When selecting a device for receiving (cDevice::GetDevice as
far i know) there are 3 bits for the count of modulation systems. Is
is the impact variable.

The method isn't used anywhere else.


 I know that there's no real problem with selecting the device. But vdr 1.7.16 uses 4 bits for this piece of the impact 
computation.


cDevice::GetDevice:
  imp <<= 4; imp |= GetClippedNumProvidedSystems(4, device[i]) - 1;

GetClippedNumProvidedSystems:
  int MaxNumProvidedSystems = (1 << AvailableBits) - 1;
  int NumProvidedSystems = Device->NumProvidedSystems();
  if (NumProvidedSystems > MaxNumProvidedSystems) {

   AvailableBits == 4
=> 1 << 4 == 1b
=> 1b - 1 == b == 15d
 Device->NumProvidedSystems() returns 7
 7 < 15
=> there should be no error message

 If I place a isyslog right before the comparison like
isyslog("AvailableBits = %d, MaxNumProvidedSystems = %d, NumProvidedSystems = 
%d",
 AvailableBits, MaxNumProvidedSystems, NumProvidedSystems);
 The expected values are printed at the syslog and there's no error message.
 If I remove the syslog call, the error message comes again.

 That's why I think, that the compiler is "optimizing" something, which leads 
to an error.
 And if the compiler is doing something wrong here - how can I be sure that 
there are no errors in other parts?

 What am I missing? I would like to be wrong - but I would like to 
understand... :-)

Lars.



The impact is smaller (numberic value) if a device has less modulation
systems. Perhaps (and only perhaps) in some situations another device
would be taken to receive a specific channel.

Regards Rainer

2011/1/19 L. Hanisch:

Hi,

  I get log messages like:
ERROR: device 1 supports 7 modulation systems but cDevice::GetDevice()
currently only supports 4 delivery systems which should be fixed

  It's a Satelco EasyWatch (DVB-C):
  frontend 0/0 provides DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256
("Philips TDA10023 DVB-C")

  But AvailableBits is 4, MaxNumProvidedSystems computes to 15 and
NumProvidedSystems is 7 if I write them with isyslog to the log.
  Is it a fault of gcc 4.4.3?
  Has anyone any idea? I just don't know what to do with this...

Regards,
Lars.

___
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



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] AvetTV a761

[L. Hanisch]

Hi,


bttv0: registered device video0
bttv0: registered device vbi0



And yet. If I try use Avertv a761 and PRV 150 with pvrinput plugin, I have vdr 
crash:


 It seems that the driver for your a761 registers also an analog video device.
 pvrinput tries to open it and sends a VIDIOC_QUERYCAP to determine if it's a 
device it can handle.
 But the driver don't like it...

 A dirty workaround would be to add the option "video_nr" and "vbi_nr" to your bttv-module (look at "modinfo bttv") and 
set the number to something greater than 16. pvrinput will only test the first 8 video-nodes (see global.h in its source 
if it's modified).


 The right way is to look into the driver and test it if it crashes when you 
send the ioctl mentioned above.

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] AvetTV a761

[L. Hanisch]

Hi,

Am 13.02.2011 14:58, schrieb Придворов Андрей (Pridvorov Andrey):

It crash also:

root@ua0lnjvdr:/var/log# v4l2-ctl -D -d /dev/video0
Killed



The syslog messages you can see in attach.


 Since this problem is unrelated to vdr/pvrinput you should ask the linux-media 
mailing list.
 http://vger.kernel.org/vger-lists.html#linux-media

 Maybe you'll find the maintainer of the driver over there...

Regards,
Lars.



-Original Message-
From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of
Martin Dauskardt
Sent: Sunday, February 13, 2011 9:55 PM
To: vdr@linuxtv.org
Subject: Re: [vdr] AvetTV a761


And yet. If I try use Avertv a761 and PRV 150 with pvrinput plugin, I

have
vdr crash:

   It seems that the driver for your a761 registers also an analog video
device. pvrinput tries to open it and sends a VIDIOC_QUERYCAP to determine
if it's a device it can handle. But the driver don't like it...

   A dirty workaround would be to add the option "video_nr" and "vbi_nr" to
your bttv-module (look at "modinfo bttv") and set the number to something
greater than 16. pvrinput will only test the first 8 video-nodes (see
global.h in its source if it's modified).

   The right way is to look into the driver and test it if it crashes when
you send the ioctl mentioned above.


To the original poster:
I guess  ? ??  is not your real name. It would be nice if you
would use at least a nickname.

Try "v4l2-ctl -D -d /dev/video0" while vdr is not running. Does this work or

does it crash also?




___
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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] dynamite plugin

[L. Hanisch]

Hi,

Some friends asked me to modify vdr/write a plugin, because their boxes boot so fast that most of the hardware is not 
initialized by the time vdr can start. They had to delay it or had to restart vdr when they think the hardware is ready. 
But since some pci-cards are 'fast enough' they would like to attach the 'slow' cards later while using the 'fast' cards 
for watching, recording etc. as soon as possible.
So 'dynamite' was born (just some kind of wordplay with 'dynamic' and it sounds more 'bombastic' and effective in 
advertising than 'dyndev' or whatever). :-)


It's clear that this can't be done without patching the device handling inside vdr, so attached is my patch against vdr 
1.7.17. It is designed in such a way that the original behaviour of vdr is not changed if the dynamite plugin is not loaded.
I know that it is pretty invasive but it is as small as I could to do it. My knowledge of the inner relations of the 
various classes is certainly limited but I spent hours and hours on reading the source. And it is tested by a brave crew 
of volunteers. Nonetheless I would like to hear some remarks from the vdr-experts out there.


In the following lines I will try to explain what this patch-plugin-combination is able to do and how it's done. It's a 
bit lengthy but it's important to me and I know it wouldn't get integrated at all if I don't give a wider overview about 
the concepts and ideas behind this.


Features:
- attach/detach devices
While vdr is running you can dynamically attach/detach (unused) receiving 
devices to/from it.
This could be a DVB-USB-stick or a very slow initialising piece of hardware 
(firmware load etc.).

New devices are detected via udev, detaching should be made manually. If a frontend is in use udev is not sending a 
corresponding signal, there are just some messages from the usb subsystem, for example. The mapping to the right 
frontend and detaching it automatically is not trivial (in other words: it's on the TODO list).

Also OSD integration is completely missing but will be added in the future.

For attaching/detaching there are SVDRP commands (and Service calls for other 
plugins):
PLUG dynamite ATTD /dev/dvb/adapter0/frontend0
PLUG dynamite DETD /dev/dvb/adapter0/frontend0

For a complete list of commands please read the README[1].

- set device on idle
You can set a device to 'idle' mode. It will be ignored by the EIT scanner and 
closes all its handles.
This is handy if you have enough tuners and want so save some power or preserve some frontends from being 'always on'. 
This is also a 'manual' feature, some kind of automatism is planned (some kind of timeout or similar).

Of course it will be 'reanimated' automatically if a recording is starting or 
someone wants to look live-tv.

- GetTSPacket timeout
It is possible to set a 'GetTSPacket' timeout on the devices. If a device delivers no data for some time it can be 
automatically detached. This is intended for devices which has known unstable drivers. After detaching such a device a 
script is started so the driver can be reloaded and the device can be attached again to the vdr (this could happen on 
its own if the created frontend is signaled by udev).

It avoids restarts of vdr and interrupting recordings on other devices.

How this all is achieved:
The class cDevice is extended by two fields: parentDevice and subDevice.
The dynamite plugin provides a class derived from cDevice which passes all calls to its methods to its subDevice if one 
is attached. Otherwise it returns the appropriate values so vdr does think it can't receive anything (like the 
dummydevice output-plugin which can play everything).
On the other side there are some methods in cDevice which have to be "parentDevice-aware", since they are called from 
other derived devices or classes inside vdr. Since parentDevice (and subDevice) are always NULL if dynamite isn't 
loaded, it's easy to preserve the original behaviour.


To get the cDynamicDevice between the vdr and the device-creating plugins 
dynamite is doing two things:
- it registers a cDvbDeviceProbe-object and moves it to the front of the list
- the patch adds a second list 'cDynamicDeviceProbe' for 'dynamite-aware' 
plugins (like pvrinput as an example)

On startup when vdr iterates through the dvb-devices dynamite captures all devices and adds a cDynamicDevice for every 
one to the global vdr-device-array. It asks all other cDvbDeviceProbes if they would like to create a device and 
attaches this as a subDevice. If no cDvbDeviceProbe is left it creates a core cDvbDevice on its own.
After this it creates enough cDynamicDevice objects to flood the vdr-device-array. This ensures that vdr and other 
plugins always communicate with the devices through dynamite (like CAM, CI etc.) and so there is enough room for devices 
which will be attached later.
If you use plugins which create (non-dvb-)devices which can't be handled by dynamite (like xine, iptv, streamdev etc.) 
they have to be lo

Re: [vdr] [ANNOUNCE] dynamite plugin

[L. Hanisch]

Hi,

Am 24.03.2011 01:57, schrieb syrius...@no-log.org:

"L. Hanisch"  writes:


Features:
- attach/detach devices

[...]

- set device on idle

[...]

- GetTSPacket timeout
It is possible to set a 'GetTSPacket' timeout on the devices. If a
device delivers no data for some time it can be automatically
detached. This is intended for devices which has known unstable
drivers. After detaching such a device a script is started so the
driver can be reloaded and the device can be attached again to the vdr
(this could happen on its own if the created frontend is signaled by
udev).
It avoids restarts of vdr and interrupting recordings on other devices.


Thanks for that !
I'll be trying your patch this week end !
This is probably one of my most wanted vdr feature and it sounds like
you've just implemented it :)


 Cool, nice to hear! :)


questions :
- have you considered changing the way vdr detects adapter on startup ?
   for instance vdr won't detect /dev/dvb/adapter1 if
   /dev/dvb/adapter0 does not exist. this might happen when using udev
   rules and restarting vdr while a module isn't loaded


 If all devices are loaded after the start of vdr every device will be attached regardless of its adapter nr. But if it 
gets initialized before the startup it might get overseen (which might be intended by some users). I'll think about some 
kind of udev-device-enumration at startup.

 BTW the -D argument of vdr is ignored for now - have to implement that as well.



- what about being able to use aliases like /dev/dvb/dvb_s2_card_one
   with the -D arg ? (tho it's not really important)

- what about a github tree of vdr with your patch already applied ?


 Maybe - shouldn't be too bad. :)

Thanks,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] dynamite plugin

[L. Hanisch]

Hi,

Am 24.03.2011 01:57, schrieb syrius...@no-log.org:

questions :
- have you considered changing the way vdr detects adapter on startup ?
   for instance vdr won't detect /dev/dvb/adapter1 if
   /dev/dvb/adapter0 does not exist. this might happen when using udev
   rules and restarting vdr while a module isn't loaded


dynamite 0.0.6 now uses udev device enumeration to detect all dvb frontends 
regardless of their numbering.
If you would like to keep an adapter from being used by vdr you can set an udev 
environment property on that device.

The following would ensure that /dev/dvb/adapter2/frontend* is not attached:

 ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_ADAPTER_NUM}=="2", 
ENV{dynamite_attach}="no"

This acts as an replacement for the "-D" option of the core vdr. Since the card index of dynamically attached devices 
are not necessarily related to their adapter number it wouldn't work as expected any more.
(the -D option is only used in the vdr internal dvb device enumeration - if you add a device afterwards it would get 
attached even if it gets a "forbidden" adapter nr)



If you run multiple instances of vdr with different ids (option -i) you can associate the devices to the different vdrs 
with the property "dynamite_instanceid".


This attaches /dev/dvb/adapter2/frontend* to "vdr -i 1" and all other adapter to 
"vdr -i 0":

ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_ADAPTER_NUM}!="2", 
ENV{dynamite_instanceid}="0"
ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_ADAPTER_NUM}=="2", 
ENV{dynamite_instanceid}="1"

Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] dynamite plugin

[L. Hanisch]

Hi,

Am 28.03.2011 12:24, schrieb syrius...@no-log.org:

"L. Hanisch"  writes:


- have you considered changing the way vdr detects adapter on startup ?
for instance vdr won't detect /dev/dvb/adapter1 if
/dev/dvb/adapter0 does not exist. this might happen when using udev
rules and restarting vdr while a module isn't loaded


dynamite 0.0.6 now uses udev device enumeration to detect all dvb frontends 
regardless of their numbering.
If you would like to keep an adapter from being used by vdr you can set an udev 
environment property on that device.


Hi !

Thanks a lot !
I'm using 0.0.6b and the new udev rules.
My setup is :
- first vdr (the one in production that has to be working, especially
   when i'm not @home)
   genuine vdr 1.7.17, 2 dvb-s cards, diseqc

- 2nd vdr
   dynamite vdr 1.7.17, 1 dvb-s ff card which keeps crashing + 1 dvb-t
   usb stick

It is working perfectly, i haven't tried to remove/add adapter yet.
I will do later today.


 Thanks for testing this!


Just another question:
When i decide to only use one vdr instance, i'll be needing the diseqc
trick in diseqc.conf (the one that replaces the sourcecaps patch), how
do you think it could work ?
I guess the quickest workaround would be to add a new udev param to
force the card index in vdr.


 I only have DVB-C and only limited knowledge about DVB-S, Diseqc and all this stuff. But I found a description of the 
sourcecaps patch. When I have read and understood it, I'll get in touch with you.
 It seems possible to configure this via udev and solve it with a device hook. But I haven't tried it and don't know 
exactly how the device hooks works. (a little bit of brainstorming)



I've been having issues with udev rules to order dvb devices in the
past, instead i'm using a simple simple script that gives vdr the
correct card number.
ex:
vdr $(get-dvb-device.sh main)
"get-dvb-devices.sh main" returns "-D 1 -D 4" for example. that way
i'm sure my main vdr always uses my two stable dvb-s cards


Regards,
Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr