Is it possible to set to not update pids only for certain channels, not
globally? YLE channels in this case.
12.10.2014 22:17, Mikko Tuumanen kirjutas:
In at least some of the recordings I've made from the Finnish YLE-
channels there is a small gap at the start of the actual program and
VDR
I've noticed strange effect with the SNR bar. Every time when UNC
counter increased SNR bar becomes more and more red. In the same time
hex and percent values are fine. Combined screenshot from femon plugin:
http://www.pictureshack.ru/images/95487_unc.jpg
It's not plugin depended. The same
14.06.2014 17:52, Klaus Schmidinger kirjutas:
On 14.06.2014 16:40, Arthur Konovalov wrote:
I've noticed strange effect with the SNR bar. Every time when UNC
counter increased SNR bar becomes more and more red. In the same time
hex and percent values are fine. Combined screenshot from femon
15.01.2014 19:45, Eike kirjutas:
Hello again,
there have been several problems with linking with different VDR versions.
Here are updated steps that should fix them:
make
rm vdr.o
g++ -c framedetectortest.cpp
g++ -o framedetectortest *.o libsi/libsi.a -lfontconfig -lfreetype -lpthread
-ldl
21.04.2013 15:54, Klaus Schmidinger kirjutas:
The question I have now is: will it be enough to have *one* single
positioner
in any given setup, or are there actually users who have more than one
positioner?
Hi and thanks for bringing this feature to the job list!
One is enough for me.
--
4.03.2013 16:30, Klaus Schmidinger kirjutas:
While implementing an option to turn on/off sorting folders first in the
Recordings
menu, one more string was necessary and needs to be translated:
Always sort folders first
The patch for this new option can be found at
8.12.2012 17:28, Klaus Schmidinger kirjutas:
On 08.12.2012 13:18, Wolfgang Rohdewald wrote:
On Saturday 08 December 2012 12:38:30 Klaus Schmidinger wrote:
- In order to be able to play TS recordings from other sources, in
which there is
more than one PMT PID in the PAT, 'int
30.08.2011 0:02, Dirk Vornheder kirjutas:
Patch for remux.c doesn't fix the problem if i use my Hauppauge
PVR-cards 500 !
With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
Aug 29 22:07:44 pcneu vdr: [20700] record
/video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu
7.08.2011 12:51, Klaus Schmidinger kirjutas:
On 06.07.2011 16:40, Arthur Konovalov wrote:
On 6.07.2011 10:40, mike_booth76 wrote:
Have you found a fix for this yet Arthur. I have the same problem but
we seem to
be the only two...Mike
Hi!
Actually I awaiting some actions or response from
21.07.2011 18:56, VDR User kirjutas:
On Thu, Jul 21, 2011 at 1:41 AM, Mike Boothmike_boot...@iprimus.com.au wrote:
I've got round the problem of noty being able to play recordings made with
vdr-1.7.19 by removing recorder.c recorder.h recording.c recording.h and
remux.c remux.h and replacing
On 6.07.2011 10:40, mike_booth76 wrote:
Have you found a fix for this yet Arthur. I have the same problem but we seem to
be the only two...Mike
Hi!
Actually I awaiting some actions or response from Klaus, because my C++
programming knowledge is very limited.
br,
A
Hello!
At least one problematic channel on local cable network with recording
problem discoverd using vdr-1.7.19.
I have successfully recorded movie from Showtime channel by timer:
Jun 27 03:59:00 akovdr vdr: [13440] switching device 4 to channel 20
Jun 27 03:59:00 akovdr vdr: [13440]
On 22.01.2011 20:31, Timothy D. Lenz wrote:
VDR being a euro program where FTA sat is far more common should have
really good support built in.
I agree and awaiting too native rotor support in the vdr core.
br,
Arthur
___
vdr mailing list
JJussi wrote:
Hi!
This is maybe more Linux question than VDR...
I have 3xPCI-DVB adapters and 1xUSB-DVB adapter. Where I can see what
/dev/dvb/adapterX is connected to which physical devices.. And how I can
made so that USB-adapter is (always) last in line... adapter3 OR VDR
uses that
Halim Sahin wrote:
Have installed the xinelib-1.2-vdpau branch?
...
You can download the right xinelib with vdpau support from hg with this command:
hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2-vdpau
Default xine-lib-1.2 branch has already incorporated vdpau support and
mentioned
Goga777 wrote:
hi
can someone to create the patch for reelchannelscan and rotor plugin for
correct compilation with vdr
1.7.13
arvdr:/usr/src/vdr-1.7.13/PLUGINS/src/reelchannelscan# make all
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE
Tobi wrote:
This release brings an update and major refactorings of the VDR patch for
VDR 1.7.12.
Good job!
Please report any bugs, ideas or feature requests to the project site (no
registration required for this!)
I just applied new feature request #271 (Estonian translation files).
Goga777 wrote:
I couldn't apply a patch
/usr/src/vdr/PLUGINS/src/rotor-0.1.5# cat patch1 | patch -p0 --dry-run
patching file rotor.c
patch: malformed patch at line 6:
(diseqc=Diseqcs.Get(source-Code(),12000,'v')) ||
if ((diseqc=Diseqcs.Get(source-Code(),12000,'h')) ||
Joachim Wilke wrote:
I have the same problem. Whenever VDR records a channel I also see
lots of these dashes.
When replaying such a recording the replay isn't smooth at these
points. All of my recordings are
effected by this. Has anyone a clue what the real problem is?
Do You have FF card as
Hi!
I observed that periodically appears lot of dashes in the console running my
vdr-1.7.9.
Probably this comes from this code in transfer.c:
if (cPlayer::IsAttached()) {
// Transfer Mode means live tv, so there's no point in doing any additional
// buffering here. The TS packets *must* get
Klaus Schmidinger wrote:
I first have to debug the fast forwarding
in SF2 recordings problem.
Not only SF2 (if You meant Schweizer Fernsehen). I discovered that with
recordings from local cable operator fast forwarding not working too. Old
1.6.0's .vdr recordings are fine with 1.7.9. Output
Goga777 wrote:
what's rotor-0.1.4S2API ? does it patched rotor plugin ?
Yes, it patched for S2API. Found at:
http://ubuntuforums.org/showthread.php?t=1126258
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Bikalexander wrote:
Please try this version, I did not had to test it:
http://www.vdr-settings.com/hg/vdr-plugins/
http://www.vdr-settings.com/hg/vdr-plugins/archive/tip.tar.bz2
Thank You, but no luck. Crashes too.
Content of this repository almost same as I have.
marti...@embl.de wrote:
Lacking that, you can visit my howto
http://ubuntuforums.org/showthread.php?t=1126258
and download the patched rotor plugin from there.
Do not patch it anymore, just enable ROTOR = 1 in your Make.config (with the
extensions patch) and it will compile ok and run on
Country: Estonia
Transmission: DVB-C, DVB-T, DVB-S
Encoding: MPEG-2 for DVB-C and DVB-S, H264 for DVB-T
Few for DVB-T HD (H264) and DVB-C HD (MPEG-2 and H264).
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Ales Jurik wrote:
Original patch from Seppo (vdr-1.5.16):
http://www.mail-archive.com/vdr@linuxtv.org/msg05864.html
Patches for 1.6.0 and 1.7.0 (could be used up to 1.7.4):
http://www.linuxtv.org/pipermail/vdr/2008-September/017637.html
Do You have any additional hints?
It doesn't compiles
Simon Siemonsma wrote:
System:
Distribution: Gentoo (amd64)
vdr version: 1.6.0_p2
single card Technotrend budget T1500 with CI cart.
CAM: Conax cam by Smit.
Output on OSD:
7 Setup - 5 CAM - 1 Conax Conditional Access - 9 About Conax CA
Number of sessions: 5
Output of cat
Simon Baxter wrote:
I can't get any signal strength on some channels - have posted to the
linux-dvb list for this.
I haven't signal on two frequencies: 322 and 386 MHz
But when I do get a channel tuned ok, the audio
starts/stops/starts/stops/starts - and sometimes just starts/stops and then
H. Onur wrote:
hi,
i get this message when compiling xine-lib with external ffmpeg and
latest ffmpeg svn.
xineplug_post_planar_la-pp.lo -MD -MP -MF
.deps/xineplug_post_planar_la-pp.Tpo -c pp.c -fPIC -DPIC -o
.libs/xineplug_post_planar_la-pp.o
pp.c:31:27: error: postprocess.h: No
Peter Fassberg wrote:
Hej!
Vad har du för roligt projekt på gång som behöver 6 st kort? :-)
Jag har planerat ett streamingprojekt men jag får tyvärr aldrig
någon tid över till att komma igång.
Sorry, we usually don't understand here in list på svenska :)
Arthur
I have a question/problem, maybe someone can explain it.
I'm using vdr with xine plugin and run it in console.
Sometimes in console appears many-many M characters and it stops only after
disconnect xine player (Shift-S). After new connect (Enter) all works again.
What is it and how to eliminate
Arthur Konovalov wrote:
Klaus Schmidinger wrote:
Can you narrow down which of these three changes is actually necessary
to make it work?
I can repeat tests tomorrow, but I recall that this (it was first change):
state = 4; // normal operation
+ repliesToQuery = true; //AK
Klaus Schmidinger wrote:
Does the log really end at that point?
If there is no Ca Pmt Reply then the CAM doesn't reply to
the query.
That is, no reply in this point.
Because I got second confirmation from TechniSat Support about multiple
decryption possibility, I made small test changes in
Klaus Schmidinger wrote:
Can you narrow down which of these three changes is actually necessary
to make it work?
I can repeat tests tomorrow, but I recall that this (it was first change):
state = 4; // normal operation
+ repliesToQuery = true; //AK
}
and this (next change,
Klaus Schmidinger wrote:
Meanwhile I increased constant
MODULE_CHECK_INTERVAL to 300 ms
and now syslog looks much better.
At any rate, if this really fixes the problem for you (please let us
know whether it actually work in the long run) I guess it shouldn't
be wrong to generally set
Klaus Schmidinger wrote:
Please start a new thread for a new topic ( I've at least changed the
subject).
Yes, You are right. Sorry.
Please activate the DumpTPDUDataTransfer and DebugProtocol switches
in ci.c
and check whether VDR receives a reply to its QUERY.
Honestly, I don't
Klaus Schmidinger wrote:
Since cCamSlot::Reset() is the only place where resetTime is set to
a non-zero value, and you had lines like resetTime1: 1207548401 in
your syslog_1 file, apparently the tc[i]-Process() call in
cCamSlot::Process() must have failed.
Yes, reset came from this procedure.
I
Klaus Schmidinger wrote:
Well, actually it's only one place there where false is returned,
and that's when the alive timer times out, which is apparently
after the 2 seconds between the resets you're observing, see
#define TC_ALIVE_TIMEOUT 2000
One possible test would be to increase this time
Now I have next question/problem.
From Technisat support I have the following answer:
Our CAM TechniCrypt CW is able to do multiple parallel decryptions since
the software version 26.1.5.0.11
I have this firmware:
Conax CA
About
0. Quit menu
1. Software version: 26.1.5.0.11
2. Interface
Klaus Schmidinger wrote:
So does this mean that with the small test.c program the module status
is continuously going on and off, without VDR even being involved?
No. It just exit.
Can you post more than the above 4 lines from ./test (like 20 or so)?
test* test.c
[EMAIL
Klaus Schmidinger wrote:
Please change the line
for (i = 0; i 200; ++i) {
so that it loop 2000 times. That should cover a longer time.
I see. Set to 4000.
Additionally added before 'return 0;':
printf(end: );
print_status(status);
Now it loops about 50 seconds :
[EMAIL
Klaus Schmidinger wrote:
The problem is that this malfunction happens on *your* system, not
on *mine*. So I'm afraid I can't be of too much help in debugging this.
What about ssh console to my PC?
I'm really don't want to abandon VDR!!
Regards,
AK
Klaus Schmidinger wrote:
At this point...
Apr 7 09:06:41 vdr vdr: [4862] ms: 3
Apr 7 09:06:41 vdr vdr: [4862] resetTime1: 0
Apr 7 09:06:41 vdr vdr: [4862] ms: 2
...the module status changed from 3 (ready) to 2 (present).
The module status is retrieved from the driver in
Well,
I'm not big guru of debugging.
I made following changes to mentioned part of code:
eModuleStatus cCamSlot::ModuleStatus(void)
{
cMutexLock MutexLock(mutex);
eModuleStatus ms = ciAdapter ? ciAdapter-ModuleStatus(slotIndex) : msNone;
isyslog(ms: %d, ms); //AKO
isyslog(resetTime1: %d,
Tuomas Jormola wrote:
I upgraded my VDR setup from 1.4.7 to 1.5.17. After the upgrade I've
begun to see these CAM initialization and TS continuity error messages
in the syslog (see the attached file). I'm using Technotrend 1500 DVB-C
card with CI and Conax CAM and card from local cable
Klaus Schmidinger wrote:
Please try commenting out the line
repliesToQuery = true;
in VDR/ci.c. Does it work then?
Can't test it anymore, I gave CAM away.
Next week will get new.
AK
___
vdr mailing list
vdr@linuxtv.org
Klaus Schmidinger wrote:
Looks like your CAM can handle multiple parallel decryptions.
So I ran the test with a CAM that can do that here, too, but the
result was the same as ever - works just fine.
I give up. May be this is really my CAM's problem because of big silence
regarding this
Klaus Schmidinger wrote:
Please run the tests with the original, *unpatched* version 1.5.14
(or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to
be part of version 1.6.0) and use as few plugins as possible (best would
be without *any* plugins).
Here we are...
Clean vdr-1.5.13
Klaus Schmidinger wrote:
Maybe you could activate the debug outputs in ci.c to see whether VDR
actually sends the CA_PMT data to the CAM.
Sorry for delay, busy weekend...
I enabled debug outputs in ci.c and made 2 attempts:
-crypted channel recording (ok files)
-FTA recording and try to
Klaus Schmidinger wrote:
I just read your original posting again, and there you described the problem
the other way round. So I also tested recording the FTA channel and then
switching
to the encrypted channel, but this also works fine here.
So I'm afraid I don't know what's causing this
Morfsta wrote:
Nope, it's all compiled - just doublechecked with fresh source: -
vdr-1.5.14
vdr-rotor-0.1.4-vdr-1.5.14.tgz
vdr-1.5.14-h264-other-rotor.diff
vdr-1.5.14-h264-syncearly-framespersec-audioindexer-fielddetection-speedup.diff
./vdr -Protor
vdr:
Morfsta wrote:
Nope, I had to roll back to an earlier version of rotor that I patched myself.
Cool. Can You share it? I can't live without rotor.
AK
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
lucian orasanu wrote:
I say that i will be tester, so rotor patcheches aply
fine and compile only in this order.
1. Rotor patch vdr-1.5.14-h264-other-rotor.diff to
vdr-rotor-0.1.4-vdr-1.5
2. Rotor patch vdr-1.5.14-h264-other-rotor.diff to
vdr.
I tried same order, but got error:
g++ -g
Klaus Schmidinger wrote:
On 02/03/08 12:06, Matthias Schniedermeyer wrote:
Is the CAM Handling regarding multiple parallel recodings (on the same
channel) fixed?
Have you tried version 1.5 yet?
It can do multiple parallel recordings with the same CAM (if the
CAM supports this).
I still
Petri Helin wrote:
If the h.264 support is left out, it's a no.
Same here.
AK
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
serge pecher wrote:
Did you had to adapt manually the patch, because when i try this patch on
vdr 1.5.12 everything is rejected ?
Previosly mentioned patch applied to attached version of rotor plugin.
I suspect that I found it in vdr-portal.de
Fresh generated patch attached also.
Regards,
This doesn't directly concern xine plugin, but maybe anybody can help me.
Trying to update xine plugin and got xine-ui compile problem like this:
gcc -I/usr/local/include -I/usr/include/readline
-I../../src/xitk/xine-toolkit -Wall -D_FILE_OFFSET_BITS=64
-Wpointer-arith -Wnested-externs
Ville Aakko wrote:
OTOH I don't see anyone mentioning anything about emergency exits in
the vdr-1.5.11 subtitling problems. Maybe what I encountered was a
different problem, after all?
I had similar problem, but after upgrade to 1.5.12 it's fine now.
AK
I'm on a FTA channel and a timer starts
after I tuned to the channel.
Theunis
On 17/10/2007, *Arthur Konovalov* [EMAIL PROTECTED] mailto:[EMAIL
PROTECTED]
wrote:
Hi all!
Our local cable operator transmit on same frequency FTA and scrambled
channels.
During
Tero Siironen wrote:
Great that the subtitles are now part of the VDR. Unfortunately, there
seems to be some problems still. I tested this new VDR version for
some minutes and noticed that some subtitles were shown too late in
live tv watching.
Testing was done with VDR 1.5.10 without any
Hi, community!
Please advise what is best way to fix vdr-1.5.6 compiling on Slackware-11.0.
What I got:
font.c:12:35: fontconfig/fontconfig.h: No such file or directory
font.c: In static member function `static bool
cFont::GetAvailableFontNames(cStringList*, bool)':
But,
[EMAIL
Ville Aakko wrote:
Wathing the program in real-time has no problems, there I can see the
subtitles without problems. Only the recordings have problems.
I have similar issue with YLE1 and YLE2. Sometimes subtitles saved, sometimes
not. ProjectX shows same: no subtitles- no DVB stream. And vice
Ville Aakko wrote:
I have a similar setup and yes, DVB subtitles are recorded. I don't
use ttxtsubs at all (only the DVB ones).
I know that it sounds stupid, but after upgrading to 1.4.5 subtitles
recording works flawlessly.
Maybe just because of restart.
I have :
- Gentoo
- kernel 2.6.19
63 matches
Mail list logo
