dvbd

dvbd

[Kjeld Flarup]

Hi

I've taken some interest in a small piece of software called dvbd. 
http://dvbd.sourceforge.net/
I really like the concept of this software, because it could be used for 
sharing one DVB card among several different applications.

BUT the software have not been developed since 2004.
Is this because it is not so smart anyway, or are there some better 
programs out there?

-- 
-------------------- Med Liberalistiske Hilsner ----------------------
  Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
  Forssavej 49, 7600 Struer, Tlf: 40 29 41 49
  Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

Re: dvbd

[Michael Riepe]

Hi!

Kjeld Flarup wrote:

> I've taken some interest in a small piece of software called dvbd.
> http://dvbd.sourceforge.net/
> I really like the concept of this software, because it could be used for
> sharing one DVB card among several different applications.

That's right.

> BUT the software have not been developed since 2004.

And it needs a few tweaks when you're using a more recent C++ compiler
like gcc 4.3.x.

> Is this because it is not so smart anyway, or are there some better
> programs out there?

There is VDR, of course. But I don't like the way it does things.
Therefore, I've been using dvbd for years to handle my small zoo of
DVB-T receivers (I've got four of them running at the moment). It easily
handles several recordings in parallel without using many resources - a
few megabytes of RAM and a few percent of CPU time on an old (2005)
Athlon64. I currently consider moving it to an Intel Atom based system.

dvbd does sometimes have issues with disk writes, though. It doesn't do
much buffering, and if another process is blocking the disk it's writing
to for too long, you may encounter drop-outs. It's best to give it a
disk of its own. Similarly, if dvbd doesn't get scheduled for a while,
it will lose data from the receivers. On a single-core machine that also
does other things (like mine), I recommend to raise its priority with
nice --20, or maybe use a realtime priority level.

-- 
Michael "Tired" Riepe <michael.riepe@googlemail.com>
X-Tired: Each morning I get up I die a little

Re: dvbd

[Kjeld Flarup]

Hi Michael

Thanks for your reply. Tweaking the scheduling is ususally easy to fix. 
I might want to look at the buffering too. It ought to be a system thing.
I never got VDR working properly, and currently I use mplayer/mencoder 
to record.

But one thing which I would like to do is to use dvbd together with VLC, 
because VLC can handle the DVB subtitles used in Denmark. But VLC does 
not seem to like connecting to the dvbd socket. If anyone have success 
with that, I sure would like to know.

Also at some time soon I would need to stream some DVB signals. But I do 
not like the way this is done by most tools, they seems to be using up 
CPU cycles even if nobody is listening.

  Regards Kjeld

Michael Riepe wrote:
> Hi!
>
> Kjeld Flarup wrote:
>
>   
>> I've taken some interest in a small piece of software called dvbd.
>> http://dvbd.sourceforge.net/
>> I really like the concept of this software, because it could be used for
>> sharing one DVB card among several different applications.
>>     
>
> That's right.
>
>   
>> BUT the software have not been developed since 2004.
>>     
>
> And it needs a few tweaks when you're using a more recent C++ compiler
> like gcc 4.3.x.
>
>   
>> Is this because it is not so smart anyway, or are there some better
>> programs out there?
>>     
>
> There is VDR, of course. But I don't like the way it does things.
> Therefore, I've been using dvbd for years to handle my small zoo of
> DVB-T receivers (I've got four of them running at the moment). It easily
> handles several recordings in parallel without using many resources - a
> few megabytes of RAM and a few percent of CPU time on an old (2005)
> Athlon64. I currently consider moving it to an Intel Atom based system.
>
> dvbd does sometimes have issues with disk writes, though. It doesn't do
> much buffering, and if another process is blocking the disk it's writing
> to for too long, you may encounter drop-outs. It's best to give it a
> disk of its own. Similarly, if dvbd doesn't get scheduled for a while,
> it will lose data from the receivers. On a single-core machine that also
> does other things (like mine), I recommend to raise its priority with
> nice --20, or maybe use a realtime priority level.
>
>   


-- 
-------------------- Med Liberalistiske Hilsner ----------------------
  Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
  Forssavej 49, 7600 Struer, Tlf: 40 29 41 49
  Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

Re: dvbd

[Michael Riepe]

Hi Kjeld,

> But one thing which I would like to do is to use dvbd together with VLC,
> because VLC can handle the DVB subtitles used in Denmark. But VLC does
> not seem to like connecting to the dvbd socket. If anyone have success
> with that, I sure would like to know.

you can access a particular stream with dvbcat and pipe it into a media
player (xine works fine). I usually do it differently, though: write the
stream to disk and let the player read the file. That way you also get
time shifting (which doesn't work when you use a pipe). And if you use a
low priority for live viewing, scheduled recordings will take precedence.

Writing a plug-in based on dvbcat would be another option. That might
also allow you to switch channels on the fly (if the other channel is
accessible, that is - one of the reasons why I use multiple receivers).

> Also at some time soon I would need to stream some DVB signals. But I do
> not like the way this is done by most tools, they seems to be using up
> CPU cycles even if nobody is listening.

If they use UDP multicast (the standard way of media streaming), they
never know who's listening.

-- 
Michael "Tired" Riepe <michael.riepe@googlemail.com>
X-Tired: Each morning I get up I die a little