The attached patch is what I've gathered from various postings regarding adapting VDR to the S2API driver API (thanks to Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't provide a way of determining whether a DVB-S device supports DVB-S2 (at least I didn't find any), you need to apply the second attached patch to the driver in order to impelement a new capability flag that reports the availability of DVB-S2 support.
If you don't want to patch the driver, you can change the line
case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
So far DVB-S and DVB-S2 appears to tune fine. DVB-C is completely untested. With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card does work with the S2API driver under VDR 1.6.0.
So for the moment I would appreciate if people could test DVB-T tuning and check whether maybe I made some silly mistake in the DVB-T tuning code.
Klaus
El Sábado, 6 de Diciembre de 2008, Klaus Schmidinger escribió:
The attached patch is what I've gathered from various postings regarding adapting VDR to the S2API driver API (thanks to Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't provide a way of determining whether a DVB-S device supports DVB-S2 (at least I didn't find any), you need to apply the second attached patch to the driver in order to impelement a new capability flag that reports the availability of DVB-S2 support.
If you don't want to patch the driver, you can change the line
case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
So far DVB-S and DVB-S2 appears to tune fine. DVB-C is completely untested. With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card does work with the S2API driver under VDR 1.6.0.
So for the moment I would appreciate if people could test DVB-T tuning and check whether maybe I made some silly mistake in the DVB-T tuning code.
Klaus
For DVB-T in S2API the bandwidth must be in HZ.
http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029556.html
Jose Alberto
On 06.12.2008 16:29, Jose Alberto Reguero wrote:
El Sábado, 6 de Diciembre de 2008, Klaus Schmidinger escribió:
The attached patch is what I've gathered from various postings regarding adapting VDR to the S2API driver API (thanks to Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't provide a way of determining whether a DVB-S device supports DVB-S2 (at least I didn't find any), you need to apply the second attached patch to the driver in order to impelement a new capability flag that reports the availability of DVB-S2 support.
If you don't want to patch the driver, you can change the line
case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
So far DVB-S and DVB-S2 appears to tune fine. DVB-C is completely untested. With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card does work with the S2API driver under VDR 1.6.0.
So for the moment I would appreciate if people could test DVB-T tuning and check whether maybe I made some silly mistake in the DVB-T tuning code.
Klaus
For DVB-T in S2API the bandwidth must be in HZ.
http://www.linuxtv.org/pipermail/linux-dvb/2008-October/029556.html
Jose Alberto
So you mean we should not use the driver's constants like BANDWIDTH_8_MHZ etc., but use numerical values instead? Ok, if that's what it takes...
With the value in Hz (e.g. 8000000) I can now tune DVB-T channels - thanks a lot!
Klaus
Just found a small flaw: the cDvbDevice::ProvidesTransponder() function needs to be adapted to the fact that the delivery system is now an enum and no longer a flag word:
bool cDvbDevice::ProvidesTransponder(const cChannel *Channel) const { 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 == SYS_DVBS && Channel->System() == SYS_DVBS2) return false; // requires modulation system which frontend doesn't provide return !Setup.DiSEqC || Diseqcs.Get(Channel->Source(), Channel->Frequency(), Channel->Polarization()); }
Maybe I'll map the SYS_DVB* stuff to a set of flags, so that these things can be handled as comfortably as in the multiproto API...
Klaus
Attached is an updated version of the patch to make VDR use the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0 out of range (451875..7230000)
and I now also get
Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0 out of range (5000000..45000000)
when trying to tune to a DVB-S2 channel.
The attached patch logs the value put into the DTV_SYMBOL_RATE slot, and it appears to be fine. Why the value falls back to 0 when tuning is currently totally unclear (as is the large frontend value in Dominik's case).
Any help in debugging this would be appreciated.
Note the comment in my initial posting about the patch to the driver required for detecting DVB-S2 (or modifiy the line using FE_CAN_2ND_GEN_MODULATION in cDvbDevice::cDvbDevice()).
Klaus
On 07.12.2008 13:21, Klaus Schmidinger wrote:
Attached is an updated version of the patch to make VDR use the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0 out of range (451875..7230000)
and I now also get
Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0 out of range (5000000..45000000)
when trying to tune to a DVB-S2 channel.
The attached patch logs the value put into the DTV_SYMBOL_RATE slot, and it appears to be fine. Why the value falls back to 0 when tuning is currently totally unclear (as is the large frontend value in Dominik's case).
Any help in debugging this would be appreciated.
Some more info: apparently the problem only happens if a DVB-S2 card (a TT-budget S2 3200 in my case) is (attempted to be) tuned to a DVB-S2 channel after the driver has been freshly loaded. Once the card has been tuned to a DVB-S channel, subsequent tuning to DVB-S2 channels works fine.
Now I'm unsure whether this is a VDR bug or a driver bug...
Klaus
On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> wrote:
On 07.12.2008 13:21, Klaus Schmidinger wrote:
Attached is an updated version of the patch to make VDR use the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist
ungültig
Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol
rate 0 out of range (451875..7230000)
and I now also get
Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0
out of range (5000000..45000000)
when trying to tune to a DVB-S2 channel.
The attached patch logs the value put into the DTV_SYMBOL_RATE slot, and it appears to be fine. Why the value falls back to 0 when tuning is currently totally unclear (as is the large frontend value in Dominik's case).
Any help in debugging this would be appreciated.
Some more info: apparently the problem only happens if a DVB-S2 card (a TT-budget S2 3200 in my case) is (attempted to be) tuned to a DVB-S2 channel after the driver has been freshly loaded. Once the card has been tuned to a DVB-S channel, subsequent tuning to DVB-S2 channels works fine.
That scenario works fine with scan-s2 utility.
Now I'm unsure whether this is a VDR bug or a driver bug...
Where is the origin of frontend value? I think its VDR internal and is not received from the driver...
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 07.12.2008 14:41, Alex Betis wrote:
On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de mailto:Klaus.Schmidinger@cadsoft.de> wrote:
On 07.12.2008 13:21, Klaus Schmidinger wrote: > Attached is an updated version of the patch to make VDR use > the S2API. Dominik Strasser reported that he got log entries like > > Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig > Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0 out of range (451875..7230000) > > and I now also get > > Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument > Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0 out of range (5000000..45000000) > > when trying to tune to a DVB-S2 channel. > > The attached patch logs the value put into the DTV_SYMBOL_RATE slot, > and it appears to be fine. Why the value falls back to 0 when tuning > is currently totally unclear (as is the large frontend value in Dominik's > case). > > Any help in debugging this would be appreciated. Some more info: apparently the problem only happens if a DVB-S2 card (a TT-budget S2 3200 in my case) is (attempted to be) tuned to a DVB-S2 channel after the driver has been freshly loaded. Once the card has been tuned to a DVB-S channel, subsequent tuning to DVB-S2 channels works fine.That scenario works fine with scan-s2 utility.
I just wanted to download the dvb-apps from linuxtv.org, but apparently all those repositories are gone, http://linuxtv.org/hg/dvb-apps is empty.
Any idea where to get the scan-s2 source now?
Klaus
2008/12/13 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
On 07.12.2008 14:41, Alex Betis wrote:
On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de mailto:Klaus.Schmidinger@cadsoft.de> wrote:
On 07.12.2008 13:21, Klaus Schmidinger wrote: > Attached is an updated version of the patch to make VDR use > the S2API. Dominik Strasser reported that he got log entries like > > Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig > Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0 out of range (451875..7230000) > > and I now also get > > Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument > Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0 out of range (5000000..45000000) > > when trying to tune to a DVB-S2 channel. > > The attached patch logs the value put into the DTV_SYMBOL_RATE slot, > and it appears to be fine. Why the value falls back to 0 when tuning > is currently totally unclear (as is the large frontend value in Dominik's > case). > > Any help in debugging this would be appreciated. Some more info: apparently the problem only happens if a DVB-S2 card (a TT-budget S2 3200 in my case) is (attempted to be) tuned to a DVB-S2 channel after the driver has been freshly loaded. Once the card has been tuned to a DVB-S channel, subsequent tuning to DVB-S2 channels works fine.That scenario works fine with scan-s2 utility.
I just wanted to download the dvb-apps from linuxtv.org, but apparently all those repositories are gone, http://linuxtv.org/hg/dvb-apps is empty.
Any idea where to get the scan-s2 source now?
I just wanted to download the dvb-apps from linuxtv.org, but apparently all those repositories are gone, http://linuxtv.org/hg/dvb-apps is empty.
Any idea where to get the scan-s2 source now?
also you can try new dvb-s/dvb-s2 scanner - xmlscan http://hg.kewl.org/dvb2010/
Goga
On 13.12.2008 22:34, Oleg Roitburd wrote:
2008/12/13 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
On 07.12.2008 14:41, Alex Betis wrote:
On Sun, Dec 7, 2008 at 3:06 PM, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de mailto:Klaus.Schmidinger@cadsoft.de> wrote:
On 07.12.2008 13:21, Klaus Schmidinger wrote: > Attached is an updated version of the patch to make VDR use > the S2API. Dominik Strasser reported that he got log entries like > > Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig > Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0 out of range (451875..7230000) > > and I now also get > > Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument > Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0 out of range (5000000..45000000) > > when trying to tune to a DVB-S2 channel. > > The attached patch logs the value put into the DTV_SYMBOL_RATE slot, > and it appears to be fine. Why the value falls back to 0 when tuning > is currently totally unclear (as is the large frontend value in Dominik's > case). > > Any help in debugging this would be appreciated. Some more info: apparently the problem only happens if a DVB-S2 card (a TT-budget S2 3200 in my case) is (attempted to be) tuned to a DVB-S2 channel after the driver has been freshly loaded. Once the card has been tuned to a DVB-S channel, subsequent tuning to DVB-S2 channels works fine.That scenario works fine with scan-s2 utility.
I just wanted to download the dvb-apps from linuxtv.org, but apparently all those repositories are gone, http://linuxtv.org/hg/dvb-apps is empty.
Any idea where to get the scan-s2 source now?
When I run scan-s2 with an initial tuning file that contains only a DVB-S2 transponder (Astra 19.2E)
S 11362000 H 22000000 2/3
and change scan.c so that it first tunes to DVB-S2, as in
/* set up list of delivery systems*/ //fe_delivery_system_t delset[]={SYS_DVBS,SYS_DVBS2}; fe_delivery_system_t delset[]={SYS_DVBS2,SYS_DVBS};
I get this with a freshly loaded driver:
=============================================================================== API major 5, minor 0 ERROR: Cannot open rotor configuration file 'rotor.conf'. scanning /home/kls/vdr/scan-s2-c728a0055904/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S2 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 11362000 H 22000000 2/3 AUTO AUTO ----------------------------------> Using DVB-S2
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000 FE_SET_PROPERTY TUNE failed: Invalid argument
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000 FE_SET_PROPERTY TUNE failed: Invalid argument ----------------------------------> Using DVB-S
tune to: 11362:hS0C23:S0.0W:22000:
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!!
tune to: 11362:hS0C23:S0.0W:22000: (tuning failed)
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done. ===============================================================================
If I run scan-s2 again, I get
=============================================================================== API major 5, minor 0 ERROR: Cannot open rotor configuration file 'rotor.conf'. scanning /home/kls/vdr/scan-s2-c728a0055904/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S2 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 11362000 H 22000000 2/3 AUTO AUTO ----------------------------------> Using DVB-S2
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000
parse_section, section number 0 out of 0...!
0x03F3 0x2B70: pmt_pid 0x0000 ZDFvision -- arte HD (running) 0x03F3 0x2B7A: pmt_pid 0x0000 IRT -- Simul SD (running) 0x03F3 0x2B84: pmt_pid 0x0000 IRT -- Simul HD (running)
parse_section, section number 0 out of 0...!
service_id = 0x0 service_id = 0x2B70 pmt_pid = 0x1838 service_id = 0x2B7A pmt_pid = 0x189C service_id = 0x2B84 pmt_pid = 0x1900
parse_section, section number 0 out of 0...!
VIDEO : PID 0x1842 AUDIO : PID 0x184D AUDIO : PID 0x184E TELETEXT : PID 0x1856
parse_section, section number 0 out of 0...!
VIDEO : PID 0x18A6 AUDIO : PID 0x18B0
parse_section, section number 0 out of 0...!
VIDEO : PID 0x190A AUDIO : PID 0x1914
parse_section, section number 0 out of 1...!
Network Name 'ASTRA'
parse_section, section number 1 out of 1...!
dumping lists (3 services) arte HD;ZDFvision:11361:hS1C23M5O35:S19.2E:22000:6210:6221=ger,6222=fra:6230:0:11120:1:1011:0 Simul SD;IRT:11361:hS1C23M5O35:S19.2E:22000:6310:6320=ger:0:0:11130:1:1011:0 Simul HD;IRT:11361:hS1C23M5O35:S19.2E:22000:6410:6420=ger:0:0:11140:1:1011:0 Done. ===============================================================================
So apparently not even scan-s2 is able to tune directly to a DVB-S2 transponder without first tuning to a DVB-S transponder.
Can anybody else confirm this, or am I doing something wrong?
Klaus
and change scan.c so that it first tunes to DVB-S2, as in
/* set up list of delivery systems*/ //fe_delivery_system_t delset[]={SYS_DVBS,SYS_DVBS2}; fe_delivery_system_t delset[]={SYS_DVBS2,SYS_DVBS};
Ok, I did run some tests. I am using following setup - kernel 2.6.27.1 - v4l-dvb drivers just updated today from linuxtv.org - szap-s2 just updated today from http://mercurial.intuxication.org/hg/szap-s2 - scan-s2 updated today from http://mercurial.intuxication.org/hg/scan-s2/ - hvr-1300 as /dev/dvb/adapter0 (frontend0 for dvb-t) - hvr-4000 as /dev/dvb/adapter1 (frontend 0 for s/s2, frontend 1 for dvb-t) - astra-19-2.conf for s2-channels S 11362000 H 22000000 2/3 S 10743750 H 22000000 2/3 - chan.conf for szap-s2 (not in vdr format) arteHD:11361:hC23M5O35S1:S19.2E:22000:6210:6230:0:11120:1:1011:0
I have lot of issues, so I try to report them with numbers...
1) scan-s2 will work if I first tune to arte HD for a while with szap-s2 - ./szap-s2 -a 1 -S 2 -c channels.conf arteHD ---> will immediately get lock - <ctrl-c> to stop szap-s2 - ./scan-s2 -a 1 -5 -o vdr astra-19-2.conf ... Network Name 'ASTRA'
parse_section, section number 1 out of 1...!
dumping lists (6 services) arte HD;ZDFvision:11361:hS1C23M5O35:S19.2E:22000:6210:6221=ger,6222=fra:6230:0:11120:1:1011:0 Simul SD;IRT:11361:hS1C23M5O35:S19.2E:22000:6310:6320=ger:0:0:11130:1:1011:0 Simul HD;IRT:11361:hS1C23M5O35:S19.2E:22000:6410:6420=ger:0:0:11140:1:1011:0 arte HD;ZDFvision:10743:hS0C56M2:S19.2E:22000:6210:6221=ger,6222=fra:6230:0:11120:1:1051:0 Simul SD;IRT:10743:hS0C56M2:S19.2E:22000:6310:6320=ger:0:0:11130:1:1051:0 Simul HD;IRT:10743:hS0C56M2:S19.2E:22000:6410:6420=ger:0:0:11140:1:1051:0
If I would have let the szap-s2 running, I could have received the channels also without astra-19-2.conf file by running
./scan-s2 -a 1 -5 -o vdr -c
2) After step (1) I can not newer use vdr-1.7.1 again for locking dvb-s channels with vlc/streamdev plugin (dvb-t channels from hvr-1300 still scans ok)
- launch vdr-1.7.1 (with latest Klaus s2-api patch for vdr-1.7.1) - vlc http://localhost:3000/PES/18
I can get vlc/vdr-1.7.1 to work again with S-channels, if I first launch vdr-1.6.0 and use use xine-liboutput to tune some S-channels.
3) I am not able to watch S2 channels with vdr-1.7.1/streamdev plugin/vlc compination (I can not connect crt tv to my ff cards directly so I must use plugin)
I have added following to vdr-1.7.1 channel.conf arteHD;ZDFvision:11361:hS1C23M5O35:S19.2E:22000:6210:6221=ger,6222=fra:6230:0:11120:1:1011:0 SimulSD;IRT:11361:hS1C23M5O35:S19.2E:22000:6310:6320=ger:0:0:11130:1:1011:0 SimulHD;IRT:11361:hS1C23M5O35:S19.2E:22000:6410:6420=ger:0:0:11140:1:1011:0
With vlc http://localhost:3000/PES/<channel-number> I am able to tune only the SimulSD channel, not arteHD or SimulHD
After trying these, I am again in situaion described in step (2) and I must first use vdr-1.6.0/xine-liboutput to tune S channels to get vdr-1.7.1 to be able to tune to them.
4) xine-liboutput plugin does not work with vdr-1.7.1 not even for dvb-t or dvb-s channels, while streamdev-server/vlc compination works ok except in case (2).
5) I can tune and watch arteHD with following commands from command line: - szap_channels.conf arteHD:11361:hC23M5O35S1:S19.2E:22000:6210:6230:0:11120:1:1011:0
- ./szap-s2 -a 1 -S 2 -c szap_channels.conf arteHD - dvbstream -c 1 8192 -o > test3.mpg - vlc test3.mpg
Here are still the full outputs from scan-s2. First once using first vdr-1.6.0 for tuning with old api to S-channels. And then the succesfull case after firts using szap-s2 to tune artehd.
[lamikr@tinka scan-s2]$ ./scan-s2 -a 1 -o vdr astra-19-2.conf API major 5, minor 0 scanning astra-19-2.conf using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' initial transponder DVB-S2 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S2 10743750 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 10743750 H 22000000 2/3 AUTO AUTO ----------------------------------> Using DVB-S2
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!!
tune to: 11362:hS1C23:S0.0W:22000: (tuning failed)
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!! ----------------------------------> Using DVB-S
tune to: 11362:hS0C23:S0.0W:22000:
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!!
tune to: 11362:hS0C23:S0.0W:22000: (tuning failed)
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!! ----------------------------------> Using DVB-S2
tune to: 10743:hS1C23:S0.0W:22000:
DVB-S IF freq is 993750 WARNING: >>> tuning failed!!!
tune to: 10743:hS1C23:S0.0W:22000: (tuning failed)
DVB-S IF freq is 993750 WARNING: >>> tuning failed!!! ----------------------------------> Using DVB-S
tune to: 10743:hS0C23:S0.0W:22000:
DVB-S IF freq is 993750 WARNING: >>> tuning failed!!!
tune to: 10743:hS0C23:S0.0W:22000: (tuning failed)
DVB-S IF freq is 993750 WARNING: >>> tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done.
[lamikr@tinka scan-s2]$ ./scan-s2 -a 1 -o vdr astra-19-2.conf API major 5, minor 0 scanning astra-19-2.conf using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' initial transponder DVB-S2 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S2 10743750 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 10743750 H 22000000 2/3 AUTO AUTO ----------------------------------> Using DVB-S2
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000
parse_section, section number 0 out of 0...!
service_id = 0x0 service_id = 0x2B70 pmt_pid = 0x1838 service_id = 0x2B7A pmt_pid = 0x189C service_id = 0x2B84 pmt_pid = 0x1900
parse_section, section number 0 out of 0...!
VIDEO : PID 0x1842 AUDIO : PID 0x184D AUDIO : PID 0x184E TELETEXT : PID 0x1856
parse_section, section number 0 out of 0...!
VIDEO : PID 0x18A6 AUDIO : PID 0x18B0
parse_section, section number 0 out of 0...!
0x03F3 0x2B70: pmt_pid 0x1838 ZDFvision -- arte HD (running) 0x03F3 0x2B7A: pmt_pid 0x189C IRT -- Simul SD (running) 0x03F3 0x2B84: pmt_pid 0x1900 IRT -- Simul HD (running)
parse_section, section number 0 out of 0...!
VIDEO : PID 0x190A AUDIO : PID 0x1914
parse_section, section number 0 out of 1...!
Network Name 'ASTRA'
parse_section, section number 1 out of 1...!
----------------------------------> Using DVB-S
tune to: 10743:hS0C56M2:S19.2E:22000:
DVB-S IF freq is 993750
parse_section, section number 0 out of 0...!
0x03F3 0x2B70: pmt_pid 0x0000 ZDFvision -- arte HD (running) 0x03F3 0x2B7A: pmt_pid 0x0000 IRT -- Simul SD (running) 0x03F3 0x2B84: pmt_pid 0x0000 IRT -- Simul HD (running)
parse_section, section number 0 out of 0...!
service_id = 0x0 service_id = 0x2B70 pmt_pid = 0x1838 service_id = 0x2B7A pmt_pid = 0x189C service_id = 0x2B84 pmt_pid = 0x1900
parse_section, section number 0 out of 0...!
VIDEO : PID 0x190A AUDIO : PID 0x1914
parse_section, section number 0 out of 0...!
VIDEO : PID 0x1842 AUDIO : PID 0x184D AUDIO : PID 0x184E TELETEXT : PID 0x1856
parse_section, section number 0 out of 0...!
VIDEO : PID 0x18A6 AUDIO : PID 0x18B0
parse_section, section number 0 out of 1...!
Network Name 'ASTRA'
parse_section, section number 1 out of 1...!
dumping lists (6 services) arte HD;ZDFvision:11361:hS1C23M5O35:S19.2E:22000:6210:6221=ger,6222=fra:6230:0:11120:1:1011:0 Simul SD;IRT:11361:hS1C23M5O35:S19.2E:22000:6310:6320=ger:0:0:11130:1:1011:0 Simul HD;IRT:11361:hS1C23M5O35:S19.2E:22000:6410:6420=ger:0:0:11140:1:1011:0 arte HD;ZDFvision:10743:hS0C56M2:S19.2E:22000:6210:6221=ger,6222=fra:6230:0:11120:1:1051:0 Simul SD;IRT:10743:hS0C56M2:S19.2E:22000:6310:6320=ger:0:0:11130:1:1051:0 Simul HD;IRT:10743:hS0C56M2:S19.2E:22000:6410:6420=ger:0:0:11140:1:1051:0 Done.
Mika
On Sun, Dec 14, 2008 at 2:01 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> wrote:
Some more info: apparently the problem only happens if a DVB-S2card
(a TT-budget S2 3200 in my case) is (attempted to be) tuned to aDVB-S2
channel after the driver has been freshly loaded. Once the card has been tuned to a DVB-S channel, subsequent tuning to DVB-S2 channels works fine.
I have Twinhan 1041 that use the same driver so I could check the problem...
When I run scan-s2 with an initial tuning file that contains only a DVB-S2 transponder (Astra 19.2E)
S 11362000 H 22000000 2/3
and change scan.c so that it first tunes to DVB-S2, as in
/* set up list of delivery systems*/ //fe_delivery_system_tdelset[]={SYS_DVBS,SYS_DVBS2}; fe_delivery_system_t delset[]={SYS_DVBS2,SYS_DVBS};
You can also start the entry in INI file with "S2" to scan only in DVB-S2 or "S1" to scan in DVB-S only mode.
I get this with a freshly loaded driver:
=============================================================================== API major 5, minor 0 ERROR: Cannot open rotor configuration file 'rotor.conf'. scanning /home/kls/vdr/scan-s2-c728a0055904/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S2 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 11362000 H 22000000 2/3 AUTO AUTO ----------------------------------> Using DVB-S2
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000 FE_SET_PROPERTY TUNE failed: Invalid argument
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000 FE_SET_PROPERTY TUNE failed: Invalid argument ----------------------------------> Using DVB-S
tune to: 11362:hS0C23:S0.0W:22000:
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!!
tune to: 11362:hS0C23:S0.0W:22000: (tuning failed)
DVB-S IF freq is 1612000 WARNING: >>> tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done.
===============================================================================
There seems to be a problem in the driver with AUTO modulation setting. Some drivers do not allow it at all. 2 options:
Explicitly specify the modulation, such as: S2 11362000 H 22000000 2/3 AUTO 8PSK
Or add the following case into switch in dtv_property_adv_params_sync function in dvb_frontend.c file of the drivers: case QAM_AUTO:
Just in case, the function will start with:
void dtv_property_adv_params_sync(struct dvb_frontend *fe) { struct dtv_frontend_properties *c = &fe->dtv_property_cache; struct dvb_frontend_private *fepriv = fe->frontend_priv; struct dvb_frontend_parameters *p = &fepriv->parameters;
p->frequency = c->frequency; p->inversion = c->inversion;
switch(c->modulation) { case PSK_8: case APSK_16: case APSK_32: case QPSK: * case QAM_AUTO: * p->u.qpsk.symbol_rate = c->symbol_rate; p->u.qpsk.fec_inner = c->fec_inner; break; default: break; }
This will solve the problem. I'll send an email to Igor about that.
If I run scan-s2 again, I get
=============================================================================== API major 5, minor 0 ERROR: Cannot open rotor configuration file 'rotor.conf'. scanning /home/kls/vdr/scan-s2-c728a0055904/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder DVB-S2 11362000 H 22000000 2/3 AUTO AUTO initial transponder DVB-S 11362000 H 22000000 2/3 AUTO AUTO ----------------------------------> Using DVB-S2
tune to: 11362:hS1C23:S0.0W:22000:
DVB-S IF freq is 1612000
parse_section, section number 0 out of 0...!
0x03F3 0x2B70: pmt_pid 0x0000 ZDFvision -- arte HD (running) 0x03F3 0x2B7A: pmt_pid 0x0000 IRT -- Simul SD (running) 0x03F3 0x2B84: pmt_pid 0x0000 IRT -- Simul HD (running)
parse_section, section number 0 out of 0...!
service_id = 0x0 service_id = 0x2B70 pmt_pid = 0x1838 service_id = 0x2B7A pmt_pid = 0x189C service_id = 0x2B84 pmt_pid = 0x1900
parse_section, section number 0 out of 0...!
VIDEO : PID 0x1842 AUDIO : PID 0x184D AUDIO : PID 0x184E TELETEXT : PID 0x1856
parse_section, section number 0 out of 0...!
VIDEO : PID 0x18A6 AUDIO : PID 0x18B0
parse_section, section number 0 out of 0...!
VIDEO : PID 0x190A AUDIO : PID 0x1914
parse_section, section number 0 out of 1...!
Network Name 'ASTRA'
parse_section, section number 1 out of 1...!
dumping lists (3 services) arte HD;ZDFvision:11361:hS1C23M5O35:S19.2E:22000:6210:6221=ger,6222=fra:6230:0:11120:1:1011:0 Simul SD;IRT:11361:hS1C23M5O35:S19.2E:22000:6310:6320=ger:0:0:11130:1:1011:0 Simul HD;IRT:11361:hS1C23M5O35:S19.2E:22000:6410:6420=ger:0:0:11140:1:1011:0 Done.
===============================================================================
So apparently not even scan-s2 is able to tune directly to a DVB-S2 transponder without first tuning to a DVB-S transponder.
Can anybody else confirm this, or am I doing something wrong?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
What happens if vdr has got multiple FF-dvb-s cards in the same machine, and you want to hookup multiple monitor/tvs? Can vdr successully handle this on the same machine? Or is the only answer now to run multiple intances of vdr, one for each FF-card? If vdr can do that, then surely implementing cross network would also become easier?
Hi Klaus,
just one question. Do you also use a budget system ? If so, how do you watch TV with vdr 1.7.1 and later ;) since xineliboutput is completly broken with it.
mfg
Edgar (gimli) Hucek
Attached is an updated version of the patch to make VDR use the S2API. Dominik Strasser reported that he got log entries like
Dec 6 18:39:02 VDR vdr: [4102] ERROR: frontend 0: Das Argument ist ungültig Dec 6 18:39:02 VDR kernel: DVB: adapter 0 frontend 1935763502 symbol rate 0 out of range (451875..7230000)
and I now also get
Dec 7 13:03:26 vdr2 vdr: [3441] ERROR: frontend 0: Invalid argument Dec 7 13:03:26 vdr2 kernel: DVB: adapter 0 frontend 0 symbol rate 0 out of range (5000000..45000000)
when trying to tune to a DVB-S2 channel.
The attached patch logs the value put into the DTV_SYMBOL_RATE slot, and it appears to be fine. Why the value falls back to 0 when tuning is currently totally unclear (as is the large frontend value in Dominik's case).
Any help in debugging this would be appreciated.
Note the comment in my initial posting about the patch to the driver required for detecting DVB-S2 (or modifiy the line using FE_CAN_2ND_GEN_MODULATION in cDvbDevice::cDvbDevice()).
Klaus _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 07.12.2008 18:40, gimli wrote:
Hi Klaus,
just one question. Do you also use a budget system ? If so, how do you watch TV with vdr 1.7.1 and later ;) since xineliboutput is completly broken with it.
Currently I still have a FF DVB card for replaying, which, in the long run, will be replaced by an eHD card.
Klaus
On Sun, Dec 7, 2008 at 9:43 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 07.12.2008 18:40, gimli wrote:
Hi Klaus,
just one question. Do you also use a budget system ? If so, how do you watch TV with vdr 1.7.1 and later ;) since xineliboutput is completly broken with it.
Currently I still have a FF DVB card for replaying, which, in the long run, will be replaced by an eHD card.
Just curious why you prefer that setup instead of going the budget route for the same or less cost? It's cheap these days to have even HDTV, especially with VDPAU now. FF seems to have understandably gone the way of the dinosaur.
On 08.12.2008 06:03, VDR User wrote:
On Sun, Dec 7, 2008 at 9:43 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 07.12.2008 18:40, gimli wrote:
Hi Klaus,
just one question. Do you also use a budget system ? If so, how do you watch TV with vdr 1.7.1 and later ;) since xineliboutput is completly broken with it.
Currently I still have a FF DVB card for replaying, which, in the long run, will be replaced by an eHD card.
Just curious why you prefer that setup instead of going the budget route for the same or less cost?
Well, because I already have several of these FF cards, and it's so easy to set up a VDR with them.
It's cheap these days to have even HDTV, especially with VDPAU now. FF seems to have understandably gone the way of the dinosaur.
I'm pretty sure there are quite a few systems out there using FF DVB cards. I wonder why you are constantly arguing against them ;-)
Klaus
Klaus Schmidinger schrieb:
On 08.12.2008 06:03, VDR User wrote:
Just curious why you prefer that setup instead of going the budget route for the same or less cost?
Well, because I already have several of these FF cards, and it's so easy to set up a VDR with them.
It's cheap these days to have even HDTV, especially with VDPAU now. FF seems to have understandably gone the way of the dinosaur.
I'm pretty sure there are quite a few systems out there using FF DVB cards. I wonder why you are constantly arguing against them ;-)
Klaus
It´s the same question I wanted to ask but I refused as I thought this might be again lead to an endless discussion.
The difference I see: The FF was available for years and delivered a near perfect image (at least if you had a FF 1.3-1.6 with RGB out), but now, this thing is discontinued and suffers of the limited bandwith (still haven´t looked for someone who could be able to modify my card). So now, the FF indeed is a dinosaur, especially with an LCD-TV and with the patches floating around delivering a synced gfx card output. I still have a FF on my own and was satisfied with if for more than 5 years, and indeed: it was easy to set up. But with HD, the time for FF in the living room will soon be over.
In contrast to the FF, in my opinion, the eHD is already a dinosaur as Micronas has stopped producing the chip. I don´t know how many eHDs Dream Multimedia has still on stock, but I think the hardware supply is much more limited than it was with the FF cards.
But this is not the point: This time I don´t like the focus on this special solution, especially as this makes it clear, that VDR will never become a media center solution. But we all know: Klaus also never wanted this.
After all those years, I don´t want to leave VDR, but as already a lot of people mentioned, I am also going to try to set up XBMC and VDR side-by-side. And if once XBMC will have a good TV support, I am going to switch completely, as my world has expanded to the wishes playing back MP3s, DivX, Ogg, MKV, YouTube etc. without any problems because of necessary transconding, and then, using a normal gfx card and no limited hardware solution.
With kind regards
Joerg Knitter (still a big VDR fan)
Hi, I don't like the hd discusion because we don't have any tv's which are build using a well developed standard. E. G. You can buy a lcd tv and after two years you can't use it's hdmi connectiorr of hdmi revision 599,95.0
hd ready->full-hd/hdmi1.1, 1.2 1.3 ..... I read something about limitations of current hdmi standard so we will maybe we get displayport as new solution???
In my opinion we should wait to get a stable well supported standard for tv's and the used format like 720I or 1080P ....
BTW. Softdevice/play, vdr-xine and xineliboutput are able to play youtube divx etc.
Regards halim
On Mon, Dec 8, 2008 at 2:00 AM, Halim Sahin halim.sahin@t-online.de wrote:
Hi, I don't like the hd discusion because we don't have any tv's which are build using a well developed standard. E. G. You can buy a lcd tv and after two years you can't use it's hdmi connectiorr of hdmi revision 599,95.0
I personally have many products with HDMI and have never experience any incompatibilities. They exist but certainly don't seem to be common.
hd ready->full-hd/hdmi1.1, 1.2 1.3 ..... I read something about limitations of current hdmi standard so we will maybe we get displayport as new solution???
Don't know anything about that but I have no problems so no reason to look. I have no problem up to the max my 60" tv handles which is 1080P.
In my opinion we should wait to get a stable well supported standard for tv's and the used format like 720I or 1080P ....
The problem I have with this way of thinking is that it completely ignores all the people who've already invested in new equipment. For example, HDMI is here to stay and it's readily available in countless products so do you really think the best solution is to ignore it until something better comes along? That makes no sense to me what-so-ever. If you want to hold out for something better then you'll always be outdated and always be holding out since something better is always coming. Support what's available today and people will be happy.
Hi, On Mo, Dez 08, 2008 at 10:28:30 -0800, VDR User wrote: V> On Mon, Dec 8, 2008 at 2:00 AM, Halim Sahin halim.sahin@t-online.de wrote:
Hi, I don't like the hd discusion because we don't have any tv's which are build using a well developed standard. E. G. You can buy a lcd tv and after two years you can't use it's hdmi connectiorr of hdmi revision 599,95.0
I personally have many products with HDMI and have never experience any incompatibilities. They exist but certainly don't seem to be common.
hd ready->full-hd/hdmi1.1, 1.2 1.3 ..... I read something about limitations of current hdmi standard so we will maybe we get displayport as new solution???
Don't know anything about that but I have no problems so no reason to look. I have no problem up to the max my 60" tv handles which is 1080P.
In my opinion we should wait to get a stable well supported standard for tv's and the used format like 720I or 1080P ....
The problem I have with this way of thinking is that it completely ignores all the people who've already invested in new equipment. For example, HDMI is here to stay and it's readily available in countless products so do you really think the best solution is to ignore it until something better comes along? That makes no sense to me what-so-ever. If you want to hold out for something better then you'll always be outdated and always be holding out since something better is always coming. Support what's available today and people will be happy.
It makes no sense to me supporting something which can't be used with hdtv stuff in one year! This wastes development time for non working and almost outdated stuff. Doing h264 decoding in software isn't praticable. I see the problems regarding the EHD from reel. Micronas doesn't develop afaik this stuff any more and paying allmost 200 EUR for a decoder card hmm ??????? My favourite solution will be decoding h264 with a strong gpu. Maybe vdpau?
Just my 2 cents. halim
On Mon, Dec 8, 2008 at 11:57 AM, Halim Sahin halim.sahin@t-online.de wrote:
It makes no sense to me supporting something which can't be used with hdtv stuff in one year!
HDMI isn't going anywhere any time soon. Neither is h264, or anything else so can you give us some examples of things you think won't be usable with HDTV in a year?
This wastes development time for non working and almost outdated stuff.
I don't think you'll find many people who agree that adding support for present and future needs, like h264, is a waste of development time.
Doing h264 decoding in software isn't praticable.
I completely disagree. You can build (or simply update) a box now at little cost which can provide this capability. If you don't believe me just ask all the people already doing it in software who didn't rely on something like the eHD!
I see the problems regarding the EHD from reel.
Me too, and one of the biggest of them being that it's already been EOL'ed!
Micronas doesn't develop afaik this stuff any more and paying allmost 200 EUR for a decoder card hmm ???????
For $200, I'd rather upgrade my cpu or video card and have money left in my pocket!
My favourite solution will be decoding h264 with a strong gpu. Maybe vdpau?
Yes! VDPAU has been giving people great results putting the cpu requirements very low! And the best thing is you can get a VDPAU'able card for cheap! In my opinion this solution is perfect for people who want HDTV at a cheap price and aren't ready to ditch their old crappy cpu.
On Mon, Dec 8, 2008 at 11:57 AM, Halim Sahin halim.sahin@t-online.de wrote:
It makes no sense to me supporting something which can't be used with hdtv stuff in one year!
HDMI isn't going anywhere any time soon. Neither is h264, or anything else so can you give us some examples of things you think won't be usable with HDTV in a year?
btw - Using HDMI Audio/Video On Linux http://www.phoronix.com/scan.php?page=article&item=linux_hdmi&num=1
Goga
BTW. Softdevice/play, vdr-xine and xineliboutput are able to play youtube divx etc.
Is there btw any vdr-plugin for browsing you tupe content (like most watched, movie trailers, etc...) and playing them.
Another nice plugin would be a something where you could select some of your recordings and then say that "compress these to divx or dirac with these resolutions (Some recordings I would propably want to produce with 1 shot for original size , N810 screen size and 320x200 ipaq screen size.
Mika
Hi, search for webvideo plugin. It works for me!
On Di, Dez 09, 2008 at 01:04:58 +0200, Mika Laitio wrote:
BTW. Softdevice/play, vdr-xine and xineliboutput are able to play youtube divx etc.
Is there btw any vdr-plugin for browsing you tupe content (like most watched, movie trailers, etc...) and playing them.
Another nice plugin would be a something where you could select some of your recordings and then say that "compress these to divx or dirac with these resolutions (Some recordings I would propably want to produce with 1 shot for original size , N810 screen size and 320x200 ipaq screen size.
Mika
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Halim Sahin E-Mail: halim.sahin (at) t-online.de
Halim Sahin wrote:
You can buy a lcd tv and after two years you can't use it's hdmi connectiorr of hdmi revision 599,95.0
hd ready->full-hd/hdmi1.1, 1.2 1.3 ..... I read something about limitations of current hdmi standard so we will maybe we get displayport as new solution???
This has (almost) nothing to do with software. HDMI's are backward compatible so you should always get at least some size of picture and basic PCM sound.
Hi,
I'm pretty sure there are quite a few systems out there using FF DVB cards. I wonder why you are constantly arguing against them ;-)
I own an FF card for two reasons only: It offers better video quality on a CRT TV and vdr (1.6) prefers it.
There are a few things to dislike about FF cards these days. To mention just a few:
- expensive - big! (a smaller vdr box would be nice) - problems with QAM 256 - bandwidth problems (see Full TS Mod)
Not too long from now, I want to replace the CRT TV and with it, one of my two reasons to use a FF card will be gone.
So yeah, it'd be nice to see vdr moving away from FF cards or specialized hardware such as the eHD.
A generic (modern) graphics card should be enough and it should be easier to setup for vdr.
Thanks,
Hanno
On 09.12.2008 17:22, Hanno Zulla wrote:
Hi,
I'm pretty sure there are quite a few systems out there using FF DVB cards. I wonder why you are constantly arguing against them ;-)
I own an FF card for two reasons only: It offers better video quality on a CRT TV and vdr (1.6) prefers it.
There are a few things to dislike about FF cards these days. To mention just a few:
- expensive
- big! (a smaller vdr box would be nice)
- problems with QAM 256
- bandwidth problems (see Full TS Mod)
Not too long from now, I want to replace the CRT TV and with it, one of my two reasons to use a FF card will be gone.
So yeah, it'd be nice to see vdr moving away from FF cards or specialized hardware such as the eHD.
A generic (modern) graphics card should be enough and it should be easier to setup for vdr.
Why don't you just use such a graphics card then? Of course you'll need a plugin that implements a proper cDevice for it, but that has nothing to do with VDR itself...
I'll probably move cDvbDevice into a separate plugin in the process of switching to S2API, but that won't by any means mean that VDR "moves away from FF cards". You can already use any output device you like, provided there's a plugin for it.
Klaus
2008/12/9 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de
On 09.12.2008 17:22, Hanno Zulla wrote:
Hi,
I'm pretty sure there are quite a few systems out there using FF DVB cards. I wonder why you are constantly arguing against them ;-)
I own an FF card for two reasons only: It offers better video quality on a CRT TV and vdr (1.6) prefers it.
There are a few things to dislike about FF cards these days. To mention just a few:
- expensive
- big! (a smaller vdr box would be nice)
- problems with QAM 256
- bandwidth problems (see Full TS Mod)
Not too long from now, I want to replace the CRT TV and with it, one of my two reasons to use a FF card will be gone.
So yeah, it'd be nice to see vdr moving away from FF cards or specialized hardware such as the eHD.
A generic (modern) graphics card should be enough and it should be easier to setup for vdr.
Why don't you just use such a graphics card then? Of course you'll need a plugin that implements a proper cDevice for it, but that has nothing to do with VDR itself...
I'll probably move cDvbDevice into a separate plugin in the process of switching to S2API, but that won't by any means mean that VDR "moves away from FF cards". You can already use any output device you like, provided there's a plugin for it.
Of couse you can, either with xineliboutput, xine-vdr or softdevice. But the disadvantages are clear: Modern GPUs support more than the OSD provided by VDR (even older gpus do that). So none of these Output-Plugins will face the real problem: The OSD is (mostly) limited to work with FF cards. Many problems occour if you plaing a .avi file with xineliboutput, which has a lower res than the TV - the OSD gets stretched and is nearly unreadable. But thats only one of the problems with the OSD - its OK for TV, but it could be mutch better.
Many concepts of todays Media Centers are just nice. Name it: XMBC, Elisa, WMC, AppleTV; Some proof-of-concepts as Entertainer (clutter + python), Gloss (clutter mythtv frontend), kaffeine-gl (very experimental in kde4 branch). Not only the effects are nice, also the concepts of using it (xmbc has support for wiimote and such devices) etc.
But when it comes to TV Watching and Recording and so on, there is NO better solotion than the VDR. And this is really your fault ;-) (and the vdr-community)
Even if you don't like such interfaces, they are the future. I think VDR should be modular enough to implement such a Frontend/Output (is it a OSD?). AFAIK this is not possible in the current state.
Just my opinion.
Karl
Karl Glatz wrote:
But the disadvantages are clear: Modern GPUs support more than the OSD provided by VDR (even older gpus do that). So none of these Output-Plugins will face the real problem: The OSD is (mostly) limited to work with FF cards.
[...]
Even if you don't like such interfaces, they are the future. I think VDR should be modular enough to implement such a Frontend/Output (is it a OSD?). AFAIK this is not possible in the current state.
The VDR 1.7.x development line has already seen some deep limitations of VDR going away, or will soon. And even more groundbreaking changes are already on the agenda. Together with HD devices, the SD limited OSD structures will surely have to change too. So just be patient, there's lots of change ahead, but: Important things first!
Cheers,
Udo
Karl Glatz a écrit :
Of couse you can, either with xineliboutput, xine-vdr or softdevice. But the disadvantages are clear: Modern GPUs support more than the OSD provided by VDR (even older gpus do that). So none of these Output-Plugins will face the real problem: The OSD is (mostly) limited to work with FF cards. Many problems occour if you plaing a .avi file with xineliboutput, which has a lower res than the TV - the OSD gets stretched and is nearly unreadable. But thats only one of the problems with the OSD - its OK for TV, but it could be mutch better.
Softdevice can already do a clean transparent OSD, independent of the video resolution, using hardware blending. Xineliboutput too. The dirty software transparency is an output problem (specially a Xine architecture problem). OSD is really clean on a cheap CLE266.
I think the only OSD limitations in the core VDR are : * size of the OSD : pixel width/height * a single OSD per VDR instance I specially like the way the OSD is treated : an overlay over the live video. VDR limitations will go away with current improvements. OSD on recent graphic cards will also improve as hardware video decoding is implemented at the driver level. For instance, the HUD OSD display in xineliboutput requires a compositing window manager, really new hardware, X, etc. etc. This is absurdly complex, when you know that DirectFB can do that since many years on really cheap hardware, with much less code. Xine's XXMC can also do that for free.
KISS has always been VDR moto. I'm waiting for the rest of the display chain to downgrade to the same level of simplicity, then I'll switch to HD. BTW : I never owner a FF card, and I'm perfectly happy with it. Hardware decoding wih a software device plugin has always been OK for me (say, since 2004).
Hi,
Why don't you just use such a graphics card then?
You're right. After my previous message in this thread, I updated my vdr box yesterday, only to find FF output not working properly (once again). [*]
Now I'm considering the built-in graphics card as an alternative output, hoping that it works better.
Regards,
Hanno
[*] Right now, another strange behaviour: http://www.linuxtv.org/pipermail/vdr/2008-December/018750.html
Hi,
vdr@helmutauer.de schrieb:
FF seems to have understandably gone the way of the dinosaur.
But the dinosaur is still the best choice to get the best picture quality on a PAL CRT TV !
But for anybody who wants to use a beamer these FF-cards are full pain with there stupid outputs. I (and many others) want DVI/HDMI/Display-Port.
FF will die in a years or two (months?) i guess and vdr has no well integrated outputs.
Struggling with xineouput or xineplugin or softdevice is a real pain. Same for direct AC3 output on SPDIF.
Some other question:
Is there any movement to files >2GB for the recordings?
VDR-fan, because anything else is even more hassle.
On 08.12.2008 10:49, Holger Rusch wrote:
Hi,
vdr@helmutauer.de schrieb:
FF seems to have understandably gone the way of the dinosaur.
But the dinosaur is still the best choice to get the best picture quality on a PAL CRT TV !
But for anybody who wants to use a beamer these FF-cards are full pain with there stupid outputs. I (and many others) want DVI/HDMI/Display-Port.
FF will die in a years or two (months?) i guess and vdr has no well integrated outputs.
Is there anything in the VDR plugin API that would prevent a plugin from implementing a suitable output device?
Struggling with xineouput or xineplugin or softdevice is a real pain. Same for direct AC3 output on SPDIF.
Some other question:
Is there any movement to files >2GB for the recordings?
I will most likely change this when going to TS recording format. In doing so, I'd like to get rid of splitting recordings into separate files altogether. However, I think there might be people who still want this feature - any comments?
I won't go for full 64 bit file sizes, though, because I'd like the index records to still fit into 8 byte. Using 6 byte for the file index would result in 256 TB for a single recording (or 128 TB if we avoid 'unsigned'), which I guess should be large enough ;-)
Klaus
Hi,
On Mon, Dec 08, 2008 at 11:03:45AM +0100, Klaus Schmidinger wrote:
On 08.12.2008 10:49, Holger Rusch wrote:
Hi,
vdr@helmutauer.de schrieb:
FF seems to have understandably gone the way of the dinosaur.
But the dinosaur is still the best choice to get the best picture quality on a PAL CRT TV !
But for anybody who wants to use a beamer these FF-cards are full pain with there stupid outputs. I (and many others) want DVI/HDMI/Display-Port.
FF will die in a years or two (months?) i guess and vdr has no well integrated outputs.
Is there anything in the VDR plugin API that would prevent a plugin from implementing a suitable output device?
Struggling with xineouput or xineplugin or softdevice is a real pain. Same for direct AC3 output on SPDIF.
Some other question:
Is there any movement to files >2GB for the recordings?
I will most likely change this when going to TS recording format. In doing so, I'd like to get rid of splitting recordings into separate files altogether. However, I think there might be people who still want this feature - any comments?
I prefer having one single file, as I don't see any need to spit it up.
What happends if VDR restarts, or when the computer gets restarted? Will it continue writing to the existing file, or will it create a new one?
Regards, Artem
On 08.12.2008 11:13, Artem Makhutov wrote:
Hi,
On Mon, Dec 08, 2008 at 11:03:45AM +0100, Klaus Schmidinger wrote:
On 08.12.2008 10:49, Holger Rusch wrote:
Hi,
vdr@helmutauer.de schrieb:
FF seems to have understandably gone the way of the dinosaur.
But the dinosaur is still the best choice to get the best picture quality on a PAL CRT TV !
But for anybody who wants to use a beamer these FF-cards are full pain with there stupid outputs. I (and many others) want DVI/HDMI/Display-Port.
FF will die in a years or two (months?) i guess and vdr has no well integrated outputs.
Is there anything in the VDR plugin API that would prevent a plugin from implementing a suitable output device?
Struggling with xineouput or xineplugin or softdevice is a real pain. Same for direct AC3 output on SPDIF.
Some other question:
Is there any movement to files >2GB for the recordings?
I will most likely change this when going to TS recording format. In doing so, I'd like to get rid of splitting recordings into separate files altogether. However, I think there might be people who still want this feature - any comments?
I prefer having one single file, as I don't see any need to spit it up.
What happends if VDR restarts, or when the computer gets restarted? Will it continue writing to the existing file, or will it create a new one?
Currently it creates a new one, but I guess this should be changed to continue an existing file (if the file size limit hasn't been exceeded, yet). If file splitting is removed, then it would of course continue the (one and only) existing file.
Klaus
On 08/12/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Currently it creates a new one, but I guess this should be changed to continue an existing file (if the file size limit hasn't been exceeded, yet). If file splitting is removed, then it would of course continue the (one and only) existing file.
I prefer 2GB files, which fits on FAT32 partitions, usually associated with USB removable drives. I guess one can then just increase the file size before it creates a new file?
Klaus
Hi,
On Mon, Dec 08, 2008 at 12:19:24PM +0200, Theunis Potgieter wrote:
On 08/12/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Currently it creates a new one, but I guess this should be changed to continue an existing file (if the file size limit hasn't been exceeded, yet). If file splitting is removed, then it would of course continue the (one and only) existing file.
I prefer 2GB files, which fits on FAT32 partitions, usually associated with USB removable drives. I guess one can then just increase the file size before it creates a new file?
FAT32 can handle up to 4GB files.
I think it would be nice to have a user setting for it. So if you set split at 1TB, there will be just one big file and others can set it to 4GB - 1Byte to fit on the usb flash.
Regards, Artem
Hi,
Klaus Schmidinger schrieb:
FF will die in a years or two (months?) i guess and vdr has no well integrated outputs.
Is there anything in the VDR plugin API that would prevent a plugin from implementing a suitable output device?
I guess not, but there are (from my view as user with knowladge how to compile and to fix compile-dependancies) it is (as i told) a real pain to get the things going.
And yes this is not a problem of vdr.
The level to get everything going is high. ac3directout, softdevice, ffmpeg, xv-xserver, ... On the other side you pick an evil-windows system, and the output of the media data simple and easy.
It is a linux/system and not vdr problem, which does the recording really nice and good!
On Mon, Dec 08, 2008 at 11:03:45AM +0100, Klaus Schmidinger wrote:
Is there any movement to files >2GB for the recordings?
I will most likely change this when going to TS recording format. In doing so, I'd like to get rid of splitting recordings into separate files altogether. However, I think there might be people who still want this feature - any comments?
I definately want it! I use the hardlink cutter patch because otherwise cutting is really slow because of the copy involved. Going to HD it might even get worse if one movie is e.g. 10gb large and to cut out the commercials 9gb have to be copied. With hardlink cutter I use 100MB file sizes and cutting is almost instant because only the files with the cut are copied/cutted. All the other files remain untouched!
Best regards,
Jogi
Jochen Heuer a écrit :
On Mon, Dec 08, 2008 at 11:03:45AM +0100, Klaus Schmidinger wrote:
Is there any movement to files >2GB for the recordings?
I will most likely change this when going to TS recording format. In doing so, I'd like to get rid of splitting recordings into separate files altogether. However, I think there might be people who still want this feature - any comments?
I definately want it! I use the hardlink cutter patch because otherwise cutting is really slow because of the copy involved. Going to HD it might even get worse if one movie is e.g. 10gb large and to cut out the commercials 9gb have to be copied. With hardlink cutter I use 100MB file sizes and cutting is almost instant because only the files with the cut are copied/cutted. All the other files remain untouched!
I was about to bring this very same reason to keep multiple files. With the increase in recording sizes, it would even be a good thing to add this patch in the VDR core.
On the other hand, with the increase of storage availability, I'd be satisfied with just leaving the file(s) uncut, and add in the core the possibility to watch a recording continuously by skipping the cut marks (I think there is a patch or plugin for this).
On Mon, Dec 8, 2008 at 12:03 PM, Klaus Schmidinger < Klaus.Schmidinger@cadsoft.de> wrote:
Is there any movement to files >2GB for the recordings?
I will most likely change this when going to TS recording format. In doing so, I'd like to get rid of splitting recordings into separate files altogether. However, I think there might be people who still want this feature - any comments?
Larger files - more possibilities the whole recording will be corrupted. Small parts will allow to recover at least some parts of it. It will also create more fragmentation in the file system.
Klaus, I've asked about the size of recording in TS format that you probably missed (or ignored :)). Will there be more overhead compared to currently recorded format?
As far as I know TS might contain several streams of a transponder. Will VDR strip other channels from the stream and record only needed data?
Thanks.
On 08.12.2008 16:34, Alex Betis wrote:
... Klaus, I've asked about the size of recording in TS format that you probably missed (or ignored :)). Will there be more overhead compared to currently recorded format?
There may be a small overhead, but with today's huge disks this should be negligable.
As far as I know TS might contain several streams of a transponder. Will VDR strip other channels from the stream and record only needed data?
It will record the same PIDs as now, only what belongs to the recorded programme.
Klaus
Just some small comments..
I don't think I argue against FF (btw, my main vdr box has two Nexus-s in it), more along the lines of argue for other/better options of the current times. Sure, FF was a great choice for it's day but that day has moved on in my opinion. Maybe it was never intended that VDR become a real media center but clearly there's a big need for it more & more every day. I would take it as a compliment that people's first choice is that VDR becomes an up-to-date solution for tv/media!
As I understand it, there will be at some point a new FF but the price will be out-of-reach for the average user. When the option becomes spend money on a single FF card you can use with an old piece of junk pc, or spend the same money on an updated pc with far more capability then the solution is clear... For my money anyways.
Believe me, a lot of people were happy to hear that VDR was _finally_ going to support things like hdtv/h264, mpeg-ts recordings, etc. because it means there's light at the end of the tunnel and we might not be forced away from VDR afterall. Even if the wait has been painfully slow. I'm sure all of us would prefer VDR to have a bright future instead of already be past it's prime.
In a way the whole thing of bringing VDR to current/future needs reminds me of my grandmother.. She's a writer and insisted on using an old crappy word processor. She turned her nose at the idea of replacing it with a computer even if it was a far more capable option. Eventually she was convinced to give the computer a try and has since never looked back.
Ok, carry on. ;)
Klaus Schmidinger wrote:
Is there any movement to files >2GB for the recordings?
I will most likely change this when going to TS recording format. In doing so, I'd like to get rid of splitting recordings into separate files altogether. However, I think there might be people who still want this feature - any comments?
Pretty much said already: I really don't want to miss hard link cutter any more, and I frequently use my (FAT32) USB-HDD as portable recording media. I've even considered offering the hard link cutter for VDR integration once the TS recording has settled. Going beyond 2TB however is a good idea in any case.
I won't go for full 64 bit file sizes, though, because I'd like the index records to still fit into 8 byte. Using 6 byte for the file index would result in 256 TB for a single recording (or 128 TB if we avoid 'unsigned'), which I guess should be large enough ;-)
I would prefer going the other direction, having more than 255.vdr files. Well, 8 bytes should be enough for everyone. ;)
While we're at doing incompatible changes to the recording format:
Two things bug me about the folder structure. First, the two-level directory structure. A single level makes IMHO more sense, and reduces the number of folders to scan by half: /video/folder/recordingname.YYYY-MM-DD.HH.MM.PP.LL.rec/ -or- /video/folder/YYYY-MM-DD.HH.MM.PP.LL.recordingname.rec/
Sure, the old way groups recordings of same name, but only if no episode title is used. And things get really confusing if a recording and a folder share the name. And if two recordings share a name, its a lot easier to rename just one of them.
Second: Priority and Lifetime of a recording IMHO don't belong to the name part. This could easily fit into the info.vdr file instead. Or does it make sense to have the same recording with different lifetime or priority in separate folders?
Well, just some of my thoughts. In the end, it has worked well in the past too...
Cheers,
Udo
Udo Richter wrote:
Second: Priority and Lifetime of a recording IMHO don't belong to the name part. This could easily fit into the info.vdr file instead. Or does it make sense to have the same recording with different lifetime or priority in separate folders?
No and it actually causes problems; when you edit a currently active timer and eg lower the prio, the recording continues, but the next time it's restarted it is treated as a different one. Also, should vdr decide to do an emergency restart for whatever reason you end up with two recordings instead of one.
artur
But for anybody who wants to use a beamer these FF-cards are full pain with there stupid outputs. I (and many others) want DVI/HDMI/Display-Port.
And I want beamer that has a network card and can download and show the content downloaded from vdr server. I don't know whether they could connect to streamdev-server or xineliboutput server plugins.
Struggling with xineouput or xineplugin or softdevice is a real pain. Same for direct AC3 output on SPDIF.
I btw. played in this evening with N810 and checked whether the device was powerful enough for connecting to VDR and showing tv. It was as the compination of streamdev server on vdr and mplayer on N810 worked really well over wlan with following command on N810.
mplayer http://<my-vdr-server>:3000/PES/<channel-number>
With vdr-xine I was not yet as lucky, I build the xine-libs and vdr-sxfe with scratchbox but sofar at least Xv or xshm video outputs failed to work. I will need to investigate this furher...
Mika
FF seems to have understandably gone the way of the dinosaur.
It has been true for the older FF cards, but there might be a possible new generation/revolution of FF cards, though it was originally considered expensive sometime back.
Other than for the FF cards, there are cards (not in retail yet, prototypes right now) which can do Bi-directional DMA to the card for descrambling of the recorded TS using the CAM. Don't know how soon these cards with Bi-directional DMA similar to the Ethernet cards would appear and even if so, might be a while till a driver for the same supports such a feature.
(Right now can't say anything more than this, stated this much, so that: if the development can go in a direction similar to what hardware appears)
For such cards, a TS format (as broadcast) for recording would be more appealing as a starting point if they were to appear.
It might be a bit more time, to know the actual status, but the TS feature might be a still important feature, if that were to happen.
Regards, Manu
On Mon, Dec 8, 2008 at 11:05 AM, Manu Abraham abraham.manu@gmail.com wrote:
It might be a bit more time, to know the actual status, but the TS feature might be a still important feature, if that were to happen.
I am an eHD user and I'm hoping that the TS feature might improve things as currently I can't watch BBCHD with my eHD because of problems with the way they are broadcasting the PES ID for the AC3 stream. Also, there is a problem when there is a slight breakup in the stream - the picture is unwatchable till changing the channel. Apparently TS will address this. Reel's own implementation of VDR already used TS and they say it is fixed in there, but it is not currently fixed in the vanilla version of VDR.
Also, I'm hoping it might improve areas such as seeking and fast forward/rewind which is currently poor using the eHD - there is bad lag and it is not sensitive enough for pressing forward/back/play etc.
Any idea when TS will be implemented? Its been talked about for a long time now... :-(
В сообщении от 6 December 2008 17:06:40 Klaus Schmidinger написал(а):
The attached patch is what I've gathered from various postings regarding adapting VDR to the S2API driver API (thanks to Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't provide a way of determining whether a DVB-S device supports DVB-S2 (at least I didn't find any), you need to apply the second attached patch to the driver in order to impelement a new capability flag that reports the availability of DVB-S2 support.
If you don't want to patch the driver, you can change the line
case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
So far DVB-S and DVB-S2 appears to tune fine. DVB-C is completely untested. With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card does work with the S2API driver under VDR 1.6.0.
So for the moment I would appreciate if people could test DVB-T tuning and check whether maybe I made some silly mistake in the DVB-T tuning code.
Klaus
Thank You for VDR. I really enjoy it.
Приветствую, Klaus
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
The attached patch is what I've gathered from various postings regarding adapting VDR to the S2API driver API (thanks to Igor M. Liplianin, Niels Wagenaar and Edgar Hucek - did I forget anybody?).
Since the S2SAPI doesn't provide a way of determining whether a DVB-S device supports DVB-S2 (at least I didn't find any), you need to apply the second attached patch to the driver in order to impelement a new capability flag that reports the availability of DVB-S2 support.
If you don't want to patch the driver, you can change the line
case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break;
in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
So far DVB-S and DVB-S2 appears to tune fine. DVB-C is completely untested. With DVB-T tuning doesn't work, even though my TDA10046H based DVB-T card does work with the S2API driver under VDR 1.6.0.
So for the moment I would appreciate if people could test DVB-T tuning and check whether maybe I made some silly mistake in the DVB-T tuning code.
On 06.12.2008 17:55, Goga777 wrote:
ðÒÉ×ÅÔÓÔ×ÕÀ, Klaus
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff patching file channels.c Hunk #6 succeeded at 636 (offset -1 lines). Hunk #7 succeeded at 643 (offset -1 lines). Hunk #8 succeeded at 665 (offset -1 lines). Hunk #9 succeeded at 685 (offset -1 lines). patching file channels.h Hunk #2 succeeded at 146 (offset -1 lines). Hunk #3 succeeded at 203 (offset -2 lines). Hunk #4 succeeded at 215 (offset -2 lines). patching file dvbdevice.c Hunk #7 FAILED at 265. Hunk #8 FAILED at 323. Hunk #9 succeeded at 407 (offset 11 lines). Hunk #10 succeeded at 430 (offset 11 lines). Hunk #11 succeeded at 493 (offset 11 lines). Hunk #12 succeeded at 831 (offset 11 lines). 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej patching file dvbdevice.h patching file menu.c patching file nit.c
Doesn't look too bad. You'll have to manually apply the failed hunks, though. Whether it will actually work, I have no idea...
Klaus
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff patching file channels.c Hunk #6 succeeded at 636 (offset -1 lines). Hunk #7 succeeded at 643 (offset -1 lines). Hunk #8 succeeded at 665 (offset -1 lines). Hunk #9 succeeded at 685 (offset -1 lines). patching file channels.h Hunk #2 succeeded at 146 (offset -1 lines). Hunk #3 succeeded at 203 (offset -2 lines). Hunk #4 succeeded at 215 (offset -2 lines). patching file dvbdevice.c Hunk #7 FAILED at 265. Hunk #8 FAILED at 323. Hunk #9 succeeded at 407 (offset 11 lines). Hunk #10 succeeded at 430 (offset 11 lines). Hunk #11 succeeded at 493 (offset 11 lines). Hunk #12 succeeded at 831 (offset 11 lines). 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej patching file dvbdevice.h patching file menu.c patching file nit.c
Doesn't look too bad. You'll have to manually apply the failed hunks, though. Whether it will actually work, I have no idea...
btw - which patch are you using for h264 channels on your vdr 171 ?
Goga
On 06.12.2008 18:16, Goga777 wrote:
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
kls@hawk:/home/kls/vdr/vdr-1.7.0 > patch --dry-run < ../VDR/vdr-1.7.1-s2api.diff patching file channels.c Hunk #6 succeeded at 636 (offset -1 lines). Hunk #7 succeeded at 643 (offset -1 lines). Hunk #8 succeeded at 665 (offset -1 lines). Hunk #9 succeeded at 685 (offset -1 lines). patching file channels.h Hunk #2 succeeded at 146 (offset -1 lines). Hunk #3 succeeded at 203 (offset -2 lines). Hunk #4 succeeded at 215 (offset -2 lines). patching file dvbdevice.c Hunk #7 FAILED at 265. Hunk #8 FAILED at 323. Hunk #9 succeeded at 407 (offset 11 lines). Hunk #10 succeeded at 430 (offset 11 lines). Hunk #11 succeeded at 493 (offset 11 lines). Hunk #12 succeeded at 831 (offset 11 lines). 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej patching file dvbdevice.h patching file menu.c patching file nit.c
Doesn't look too bad. You'll have to manually apply the failed hunks, though. Whether it will actually work, I have no idea...
btw - which patch are you using for h264 channels on your vdr 171 ?
I haven't gotten that far, yet. So far I only watch "normal" MPEG channels.
Klaus
Приветствую, Goga777
Приветствую, Klaus
does your vdr-1.7.1-s2api.diff good for vdr 1.7.0 ?
ah, no
/vdr170# patch -p1 < vdr-1.7.1-s2api_from_Klaus.diff
patching file channels.c Hunk #6 succeeded at 636 (offset -1 lines). Hunk #7 succeeded at 643 (offset -1 lines). Hunk #8 succeeded at 665 (offset -1 lines). Hunk #9 succeeded at 685 (offset -1 lines). patching file channels.h Hunk #2 succeeded at 146 (offset -1 lines). Hunk #3 succeeded at 203 (offset -2 lines). Hunk #4 succeeded at 215 (offset -2 lines). patching file dvbdevice.c Hunk #7 FAILED at 265. Hunk #8 FAILED at 323. Hunk #9 succeeded at 407 (offset 11 lines). Hunk #10 succeeded at 430 (offset 11 lines). Hunk #11 succeeded at 493 (offset 11 lines). Hunk #12 succeeded at 831 (offset 11 lines). 2 out of 12 hunks FAILED -- saving rejects to file dvbdevice.c.rej patching file dvbdevice.h patching file menu.c patching file nit.c
On Sat, 6 Dec 2008, Klaus Schmidinger wrote:
If you don't want to patch the driver, you can change the line case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
Howabout just adding a FE_CAN_2ND_GEN_MODULATION define as a temporary workaroung into dvbdevice.c? It shouldn't interfere with the frontend capability enumeration and you'd have to patch only if you happen to have DVB-S2 hardware. I'm just guessing, but only a small minority of VDR users are having S2 capable hardware nowadays...
+ #define FE_CAN_2ND_GEN_MODULATION 0x10000000
BR, -- rofa
On 07.12.2008 00:34, Rolf Ahrenberg wrote:
On Sat, 6 Dec 2008, Klaus Schmidinger wrote:
If you don't want to patch the driver, you can change the line case FE_QPSK: frontendType = (frontendInfo.caps & FE_CAN_2ND_GEN_MODULATION) ? SYS_DVBS2 : SYS_DVBS; break; in dvbdevice.c to avoid FE_CAN_2ND_GEN_MODULATION. Either set frontendType permanently to SYS_DVBS or SYS_DVBS2, depending on what you have.
Howabout just adding a FE_CAN_2ND_GEN_MODULATION define as a temporary workaroung into dvbdevice.c? It shouldn't interfere with the frontend capability enumeration and you'd have to patch only if you happen to have DVB-S2 hardware. I'm just guessing, but only a small minority of VDR users are having S2 capable hardware nowadays...
- #define FE_CAN_2ND_GEN_MODULATION 0x10000000
Sure, no problem.
Klaus
-
Alex Betis -
Artem Makhutov -
Artur Skawina -
gimli -
Goga777 -
Halim Sahin -
Hanno Zulla -
Holger Rusch -
Igor M. Liplianin -
Jochen Heuer -
Jose Alberto Reguero -
Jörg Knitter -
Karl Glatz -
Klaus Schmidinger -
Manu Abraham -
Mika Laitio -
Morfsta -
Nicolas Huillard -
Oleg Roitburd -
Pertti Kosunen -
Rolf Ahrenberg -
Theunis Potgieter -
Udo Richter -
VDR User -
vdr＠helmutauer.de