.
cAudioRepacker suppresses the first syncing message, but occasionally it
needs to resync e. g. when the start code was (incorrectly) found in
the tail of the previous audio frame's sound data.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
vdr: [17881] ERROR: video data stream broken
Just an idea: maybe you should disable cVideoRepacker. See remux.c
#define TEST_cVideoRepacker.
cVideoRepacker can currently only parse MPEG1 and MPEG2 video streams.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
appears before the segfault.
Another idea is to use valgrind on vdr to see whether there are any
memory corruptions in vdr-xine.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org
to try the following settings in vdr-xine's setup menu:
Control xine's volume: No
Muting: Ignore
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
to do just an EPG scan and shutdown afterwards.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
menu 0x008B
I'd suggest to remove remote.conf to have VDR learn your remote again.
Keep in mind to immediately connect xine to VDR to not miss entering the
learning phase on OSD.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
resolution
or overscan mode are either a matter of fbset or some other tool which
might be hardware dependent.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo
trigger
paint
paint
paint
paint
I. e., thread B get's stuck in trigger_drawing() when trying to lock the
mutex.
But I have no idea, why this can happen. Is there anything obvious to
you in the above code, which I didn't take into account?
Thanks in advance.
Bye.
--
Dipl.-Inform. (FH) Reinhard
. This
might explain why reloading the driver cures the problem.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
to tune to. I first need to take a look into the code how
kaffeine and xine-lib pass the information about the port to use to the
DVB driver.
Haven't had a look at this yet.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr
/associated%20docs/update_recomm_for_implim.pdf
I also had a closer look into the specification and into the
implementation guide. There is only one mandatory command for DiSEqC
1.0: the above used 0x38.
Well, good to know :-)
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
for vdr-xine in
cXineDevice::SetPlayMode() for PlayMode being != pmNone).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
be a reason
why the menu is slow when running several recordings at the same time.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Reinhard Nissl wrote:
I'll now add the same output to szap.
See attachment.
While comparing the output of VDR and szap I've discovered a bug in
szap. It didn't set FE_DISEQC_SEND_BURST correctly.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
szap.tar.gz
to be changed to pass the information, that
the receiving device may be blocked, to the places where buffer
overflows are detected.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org
) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
that it doesn't overflow the
buffers any more.
BTW: keep in mind, that video PTS jump back and forth as the images are
broadcast in decoding order while the PTS time stamps describe
presentation order.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
it includes -l 3 (log debug messages) and depending on your
system setup, debug messages might get logged to a different file.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi
VDR replays
a recording and reaches its end.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
while tuning.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.4.5-orig/dvbdevice.c 2006-08-14 11:38:32.0 +0200
+++ dvbdevice.c 2007-02-01 21:38:44.0 +0100
@@ -176,6 +176,13 @@ static unsigned int FrequencyToHz(unsign
return f;
}
+#include sys
.
doesn't my driver or card support diseqc ?
Don't know. But have you tried DiSEqC with VDR (menu Settings - LNB)?
You might get similar messages but on the other hand, it might work ;-)
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
11700 V 9750 v t
S19.2E 9 V 10600 v T
S19.2E 11700 H 9750 V t
S19.2E 9 H 10600 V T
Test D) is identical to disabling DiSEqC in VDR's setup menu.
I assume that either B) or C) will be the shortest sequence that still
works in your case.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
a tuning timeout. If this
is no longer the case, then you may want to experiment with
WAIT_FOR_TUNER_LOCK in device.c.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.4.5-orig/dvbdevice.c 2006-08-14 11:38:32.0 +0200
+++ dvbdevice.c 2007-02-18 12:23:47.0
found a real sync pattern, the indicated frame length will guide
cAudioRepacker precisely to the next audio frame.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin
may reduce the number of packets to
100.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
may reduce the number of packets to
100.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.4.5-orig/remux.c 2006-12-01 15:46:25.0 +0100
+++ remux.c 2007-02-19 21:39:41.0 +0100
@@ -86,6 +86,65 @@ ePesHeader AnalyzePesHeader(const uchar
return
Hi,
Reinhard Nissl wrote:
Please provide me some of these files which were dumped in the middle
of a recording. If size matters, you may reduce the number of packets to
100.
I had a look into the files you've provided me. It looks like some TS
packets get lost. You can simply check
.
Feel free to modify this patch to better simulate real TS packet losses
like bursts of 16 frames.
BE WARNED: *** do not use this patch on a production system ***
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.4.5-orig/remux.c 2006-12-01 15:46:25.0 +0100
Hi,
Dr. Werner Fink wrote:
On Wed, Feb 21, 2007 at 11:12:43PM +0100, Reinhard Nissl wrote:
Actually, I don't know how this is done in the case of a FF card and
what the firmware has to do in this regard. A guess -- which could
explain the issues you see -- would be that sync
to what szap does. The relevant part of
dvbdevice.c looks like that:
while (1) {
if (ioctl(fd_frontend, FE_READ_STATUS, Status) != -1)
return true;
if (errno != EINTR)
break;
}
return false;
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
PES packets needs to be considered too but that's a
little bit too complicated to explain.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
the current approach is the best approach? Does
vdr-1.5.x plan to offer new and improved tuning algos?
I don't know whether Klaus (or maybe somebody else) has already a
concept of how things should be changed.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
reads on the next recording file when replaying the
current recording file enters the disk spinup margin.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman
be achieved via xine's menu.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
this patch is against VDR-1.4.6, it applies with some offset
also against VDR-1.5.1.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.4.6-orig/dvbplayer.c ./dvbplayer.c
--- ../vdr-1.4.6-orig/dvbplayer.c 2006-04-17 14:45:48.0 +0200
+++ ./dvbplayer.c 2007
. cVideoRepacker takes
care that VDR's index file contains valid entries. Before
cVideoRepacker, the index file could address incomplete frames or even
miss some frames.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing
Hi,
Richard Lithvall wrote:
Why not just change the naming of video files to four, five or even
eight digits?
The problem is not the file name, it's the index file. An index entry
stores the file number as uchar, which allows 256 recording files.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
designed to be integrated
into the existing TS/PES remux code at almost no changes (at least no
complex changes). I thought about rewriting the whole chain too but
didn't find time so far respectively didn't have the need to do it.
Thanks for your work in this area.
Bye.
--
Dipl.-Inform. (FH) Reinhard
Hi,
Halim Sahin wrote:
Does vdr leave the transfermode after a recording ends?
I didn't have a look at the sources but I think it only leaves
transfermode when it has to, e. g. to do an EPG scan (this is what
happens on my system).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
the alsa mixer
device to PCM helps.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
the hardware controls at all, right?
Maybe an audio post process plugin could scale all audio samples by a
factor to simulate changing the volume. But I'm sorry, no such plugin
exists at the moment.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
though.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
audio.volume.remember_volume:1
Maybe this gives you some hint of what works here.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
info: openSUSE 10.2, pretty actual vdr drivers from hg server,
vdr 1.46, 2 Hauppauge FF 2.1 dvb-s cards.
Most likely, the DVB drivers are to blame. Do you see any relationship
between updating the drivers and the occurrence of these messages in the
logfiles?
Bye.
--
Dipl.-Inform. (FH) Reinhard
-***) device-***=new c***;
This change is highly recommended if you experience buffer overflows
while switching channels, though they are not related to the sync early
patch.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.4.6-1-orig/device.c ./device.c
time now and it was the first time, that VDR dumped a core
regarding a pure virtual function call. Such a debug output would have
triggered way more early.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.4.6-orig/receiver.c 2006-03-26 16:07:21.0 +0200
::CanHandleAreas()?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Oliver Endriss wrote:
Are there any FTA NTSC transmissions on Astra 19.2°
or Eutelsat 13°? I'd like to do some tests...
Pentagon Channel:11095:hC34:S13.0E:28000:810:800,802,804:0:0:8:6:301:0
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
see what we get later this year.
Also, the multithreaded H.264 decoding sounds promising, as a single
core cannot cope with 1920x1080.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http
a recording, would you please be so kind
and provide me a sample for testing.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.5.2-orig/channels.h ./channels.h
--- ../vdr-1.5.2-orig/channels.h 2007-01-05 11:37:35.0 +0100
+++ ./channels.h 2007-05-06 21
Hi,
Martin Werner wrote:
gives me hope that we finally can see Pro7 and SAT.1 in HDTV .. a long awated
from me!
Well, these two use interlace massively. At the moment, one won't get
even a single frame before crash. The ASTRA demo works though.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
:332=pol;333=ORY:551:100:15423:318:1400:0
On my system, VDR says this channel is encrypted. Do you have the
necessary means to receive this channel?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
hours, so I'd like to know if I can
record the channel before making my mind whether to continue the
subscription ;)
Then you have to hurry now, I won't have much time tomorrow evening.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
Hi,
Reinhard Nissl wrote:
Can you provide me with a few MB of TS stream from that channel?
Something like czap and cat /dev/dvb/adapterX/dvr0 sample.ts should do
the trick.
The TS sample you've sent me looks ok, i. e. it can be parsed by
H264::cParser.
Please locate the following
Hi,
Reinhard Nissl wrote:
The line will write the PES packet's content into file
/video/sample.es.h264 when a h264parser exists. Then please send me some
MB of the file.
The file you've sent me doesn't contain any useful data. You can have a
look at it yourself:
od -Ax -t x1 -v sample2
.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
(const uchar*, int, int, uchar)' without object
make[1]: *** [xineDevice.o] Error 1
Is there any solution?
Use vdr-xine-0.7.11 please.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http
do not get decrypted.
But I don't understand why streamdev still delivers a decrypted video
stream in that case. Can it be that the client asks streamdev to filter
certain TS packets and therefore uses the correct VPID?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
PMT and
does not use VDR channel data. But the VDR-VDR streaming mode probably
does not work if PIDs are not real ones.
Please try the attached patch which adds VPID clipping to some locations.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.9-orig/ci.c 2007
Hi,
Reinhard Nissl wrote:
But I don't understand why streamdev still delivers a decrypted video
stream in that case. Can it be that the client asks streamdev to filter
certain TS packets and therefore uses the correct VPID?
Yes. In http streaming mode streamdev parses PIDs directly from PMT
-1.1.8 I've therefore disabled decoding of
interlaced frames (more or less properly).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
E6300 (1,83GHz) which might not be enough. Do
you have the xine-lib.patch for disabling interlaced frames available
for download somewhere?
The attached patch is also part of the larger xine-lib.patch included in
vdr-xine-0.7.11.tgz.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
Hi,
Reinhard Nissl wrote:
the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
After the above patch, my sync early patch fails to apply. Attached
you'll find an updated version which should apply cleanly.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
.
Astra HD (MPEG2) plays at a total load of about 30 % with xxmc (nVidia
GF6600) on my P4 2.8 GHz HT.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo
Hi,
I'd like interested people to follow this link:
http://www.vdr-portal.de/board/thread.php?postid=654473#post654473
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi
of this
broadcast.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
a short recording (Wetter), which can be used to reproduce the
problem.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
activated when xine
signals a format change (thanks to Detlef Nebermann for the
request).
Enjoy.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
too, but I
didn't
seen any subtitles yet on this chhnnel, only SPID's. Is there any fixed time
when subtitles presents on TV5?
I took a recording of La Crim' on last Monday evening.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
in openSUSE 10.3
seems to be, that it now uses a xcb-based libX11.
Is there some similarity to your system?
Which one of xine's video output drivers do you use?
Have you tried --verbose=2 -V xv and verified from the output, that
video_out_xv is used?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
for
providing sample recordings).
Enjoy.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
repository. Please follow
this guide:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Installationsanleitung_%28Achtung_Beta%29
Although not required, I'd suggest you to use vdr-xine-0.8.0 too (see
other thread about fixes).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
the volume setting, then vdr-xine's internal
value will be 0 and xine's volume will be set to 0, too.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
the attached patch is for VDR-1.4.7.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.4.7-orig/remux.c ./remux.c
--- ../vdr-1.4.7-orig/remux.c 2006-12-01 15:46:25.0 +0100
+++ ./remux.c 2007-10-25 13:22:55.0 +0200
@@ -19,6 +19,7
.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
I'm sorry for the trouble but the patches miss a check, whether
audioIndexer exists when VDR calls cRemux::Clear(). So VDR may segfault
for non radio channels.
Attached are updated patches for VDR 1.5.10 and 1.4.7.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
Hi,
Reinhard Nissl schrieb:
I'm sorry for the trouble but the patches miss a check, whether
audioIndexer exists when VDR calls cRemux::Clear(). So VDR may segfault
for non radio channels.
Am I blind? audioIndexer was not initialized to NULL for non radio channels.
Attached are updated
switch outputs without reconfiguring/restarting VDR?
Change the primary device in VDR's DVB setup menu. Don't know if it is
possible via a macro. Maybe there exists an SVDRP command.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
is a link to a short recording (26Mb) demonstrating the problem: -
Please have a look at the patches referenced at
http://www.vdr-portal.de/board/thread.php?postid=664938#post664938
With theses patches, your recording looks much better.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
as mentioned on the vdr-portal
page.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
. I reverted it
back to 2048 and haven't noticed the problem after that.
Thinking about a repacker for subtitles, can anyone provide me some
links to documentation about the subtitle PES packet's contents?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
%20and%20Standards/subtitling/dvb-sub/Ets300743_e1.pdf
Thanks for this information. ETS 300 743 V1.3.1 (2006-11) is available
-- free of charge -- at www.etsi.org, too.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing
, false, Result);
IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet
larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of
the buffer which holds reading the buffer and will finally let the
buffer run full.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
find the supported SubStreamId 20 but cd
which activated compatibility mode.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.10-orig/remux.c 2007-09-22 14:08:22.0 +0200
+++ remux.c 2007-11-07 22:25:17.0 +0100
@@ -1748,14 +2193,15 @@ void cTS2PES
) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
;
diseqcCommands = NULL;
- Change the last line to:
//diseqcCommands = NULL;
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin
Hi,
Reinhard Nissl schrieb:
Though, a cleaner solution would be to fix the result buffer to allow
retrieving any packet as soon as it is completely available in the
buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do.
Can you suggest a patch
(before the mplex call),
while for your noSignal.mpg it reports
MPEG sequence, v2, [EMAIL PROTECTED] interlaced Y'CbCr 4:2:0 video,
CCIR/ITU PAL 625, 4:3, 25 fps
Maybe this indicates where the problem might be?
Don't think so.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
that there is no change in
the image data? Like creating an MPEG sequence from a set of still
images, where all stills are the same.
Hhm, if you set -n 3 for ppmtoy4m, mpeg2enc should detect, that there
are no changes.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
. Sending a
progressive I-frame as still image should be sufficient, no matter what
size the file has. Don't know whether the DVB-API has some limitations
regarding image size of still frames.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED
1 - 100 of 280 matches
Mail list logo
