channels
with PPID != VPID are handled differently by VDR, hence causing
this issue in vdr-xine.
vdr-xine-0.9.4 will include that patch, but it will still take a
few days to get it ready.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../xine-0.9.3/xineDevice.c 2009-06-1
ks to Valdemaras
Pipiras).
- Included Slovak translation (thanks to Milan Hrala).
- Included Chinese and Taiwanese translations (thanks to
NanFeng).
- Fixed MANUAL about centre_cut_out_mode (thanks to Vorg on
#xine-vdpau).
Enjoy.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@g
Hi,
Am 16.03.2011 20:29, schrieb Reinhard Nissl:
- Added support for VDR-1.7.17s TrueColor OSD.
I forgot to mention, that TrueColor OSD is currently only
possible with VDPAU.
Furthermore you have to select an "OSD display mode" different
from "X11 overlay" in
/config:
# disable decoder flush at discontinuity
# bool, default: 0
engine.decoder.disable_flush_at_discontinuity:1
# disable decoder flush from video out
# bool, default: 0
engine.decoder.disable_flush_from_video_out:1
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
2: can_record, can_do_epg_scan, can_do_liveview, devprio=90
device #3: can_do_liveview, devprio=10
Is there a way for plugins to alter *cDevice::GetDevice behavior ?
Are there any plans on that matter ?
Please modify the attached plugin, telling that device 3 doesn't
provide any transponder.
annel.
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
mai
tbox 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 PROTE
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
changes would be necessary to have them reported in
display order (see comment in decode.c).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- xine-cvs/xine-lib/src/libmpeg2/decode.c 2006-12-09 22:04:30.0 +0100
+++ xine-lib/src/libmpeg2/decode.c 2006-12-15 23:24:46.0
d some older versions of VDR and xine-plugin.
You may want 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
g. at 03:01 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
wn 0x006C
> 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.-Info
gt; vdr-1.2.6-dvbplayer5.patch
If you do not want to edit any recordings made with a VDR version prior
to 1.4, you won't need this patch at all.
BTW: you would have to use vdr-1.3.44-dvbplayer5.patch for VDR 1.4.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
mpiling xine-lib.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
xternal solution is much more complex than adding a
simple additional restart request for 03:01 -- shure, this time
shouldn't be hard coded ;-)
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
lines beginning with + (but without the +) into line 179 of
PLUGINS/src/xine/xine.c.
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 the frame buffer. Things like setting 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.or
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 Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
0) && (b[2] == 0x01)
&& (0xc0 <= b[3] && b[3] <= 0xdf);
}
As video recordings always start with a video PES packet, testing for an
audio PES packet should be sufficient.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
store the decision whether a client uses
mini or full DiSEqC until the switch port sees a power cycle. 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
DVB0_LNB2_switch=11700
> DVB0_LNB3_hi=10600
> DVB0_LNB3_lo=9750
> DVB0_LNB3_switch=11700
>
> Which is the same for DVB1 and DVB2.
>
> I would really enjoy if someone could explain me how to use the same
> settings as kaffeine use :-)
Hhm, these set
DR can then switch to all three satellites again.
>> Hhm, these settings only help in determining high/low band and the
>> frequency 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 t
15 T
S28.2E 11700 H 9750 t V W15 [E0 10 38 FA] W15 A W15 t
S28.2E 9 H 10600 t V W15 [E0 10 38 FB] W15 A W15 T
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.
Bye.
--
Dipl.-Inform. (F
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]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
ng
different than in kaffeine.
Tomorrow, I'll have a look into VDR and add some debug output. So, stay
tuned ;-)
> One card in vdr works great (-D 0 or -D 1 or -D 2) but I can't use
> more...
>
> Thank you very much,
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL
st 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 blamed. Around 1.3.27, cVideoRepacker
was introduced which has an impact on CPU load. This could 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]
dio frames do not contain any length
information. Please modify the line
*FrameSize = 0;
in cAudioRepacker::IsValidAudioHeader to
{ *FrameSize = 0; dsyslog("cAudioRepacker: FrameSize == 0"); }
for getting this situation reported.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMA
different transponder on the same "band", so there is just
FE_SET_FRONTEND reported.
I'll now add the same output to szap.
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 20
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 PROTEC
Hi,
Kartsa wrote:
> Should I do both these changes at the same time or separately?
I think you may apply both changes at the same time.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
h
al functions would have 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
n't report
such issues in the past?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
an throttle the TS stream so 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
..
Just remove "cOSDClock::".
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
he deadlock is gone, but the OSD is still not shown on screen.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
yslog() to esyslog() or check the commandline of VDR
whether 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]
___
When I got the PATA drive back and removed the SATA model, the
TS errors were gone.
So I'd say this is a hardware/driver/configuration issue -- but not
necessarily in the DVB area. I hope, someone else can give you further
hints.
Bye.
--
Dipl.-Inform. (FH
n is (only) used by vdr-xine to give xine a chance to
display all the decoded and internally buffered frames when 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
e is configured to get
> primary device on Xine connect.
I'm sorry, I've no hint for you concerning the audio issue.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
ct (in case you are using DiSEqC)?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
DiSEqC commands, so I'd suggest to use VDR's
diseqc.conf. It's default section "Full DiSEqC sequence" is identical to
the tuning sequence that szap uses.
You may want to try the attached szap and VDR patch. You'll then get
some output while tuning.
Bye.
--
Dipl.-Inform
ched szap and VDR patch. You'll then get
>> some output while tuning.
>
> 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
API function has changed some time before VDR 1.4.x.
You may want to use burn-cvs where this issue has already been fixed.
http://www.vdr-wiki.de/wiki/index.php/Burn-plugin#Snapshot
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
ssume that either B) or C) will be the shortest sequence that still
works in your case.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
nötigt von »burn.o«, zu erstellen. Schluss.
Have a look at this:
http://www.vdr-wiki.de/wiki/index.php/Burn-plugin#Softwareanforderungen
You'll need boost. E. g. on my openSUSE 10.2:
video:~> rpm -q boost-devel
boost-devel-1.33.1-42
Bye.
--
Dipl.-Inform. (F
ile (0); loop.
BTW: I still assume, that your logfile reports 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:
ed to find it.
This procedure is executed all over the time and once cAudioRepacker has
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]
a recording. If size matters, you 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
a recording. If size matters, you 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 AnalyzePesH
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. Y
t you are
looking for before you start porting the post plugin support from fbxine
to df_xine, which shouldn't be too complicated ;-)
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
like users of FF cards to test this patch. If this triggers AV sync
issues, firmware developers are invited to fix this issue.
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
the recording, then sync is
maintained actively and you don't see this issue again at that position
in the recording.
Please keep in mind that the last paragraph was just a guess -- I do not
want to blame anybody with this email.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTE
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
301 - 355 of 355 matches
Mail list logo
