Teemu Suikki wrote:
Perhaps there is some problem having tda10045 and tda10046 in same system?
After all, both are handled by the same tda1004x module..
The dmesg output does not look suspicious at all. It seems as if both
cards have been registered successfully.
The only thing you can do,
Ville Rannikko kirjoitti:
Hi!
The newest firmware for FF cards did not completely fix the AV
desync problems
for me.
Can you provide a sample recording where A/V sync fails with the current
firmware?
Oh, well. Turns out that I had somehow failed to install the new
firmware properly.
Kartsa kirjoitti:
I have been running vdr now for a couple days with
#define PLAYERBUFSIZE MEGABYTE(64) in dvbplayer.c
and for now it seems like better as in no stuttering. But I am still
testing it.
Okey, I've had this setting in action for a week or so now and it is
definitely better.
Kartsa wrote:
Kartsa kirjoitti:
I have been running vdr now for a couple days with
#define PLAYERBUFSIZE MEGABYTE(64) in dvbplayer.c
and for now it seems like better as in no stuttering. But I am still
testing it.
Okey, I've had this setting in action for a week or so now and it is
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22
(or something about) I made a test by recording nine channels
simultaneously and watching a recording at the same time. I remember
there seemed to be no trouble doing it. Now when I have vdr 1.4.4 after
fourth recording
I demand that Teemu Suikki may or may not have written...
Hi,
I have been using VDR for about two years now, without any big problems. :)
Now I built a new system with two cards. One is my old hauppaude nova-t,
other is technotrend nova-t with CI..
[snip]
What has this to do with the
On to, 2007-02-01 at 19:29 +0200, Kartsa wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22
(or something about) I made a test by recording nine channels
simultaneously and watching a recording at the same time. I remember
there seemed to be no trouble doing it.
Hi,
Marko Mäkelä wrote:
I believe that the easy fix would be to have these methods return 0 only
when playing a recording. Can the plugin detect this somehow?
For live TV, VDR runs a transfer thread and the replaying device may use
cDevice::Transferring() to detect this (works at least for
Hi,
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22
(or something about) I made a test by recording nine channels
simultaneously and watching a recording at the same time. I remember
there seemed to be no trouble doing it. Now when I have vdr
I have noticed smilar trouble:
When VDR playbacks a recording, and I pause playback and put play
again, video starts playing, then stops for less than second after about 5
seconds, then plays, after two seconds stops again for one second, and
then plays smoothly.
I have noticed replay
On Thu, Feb 01, 2007 at 07:57:20PM +0100, Reinhard Nissl wrote:
Hi,
Marko Mäkelä wrote:
I believe that the easy fix would be to have these methods return 0 only
when playing a recording. Can the plugin detect this somehow?
For live TV, VDR runs a transfer thread and the replaying
On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote:
Most likely, it's me who has to 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.
I do not
Reinhard Nissl kirjoitti:
Hi,
Heikki Manninen wrote:
I've noticed that earlier when I was using PIII 550 MHz and vdr 1.3.22
(or something about) I made a test by recording nine channels
simultaneously and watching a recording at the same time. I remember
there seemed to be no trouble
On Thu, Feb 01, 2007 at 08:27:14PM +0200, Marko Mäkelä wrote:
Maybe not switching off display while doing playback? It doesn't make
much sense anyway to run playback invisible.
It does. The typical use case is that you pause live video or start
a recording with a timer, then start
In [EMAIL PROTECTED], you wrote:
I wouldn't be so sure about the majority of VDRs using FF cards. I
haven't seen any ad for an FF card, but I have seen many ads for cheap
USB DVB-T tuners. The trend is likely to change, given that decoding
MPEG-2 is no challenge to current PC hardware.
Ville Rannikko kirjoitti:
Hi!
The newest firmware for FF cards did not completely fix the AV
desync problems
for me.
Can you provide a sample recording where A/V sync fails with the current
firmware?
I was just watching an Idols Extra recorded today and there were
multiple out of
Marko Mäkelä kirjoitti:
On Thu, Feb 01, 2007 at 09:49:55PM +0200, Kartsa wrote:
Most likely, it's me who has to 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
I wouldn't be so sure about the majority of VDRs using FF cards. I
haven't seen any ad for an FF card, but I have seen many ads for cheap
USB DVB-T tuners. The trend is likely to change, given that decoding
MPEG-2 is no challenge to current PC hardware.
Also generic video cards are
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote:
Marko Mäkelä kirjoitti:
I do not think that it is the reason. I checked that the cpu load was
less than 10% on my 3000+ AMD and even with my 550MHz PIII less than 20%
when there were 5 simultaneuous recordings.
You should
Marko Mäkelä kirjoitti:
On Thu, Feb 01, 2007 at 10:18:03PM +0200, Kartsa wrote:
Would it really matter in this case when cpu load was that small? I was
just trying to say that even though there were almost no cpu load vdr
was working sluggish.
Without trying it, it is hard to say.
Reinhard Nissl kirjoitti:
If you can reproduce this behaviour, would you please activate the
following line in remux.c:
dsyslog(TS continuity error (%d), ccCounter);
I will try with the recording if the problem reappears and then activate
that line.
The cRepacker messages might be a
Hello,
here VDR's log with your patch :
nice -n -19 ./vdr -u root -c /etc/vdr -l 3 -w 90 -s /usr/local/bin/vdrshutdown
-P'xine -r -q'
t: 1170367257.885, c: 0, r: 0, a: --
t: 1170367257.885, c: 0, r: 0, a: ioctl(fd_frontend, FE_DISEQC_SEND_BURST,
In [EMAIL PROTECTED], Patrick Mackin wrote:
Also generic video cards are increasingly coming with video decoding
features, and HDTVs can be connected straight to a PC without the need
for a horrible scaler or special screen mode. Although not all the
decoding features are available to Linux,
Hello,
just after a dvb modules reload :
nice -n -19 ./vdr -u root -c /etc/vdr -l 3 -w 90 -s /usr/local/bin/vdrshutdown
-P'xine -r -q'
t: 1170368152.594, c: 0, r: 0, a: --
t: 1170368152.598, c: 1, r: 0, a:
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
hello all
wondering if there is a way from the timers menu to only select to
record or not record a program. what im wanting to do is set a timer
to watch a program but not have vdr record it... not sure but just
thinking it would be nice to have a option in the menu to not record
but still go
I too would like this feature, but if you are using yaepg as many are, it
seems like that is a feature the plugin should provide, not vdr.
wondering if there is a way from the timers menu to only select to
record or not record a program. what im wanting to do is set a timer
to watch a program
You should have a look at the BigPatch. It has some switch timer included.
Martin
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von
abbe normal
Gesendet: Donnerstag, 1. Februar 2007 23:42
An: vdr@linuxtv.org
Betreff: [vdr] to record or not
hello
On 2/1/07, abbe normal [EMAIL PROTECTED] wrote:
hello all
wondering if there is a way from the timers menu to only select to
record or not record a program. what im wanting to do is set a timer
to watch a program but not have vdr record it... not sure but just
thinking it would be nice to have
29 matches
Mail list logo
