VDR with S2API (update)

  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
>
  

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)
  

> 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 !
  

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.
  

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 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,

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!
  

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
  

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
  

> 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... :-(
  

On 08.12.2008 12:34, Morfsta wrote:
> ...
> Any idea when TS will be implemented? Its been talked about for a long
> time now... :-(

It's pretty much the next thing on my list, once the S2API switch
is done.

Klaus
  

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.  ;)
  

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.
  

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
  

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
  

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
  

> 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
  

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.
  

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
  

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
  

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
  

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
  

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).
  

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?

http://mercurial.intuxication.org/hg/scan-s2/
  

> > 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?
> 
> http://mercurial.intuxication.org/hg/scan-s2/

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?
> 
> http://mercurial.intuxication.org/hg/scan-s2/

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-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.
>
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_t
> delset[]={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?