Hi,
I have a working vdr 1.7.16 installation with a satellite dvb-s2 card working fine.
Now I have a separate receiver which I would like to integrate with vdr
I have a supported bt878 card (item number 23 in the list)
http://linuxtv.org/hg/v4l-dvb/file/tip/linux/Documentation/video4linux/CARDL...
Besides a scart to rca cable to connect the receiver to the bt878 card what else will I need to do so vdr works with it?
The sky plugin? (I am not interested in Sky, just want to have analog video input from my third party receiver into my vdr box)
or some other analog tv plugin?
On 22/05/11 11:32, Arturo Martinez wrote:
Hi,
I have a working vdr 1.7.16 installation with a satellite dvb-s2 card working fine.
Now I have a separate receiver which I would like to integrate with vdr
I have a supported bt878 card (item number 23 in the list)
http://linuxtv.org/hg/v4l-dvb/file/tip/linux/Documentation/video4linux/CARDL...
Besides a scart to rca cable to connect the receiver to the bt878 card what else will I need to do so vdr works with it?
The sky plugin? (I am not interested in Sky, just want to have analog video input from my third party receiver into my vdr box)
or some other analog tv plugin?
You need to use an analog card which will convert the analog stream to an mpep2 stream, such as the Hauppauge PVR series (150, 500 etc). You can probably pick one up on ebay for pennies. Alternatively, you can use the Hauppauge PVR-HD which will give you AC3 audio input and possibly HD input if you can find an HDMI to Component converter. You want one of these and the pvrinput plugin.
Has anyone seen something similar to this?
I have two unscrambled channels on the same MUX where both is watchable in Live-TV but only one is recordable. The other terminates vdr (video stream broken).
The MUX is f=522MHz, se_Gothenburg-BrudareMossen, channels TV4 and TV6.
After throwing tons of debug prints in recorder.c and remux.c, it seems for TV6 the cFrameDetector never gets to 'synced' state.
I am debugging with vdr 1.7.14, but yaVDR teams vdr 1.7.17 release has the same problem.
The relevant line in remux.c is: #609: independentFrame = ((Data[i+2]>>3) & 0x07)==1;
For TV6 this '(Data[i+2]>>3) & 0x07' is 0,2 and 3 but not '1' for the 30s before recorder times out and considers video stream broken.
For TV4 it gets to be '1' within a couple of seconds.
Any ideas or debug suggestions are welcome.
Yours, Johan
Hi
This has been discussed here .. even if the solution is a temporary one, it works nice in France from months
http://www.linuxtv.org/pipermail/vdr/2010-June/023193.html
Best regards
Le mercredi 25 mai 2011 21:57:15, Johan Andersson a écrit :
Has anyone seen something similar to this?
I have two unscrambled channels on the same MUX where both is watchable in Live-TV but only one is recordable. The other terminates vdr (video stream broken).
The MUX is f=522MHz, se_Gothenburg-BrudareMossen, channels TV4 and TV6.
After throwing tons of debug prints in recorder.c and remux.c, it seems for TV6 the cFrameDetector never gets to 'synced' state.
I am debugging with vdr 1.7.14, but yaVDR teams vdr 1.7.17 release has the same problem.
The relevant line in remux.c is: #609: independentFrame = ((Data[i+2]>>3) & 0x07)==1;
For TV6 this '(Data[i+2]>>3) & 0x07' is 0,2 and 3 but not '1' for the 30s before recorder times out and considers video stream broken.
For TV4 it gets to be '1' within a couple of seconds.
Any ideas or debug suggestions are welcome.
Yours, Johan
Thank you!
It all works if we change the line to:
#609: independentFrame = ((Data[i+2]>>3)& 0x06)==0;
For some reason 'picture_coding_type' is set to '000' in this stream, not '001'. So only checkin the upper bits seem to do the trick.
As streams like this seem to exist both in Sweden and in France, is there any chance of making this change in the official VDR?
Yours, Johan
Dominique skrev 2011-05-25 22:25:
Hi
This has been discussed here .. even if the solution is a temporary one, it works nice in France from months
http://www.linuxtv.org/pipermail/vdr/2010-June/023193.html
Best regards
Le mercredi 25 mai 2011 21:57:15, Johan Andersson a écrit :
Has anyone seen something similar to this? [...] The relevant line in remux.c is: #609: independentFrame = ((Data[i+2]>>3)& 0x07)==1;
[...]
On 25.05.2011 23:47, Johan Andersson wrote:
Thank you!
It all works if we change the line to:
#609: independentFrame = ((Data[i+2]>>3)& 0x06)==0;
For some reason 'picture_coding_type' is set to '000' in this stream, not '001'. So only checkin the upper bits seem to do the trick.
As streams like this seem to exist both in Sweden and in France, is there any chance of making this change in the official VDR?
If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-)
Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this...
Klaus
Dominique skrev 2011-05-25 22:25:
Hi
This has been discussed here .. even if the solution is a temporary one, it works nice in France from months
http://www.linuxtv.org/pipermail/vdr/2010-June/023193.html
Best regards
Le mercredi 25 mai 2011 21:57:15, Johan Andersson a écrit :
Has anyone seen something similar to this? [...] The relevant line in remux.c is: #609: independentFrame = ((Data[i+2]>>3)& 0x07)==1;
[...]
Klaus Schmidinger skrev 2011-05-26 00:41:
If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-)
Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this...
Like making channels unrecordable :-)
I really have'nt got a clue who to ask. All physical transmission in Sweden is done by 'Teracom AB' but channels in the MUX'es are from mixed sources. TV4 is from 'TV4 AB' and TV6 is from 'Viasat Broadcasting UK' if one looks in channel.conf. All the marketing around DVB-T reception and selling smartcards for watching scrambled channels are done by 'Boxer AB'.
I suppose the key question is who is doing the DVB encoding.
The change is fairly recent though, I have recorded TV6 without problems for years. This has occured within the last few months.
/Johan
I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'. 'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though.
I managed to build the yavdr teams vdr-dev(1.7.17) for Ubuntu Lucid, from source with my change so I can again record TV6.
The main reason for using the yavdr stuff is VDPAU, as I use xineliboutput.
/Johan
Johan Andersson skrev 2011-05-26 07:16:
Klaus Schmidinger skrev 2011-05-26 00:41:
If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-)
Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this...
Like making channels unrecordable :-)
I really have'nt got a clue who to ask. All physical transmission in Sweden is done by 'Teracom AB' but channels in the MUX'es are from mixed sources. TV4 is from 'TV4 AB' and TV6 is from 'Viasat Broadcasting UK' if one looks in channel.conf. All the marketing around DVB-T reception and selling smartcards for watching scrambled channels are done by 'Boxer AB'.
I suppose the key question is who is doing the DVB encoding.
The change is fairly recent though, I have recorded TV6 without problems for years. This has occured within the last few months.
/Johan
On Sat, May 28, 2011 at 1:57 AM, Johan Andersson jna@jna.pp.se wrote:
I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'. 'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though.
I managed to build the yavdr teams vdr-dev(1.7.17) for Ubuntu Lucid, from source with my change so I can again record TV6.
The main reason for using the yavdr stuff is VDPAU, as I use xineliboutput.
Getting a VDR setup with vdpau is very easy. There's no need to use special repositories, packages, etc. unless you actually want to. If vdpau is the only thing you're after, you might be creating more work for yourself by not just keeping it small & simple.
VDR User skrev 2011-05-28 11:44:
Getting a VDR setup with vdpau is very easy. There's no need to use special repositories, packages, etc. unless you actually want to. If vdpau is the only thing you're after, you might be creating more work for yourself by not just keeping it small& simple.
Perhaps. I had a lot of trouble a year or so ago trying to get xineliboutput working with VDPAU under Ubuntu9. It has probably improved since then.
Nowadays I simply add a launchpad repos and do 'apt-get install' for vdr, xineliboutput etc. I probably get a lot of stuff I do not need, but it is very simple to install and maintain.
/Johan
On 28.05.2011 10:57, Johan Andersson wrote:
I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'.
Thanks for actually doing this - finally a broadcaster who at least admits *they* have a problem ;-)
'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though.
Maybe they would give this more priority if more people contacted them about this. Once replying to inquiries takes up a considerable amount of their time, they might consider doing something about it. Perhaps you should post here how to contact them, so other viewers of their channels could also bother them ;-)
Klaus
Johan Andersson skrev 2011-05-26 07:16:
Klaus Schmidinger skrev 2011-05-26 00:41:
If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-)
Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this...
Like making channels unrecordable :-)
I really have'nt got a clue who to ask. All physical transmission in Sweden is done by 'Teracom AB' but channels in the MUX'es are from mixed sources. TV4 is from 'TV4 AB' and TV6 is from 'Viasat Broadcasting UK' if one looks in channel.conf. All the marketing around DVB-T reception and selling smartcards for watching scrambled channels are done by 'Boxer AB'.
I suppose the key question is who is doing the DVB encoding.
The change is fairly recent though, I have recorded TV6 without problems for years. This has occured within the last few months.
/Johan
In a small company like where I work I take the support call and fix the issue. Then your strategy would work.
I suspect that in a larger company the only thing that happens is that the people at frontline support gets annoyed. The relevant people will only see one issue in their issue tracking system regardless.
It would however be interesting to know if more people in Sweden have seen this. Perhaps everyone but me knew of the french situation and had it fixed long ago. Perhaps recording old Stargate reruns on TV6 is too geekish so noone else noticed :-)
I got a very positive sounding response from Teracom. I got the impression they are really going to fix this. For anyone else interested I simply mailed their support address on their homepage http://www.teracom.se, ie: kundtjanst@teracom.se
/Johan
Klaus Schmidinger skrev 2011-05-28 23:55:
On 28.05.2011 10:57, Johan Andersson wrote:
I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'.
Thanks for actually doing this - finally a broadcaster who at least admits *they* have a problem ;-)
'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though.
Maybe they would give this more priority if more people contacted them about this. Once replying to inquiries takes up a considerable amount of their time, they might consider doing something about it. Perhaps you should post here how to contact them, so other viewers of their channels could also bother them ;-)
Klaus
On 05/29/2011 07:14 PM, Johan Andersson wrote:
In a small company like where I work I take the support call and fix the issue. Then your strategy would work.
I suspect that in a larger company the only thing that happens is that the people at frontline support gets annoyed. The relevant people will only see one issue in their issue tracking system regardless.
It would however be interesting to know if more people in Sweden have seen this. Perhaps everyone but me knew of the french situation and had it fixed long ago. Perhaps recording old Stargate reruns on TV6 is too geekish so noone else noticed :-)
I got a very positive sounding response from Teracom. I got the impression they are really going to fix this. For anyone else interested I simply mailed their support address on their homepage http://www.teracom.se, ie: kundtjanst@teracom.se
/Johan
Klaus Schmidinger skrev 2011-05-28 23:55:
On 28.05.2011 10:57, Johan Andersson wrote:
I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'.
Thanks for actually doing this - finally a broadcaster who at least admits *they* have a problem ;-)
'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though.
Maybe they would give this more priority if more people contacted them about this. Once replying to inquiries takes up a considerable amount of their time, they might consider doing something about it. Perhaps you should post here how to contact them, so other viewers of their channels could also bother them ;-)
Klaus
Hi Johan. Yes, I have seen this too. TV10 has had it all the time but like you said, now TV6 has the same problem. I will send them a mail too and I must say I understand why Klaus doesn't want to make an ugly fix for this. I guess most STB people has, and that's why these problems exist. If everybody could just follow the standards things would be more stable. /Magnus H
Klaus,
I got a new reply from Teracom, where they had looked into this and could not see any problem on their end. They did say they had recently changed coding platform for TV6 though but it produced correct codes.
So, I did some further analysis of this, and I believe now the error is in vdr/remux.c.
It seems the 'new coding platform', before an I-frame, always puts the picture startcode, ie '00000100' at the end of the TS packet. This means that the code:
independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame
looks at the wrong byte, as i+2 > TS_SIZE
For non-I frames it can appear anywhere in the packet. The idea seems to be that an I-frame is always at the start of a TS-packet, do not ask me why.
So, your instinct of rejecting my suggestion for a patch was correct.
I have sample TS data of this stream, or dvbsnoop output of the relevant PID, if you are interested.
/Johan
Johan Andersson skrev 2011-05-29 19:14:
[...] I got a very positive sounding response from Teracom. I got the impression they are really going to fix this. For anyone else interested I simply mailed their support address on their homepage http://www.teracom.se, ie: kundtjanst@teracom.se
/Johan
Klaus Schmidinger skrev 2011-05-28 23:55:
On 28.05.2011 10:57, Johan Andersson wrote:
I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'.
Thanks for actually doing this - finally a broadcaster who at least admits *they* have a problem ;-)
'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though.
Maybe they would give this more priority if more people contacted them about this. Once replying to inquiries takes up a considerable amount of their time, they might consider doing something about it. Perhaps you should post here how to contact them, so other viewers of their channels could also bother them ;-)
Klaus
On 03.06.2011 22:33, Johan Andersson wrote:
Klaus,
I got a new reply from Teracom, where they had looked into this and could not see any problem on their end. They did say they had recently changed coding platform for TV6 though but it produced correct codes.
So, I did some further analysis of this, and I believe now the error is in vdr/remux.c.
It seems the 'new coding platform', before an I-frame, always puts the picture startcode, ie '00000100' at the end of the TS packet. This means that the code:
independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame
looks at the wrong byte, as i+2 > TS_SIZE
For non-I frames it can appear anywhere in the packet. The idea seems to be that an I-frame is always at the start of a TS-packet, do not ask me why.
So, your instinct of rejecting my suggestion for a patch was correct.
I have sample TS data of this stream, or dvbsnoop output of the relevant PID, if you are interested.
I am very interested! Can you put the sample data somewhere I can download it? The dvbsnoop output might also be helpful.
Klaus
Johan Andersson skrev 2011-05-29 19:14:
[...] I got a very positive sounding response from Teracom. I got the impression they are really going to fix this. For anyone else interested I simply mailed their support address on their homepage http://www.teracom.se, ie: kundtjanst@teracom.se
/Johan
Klaus Schmidinger skrev 2011-05-28 23:55:
On 28.05.2011 10:57, Johan Andersson wrote:
I sent off a question to customer support at Teracom and got a reply indicating that they do have an error relating to these channels in their 'coding platform'.
Thanks for actually doing this - finally a broadcaster who at least admits *they* have a problem ;-)
'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though.
Maybe they would give this more priority if more people contacted them about this. Once replying to inquiries takes up a considerable amount of their time, they might consider doing something about it. Perhaps you should post here how to contact them, so other viewers of their channels could also bother them ;-)
Klaus