1.5.11 fixed one subtitling issue and caused the issue you are
seeing. In 1.5.12, the offending change has been reverted and the
subtitling issue has been fixed by a different approach.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
__
60 ms) which must first be
established before replaying at normal speed starts.
BTW: The software decoding solutions need such a buffer to compensate
latency issues with the threads involved in the chain from input to output.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
__
R runs in transfermode and outputs the remuxed stream via a FF
card. Is this correct?
What are the problems you are seeing with cAudioRepacker enabled?
Are there any problems when you replay a radio recording?
Are there any logfile entries mentioning a problem?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nis
a pigtail from an nVidia
graphics card and I'd like to know where to find for example S-Video.
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 stdout
>
> Can anyone help??
I don't think that this is vdr-xine related. Have you tried a different
MRL too?
Something like:
xine /path/to/mpegfile
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailin
rt H.264, but are
also useful for MPEG2. One provides faster zapping and the latter will
make VDR show correct recording lengths e. g. for NTSC recordings.
So to sum up and refer to my previous post, there is no need to watch
H.264 on a PIII 450 MHz (although this should be possible with a HDe),
but even t
#x27;ve seen enough anomalies, please provide us (a link to) the files.
BTW: the patch is almost untested as there are currently no subtitles
running.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.5.11-orig/device.c ./device.c
--- ../vdr-1.5.11-orig/device.c
x.
So whenever you like, feel free to contact me regarding integration of
H.264 support. Till then, I'll try to provide updated patches, so there
is no need to hurry.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing
pling an own frontend. I didn't
want to write an own frontend. But my xine plugin has to act like a
frontend within any other frontend and therefore requires some xine-lib
patches to prevent deadlocks.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
budget cards, so it's not an issue for me.
> A feature that allows to watch different channels on clients at the same
> time (without using multiple vdr installations and streamdev) would
> definetely make me switch back to vdr-xine :)
And you wouldn't mind applying a huge patch on
Hi,
Reinhard Nissl schrieb:
>> Yes, they are smooth for a brief moment, and then get jagged.
>
> I recall this behavior when I had a FF card for testing. Maybe it's a
> feature to stop flickering one pixel high horizontal lines in still
> images by doubling one field of
Hi,
Timo J. Rinne schrieb:
> Posting to the mailing list seems to be for subscribers only and I'm
> reading it only through archive. However ...
>
>> Reinhard Nissl schrieb:
>>
>> >>> Though, a cleaner solution would be to fix the result buffer to
>
displays only a single field of the frame twice (to avoid flickering one
pixel horizontal lines on TV) short time after not further data arrives
(typical for still frames). And displaying just a single field removes
halve of the information to display.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mail
provide a proper fix for this 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
d of the file before mplexing and the
MPEG program end code (00 00 01 B9) from the file after mplexing. Maybe
remove everything up to the first video PES packet from the final file.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
an I frame isn't larger than 40 KB.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
se options:
mpeg2enc -f 8 -a 2 -q 1 -n p -I 0 -T 120 -R 0 -g 10 -G 12 -o noSignal.mpg
But I still think that there is no need to repeat anything. 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 ha
of one (large) I-frame, followed
> by some number of P-frames, which indicate 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
ROTECTED] 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 PROTECTED]
mkNoSignal.sh
Description: application/shellscript
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
t thing to do.
> Can you suggest a patch for this?
I hope to get something ready till tomorrow 12:00.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
tunerStatus = tsSet;
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.li
mpletely available in the
buffer (final subtitle packets are about 100 bytes in size).
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
storted on the way to the multiswitch/LNB with the result
that VDR never successfully tuned in such a 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
PlayPES() didn't 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 @@
ERSIZE, IPACKS, 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. (F
DVB/DVB%20BlueBooks%20Standards/Specifications%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]
ew SUBTITLE_PACKS size. 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
thout xine-lib
> it doesn't appear.
Maybe I'll have a look at it tomorrow.
Meanwhile, you could have a look at this issue with this gdb command:
thread apply all bt
It'll tell you the backtrace for all threads.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
o specify a deinterlacer 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
r HD recording as part of the
> preview...
>
> Here 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.
B
2300 dvb-c card.
>
> Can I 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) Reinhar
/?d=55JZHZ4A
Please give the patch on the below mentioned site a try. Your recording
(which uses only interlaced frames) plays properly here when I play it
at 50 % of normal speed (my PC simply isn't fast enough for realtime
decoding).
http://www.vdr-portal.de/board/thread.php?postid=662944#p
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.
Attach
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 PROT
this recording.
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
ation is based on 40 ms per index entry.
The attached patch fixes cRemux to only generate an index entry whenever
the recorded amount of music crosses a 40 ms boundary.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.10-orig/remux.h 2007-09-02 12:19:06.0
Hi,
JJussi schrieb:
> xineliboutput.
Well, I'm not used to it, but it uses libxine like vdr-xine does.
Therefore I think that your libxine lacks support for libmad, which
implements the Mpeg Audio Decoder.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL P
xine, xineliboutput, softdevice ...
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
hen it starts.
When VDR doesn't restore 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@l
-1.2 is only available from the hg 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.
--
D
6 colors but doesn't support OSD
transparency at all.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
rthur Konovalov 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
he need to go this way, feel free to do so.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
lay() or XSync(). One change 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.-I
oduce this here.
> - vdradmin 3.6.0 am has problems staying connected to VDR
I'm sorry, I do not have any test results here so far.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
terminal.
> I discovered that TV5 Monde transmitted on local cable network 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'
ettings for
4:3 and 16:9 images, which are automatically 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@l
th dolby
audio packets.
It seems to me, that subtitle packets slip through as "ancient" dolby
audio packets.
I took 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
ist. But I cannot tell anything
about correct sync, because I didn't understand the audio track 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
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.or
ess consumes 61-67% and Xorg 9-10% of CPU
> on my machine.
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 li
le leaks in case this issue is a matter of
the DVB drivers (kernel).
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:
> 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
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 PROTECTED]
diff -r 0f20b6e8ac9d src/libffmpeg/libavcodec/h264.c
--- a/src
It typically crashes after a few frames. In my
xine-lib.patch for xine-lib-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
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 htt
ng mode streamdev parses PIDs directly from 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) Reinh
he VPID is scheduled for decrypting. This could be the reason why
the video TS packets 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 t
tests using dvb-s2 during the weekend.
Please keep in mind, that my patch doesn't add DVB-S2 support.
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 on http://hotel.hanu.com/~hanu/h264
Plays perfectly here with vdr-xine-0.7.11 and xine-lib-cvs from my
homepage + vdr-xine's xine-lib.patch. If I play it in slow motion, my PC
is fast enough to decode and display all frames.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTE
p;, double*)':
> xineDevice.c:2017: error: cannot call member function 'int
> cRemux::ScanVideoPacket(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.-Inf
njoy.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
it once must have worked to get a properly decrypted TS.
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:
> 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:
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
> My subscription is ending in 24 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.-Infor
may differ from your's a little)?
CANAL+ FILM
HD;Harmonic:11470:vC56M2S0Z0:S13.0E:27500:10331+331: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
mailt
ame.progressive_frame
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,
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) Rei
ash.
In case you are able to create 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.
aced H.264 decoding got a google summer of code 2007 project. So
lets 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]
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:[EMAI
" 16
color STNG OSD. Or will it depend on the result of cOsd::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
ng femon for
quite some 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:
//if(!device->***) 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-
using vdr-xine and VDR-1.4.6 patched with my (still unreleased) sync
early patch.
Audio and video appear after about a second after switching to that
channel and seem to be in sync from that time on.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
__
via remote control nor SVDRP interface.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
s in the
logfiles?
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
tronom feedback
> audio.synchronization.resample_mode:off
> audio.volume.mixer_volume:100
> 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 mai
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
h vdr-xine at the moment -- it uses a different xine-lib stream
property to signal the requested volume.
If you change the volume in xine's UI, it should work 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
ght option but it does not work for me.
> Perhaps someone can try this too?
Just to make sure, you are not going to send digital audio data to an
external decoder, are you? In case you are, the above option doesn't
work as it processes only decoded audio samples. It cannot modify the
en
Hi,
Peer Oliver Schmidt wrote:
> Mar 21 18:06:31 vdr vdr: [17991] ERROR: no DiSEqC parameters found
> for channel 13
You are missing some lines in diseqc.conf. Just copy the 4 lines for
S19.2E and replace S19.2E by S28.2E.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PRO
ine's setup dialog. It might well be
that this software mode does what I've mentioned above.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> Thats not my problem.
So, you don't want to touch 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.-
be changing 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
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
mailt
rea.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
repacked packets all the 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,
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.-
vice choose if repacking is needed or not? It
> should now if repacking is needed, and in most cases it should be able
> to do it by itself.
Well, it isn't just a matter of the output device. cVideoRepacker takes
care that VDR's index file contains valid
ish as time passes by.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
at
the end and the beginning of the next PES packet. cAudioRepacker can do
this for you. Just feed it PES packets via it's Repack() method and the
given ResultBuffer will contain a PES packet per audio frame.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
__
though 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
+++ ./dvbpl
this might
stretch to much horizontally.
All the above can 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
s bar advances very
quickly by 10 seconds, as VDR sends the recording data as fast as
possible (i. e. as fast as your harddisk can supply the data) to xine.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
inion, a more proper solution should patch VDR to do some
nonblocking dummy 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]
tion logic for real driver issues (given
that such a detection logic is feasible) or whether the current
detection should simply be dropped. But that's off topic in this thread.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr
201 - 300 of 355 matches
Mail list logo
