VDR requires an output device to start.
But as already pointed out this doesn't necessarily have to be real
hardware but could also be a plugin.
However, instead of using (and recommending) such a heavy-scale (from
dependency and complexity perspective) plugin like xineliboutput, how
about th
When using vdr in non-deamon mode with "--edit" to just cut a recording
it seems the videodir is being ignored and the output will be stored
along the original path (of course with a % in front of the name).
Is this behaviour intentional or a bug/missing feature?
If its intentional I would sug
Am 13.11.2010 11:23, schrieb Klaus Schmidinger:
However, my suggestion would be to implement authentication, encryption
and compression as an externel "layer". Much like a proxy, which offers
a secure port to the outside world, and internally connects to the
standard SVDRP interface of VDR. That
Right now when the needs of a vdr extension goes beyond core SVDRP
capabilities a different approach is being used by the each extensions.
Prominent examples are:
- vdradmin (using native SVDRP and suffering from its performance,
optional use of direct file access to epg data)
- live-plugin (in
Am 04.03.2010 23:08, schrieb Klaus Schmidinger:
I like port 2001 - why stir this up and cause turmoil amoung all
those who have been using the default port for so long?
What are services "dc" and "wizard", anyway?
Klaus
I understand that you don't want to touch this, but you are also
regula
Am 04.03.2010 13:00, schrieb Theunis Potgieter:
A lot of changes is required if from end user perspective. Nothing
that can't be fixed in a few minutes.
No change is required from end-user perspective in the end when the
plugins/extensions are adapted to the new port. (In the current vdr-dev
The current SVDRP Port 2001 is being used for several years now, but
unfortunately it has never been registered with IANA.
As such it does not show up in /etc/services and there is no name
resolution for it, i.e. when starting a tcpdump.
While this is not a major issue I'd prefer to register an
Klaus Schmidinger schrieb:
You can take the size of the index file, divide it by 8 and
you get the number of frames in the recording. The info file
tells you the number of frames per second (at least with newer
TS recordings).
I don't think this calculation is always accurate (i.e. for h264/HD
Theunis Potgieter wrote:
I reverted to older version of vdr-xineliboutput (20091013) where the
channel becomes garbage (green blocks) after a while when cropping is
enabled. I also see these green blocks when changing a channel. With
vdpau, when using streamdev-client with a bad wifi connection,
I don't think people would like that.
DRBD has imho a good approach* to track users (and used versions!), but
regardless of the method, this is certainly not on Klaus' priority list.
Best regards,
Christian (#68)
*On first startup (or after upgrades) a unique ID will generated and the
us
That seems to be the right approach, however I doubt that 0x12c is the
right pid.
Maybe you should get a copy of the TS from streamdev (just use wget on
the streamdev url) and then analyze what you can identify there. I think
it should be 0x11 for MPEG4-Audio...
You could also have a look at s
Alex Fazzari wrote:
Thanks Christian. Based on your info I've found the following 2 threads:
http://forum.handbrake.fr/viewtopic.php?f=4&t=5715 - describes which
PID is used for NZ AAC TV
and
http://www.mail-archive.com/vdr@linuxtv.org/msg10575.html - describes
where in the code the PID id ne
My guess would be that since streamdev gives the whole TS to xbmc you
can hear audio as long as xbmc knows how to handle it. When doing
recordings however the PID filtering of vdr will be used and may omit
the (to vdr unknown) audio track.
This is just a shot into the dark but you could verify t
hu_emulator wrote:
> Heres my final errors:
>
> -> add frames
> Audio PTS: first packet 06:58:29.361, last packet 08:42:03.105
> Video PTS: start 1.GOP 06:58:29.768, end last GOP 08:37:00.640
> -> adjusting audio at video-timeline
> -> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 160kbps, noCRC @ 0
Klaus Schmidinger schrieb:
> Well, if they don't broadcast their Vpid in the SI data, how is a
> receiver supposed to know what to receive?
>
> Maybe you should complain to the broadcaster about this.
>
> Klaus
Afaik this is intentional to limit the scope of viewers to users of
their "Freesat"
Hi,
afaik this behaviour is related to PES recordings only, see my bug
report here (it broke sometime last year but worked with the release
version of the A110!):
http://www.popcornforum.de/showthread.php?tid=4143
I couldn't observe this behaviour anymore since using vdr 1.7.4 with
native TS.
> which streamdev version and which patches do you use ?
Plain vanilla vdr and streamdev from cvs (reports as pre-0.5.0).
Input device is a Netceiver (with dvbloop fixes for S2API).
Best regards,
Christian
___
vdr mailing list
vdr@linuxtv.org
htt
> could someone to run the streaming with vdr 174 + streamdev-plugin for
> popcorn
Yes, I do have this combination running. Streaming live-tv breaks after
a couple of minutes (only tested HD), but other than that it works like
a charm (i.e. replaying TS recordings [even while they are being
reinhard.buch...@rw-buchner.de schrieb:
> Hmm, I thought it wasn't possible to have two
> identical channels (even IF soley the name is
> different). Has this changed?
You can have multiple channels with the same name, i.e.:
Das
Erste;ARD:11837:hC34M2O0S0:S19.2E:27500:101=2:102=deu,103=2ch;106=dd
Hi,
I'm also interested in this topic, although I'm looking for a really
*embedded* device:
Some newer LCD TV sets are internally based on Linux (yes right!), some
even using the DVB API (for the internal DVB-T tuner).
I'm currently trying to find out more about the firmware, but I hope it
migh
Morfsta schrieb:
>> have a look at the patch Gregoire provided starting at line 246.
>> You may want to look for "DVBFE_DELSYS_DVBS2" which is what I think
>> you'll need.
>>
>> What version of the HVR4000 patch/driver are you using if not the same
>> as Gregoire? Is it more recent?
>
> I think it
Morfsta schrieb:
[...]
> How do you declare a card DVB-S2 capable? This is the bit I need to
> add to cx24116.c in the current multiproto to make it work with the
> new VDR.
Morfsta,
have a look at the patch Gregoire provided starting at line 246.
You may want to look for "DVBFE_DELSYS_DVBS2" whi
Morfsta schrieb:
>> which addon patch are you using? The h264 autodetection posted on
>> January 20th?
>>
>
> That's correct..
I'm using it without any problems so far (applied on January 21st) and
both recordings and live-view via streamdev are working.
Have you checked the vpids? They shouldn'
Morfsta schrieb:
[...]
> I have just tried the new DVB-S2 patches for VDR-1.5.13 and the
> additional addon.
>
> Now I cannot tune to a DVB-S2 channel and I get a "Channel Not
> Available". H264 on DVB-S works fine.
[...]
Hi Morfsta,
which addon patch are you using? The h264 autodetection po
I guess that's caused by an offset defined in the patch:
vdr-1.5.12-dvbs2-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff:
#define VPID_OFFSET_BASE 1
I don't know what it does or is meant to do, but I also have wrong pids
in my channels.conf
Best regards,
Hi all,
first of all thanks a lot to Klaus Schmidinger for his great work but
also to Manu Abraham, Marco Schlüßler and Reinhard Nissl for taking up
the DVB-S2 challenge!
I have a DVB-S based vdr running as server for recordings and
streamdev-server for remote live-view.
Now I was playing around
26 matches
Mail list logo
