Hi,
attached you'll find updated patches for VDR-1.5.12, which replace all formerly patches regarding this subject.
The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR (thanks to Marco Schlüßler) and requires to use the DVB drivers from the multi-proto tree (see URL below for further details).
The other patch is without DVB-S2 support and therefore most suitable for DVB-C users.
The patches have been extended to also include the recently released audioindexer patch. Furthermore, the field detection code for H.264 has been adopted to MPEG2, where the same issue (VDR's index.vdr addresses frame pictures, so an index entry must not be generated for the second field of a field picture pair) exists, though hardly used compared to H.264.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
Bye.
Trying to get this h.264 stuff going and vdr-1.5.12-h264-syncearly-framespersec-audioindexer-fielddetection.diff and vdr-1.5.10-genpix-usb.diff aren't playing nice during compile .. :(~
dvbdevice.c: In member function 'bool cDvbTuner::SetFrontend()': dvbdevice.c:253: error: jump to case label dvbdevice.c:184: error: crosses initialization of 'unsigned int frequency' dvbdevice.c:267: error: jump to case label dvbdevice.c:184: error: crosses initialization of 'unsigned int frequency' dvbdevice.c:285: error: jump to case label dvbdevice.c:184: error: crosses initialization of 'unsigned int frequency' make: *** [dvbdevice.o] Error 1
me lost, lol. Thankz
No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.6/1150 - Release Date: 11/24/2007 5:58 PM
Hi,
ShorTie schrieb:
Trying to get this h.264 stuff going and vdr-1.5.12-h264-syncearly-framespersec-audioindexer-fielddetection.diff and vdr-1.5.10-genpix-usb.diff aren't playing nice during compile .. :(~
dvbdevice.c: In member function 'bool cDvbTuner::SetFrontend()': dvbdevice.c:253: error: jump to case label dvbdevice.c:184: error: crosses initialization of 'unsigned int frequency' dvbdevice.c:267: error: jump to case label dvbdevice.c:184: error: crosses initialization of 'unsigned int frequency' dvbdevice.c:285: error: jump to case label dvbdevice.c:184: error: crosses initialization of 'unsigned int frequency' make: *** [dvbdevice.o] Error 1
This is not a matter of applying both patches -- only vdr-1.5.10-genpix-usb.diff is wrong. The error is the result of changes like that:
@@ -173,13 +173,14 @@
bool cDvbTuner::SetFrontend(void) { - dvb_frontend_parameters Frontend; + dvb_frontend_parameters_new Frontend;
memset(&Frontend, 0, sizeof(Frontend));
switch (frontendType) { - case FE_QPSK: { // DVB-S - + case FE_QPSK: // DVB-S + case FE_DVB_S: // DVB-S + case FE_DVB_S2: // DVB-S unsigned int frequency = channel.Frequency();
if (Setup.DiSEqC) {
See that the variable frequency a few lines above is declared within a switch statement which requires to use a separate block (= a pair of curly braces) for this declaration or you will get the above error. The original code correctly opened a curly brace after "case FE_QPSK:" while the new one doesn't after "case FE_DVB_S2:".
BTW: this is the matching curly brace that was removed from the orignal code:
tuneTimeout = DVBS_TUNE_TIMEOUT; lockTimeout = DVBS_LOCK_TIMEOUT; - } break; case FE_QAM: { // DVB-C
@@ -280,10 +286,17 @@
Try to add those removed curly braces and give it a try. Don't know whether it will work correctly afterwards, but it should compile (though not tested).
Bye.
Hi,
Reinhard Nissl schrieb:
attached you'll find updated patches for VDR-1.5.12, which replace all formerly patches regarding this subject.
The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR (thanks to Marco Schlüßler) and requires to use the DVB drivers from the multi-proto tree (see URL below for further details).
The other patch is without DVB-S2 support and therefore most suitable for DVB-C users.
The patches have been extended to also include the recently released audioindexer patch. Furthermore, the field detection code for H.264 has been adopted to MPEG2, where the same issue (VDR's index.vdr addresses frame pictures, so an index entry must not be generated for the second field of a field picture pair) exists, though hardly used compared to H.264.
The patches now include my recently released speedup patches as well as an unreleased speedup patch for cAudioRepacker and cVideoRepacker, because at least the latter one would have been hard to extract separately.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
Bye.
Reinhard,
Wow! I am running vdr-1.5.12 with the new xine-lib CVS (with your loop filter and speed over accuracy changes enabled) alongside FFMPEG built for 64bit linux on a k8 (AMD dual core BE-2350 processor overclocked at 2.7Ghz) and the results are nothing short of amazing! Firstly I would like to say thank-you very much for all your hard work on H264 - what you have achieved is fantastic.
I can view channels such as BBC HD, Channel 4 HD and others perfectly.
I think this might have been covered before, but the only problem I now see is with interlaced and spatial direct mode (particularly on the French and Polish HD channels): -
[h264 @ 0x2aaaad0b0700]Interlaced pictures + spatial direct mode is not implemented [h264 @ 0x2aaaad0b0700]Interlaced pictures + spatial direct mode is not implemented buffer usage: 492, 0, 6, 0, 0x97d390 buffer usage: 492, 0, 7, 0, 0x97d390 buffer usage: 444, 0, 7, 0, 0x97d390 buffer usage: 444, 0, 7, 0, 0x97d390 [h264 @ 0x2aaaad0b0700]Interlaced pictures + spatial direct mode is not implemented [h264 @ 0x2aaaad0b0700]Interlaced pictures + spatial direct mode is not implemented buffer usage: 411, 0, 7, 0, 0x97d390 buffer usage: 411, 0, 7, 0, 0x97d390
this results in a picture, but artifacting on motion and eventually in a crash.
I have a short clip recorded if you would like to work on it and need an example?
Please let me know,
Kind Regards,
Morfsta
On Jan 1, 2008 10:15 PM, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Reinhard Nissl schrieb:
attached you'll find updated patches for VDR-1.5.12, which replace all formerly patches regarding this subject.
The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR (thanks to Marco Schlüßler) and requires to use the DVB drivers from the multi-proto tree (see URL below for further details).
The other patch is without DVB-S2 support and therefore most suitable for DVB-C users.
The patches have been extended to also include the recently released audioindexer patch. Furthermore, the field detection code for H.264 has been adopted to MPEG2, where the same issue (VDR's index.vdr addresses frame pictures, so an index entry must not be generated for the second field of a field picture pair) exists, though hardly used compared to H.264.
The patches now include my recently released speedup patches as well as an unreleased speedup patch for cAudioRepacker and cVideoRepacker, because at least the latter one would have been hard to extract separately.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
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 Jan 2, 2008 11:08 AM, Torgeir Veimo torgeir@pobox.com wrote:
A howto outlining the steps you've taken to get this to work would be appreciated! :)
-- Torgeir Veimo torgeir@pobox.com
Hi Torgeir,
I used a lot of information from: -
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
Essentially: -
1) Download and make install the multiproto tree from http://jusst.de/hg/multiproto. I had to apply the HVR4000 patch for my Hauppauge Nova S2 (http://www.linuxtv.org/pipermail/linux-dvb/attachments/20071215/13bb7cb3/att...). If you are running a TT 3200 you probably don't need a patch.
2) Download and install latest ffmpeg cvs (see URL above for details on config options)
3) Download and install latest xine-lib (see URL above for details on config options)
4) Download and install latest xine-ui (see URL above for details on config options)
5) Download and make vdr-1.5.12 and patch with Reinhard's patches in this thread
6) Download xine-0.8.1 from http://home.vrweb.de/~rnissl/ and put it in the plugins directory and make it
7) Setup a channels.conf with some HD channels (here's some I have collected): -
BBCHD;EURO1080:10847:vS0Z0:S28.2E:22000:12327+2327:2329=NAR;2328=eng:2330:0:6940 :0:0:0 Channel 4 HD;EURO1080:11798:hC34M2S1Z35:S28.2E:29500:10513+8190:0;661=eng:0:960, 961:3875:0:0:0 PREMIERE HD,PREM HD;PREMIERE:11914:hC910M2S1Z35:S19.2E:27500:10767+767:0;771=deu ,772=eng:32:1801,1831,1830:129:133:6:0 DISCOVERY HD,DISC HD;PREMIERE:11914:hC910M2S1Z35:S19.2E:27500:11023+1023:0;1027= deu:32:1801,1831,1830:130:133:6:0 D.Alb HD-1;DigitALB:11094:vS0Z0:S16.0E:27900:2001:2002:0:B00:1004:366:30402:0 D.Alb HD-2;DigitALB:11094:vS0Z0:S16.0E:27900:2021:2022:0:0:1005:366:30402:0 CANAL+ FILM HD;Telenor:11421:hC23M5S1Z35:S1.0W:25000:10513+513:644=eng;645=eng:0 :B00:3306:70:14:0 CANAL+ SPORT HD;Telenor:11421:hC23M5S1Z35:S1.0W:25000:10514+514:648=sve,649=nor: 0:B00:1404:70:14:0 SVT HD;Telenor:11421:hC23M5S1Z35:S1.0W:25000:10512+512:640=sve;641=sve:0:B00:380 1:70:14:0 CANAL+ HI-TECH HD;CSAT:12522:vC23M5S1Z35:S19.2E:22000:10160+160:0;82=fra,83=eng: 0:100:9201:1:1106:0 NATIONAL GEO HD;CSAT:12522:vC23M5S1Z35:S19.2E:22000:10161+161:0;86=fra:0:100:920 2:1:1106:0 TF1 HD;CSAT:12522:vC23M5S1Z35:S19.2E:22000:10163+163:0;94=fra:0:100:9204:1:1106: 0 CINE PREMIER HD;CSAT:12581:vC23M5S1Z35:S19.2E:22000:10160+160:0;82=fra,83=eng:0: 100:9301:1:1110:0 HD suisse;SRG SSR idee suisse:12399:hS0Z0:S13.0E:27500:10180+180:0;131=deu,132=f ra,133=ita,134=eng:0:500:990:318:8500:0 SKY Sport HD 1;SkyItalia:11996:vC23M5S1Z35:S13.0E:27500:10164+164:0;416=ita,417= eng:0:919,93B:11020:64511:6400:0 Next HD;SkyItalia:11996:vC23M5S1Z35:S13.0E:27500:10160+160:0;400=ita,401=eng:0:9 19,93B:11030:64511:6400:0 SKY Cinema HD;SkyItalia:11996:vC23M5S1Z35:S13.0E:27500:10161+161:0;404=ita,405=e ng:0:919,93B:11031:64511:6400:0 NationalGeo HD;SkyItalia:11996:vC23M5S1Z35:S13.0E:27500:10163+163:0;412=ita,413= eng:0:919,93B:11032:64511:6400:0 SKY Sport HD 2;SkyItalia:11996:vC23M5S1Z35:S13.0E:27500:10165+165:0;420=eng,421= ita:0:919,93B:11033:64511:6400:0 13EME RUE HD;CSAT:12581:vC23M5S1Z35:S19.2E:22000:10161+161:0;86=fra:0:100:9302:1 :1110:0 DISNEY MAGIC HD;CSAT:12581:vC23M5S1Z35:S19.2E:22000:10162+162:0;90=fra,91=eng:0: 100:9303:1:1110:0 M6 HD;CSAT:12581:vC23M5S1Z35:S19.2E:22000:10170+170:0;122=fra:0:100:9310:1:1110: 0 Discovery HD Europe;Canal+:11434:vC23M5S1Z35:S1.0W:25000:10513+513:0;645:0:B00:3 804:70:38:0 Fox Sports Turkey;DigiTurk:10928:hC23M5S1Z35:S7.0E:30000:10201+201:0;301:0:D00,6 64:201:126:21100:0 Lig TV;DigiTurk:10928:hC23M5S1Z35:S7.0E:30000:10202+202:0;302:0:D00,664:202:126: 21100:0 ANIXE HD;BetaDigital:12722:hC23M5S1Z35:S19.2E:22000:11023+1023:0;1027=deu:0:0:10 203:1:1119:0 ASTRA HD;BetaDigital:12722:hC23M5S1Z35:S19.2E:22000:10767+767:768=deu:0:0:10202: 1:1119:0 ProSieben HD;ProSiebenSat.1:12722:hC23M5S1Z35:S19.2E:22000:10255+255:0;259=deu:0 :0:10200:1:1119:0 Sat.1 HD;ProSiebenSat.1:12722:hC23M5S1Z35:S19.2E:22000:10511+511:0;515=deu:0:0:1 0201:1:1119:0 Euro1080 HD1;Euro1080:10758:vS0Z0:S23.5E:22000:10308+308:256=eng:0:622,624,100:1 081:9999:3104:0 Euro1080 HD2/5;Euro1080:10758:vS0Z0:S23.5E:22000:10307+307:255=eng;258=deu:1026: 622,624:1:9999:3104:0 EXQI;Euro1080:10758:vS0Z0:S23.5E:22000:10034+34:35=eng:0:622,624,100:2:9999:3104 :0 HD Retail Info;BSkyB:12324:VC34M2S1Z0:S28.2E:29500:10512+8190:640=NAR;660=eng:23 05:960,961:3801:2:2032:0 Discovery HD;BSkyB:12324:VC34M2S1Z0:S28.2E:29500:10514+8190:0;662=eng:0:960,961: 3803:2:2032:0 Sky One HD;BSkyB:12344:HC34M2S1Z0:S28.2E:29500:10512+8190:640=NAR;660=eng:2305:9 60,961:3861:2:2033:0 SkyMovies HD2;BSkyB:12344:HC34M2S1Z0:S28.2E:29500:10513+8190:641=NAR;661=eng:231 2:960,961:3862:2:2033:0 Anytime;BSkyB:12344:HC34M2S1Z0:S28.2E:29500:0:0:0:0:4148:2:2033:0 NVOD:12344:HC34M2S1Z0:S28.2E:29500:0:0:0:0:3894:2:2408:0 NVOD:12344:HC34M2S1Z0:S28.2E:29500:0:0:0:0:3895:2:2408:0 NVOD:12344:HC34M2S1Z0:S28.2E:29500:0:0:0:0:3896:2:2005:0 NVOD:12344:HC34M2S1Z0:S28.2E:29500:10513+8190:641=NAR;661=eng:2312:960,961:3897: 2:2033:0 Nat Geo HD;BSkyB:12363:VC34M2S1Z35:S28.2E:29490:10513+8190:641=NAR;661=eng:0:960 ,961:3831:2:2034:0 SBO HD1;BSkyB:12363:VC34M2S1Z35:S28.2E:29490:10514+8190:642=NAR;662=eng:2305:960 ,961:3879:2:2034:0 History HD;BSkyB:12363:VC34M2S1Z35:S28.2E:29490:10512+8190:640=NAR;660=eng:0:960 ,961:3886:2:2034:0 CANAL+ FILM HD;Harmonic:11470:vS0Z0:S13.0E:27500:10331+331:332=pol;333=ORY:551:1 00:15423:318:1400:0 National Geographic HD;Globecast UK:11117:vS0Z0:S13.0E:27500:12301+2301:0;2311=p ol:0:100:14623:318:13000:0
Start X and xine to create a .config file then stop xine and edit your ~/.xine/config file. I have a dual core processor so here are the settings I used in there: -
video.processing.ffmpeg_skip_loop_filter:all video.processing.ffmpeg_thread_count:2 video.processing.ffmpeg_pp_quality:3 video.processing.ffmpeg_choose_speed_over_accuracy:1
Run vdr -Pxine
Start xine with: -
xine -f -I -V xv -A alsa --verbose=2 --post vdr_video --post vdr_audio -Dtvtime: method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 vdr://t mp/vdr-xine/stream#demux:mpeg_pes > /tmp/xine.log 2>&1
Enjoy HD channels!
HTH,
Morfsta
On 2 Jan 2008, at 21:59, Morfsta wrote:
- Download and make install the multiproto tree from
http://jusst.de/hg/multiproto. I had to apply the HVR4000 patch for my Hauppauge Nova S2
Is S2 currently required to get BBC HD or CH4 HD? I've got a dvb-s card set up against Sky FTA, but no S2 card atm.
S2 is required for channel4 HD, not for BBC HD - they are running MPEG4 DVB-S at the moment.
See http://www.lyngsat.com/hd/28east.html
On Jan 2, 2008 12:04 PM, Torgeir Veimo torgeir@pobox.com wrote:
Is S2 currently required to get BBC HD or CH4 HD? I've got a dvb-s card set up against Sky FTA, but no S2 card atm.
On Wed, 2 Jan 2008 11:59:36 +0000, in gmane.linux.vdr Morfsta wrote:
On Jan 2, 2008 11:08 AM, Torgeir Veimo torgeir@pobox.com wrote:
A howto outlining the steps you've taken to get this to work would be appreciated! :)
I used a lot of information from: -
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
Essentially: -
<detailed instructions snipped />
Enjoy HD channels!
Of course, there's one bit of *vital* information missing from your HOWTO, at least in regard to enjoying Channel4HD and the various Sky HD channels. Any explanations would be gratefully received. Please reply offlist, since I gather discussion of such procedures is frowned on here.
Thanks!
Iwan Davies
I think this might have been covered before, but the only problem I now see is with interlaced and spatial direct mode (particularly on the French and Polish HD channels): -
[h264 @ 0x2aaaad0b0700]Interlaced pictures + spatial direct mode is not implemented [h264 @ 0x2aaaad0b0700]Interlaced pictures + spatial direct mode is not implemented
ah, it's known problem with FFmpeg. Unfortunately in FFmpeg this feature is not implement. Nobody knows when FFmpeg will support spatial direct mode for Interlaced pictures
Igor
On Tue, Jan 01, 2008 at 11:15:58PM +0100, Reinhard Nissl wrote:
Hello :-)
The patches now include my recently released speedup patches as well as an unreleased speedup patch for cAudioRepacker and cVideoRepacker, because at least the latter one would have been hard to extract separately.
I found those patches tremendous, thank you very much, it works very well here !!!
Is there a way to use more than a card with it when only one is DVB-S2 capable ?
Thank you very much,
Is there a way to use more than a card with it when only one is DVB-S2 capable ?
I just dropped a mail to Reinhard asking the same question. My "production" system runs 2 DVB-T cards that currently don't work with vdr-1.5.12 / multiproto. I would love to start using it full time but until I can get support for DVB-T then it won't be possible.
There's two ways you can do this I believe, port the dvb-t driver properly to the new multiproto tree or modify VDR to fall back to the old interface to tune the driver if the new one fails.
I know that it is possible to use the old interface because when I use vdr-1.4.7 with the multiproto tree it works fine for DVB-T, however I am not sure where to start coding this into either VDR and I'm not sure my skills are that hot at the driver level!
If someone could provide some pointers here, that would be great (Manu or Reinhard?)
Thanks,
Phil
On Wed, Jan 02, 2008 at 02:48:09PM +0000, Morfsta wrote:
Is there a way to use more than a card with it when only one is DVB-S2 capable ?
I could also use two separates VDR as my two other cards are supported by multiproto and put DVB-S2 channels only on the vdr which run the DVB-S2 card, but I would higly prefer an all in one solution in which DVB-S channels are only used with DVB-S only cards and the DVB-S2 capable card is reserved for the DVB-S2 channels.
Thanks,
Morfsta wrote:
Is there a way to use more than a card with it when only one is DVB-S2 capable ?
I just dropped a mail to Reinhard asking the same question. My "production" system runs 2 DVB-T cards that currently don't work with vdr-1.5.12 / multiproto. I would love to start using it full time but until I can get support for DVB-T then it won't be possible.
There's two ways you can do this I believe, port the dvb-t driver properly to the new multiproto tree or modify VDR to fall back to the old interface to tune the driver if the new one fails.
I know that it is possible to use the old interface because when I use vdr-1.4.7 with the multiproto tree it works fine for DVB-T, however I am not sure where to start coding this into either VDR and I'm not sure my skills are that hot at the driver level!
If someone could provide some pointers here, that would be great (Manu or Reinhard?)
Over here, tests were done on STB0899, STV0299 and TDA10021 based all work out of the same multiproto tree (http://jusst.de.hg/multiproto)
Regards, Manu
On Wed, Jan 02, 2008 at 07:12:52PM +0400, Manu Abraham wrote:
Over here, tests were done on STB0899, STV0299 and TDA10021 based all work out of the same multiproto tree (http://jusst.de.hg/multiproto)
Do you mean VDR keep the DVB-S2 card for DVB-S2 channels and use the others for DVB-S usage ?
Thanks,
Gregoire Favre wrote:
On Wed, Jan 02, 2008 at 07:12:52PM +0400, Manu Abraham wrote:
Over here, tests were done on STB0899, STV0299 and TDA10021 based all work out of the same multiproto tree (http://jusst.de.hg/multiproto)
Do you mean VDR keep the DVB-S2 card for DVB-S2 channels and use the others for DVB-S usage ?
No, that seems silly. The DVB-S2 card works for DVB-S also. It should be able to use all the cards. Though you can't ask a DVB-S card to tune to DVB-S2, that's all the limitation it poses.
Regards, Manu
On Wed, Jan 02, 2008 at 07:32:13PM +0400, Manu Abraham wrote:
No, that seems silly. The DVB-S2 card works for DVB-S also. It should be able to use all the cards. Though you can't ask a DVB-S card to tune to DVB-S2, that's all the limitation it poses.
:-)
I know DVB-S2 cards can do DVB-S that's the reason to force VDR to use DVB-S only cards for DVB-S before the DVB-S2 ones, which if you want a DVB-S2 channels, so is your DVB-S2 cards free.
But one should get a way to tell VDR no to try to tune DVB-S2 channels on DVB-S card.
Thanks,
Gregoire Favre wrote:
On Wed, Jan 02, 2008 at 07:32:13PM +0400, Manu Abraham wrote:
No, that seems silly. The DVB-S2 card works for DVB-S also. It should be able to use all the cards. Though you can't ask a DVB-S card to tune to DVB-S2, that's all the limitation it poses.
:-)
I know DVB-S2 cards can do DVB-S that's the reason to force VDR to use DVB-S only cards for DVB-S before the DVB-S2 ones, which if you want a DVB-S2 channels, so is your DVB-S2 cards free.
But one should get a way to tell VDR no to try to tune DVB-S2 channels on DVB-S card.
You can do that. In fact the application should do a DVBFE_GET_INFO. This will query the capability of that specific driver. Based on the driver capabilities, issue a tuning request. That way a tune will be attempted only on the capable device.
It is a simple check, though.
Reinhard,
The patched version doesn't look at the device capability flags, before issuing a tune ? Or is something else wrong/missing ?
Regards, Manu
Hi,
Manu Abraham schrieb:
I know DVB-S2 cards can do DVB-S that's the reason to force VDR to use DVB-S only cards for DVB-S before the DVB-S2 ones, which if you want a DVB-S2 channels, so is your DVB-S2 cards free.
But one should get a way to tell VDR no to try to tune DVB-S2 channels on DVB-S card.
You can do that. In fact the application should do a DVBFE_GET_INFO. This will query the capability of that specific driver. Based on the driver capabilities, issue a tuning request. That way a tune will be attempted only on the capable device.
It is a simple check, though.
Reinhard,
The patched version doesn't look at the device capability flags, before issuing a tune ? Or is something else wrong/missing ?
I must admit, I didn't have a look at the source code so far, but from what I recall, I don't think that it is that easy. I think, a simple check will only make VDR tell you that the channel in question cannot be received.
I've experienced myself that VDR used the DVB-S2 card for a DVB-S recording and then endlessly tried to switch to a DVB-S2 channel using the DVB-S card -- obviously without success.
VDR's device selection logic is already quite complex. It has to deal with FF cards which have so far been used to watch the DVB-S channels, cards which provide CI interfaces and simple receiver cards. Moreover it now would have to deal with cards capable of doing DVB-S2, with or without CI interface respectively.
As I'm only distributing the DVB-S2 part which Marco Schlüßler provided several months ago, I've contacted him and asked him for an update.
Bye.
Reinhard Nissl wrote:
Hi,
Manu Abraham schrieb:
I know DVB-S2 cards can do DVB-S that's the reason to force VDR to use DVB-S only cards for DVB-S before the DVB-S2 ones, which if you want a DVB-S2 channels, so is your DVB-S2 cards free.
But one should get a way to tell VDR no to try to tune DVB-S2 channels on DVB-S card.
You can do that. In fact the application should do a DVBFE_GET_INFO. This will query the capability of that specific driver. Based on the driver capabilities, issue a tuning request. That way a tune will be attempted only on the capable device.
It is a simple check, though.
Reinhard,
The patched version doesn't look at the device capability flags, before issuing a tune ? Or is something else wrong/missing ?
I must admit, I didn't have a look at the source code so far, but from what I recall, I don't think that it is that easy. I think, a simple check will only make VDR tell you that the channel in question cannot be received.
I've experienced myself that VDR used the DVB-S2 card for a DVB-S recording and then endlessly tried to switch to a DVB-S2 channel using the DVB-S card -- obviously without success.
How can you ask a DVB-S device to tune to DVB-S2 ? Poor demodulator, it has to do what it is not even capable of. :)
VDR's device selection logic is already quite complex. It has to deal with FF cards which have so far been used to watch the DVB-S channels, cards which provide CI interfaces and simple receiver cards. Moreover it now would have to deal with cards capable of doing DVB-S2, with or without CI interface respectively.
The logic wouldn't be much different. It is the same as requesting a DVB-C device to be tuned to DVB-S. The CI interface doesn't make the hardware look any different.
As I'm only distributing the DVB-S2 part which Marco Schlüßler provided several months ago, I've contacted him and asked him for an update.
Ok, I will ask Marco on the relevant. Thanks for the feedback.
Regards, Manu
Hi,
Manu Abraham schrieb:
The patched version doesn't look at the device capability flags, before issuing a tune ? Or is something else wrong/missing ?
I must admit, I didn't have a look at the source code so far, but from what I recall, I don't think that it is that easy. I think, a simple check will only make VDR tell you that the channel in question cannot be received.
I've experienced myself that VDR used the DVB-S2 card for a DVB-S recording and then endlessly tried to switch to a DVB-S2 channel using the DVB-S card -- obviously without success.
How can you ask a DVB-S device to tune to DVB-S2 ? Poor demodulator, it has to do what it is not even capable of. :)
VDR's device selection logic is already quite complex. It has to deal with FF cards which have so far been used to watch the DVB-S channels, cards which provide CI interfaces and simple receiver cards. Moreover it now would have to deal with cards capable of doing DVB-S2, with or without CI interface respectively.
The logic wouldn't be much different. It is the same as requesting a DVB-C device to be tuned to DVB-S. The CI interface doesn't make the hardware look any different.
As I'm only distributing the DVB-S2 part which Marco Schlüßler provided several months ago, I've contacted him and asked him for an update.
Ok, I will ask Marco on the relevant. Thanks for the feedback.
Well, I was in contact with Marco already and attached you'll find a minimalistic change which reports "channel not available". Now VDR should already be able to kick a low priority DVB-S recording (or transfer thread) from a DVB-S2 device.
Still missing is to prefer DVB-S devices for DVB-S recordings so that DVB-S2 devices remain available for DVB-S2 recordings of same priority.
The patch is incremental to the original dvbs2 patch from yesterday, i. e. you can simply apply it to your already patched VDR.
Bye.
Hi,
Reinhard Nissl schrieb:
Well, I was in contact with Marco already and attached you'll find a minimalistic change which reports "channel not available". Now VDR should already be able to kick a low priority DVB-S recording (or transfer thread) from a DVB-S2 device.
The previous patch was wrong. Only DVB-S2 devices "could" provide channels. The revised patch works now as expected.
Still missing is to prefer DVB-S devices for DVB-S recordings so that DVB-S2 devices remain available for DVB-S2 recordings of same priority.
Still to do.
The patch is incremental to the original dvbs2 patch from yesterday, i. e. you can simply apply it to your already patched VDR.
Bye.
Hi,
Reinhard Nissl schrieb:
Well, I was in contact with Marco already and attached you'll find a minimalistic change which reports "channel not available". Now VDR should already be able to kick a low priority DVB-S recording (or transfer thread) from a DVB-S2 device.
The previous patch was wrong. Only DVB-S2 devices "could" provide channels. The revised patch works now as expected.
Still missing is to prefer DVB-S devices for DVB-S recordings so that DVB-S2 devices remain available for DVB-S2 recordings of same priority.
Still to do.
The attached version implements this behavior now. You may want to experiment a bit with the decision logic as explained below.
The decision is based on the number of modulation systems a card provides. For example, my NOVA-S provides one (DVB-S) and my SkyStar HD provides three (DVB-S, DVB-DSS, DVB-S2).
The decision logic is implemented in cDevice::GetDevice(), so have a look into device.c. After applying the patch, you'll find two lines in that function marked with comments like /*1*/ and /*2*/, and the latter one was disabled by a line comment.
In my scenario with just the above cards and vdr-xine as software device, watching a channel requires VDR to operate in transfer mode. Therefore it selects a device which provides for example a DVB-S channel. The patched version will choose the NOVA-S with either implementation /*1*/ or /*2*/.
Let's then start a DVB-S recording on a different transponder. When implementation /*2*/ would be active, VDR would choose the SkyStar HD, as the NOVA-S is claimed by transfer mode. Then, try to switch to a DVB-S2 channel. It wouldn't work, as the SkyStar HD would be claimed by a DVB-S recording.
That's why I've chosen implementation /*1*/ as default. For the above scenario, starting a DVB-S recording on a different transponder will choose the NOVA-S and kick off transfer mode. Then VDR will look for a card to set up transfer mode again and it will choose the only remaining card, the SkyStar HD. If you then try to switch to a DVB-S2 channel, it will work as the SkyStar HD is not claimed by a recording.
The patch is incremental to the original dvbs2 patch from yesterday, i. e. you can simply apply it to your already patched VDR.
Bye.
On Sat, Jan 05, 2008 at 06:53:48PM +0100, Reinhard Nissl wrote:
Hello,
with the last patch, VDR refuse to tune to any DVB-S2 channels. I guess that VDR thinks all my card are only DVB-S ones. I get "Channel not available!" on all DVB-S2 channels.
Any maybe not directly interesting, but with this patch, graphlcd make vdr segault at start.
Thanks,
The attached version implements this behavior now. You may want to experiment a bit with the decision logic as explained below.
The decision is based on the number of modulation systems a card provides. For example, my NOVA-S provides one (DVB-S) and my SkyStar HD provides three (DVB-S, DVB-DSS, DVB-S2).
The decision logic is implemented in cDevice::GetDevice(), so have a look into device.c. After applying the patch, you'll find two lines in that function marked with comments like /*1*/ and /*2*/, and the latter one was disabled by a line comment.
In my scenario with just the above cards and vdr-xine as software device, watching a channel requires VDR to operate in transfer mode. Therefore it selects a device which provides for example a DVB-S channel. The patched version will choose the NOVA-S with either implementation /*1*/ or /*2*/.
Let's then start a DVB-S recording on a different transponder. When implementation /*2*/ would be active, VDR would choose the SkyStar HD, as the NOVA-S is claimed by transfer mode. Then, try to switch to a DVB-S2 channel. It wouldn't work, as the SkyStar HD would be claimed by a DVB-S recording.
That's why I've chosen implementation /*1*/ as default. For the above scenario, starting a DVB-S recording on a different transponder will choose the NOVA-S and kick off transfer mode. Then VDR will look for a card to set up transfer mode again and it will choose the only remaining card, the SkyStar HD. If you then try to switch to a DVB-S2 channel, it will work as the SkyStar HD is not claimed by a recording.
The patch is incremental to the original dvbs2 patch from yesterday, i. e. you can simply apply it to your already patched VDR.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
--- ../vdr-1.5.12-dvbs2-other/device.c 2008-01-01 22:55:18.000000000 +0100 +++ device.c 2008-01-05 18:06:15.000000000 +0100 @@ -359,6 +359,21 @@ cDevice *cDevice::GetDevice(int Index) return (0 <= Index && Index < numDevices) ? device[Index] : NULL; }
+inline int GetClippedModulationSystemCount(int AvailableBits, cDevice *Device) +{
- int ModulationSystemCount = Device->ModulationSystemCount();
- int MaxModulationSystemCount = 1 << AvailableBits;
- if (ModulationSystemCount > MaxModulationSystemCount) {
esyslog("ERROR: device %d supports %d modulation systems but cDevice::GetDevice() currently only supports %d modulation systems which should be fixed", Device->CardIndex() + 1, ModulationSystemCount, MaxModulationSystemCount);ModulationSystemCount = MaxModulationSystemCount;}- else if (ModulationSystemCount <= 0) {
esyslog("ERROR: device %d reported an invalid number (%d) of supported modulation systems. The device should be fixed to return at least 1", Device->CardIndex() + 1, ModulationSystemCount);ModulationSystemCount = 1;}- return ModulationSystemCount;
+}
cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) { // Collect the current priorities of all CAM slots that can decrypt the channel: @@ -408,11 +423,13 @@ cDevice *cDevice::GetDevice(const cChann imp <<= 1; imp |= LiveView ? !device[i]->IsPrimaryDevice() || ndr : 0; // prefer the primary device for live viewing if we don't need to detach existing receivers imp <<= 1; imp |= !device[i]->Receiving() && (device[i] != cTransferControl::ReceiverDevice() || device[i]->IsPrimaryDevice()) || ndr; // use receiving devices if we don't need to detach existing receivers, but avoid primary device in local transfer mode imp <<= 1; imp |= device[i]->Receiving(); // avoid devices that are receiving +/*1*/ imp <<= 2; imp |= GetClippedModulationSystemCount(2, device[i]) - 1; // avoid cards which support multiple modulation systems imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice(); // avoid the Transfer Mode receiver device imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used) imp <<= 8; imp |= min(max((NumUsableSlots ? SlotPriority[j] : 0) + MAXPRIORITY, 0), 0xFF); // use the CAM slot with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used) imp <<= 1; imp |= ndr; // avoid devices if we need to detach existing receivers imp <<= 1; imp |= device[i]->IsPrimaryDevice(); // avoid the primary device +///*2*/ imp <<= 2; imp |= GetClippedModulationSystemCount(2, device[i]) - 1; // avoid cards which support multiple modulation systems imp <<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid cards with Common Interface for FTA channels imp <<= 1; imp |= device[i]->HasDecoder(); // avoid full featured cards imp <<= 1; imp |= NumUsableSlots ? !ChannelCamRelations.CamDecrypt(Channel->GetChannelID(), j + 1) : 0; // prefer CAMs that are known to decrypt this channel --- ../vdr-1.5.12-dvbs2-other/device.h 2007-10-21 11:21:52.000000000 +0200 +++ device.h 2008-01-05 17:22:25.000000000 +0100 @@ -224,6 +224,10 @@ public: ///< function itself actually returns true. ///< The default implementation always returns false, so a derived cDevice ///< class that can provide channels must implement this function.
- virtual int ModulationSystemCount() const { return 0; }
///< Returns the number of modulation systems the device supports.///< The default implementation always returns 0, so a derived cDevice///< class that can provide channels must implement this function.--- ../vdr-1.5.12-dvbs2-other/dvbdevice.c 2008-01-01 22:55:18.000000000 +0100 +++ dvbdevice.c 2008-01-05 17:36:36.000000000 +0100 @@ -406,6 +406,7 @@ cDvbDevice::cDvbDevice(int n) { ciAdapter = NULL; dvbTuner = NULL;
- modulationSystemCount = 0; frontendType = DVBFE_DELSYS_DUMMY; spuDecoder = NULL; digitalAudio = false;
@@ -468,8 +469,14 @@ cDvbDevice::cDvbDevice(int n) // We only check the devices that must be present - the others will be checked before accessing them://XXX
if (fd_frontend >= 0) {
if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0)
if (ioctl(fd_frontend, DVBFE_GET_DELSYS, &frontendType) >= 0) {// determine number of supported modulation systems by counting the bitsfor (int i = 0; i < 32; i++) {if (frontendType & (1u << i))modulationSystemCount++;} dvbTuner = new cDvbTuner(fd_frontend, CardIndex(), frontendType);} else LOG_ERROR; }@@ -798,7 +805,13 @@ bool cDvbDevice::ProvidesSource(int Sour
bool cDvbDevice::ProvidesTransponder(const cChannel *Channel) const {
- return ProvidesSource(Channel->Source()) && (!cSource::IsSat(Channel->Source()) || !Setup.DiSEqC || Diseqcs.Get(Channel->Source(), Channel->Frequency(), Channel->Polarization()));
- if (!ProvidesSource(Channel->Source()))
return false; // doesn't provide source- if (!cSource::IsSat(Channel->Source()))
return true; // source is sufficient for non sat- if (!(frontendType & Channel->ModulationSystem()))
return false; // requires modulation system which frontend doesn't provide- return !Setup.DiSEqC || Diseqcs.Get(Channel->Source(), Channel->Frequency(), Channel->Polarization());
}
bool cDvbDevice::ProvidesChannel(const cChannel *Channel, int Priority, bool *NeedsDetachReceivers) const @@ -807,7 +820,7 @@ bool cDvbDevice::ProvidesChannel(const c bool hasPriority = Priority < 0 || Priority > this->Priority(); bool needsDetachReceivers = false;
- if (ProvidesSource(Channel->Source())) {
- if (ProvidesTransponder(Channel)) { result = hasPriority; if (Priority >= 0 && Receiving(true)) { if (dvbTuner->IsTunedTo(Channel)) {
--- ../vdr-1.5.12-dvbs2-other/dvbdevice.h 2008-01-01 22:55:18.000000000 +0100 +++ dvbdevice.h 2008-01-05 17:29:49.000000000 +0100 @@ -35,6 +35,7 @@ public: ///< Must be called before accessing any DVB functions. ///< \return True if any devices are available. private:
- int modulationSystemCount; dvbfe_delsys frontendType; int fd_osd, fd_audio, fd_video, fd_dvr, fd_stc, fd_ca;
protected: @@ -66,6 +67,7 @@ public: virtual bool ProvidesSource(int Source) const; virtual bool ProvidesTransponder(const cChannel *Channel) const; virtual bool ProvidesChannel(const cChannel *Channel, int Priority = -1, bool *NeedsDetachReceivers = NULL) const;
- virtual int ModulationSystemCount() const { return modulationSystemCount; } virtual bool IsTunedToTransponder(const cChannel *Channel);
protected: virtual bool SetChannelDevice(const cChannel *Channel, bool LiveView);
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Gregoire Favre schrieb:
with the last patch, VDR refuse to tune to any DVB-S2 channels. I guess that VDR thinks all my card are only DVB-S ones. I get "Channel not available!" on all DVB-S2 channels.
Please add some debug code to cDvbDevice::ProvidesTransponder() to find out what's going wrong in your case, i. e. compare the provided and requested modulation systems.
Any maybe not directly interesting, but with this patch, graphlcd make vdr segault at start.
Did you recompile all plugins as a virtual function had been added?
Please provide a backtrace otherwise.
Bye.
On Sun, Jan 06, 2008 at 09:34:32PM +0100, Reinhard Nissl wrote:
Hi,
Hello :-)
Please add some debug code to cDvbDevice::ProvidesTransponder() to find out what's going wrong in your case, i. e. compare the provided and requested modulation systems.
I'll do tomorrow ;-)
Any maybe not directly interesting, but with this patch, graphlcd make vdr segault at start.
Did you recompile all plugins as a virtual function had been added?
Please provide a backtrace otherwise.
The two fix solve it :-) (not the non tunable DVB-S2).
Thanks,
On Sun, Jan 06, 2008 at 09:34:32PM +0100, Reinhard Nissl wrote:
Hi,
Please add some debug code to cDvbDevice::ProvidesTransponder() to find out what's going wrong in your case, i. e. compare the provided and requested modulation systems.
My cards :
0: 101469280 1: 101469280 2: 101469280
But the card 1 : Hauppauge HVR-4000 is the dvb-s2 one ???
DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (Conexant CX24116/CX24118)... DVB: registering frontend 2 (Conexant CX24123/CX24109)... Without the patch and with -D1 DVB-S2 works perfectly.
On Mon, Jan 07, 2008 at 05:19:17PM +0100, Gregoire Favre wrote:
On Sun, Jan 06, 2008 at 09:34:32PM +0100, Reinhard Nissl wrote:
Hi,
Please add some debug code to cDvbDevice::ProvidesTransponder() to find out what's going wrong in your case, i. e. compare the provided and requested modulation systems.
My cards :
0: 101469280 1: 101469280 2: 101469280
But the card 1 : Hauppauge HVR-4000 is the dvb-s2 one ???
DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (Conexant CX24116/CX24118)... DVB: registering frontend 2 (Conexant CX24123/CX24109)... Without the patch and with -D1 DVB-S2 works perfectly.
In case someone want to try to log here a small diff for it :
--- device.c.orig 2008-01-07 17:17:05.000000000 +0100 +++ device.c 2008-01-07 16:59:22.000000000 +0100 @@ -18,6 +18,7 @@ #include "receiver.h" #include "status.h" #include "transfer.h" +#include <iostream>
// --- cLiveSubtitle ---------------------------------------------------------
@@ -433,6 +434,7 @@ imp <<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid cards with Common Interface for FTA channels imp <<= 1; imp |= device[i]->HasDecoder(); // avoid full featured cards imp <<= 1; imp |= NumUsableSlots ? !ChannelCamRelations.CamDecrypt(Channel->GetChannelID(), j + 1) : 0; // prefer CAMs that are known to decrypt this channel + std::cerr << "DVBS2-log: " << i << ": " << imp << std::endl; if (imp < Impact) { // This device has less impact than any previous one, so we take it. Impact = imp; --- dvbdevice.c.orig 2008-01-07 17:17:58.000000000 +0100 +++ dvbdevice.c 2008-01-07 17:01:46.000000000 +0100 @@ -26,6 +26,7 @@ #include "receiver.h" #include "status.h" #include "transfer.h" +#include <iostream>
#define DO_REC_AND_PLAY_ON_PRIMARY_DEVICE 1 #define DO_MULTIPLE_RECORDINGS 1 @@ -805,12 +806,18 @@
bool cDvbDevice::ProvidesTransponder(const cChannel *Channel) const { - if (!ProvidesSource(Channel->Source())) + if (!ProvidesSource(Channel->Source())) { + std::cerr << "DVBS2-log: - Doesn't provide source" << std::endl; return false; // doesn't provide source - if (!cSource::IsSat(Channel->Source())) + } + if (!cSource::IsSat(Channel->Source())) { + std::cerr << "DVBS2-log: + source is sufficient for non sat" << std::endl; return true; // source is sufficient for non sat - if (!(frontendType & Channel->ModulationSystem())) + } + if (!(frontendType & Channel->ModulationSystem())) { + std::cerr << "DVBS2-log: - requires modulation system which frontend doesn't provide" << std::endl; return false; // requires modulation system which frontend doesn't provide + } return !Setup.DiSEqC || Diseqcs.Get(Channel->Source(), Channel->Frequency(), Channel->Polarization()); }
Hi,
Gregoire Favre schrieb:
Please add some debug code to cDvbDevice::ProvidesTransponder() to find out what's going wrong in your case, i. e. compare the provided and requested modulation systems.
My cards :
0: 101469280 1: 101469280 2: 101469280
Hmm, looks like you've reported the impact numbers from GetDevice(). But I've wanted some log messages from ProvidesTransponder().
Anyway, as the impact is the same for all devices, your driver doesn't set DVBFE_DELSYS_DVBS2.
But the card 1 : Hauppauge HVR-4000 is the dvb-s2 one ???
DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering frontend 1 (Conexant CX24116/CX24118)... DVB: registering frontend 2 (Conexant CX24123/CX24109)... Without the patch and with -D1 DVB-S2 works perfectly.
I've patched multiproto with the HVR-4000 support patch you've mentioned on the linux-dvb mailing list.
cx24116.c contains this function: /* TODO: The hardware does DSS too, how does the kernel demux handle this? */ static int cx24116_get_delsys(struct dvb_frontend *fe, enum dvbfe_delsys *fe_delsys) { dprintk("%s()\n",__FUNCTION__); *fe_delsys = DVBFE_DELSYS_DVBS | DVBFE_DELSYS_DVBS2;
return 0; }
Therefore the above mentioned flag should be set. Please check whether this function gets called when VDR reaches the end of cDvbDevice::cDvbDevice().
In case the emulation layer of the multiproto tree kicks in, then the function will not get called and therefore DVBFE_DELSYS_DVBS2 is not set.
Bye.
On Mon, Jan 07, 2008 at 07:27:21PM +0100, Reinhard Nissl wrote:
Hello :-)
I've patched multiproto with the HVR-4000 support patch you've mentioned on the linux-dvb mailing list.
I use this one : http://www.mail-archive.com/linux-dvb@linuxtv.org/msg28020.html but it don't seems to be the same as the one you used to check your source. It miss this function... I have to look after it in other patch...
Thank you very much, then the problem don't seems to be your patch but my driver, which will take some time to investigate :-)
Have a nice evening,
I have an problem with the original patch to vdr-1.5.12:
root@video:/usr/local/src/vdr-1.5.12-dvbs2# make g++ -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video" -DCONFDIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="./locale" -I/usr/include/freetype2 audio.c dvbdevice.h:38: Fehler: »dvbfe_delsys« bezeichnet keinen Typ make: *** [audio.o] Fehler 1
Any hints ?
Thank you...
...Hagen
On Sunday 13 January 2008, Hagen Schöbel wrote:
I have an problem with the original patch to vdr-1.5.12:
root@video:/usr/local/src/vdr-1.5.12-dvbs2# make g++ -g -O2 -Wall -Woverloaded-virtual -c -DREMOTE_KBD -DLIRC_DEVICE="/dev/lircd" -DRCU_DEVICE="/dev/ttyS1" -D_GNU_SOURCE -DVIDEODIR="/video" -DCONFDIR="/video" -DPLUGINDIR="./PLUGINS/lib" -DLOCDIR="./locale" -I/usr/include/freetype2 audio.c dvbdevice.h:38: Fehler: »dvbfe_delsys« bezeichnet keinen Typ make: *** [audio.o] Fehler 1
Any hints ?
The include path to your modified DVB-S2 drivers is missing. I set this path in Make.config (see Make.config.template) to: DVBDIR = /usr/local/src/v4l-dvb/linux
..-DLOCDIR="./locale" -I/usr/include/freetype2 -I/usr/local/src/v4l-dvb/linux/include dvbdevice.c ..
Over here, tests were done on STB0899, STV0299 and TDA10021 based all work out of the same multiproto tree (http://jusst.de.hg/multiproto)
There is something wrong then as it does not tune in vdr-1.5.12. I have the following DVB-T frontends: -
[ 9539.157598] DVB: registering frontend 1 (Conexant CX22702 DVB-T)... [ 9539.197883] DVB: registering frontend 3 (Philips TDA10045H DVB-T)...
Should the TDA10045H work? If so, perhaps the problem is that VDR is tuning frontend 1 first which is not supported yet.
How can I go about porting the Conexant to the new interface? Is it straightforward (i.e. can I compare the code for the TDA10021 based frontend in v4l-dvb and multiproto and make the changes for the cx22702 frontend?)
Thanks
Morfsta wrote:
Over here, tests were done on STB0899, STV0299 and TDA10021 based all work out of the same multiproto tree (http://jusst.de.hg/multiproto)
There is something wrong then as it does not tune in vdr-1.5.12. I have the following DVB-T frontends: -
[ 9539.157598] DVB: registering frontend 1 (Conexant CX22702 DVB-T)... [ 9539.197883] DVB: registering frontend 3 (Philips TDA10045H DVB-T)...
Should the TDA10045H work? If so, perhaps the problem is that VDR is tuning frontend 1 first which is not supported yet.
If the driver what you have in the multiproto tree, if you see it as old, ie: changes have gone into those drivers in between. The easiest thing to get going is:
Get the latest tree or whichever for which that demodulator/card is working with. Just overwrite the relevant older files for your driver/card in the multiproto tree (your local copy) That way, the devices which have been newly updated also will work.
How can I go about porting the Conexant to the new interface? Is it straightforward (i.e. can I compare the code for the TDA10021 based frontend in v4l-dvb and multiproto and make the changes for the cx22702 frontend?)
No need to do any porting. The same drivers which worked with the old API will work with the new API too, just that there is a thin translation layer in between. If you need the "shortest call" to those drivers, then you will need to port them to the new API. Till then, you can go ahead with copying the old drivers to the new API tree.
Regards, Manu
A diff of cx22702.c, cx22702.h and cx22702.mod.c between the normal hg of v4l-dvb and the multiproto tree reveals no differences...
Almost the same for tda1004x (tda1004x.c makes reference to an include for moduleparam.h) Is it these frontend modules that are the relevant ones?
If the driver what you have in the multiproto tree, if you see it as old, ie: changes have gone into those drivers in between. The easiest thing to get going is:
Get the latest tree or whichever for which that demodulator/card is working with. Just overwrite the relevant older files for your driver/card in the multiproto tree (your local copy) That way, the devices which have been newly updated also will work.
Hi,
Reinhard Nissl schrieb:
The patches now include my recently released speedup patches as well as an unreleased speedup patch for cAudioRepacker and cVideoRepacker, because at least the latter one would have been hard to extract separately.
cAudioRepacker speedup patch contains a typo. Please apply the attached fix.
Bye.
Hi,
Reinhard Nissl schrieb:
The patches now include my recently released speedup patches as well as an unreleased speedup patch for cAudioRepacker and cVideoRepacker, because at least the latter one would have been hard to extract separately.
cAudioRepacker speedup patch contains a typo. Please apply the attached fix.
The optimized DrawRectangle() will crash when called with incorrect coordinates, i. e. x1 > x2 or y1 > y2.
More generally such issues should be handled in Intersects() and Covers(). The attached patch adds sanity checks to them.
Thanks to Claus Meder for reporting this issue.
Bye.
Reinhard Nissl wrote:
Hi,
attached you'll find updated patches for VDR-1.5.12, which replace all formerly patches regarding this subject.
The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR (thanks to Marco Schlüßler) and requires to use the DVB drivers from the multi-proto tree (see URL below for further details).
The other patch is without DVB-S2 support and therefore most suitable for DVB-C users.
The patches have been extended to also include the recently released audioindexer patch. Furthermore, the field detection code for H.264 has been adopted to MPEG2, where the same issue (VDR's index.vdr addresses frame pictures, so an index entry must not be generated for the second field of a field picture pair) exists, though hardly used compared to H.264.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
Bye.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi. Big thanks to Reinhard, Manu, Claus and others who has made this possible. Using the old multiproto tree from 2007-10-25 I have SVT HD (swedish) working quite well with an S2-3200 on a 2.3GHz AMD BE-2400. My problem is that with that multiproto tree, VDR won't tune to any dvb-t channels on my nova-t 500. And with the latest multiproto tree dvb-t works but only unless I load the S2-3200 modules. If I do that VDR just hangs at startup saying nothing and doesn't answer on svdrp. Is there a way to debug this and see what's happening? Does anybody have any ideas about what's going on? If I remove the channels.conf vdr complains about that, so I know it's coming that far at least. There's no difference if I load any plugins or not.
Again, I have followed all steps on the wiki and h.264+dvb-s2 works with the old multiproto, both using vdr-1.5.10 with your "old" patch and on vdr-1.5.12 with the new one. I'm running this on the 2.6.22-14-generic kernel that ships with Ubuntu 7.10.
Keep up the good work, /Magnus H
On Jan 3, 2008 5:40 PM, Magnus Hörlin magnus@alefors.se wrote:
Hi. Big thanks to Reinhard, Manu, Claus and others who has made this possible. Using the old multiproto tree from 2007-10-25 I have SVT HD (swedish) working quite well with an S2-3200 on a 2.3GHz AMD BE-2400. My problem is that with that multiproto tree, VDR won't tune to any dvb-t channels on my nova-t 500. And with the latest multiproto tree dvb-t works but only unless I load the S2-3200 modules. If I do that VDR just hangs at startup saying nothing and doesn't answer on svdrp. Is there a way to debug this and see what's happening? Does anybody have any ideas about what's going on? If I remove the channels.conf vdr complains about that, so I know it's coming that far at least. There's no difference if I load any plugins or not.
Again, I have followed all steps on the wiki and h.264+dvb-s2 works with the old multiproto, both using vdr-1.5.10 with your "old" patch and on vdr-1.5.12 with the new one. I'm running this on the 2.6.22-14-generic kernel that ships with Ubuntu 7.10.
Sounds like you are having the same problem I am - when you say "new" multiproto, what do you mean?
I am using the mercurial tree at http://jusst.de/hg/multiproto which hasn't been updated now in 4 weeks.
I can't get the DVB-T devices working with it, even though Manu said it should work. The devices I use haven't had their source code modified from the v4l-dvb tree, so according to Manu the compatibility layer should mean they work OK, but when I tune to a DVB-T channel in VDR I just get a black screen.
As it seems there are quite a few people desperately hoping for some kind of DVB-T support alongisde their beloved DVB-S2 are there any other suggestions from Manu or Reinhard on this?
Cheers
-
Gregoire Favre -
Hagen Schöbel -
Igor Nikanov -
Iwan Davies -
Magnus Hörlin -
Manu Abraham -
Morfsta -
Reinhard Nissl -
ShorTie -
Stefan Lucke -
Torgeir Veimo