BUG: DVB-T and DVB-S[2] do not work with VDR & multiproto [Was: Two VDR's on one machine]
This problem keeps coming up over again, but for some reason Reinhard and Manu don't seem to want to talk about it.
I do not understand why you can't use DVB-T with DVB-S2 using the multiproto drivers and VDR, but I doubt it can be much of a problem.
I started modifying VDR to use the old API calls for DVB-T whilst using the new calls for DVB-S and S2 and I managed to get VDR to tune to the current DVB-T frequency and show the picture, but it would not tune to new frequencies. :-(
I too was considering using 2 VDRs on a single system using the -D options but it's very messy.
It would be great if someone could look into this for us!
Hi,
Morfsta schrieb:
This problem keeps coming up over again, but for some reason Reinhard and Manu don't seem to want to talk about it.
Well, what should I talk about it? I don't have a DVB-T device for testing and even if I had one, I live in a DVB-S only area in Germany.
And furthermore, I was only involved in the multiproto development as a tester. I don't know much about the internals. The DVB-S2 port of VDR was contributed by Marco Schlüßler and I only redistribute it to protect users form the pain to merge two patchsets by hand.
I do not understand why you can't use DVB-T with DVB-S2 using the multiproto drivers and VDR, but I doubt it can be much of a problem.
Well, both Manu and Marco wrote that the current multiproto tree provides an emulation layer which allows to access drivers which only provide the old API via the new API.
So it seems to me that either the emulation layer has a bug for DVB-T or the patched VDR passes incorrect data to the new API.
It would be great if someone could look into this for us!
I'm sorry that I cannot help you in this regard.
Bye.
Hi,
Reinhard Nissl schrieb:
So it seems to me that either the emulation layer has a bug for DVB-T or the patched VDR passes incorrect data to the new API.
Looks like the latter is true: Marco Schlüßler informed me that the mapping of TransmissionModes in nit.c for DVB-T is wrong.
I've created the attached patch according to his' instructions.
Please give the patch a try and report success or failure.
Bye.
Hi,
Thanks for speaking with Marco, Reinhard - its appreciated.
Unfortunately, the patch does not fix the problem. Still no picture on DVB-T transmissions.
Regards
On Jan 11, 2008 7:21 PM, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Reinhard Nissl schrieb:
So it seems to me that either the emulation layer has a bug for DVB-T or the patched VDR passes incorrect data to the new API.
Looks like the latter is true: Marco Schlüßler informed me that the mapping of TransmissionModes in nit.c for DVB-T is wrong.
I've created the attached patch according to his' instructions.
Please give the patch a try and report success or failure.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Saturday 12 January 2008, Morfsta wrote:
Hi,
Thanks for speaking with Marco, Reinhard - its appreciated.
Unfortunately, the patch does not fix the problem. Still no picture on DVB-T transmissions.
Same here. Which DVB-T device do you use ? I'm using a cinergyT2.
Ioctl's for this device are not passed via the common frontend interface. The new "API" has to get integrated into the cinergyT2 driver or client programs like vdr etc. have to recognize the driver supported API ;-) .
Regards
On Jan 11, 2008 7:21 PM, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Reinhard Nissl schrieb:
So it seems to me that either the emulation layer has a bug for DVB-T or the patched VDR passes incorrect data to the new API.
Looks like the latter is true: Marco Schlüßler informed me that the mapping of TransmissionModes in nit.c for DVB-T is wrong.
I've created the attached patch according to his' instructions.
Please give the patch a try and report success or failure.
Bye.
Stefan Lucke
On Jan 12, 2008 3:37 PM, Stefan Lucke stefan@lucke.in-berlin.de wrote:
Same here. Which DVB-T device do you use ? I'm using a cinergyT2.
Ioctl's for this device are not passed via the common frontend interface. The new "API" has to get integrated into the cinergyT2 driver or client programs like vdr etc. have to recognize the driver supported API ;-) .
I am using two Hauppauge Nova-T (tda1004x and cx2388x).
Manu said in an earlier thread that there should be compatibility with the old API so he doesn't think that should be a problem. The driver in the multiproto tree for my devices have not been changed so should work through the compatibility layer.
The odd thing is that when I use an older pre-compiled VDR 1.4.x with the new multiproto drivers everything works fine but when I compile 1.5.12 with multiproto includes it doesn't work.
On Saturday 12 January 2008, Morfsta wrote:
On Jan 12, 2008 3:37 PM, Stefan Lucke stefan@lucke.in-berlin.de wrote:
Same here. Which DVB-T device do you use ? I'm using a cinergyT2.
Ioctl's for this device are not passed via the common frontend interface. The new "API" has to get integrated into the cinergyT2 driver or client programs like vdr etc. have to recognize the driver supported API ;-) .
I am using two Hauppauge Nova-T (tda1004x and cx2388x).
Manu said in an earlier thread that there should be compatibility with the old API so he doesn't think that should be a problem. The driver in the multiproto tree for my devices have not been changed so should work through the compatibility layer.
The odd thing is that when I use an older pre-compiled VDR 1.4.x with the new multiproto drivers everything works fine but when I compile 1.5.12 with multiproto includes it doesn't work.
So I guess in your case, there is still an issue with the compatibility layer of http://jusst.de/hg/multiproto/ .
In my case I managed to get my cinergyT2 work with Reinhard's modified vdr, with attached diff.
Hi,
Stefan Lucke schrieb:
Same here. Which DVB-T device do you use ? I'm using a cinergyT2.
Ioctl's for this device are not passed via the common frontend interface. The new "API" has to get integrated into the cinergyT2 driver or client programs like vdr etc. have to recognize the driver supported API ;-) .
I am using two Hauppauge Nova-T (tda1004x and cx2388x).
Manu said in an earlier thread that there should be compatibility with the old API so he doesn't think that should be a problem. The driver in the multiproto tree for my devices have not been changed so should work through the compatibility layer.
The odd thing is that when I use an older pre-compiled VDR 1.4.x with the new multiproto drivers everything works fine but when I compile 1.5.12 with multiproto includes it doesn't work.
I spent the whole evening with Manu looking through the emulation layer and cannot see any obvious errors in the DVB-T case.
It looks like there is still an error in the translation from the multiproto SET_PARAMS ioctl to the old SET_FRONTEND. Manu was so kind and created the attached patch, which prints the original values given to SET_PARAMS in the DVB-T case and the translated values which tda1004x' set_frontend() implementation receives.
Morfsta: as you have such a card and reported that VDR-1.4.x tunes to DVB-T using the multiproto drivers (but old API) I ask you to test this patch.
Make sure that VDR only uses the device with the tda1004x on it by adding a suitable -Dx argument to VDR's command line.
To activate the logging messages, load the module dvb_core with parameter dvb_frontend_debug=1 and the module tda1004x with parameter debug=1.
Then use VDR-1.4.x (limited to only one device) and tune to a certain DVB-T channel. Have a look what the driver reports (see dmesg or /var/log/messages or anything else which suits your system) at least for the set_frontend() function.
Next use VDR-1.5.12-dvbs2-... (limited to only one device) and tune to the same DVB-T channel. Check what the driver reports this time. Additionally to the set_frontend() output there must a similar output before it which shows the parameters which VDR passed to the emulation layer.
Please report the debug output here for further investigation.
So I guess in your case, there is still an issue with the compatibility layer of http://jusst.de/hg/multiproto/ .
In my case I managed to get my cinergyT2 work with Reinhard's modified vdr, with attached diff.
Hmm, looks like you provide your own emulation layer :-(
Anyway, Manu agrees with me that it is not a good idea to have multiple implementations of an emulation layer with the expense of fixing the same bugs in every single driver.
Only when a device requires to use the new API (e. g. to report DELSYS_DVBS2), the driver should be ported to the new API and typically it should drop support for the old API at the same time, too.
So, please revert your change and apply the attached patch. Copy the debug output code from the tda1004x to your driver's file and take part in the test.
Thanks in advance.
Bye.
Hi,
Reinhard Nissl schrieb:
Please report the debug output here for further investigation.
Please report the relevant channel from VDR-1.4.x' channel.conf and from VDR-1.5.12's channel.conf too.
Bye.
Please report the relevant channel from VDR-1.4.x' channel.conf and from VDR-1.5.12's channel.conf too.
1.4.x: -
BBC ONE;BBC:730000000:I0C34D34M16B8T2G32Y0:T:27500:600:601=eng,602=eng:0:0:4165: 9018:4101:0
1.5.12: -
BBC ONE;BBC:730000000:A0I0C34D34M16B8T2G32Y0P0:T:27500:600:601=eng,602=eng:0:0:4 165:9018:4101:0
Regards
I spent the whole evening with Manu looking through the emulation layer and cannot see any obvious errors in the DVB-T case.
Thank-you very much for your time.
Then use VDR-1.4.x (limited to only one device) and tune to a certain DVB-T channel. Have a look what the driver reports (see dmesg or /var/log/messages or anything else which suits your system) at least for the set_frontend() function.
Next use VDR-1.5.12-dvbs2-... (limited to only one device) and tune to the same DVB-T channel. Check what the driver reports this time. Additionally to the set_frontend() output there must a similar output before it which shows the parameters which VDR passed to the emulation layer.
Please report the debug output here for further investigation.
Attached are two files - tuning to the same DVB-T channel using either system and the Philips frontend... vdr-1.4.x shows the channel fine, 1.5.12 does not.
Hope this helps and thanks again for your assistance.
Regards
Hi,
Morfsta schrieb:
Please report the debug output here for further investigation.
Attached are two files - tuning to the same DVB-T channel using either system and the Philips frontend... vdr-1.4.x shows the channel fine, 1.5.12 does not.
Hope this helps and thanks again for your assistance.
Hmm, the translation layer doesn't work correctly. It doesn't translate new bandwidth value 1 to old bandwidth value 0, although there exists code to do this translation, and it should get called as the other translations happen correctly.
As a result the old driver uses a bandwidth of 7 MHz instead of 8 MHz.
While copying the code here to ask for help in searching the bug, it seems that I found the bug -- a missing break in the DVB-T case ;-)
Please try the attached patch.
Bye.
While copying the code here to ask for help in searching the bug, it seems that I found the bug -- a missing break in the DVB-T case ;-)
Please try the attached patch.
Reinhard you've done it!!! All working! :-)
Thanks a lot for your work, I'm sure a lot of people are going to be very happy!
Cheers,
Morfsta
Reinhard Nissl wrote:
Hi,
Morfsta schrieb:
Please report the debug output here for further investigation.
Attached are two files - tuning to the same DVB-T channel using either system and the Philips frontend... vdr-1.4.x shows the channel fine, 1.5.12 does not.
Hope this helps and thanks again for your assistance.
Hmm, the translation layer doesn't work correctly. It doesn't translate new bandwidth value 1 to old bandwidth value 0, although there exists code to do this translation, and it should get called as the other translations happen correctly.
As a result the old driver uses a bandwidth of 7 MHz instead of 8 MHz.
While copying the code here to ask for help in searching the bug, it seems that I found the bug -- a missing break in the DVB-T case ;-)
Please try the attached patch.
Bye.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Big thanks guys, works here too! Finally I can put my S2-3200 in my "production" server. /Magnus H
Reinhard Nissl wrote:
Hi,
Morfsta schrieb:
Please report the debug output here for further investigation.
Attached are two files - tuning to the same DVB-T channel using either system and the Philips frontend... vdr-1.4.x shows the channel fine, 1.5.12 does not.
Hope this helps and thanks again for your assistance.
Hmm, the translation layer doesn't work correctly. It doesn't translate new bandwidth value 1 to old bandwidth value 0, although there exists code to do this translation, and it should get called as the other translations happen correctly.
As a result the old driver uses a bandwidth of 7 MHz instead of 8 MHz.
While copying the code here to ask for help in searching the bug, it seems that I found the bug -- a missing break in the DVB-T case ;-)
Please try the attached patch.
That indeed did fix. Have applied it to the tree.
Thanks, Manu
-
Magnus Hörlin -
Manu Abraham -
Morfsta -
Reinhard Nissl -
Stefan Lucke