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] actuato
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
___
21.07.2011 18:56, VDR User kirjutas:
On Thu, Jul 21, 2011 at 1:41 AM, Mike Booth 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 them with the same files from
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
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 vd
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
cPatPmtParser::
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
http://www.vdr-portal.d
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.
--
br,
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 -l
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 behav
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
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 ha
Anssi Hannula wrote:
1) DVB Subtitles sent in the HTTP datastream:
http://users.tkk.fi/~rahrenbe/vdr/vdr-streamdev-cvs-subtitles.diff.gz
Forbidden:
You don't have permission to access
/~rahrenbe/vdr/vdr-streamdev-cvs-subtitles.diff.gz on this server
AK
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
Pekka Virtanen wrote:
The problem is most likely caused by the fact that the PIDs for
subtitles are different than at the time the recording started.
Current implementation doesn't detect if PIDs change during recording.
I don't think so. Tried manual recording in the middle of program as well.
Arthur Konovalov wrote:
Pekka Virtanen wrote:
The problem is most likely caused by the fact that the PIDs for
subtitles are different than at the time the recording started.
Current implementation doesn't detect if PIDs change during recording.
I don't think so. Tried manual record
listnisse wrote:
> But no, I am looking for the package that extract ttxtsubs from vdr
> recordings.
One possible solution is ProjectX package. It can demux teletext subs to
text file.
Regards,
AK
___
vdr mailing list
vdr@linuxtv.org
http://www.lin
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 PROTECTED]:/usr/
> Reinhard Nissl wrote:
> the attached vdr-1.5.9-h264.patch adds H.264 support to VDR's remuxer.
Hi,
I trying to compile vdr-1.5.9 with h264 patches but vdr-xine-0.7.10 plugin give
me error:
xineDevice.c: In member function 'int
PluginXine::cXineDevice::PlayCommon3(const
uchar*, int, int64_t)'
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 an
Hi all!
Our local cable operator transmit on same frequency FTA and scrambled
channels.
During recording on FTA channel it is not possible to switch to any
scrambled channel on the same frequency.
"Channel not available!" message received.
At the same time, when recording scrambled channel, swi
Reinhard Nissl wrote:
> vdr-xine-0.7.11 doesn't support multiple OSDs but it shouldn't crash.
> 0.7.12 is on the way. I've run a 1 hour test yesterday on TV5MONDE
> EUROPE, as mentioned in this mailing list.
vdr-xine-0.7.12 crashing without notice on YLE channels with subtitles as well.
I discov
io
> channel. Same happens every time 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!
>
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
___
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 -Wc
[EMAIL PROTECTED] wrote:
I am looking for the patch to compile the rotor plugin together with
vdr-1.5.12.
Does anyone achieved to compile it with 1.5.12
I had success with attached patch.
Regards,
AK
diff -ur rotor-0.1.4/filter.c rotor-0.1.4_vdr-1.5.10/filter.c
--- rotor-0.1.4/filter.c
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,
A
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
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).
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++
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: ./PLUGINS/lib/libvdr-rot
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
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 t
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 wi
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 switc
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 issue
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
http://www.linuxtv
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 operator
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:
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 cDvbCiAdapter::
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:
> 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 PROTECTED]:/video/vd
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
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.
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 versio
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 unders
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 g
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 cha
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 ope
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 eliminat
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
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
Igor wrote:
> I never have seen the command [E0 00 00] - what's mean ?
From Diseqc bus specification:
E0 Command from Master, No reply required, First transmission
00 Any Device (Master to all devices)
00 Reset DiSEqC microcontroller
I suppose it means Reset All Diseqc Devices. Another thing
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 t
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
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 compi
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
marti...@embl.de wrote:
> What you are missing without the rotor plugin is the ability to move your
> rotor
> hunting for new positions or re-aligning the dish.
Exactly. It's a main problem.
> xdipo can help there, it is
> a stand alone program.
Can I run it without leavig vdr?
I have command l
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 r
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
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. Outpu
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* ge
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 pr
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')) ||
(diseqc=D
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:
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
-DPLUGIN_NAME_I18N='"re
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 a
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 adapter
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
vdr@linuxt
Hello all!
Recently added Technotrend TT Connect C-1200 USB device to vdr (1.4.3-1).
All went fine, but one problem occurs.
If switch channel during recording on same mux frequency, picture become
disturbed (both: recorded and watched) due to limited USB DVB device bandwidth
(from card spec: 7
Soeren Sonnenburg wrote:
does anyone else observer that the mplayer plugin does no longer give
sound output with vdr 1.4.4 ? Could it be that the sound device is somehow
still locked/occupied by vdr ?
I am using the latest vdr-mp3/mplayer (0.9.15) and it used to work with
1.4.1 ... so what chang
Hi.
I noticed that dvb subtitles not recorded with video.
Can anyone confirm that it works?
My environment:
Slackware-11.0, kernel 1.6.19,
vdr-1.4.4-3 with
vdr-1.4.4-liemikuutio-1.13.diff,
vdr-1.4.4-subtitles-0.4.0-and-ttxtsubs-0.0.5.diff
Recorded teletext subtitles are ok.
Tried on YLE1 and YL
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
76 matches
Mail list logo
