Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[Klaus Schmidinger]

martin wrote:
> To be honest, i use BigPatch for just one reason. During playback, I can
> jump 10 sec + / - with the “1” and “3” keys. I can’t live without this
> feature, because jumping 1 Minute is nice, but most of the times way too
> long. So, actually, adding this 10 seconds jump to the main part, would
> also help me a lot!

Why don't you just press FFWD/FREW shortly?

> PS: I changed the subject to the eMail, beause we have opened a new
> topic here.

Actually you should have started a new thread!

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Udo Richter]

Marko Mäkelä wrote:
Actually I would press the pause button, as I usually don't want to miss 
anything. And then the playback should be halted anyway, no matter if 
display is on or off.


But you surely would power the display off, to avoid burning the still
image on the CRT or plasma screen or to save the precious hours on the
lamp of your video beamer?  Or maybe you have a TFT screen and do not
care about wasting electricity?


Actually, I have a plain old CRT that doesn't seriously suffer from 
burning in. (provide that I resume playback within a month or so. ;) )


And if I want to save power, I power off the CRT completely, and thats 
something my VDR cannot do on its own (yet). Just blanking the screen 
has no advantage for me.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Vdr or driver performance dropout

[Clemens Kirchgatterer]

Marko Myllymaa <[EMAIL PROTECTED]> wrote:

> Also this newer version does some weird busylooping or whatever from
> time to time. Vdr gets all remote codes and buffers them, but just
> starts executing them after ~45s. One time it took so long, that I
> got ssh opened from other computer to restart vdr, but vdr had
> recovered.

i can confirm this. i get the same delays in key processing very
frequently. i use also a low end machine - PII 233 MHz.

> And third problem which have gone worse is weird black output I get.
> Vdr is up and running, osd is shown, but no live video. Changing
> channels are very slow (ie. vdr shows the info screen very long).
> Restarting vdr corrects this (propably reloading the drivers is the
> actual "fix"). This has happened with 1.3.19 about once a week. Now
> with 1.4.4 I had to restart vdr everyday. That's not so nice.

me 2 also on this point. exactly the same behalfier.

clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Sky+ Series Link

[Rob Davis]

I was playing with a Sky+ box over Christmas and was quite impressed 
mainly with Series Link.


What would be involved to get this implemented on VDR?  I understand the 
likelihood of reading the Sky UK epg streams is small - however I am 
downloading a week or so worth of epg listings off xmltv.  Is it 
possible to do a quick search on the epg if a "record series" link is 
requested?



--
Latest news on http://www.streetcredo.org.uk/rob

Rob Davis

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Vdr or driver performance dropout

[Laz]

On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote:
> Marko Myllymaa <[EMAIL PROTECTED]> wrote:
> > Also this newer version does some weird busylooping or whatever from
> > time to time. Vdr gets all remote codes and buffers them, but just
> > starts executing them after ~45s. One time it took so long, that I
> > got ssh opened from other computer to restart vdr, but vdr had
> > recovered.
>
> i can confirm this. i get the same delays in key processing very
> frequently. i use also a low end machine - PII 233 MHz.

What type of remote receiver are you using? I've had delays with some remotes 
but not others:

1. USB2 Nova-T receiver with the remote plugin: works most of the time but 
goes through phases where it seems to be ignoring keypresses so I press the 
button again (several times!) and then a few seconds later it "catches up" 
and I end up in a different menu, etc. to what I wanted! Works OK but can be 
very annoying! Also gives the wrong codes, i.e. keys, sometimes which can be 
confusing!

2. PCI Nova-T receiver through lirc: works much better than the USB receiver 
but does feel as if there is a lag between pressing keys and things 
happening. Does sometimes do the buffering thing mentioned above but nowhere 
near as bad.

3. Home-made simple lirc receiver on a serial port through lirc: much more 
responsive than the two "proper" remote receivers! I would recommend this to 
anyone who can build the simple receiver. Finally got round to building 
another one for my main vdr system and it is so so much better now (was using 
the USB receiver previously).

I never worked out where the delays occurred, i.e. whether it was down to the 
DVB drivers or vdr itself. Seeing as the lirc receiver works fine, I'd be 
suspicious of the driver.

The above observations are on a 1.2 GHz Via Epia system, so not that powerful 
all things considered.

Cheers,

Laz

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Vdr or driver performance dropout

[Clemens Kirchgatterer]

Laz <[EMAIL PROTECTED]> wrote:

> On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote:
> > Marko Myllymaa <[EMAIL PROTECTED]> wrote:
> > > Also this newer version does some weird busylooping or whatever
> > > from time to time. Vdr gets all remote codes and buffers them,
> > > but just starts executing them after ~45s. One time it took so
> > > long, that I got ssh opened from other computer to restart vdr,
> > > but vdr had recovered.
> >
> > i can confirm this. i get the same delays in key processing very
> > frequently. i use also a low end machine - PII 233 MHz.
> 
> What type of remote receiver are you using? I've had delays with some
> remotes but not others:

home brewed ir receiver on serial port using lirc. the same as you say
worked best for you. i'm sure the problem is not on the IR side but on
vdr, as that setup was not changed between vdr upgrades. 

best regards ...
clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Marko Mäkelä]

On Sat, Feb 03, 2007 at 10:48:42AM +0100, Udo Richter wrote:
> Marko Mäkelä wrote:
> >>Actually I would press the pause button, as I usually don't want to miss 
> >>anything. And then the playback should be halted anyway, no matter if 
> >>display is on or off.
> >
> >But you surely would power the display off, to avoid burning the still
> >image on the CRT or plasma screen or to save the precious hours on the
> >lamp of your video beamer?  Or maybe you have a TFT screen and do not
> >care about wasting electricity?
> 
> Actually, I have a plain old CRT that doesn't seriously suffer from 
> burning in. (provide that I resume playback within a month or so. ;) )
> 
> And if I want to save power, I power off the CRT completely, and thats 
> something my VDR cannot do on its own (yet). Just blanking the screen 
> has no advantage for me.

I'll shortly make my updated vdr-relay plugin available, adapted for
your shutdown rewrite patch.  Then you can install a simple solid-state
relay to a spare RS-232 port.  I ended up installing mine inside the soon
20-year-old 14" CRT, to reduce clutter.  I control everything from the
bundled Hauppauge remote control unit.

http://www.iki.fi/~msmakela/electronics/relay/

For the cable, I used an old mouse cord that I soldered to a mono plug.
I attached a mono jack to the monitor's back together with a manual
override switch.  The solid-state relay is connected in series with the
power switch of the monitor.

Marko

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

RCU interfaces (Re: [vdr] Vdr or driver performance dropout)

[Marko Mäkelä]

On Sat, Feb 03, 2007 at 10:43:37AM +, Laz wrote:
> What type of remote receiver are you using? I've had delays with some remotes 
> but not others:
> 
> 2. PCI Nova-T receiver through lirc: works much better than the USB receiver 
> but does feel as if there is a lag between pressing keys and things 
> happening. Does sometimes do the buffering thing mentioned above but nowhere 
> near as bad.

I got rid of this lag by disabling the asynchronously running repeat
timer in the kernel:

http://www.iki.fi/~msmakela/software/vdr/linux-2.6.15.2-cx88_input2.patch

The file ir-common.c has been renamed to ir-functions.c, but this
still applies cleanly to the 2.6.19.2 kernel.

I'm using the linuxinput driver of DirectFB via softdevice.  The remote
plugin adds a layer of abstraction.  If I remember correctly, it reduced
the repeat rate, but there wasn't any noticeable lag.  That is, I could
open up a long menu, such as the EPG, and navigate to the desired line
by pressing and holding the Down button.  Without my kernel patch, the
cursor would end up a few lines before or after the desired spot.

Marko

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] MLdkGUIStart.cpp:106: error: invalid lvalue in assignment

[h . h . braun]

When I compile the plugin I get :
MLdkGUIStart.cpp: In member function 'virtual eOSState
MLdkGUIStart::ProcessKey(eKeys)':
MLdkGUIStart.cpp:106: error: invalid lvalue in assignment


Cheers 
H.Braun

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Same Channel from DVB-C, DVB-T and channels.conf

[Tommi Lundell]

Hello

I'm cannot find information how i can tell to vdr that example following 
channels are one and same. (Is that even possible?)


Example 1:
YLE 
TV1;YLE:56200:I0C23D23M64B8T8G8Y0:T:0:512+128:650=fin:2321:0:17:8438:4097:0

and
TV1;YLE:274000:C0M128:C:6900:512+128:650=fin:2321:0:17:0:1:0

Example 2:
Subtv;SubTV 
Oy:65800:I0C23D23M64B8T8G8Y0:T:0:353:609=fin:865:0:97:8438:8193:0

and
subtv;Citytv Oy:282000:C0M128:C:6900:353:609=fin:865:0:97:0:2:0

And is there some way possible to prefer cable channels in recordings?

Tommi

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] error: extra qualification 'cOSDClock::' on member 'DrawModernSec'

[h . h . braun]

When I compile the plugin clock I get the following error :
 error: extra qualification 'cOSDClock::' on member 'DrawModernSec' 


Cheers 
H.Braun

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] error: extra qualification 'cOSDClock::' on member 'DrawModernSec'

[Reinhard Nissl]

Hi,

[EMAIL PROTECTED] wrote:

> When I compile the plugin clock I get the following error :
>  error: extra qualification 'cOSDClock::' on member 'DrawModernSec' 

I assume, the class definition of cOSDClock contains an entry

... cOSDClock::DrawModernSec ...

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

[vdr] error freecell

[h . h . braun]

When I compile freecell I get the folllowing errors: 
tools/list.h:93: error: declaration of 'operator+=' as non-function
tools/list.h:93: error: expected ';' before '<' token
tools/list.h:94: error: declaration of 'operator+=' as non-function
tools/list.h:94: error: expected ';' before '<' token
tools/list.h:96: error: declaration of 'operator+' as non-function
tools/list.h:96: error: expected ';' before '<' token
tools/list.h:97: error: declaration of 'operator+' as non-function
tools/list.h:97: error: expected ';' before '<' token
tools/list.h:98: error: declaration of 'operator+' as non-function
tools/list.h:98: error: expected ';' before '<' token
tools/list.h: In member function 'int cTBList::Find(const T&)':
tools/list.h:108: error: 'item' was not declared in this scope
tools/list.h: In member function 'typename cTBList::cItem* 
cTBList::NewItem(cTBList::cItem*, cTBList::cItem*) const':
tools/list.h:206: error: 'item' was not declared in this scope
tools/list.h:206: error: expected type-specifier
tools/list.h:206: error: expected `;'
tools/list.h: In member function 'typename cTBList::cItem* 
cTBList::Locate(uint)':
tools/list.h:238: error: 'item' was not declared in this scope
tools/list.h: In member function 'T& cTBList::Prepend()':
tools/list.h:274: error: 'item' was not declared in this scope
tools/list.h: In member function 'T& cTBList::Append()':
tools/list.h:288: error: 'item' was not declared in this scope
tools/list.h: In member function 'bool cTBList::Insert(uint, const T&)':
tools/list.h:320: error: 'nextItem' was not declared in this scope
tools/list.h:324: error: 'prevItem' was not declared in this scope
tools/list.h:326: error: 'item' was not declared in this scope
tools/list.h: In member function 'typename cTBList::cItem* 
cTBList::Unlink()':
tools/list.h:341: error: 'item' was not declared in this scope
tools/list.h: In member function 'bool cTBList::Remove(const T&)':
tools/list.h:373: error: 'item' was not declared in this scope
tools/list.h: In member function 'bool cTBList::Remove(uint)':
tools/list.h:386: error: 'item' was not declared in this scope
tools/list.h: In member function 'void cTBList::Clear()':
tools/list.h:415: error: 'item' was not declared in this scope
cards.c: In constructor 'cCardStack::cCardStack(int, int, bool)':
cards.c:55: error: 'time_ms' was not declared in this scope
tools/list.h: In member function 'void cTBList::Clear() [with T = cCard*]':
cards.c:81:   instantiated from here
tools/list.h:415: error: dependent-name 'cTBList::cItem' is parsed as a 
non-type, but instantiation yields a type
tools/list.h:415: note: say 'typename cTBList::cItem' if a type is meant
cards.c:81:   instantiated from here
tools/list.h:421: error: dependent-name 'cTBList::cItem' is parsed as a 
non-type, but instantiation yields a type
tools/list.h:421: note: say 'typename cTBList::cItem' if a type is meant
cards.c:81:   instantiated from here
tools/list.h:425: error: no matching function for call to 
'cTBList::DelItem()'
tools/list.h:223: note: candidates are: void 
cTBList::DelItem(cTBList::cItem*) const [with T = cCard*]
tools/list.h: In member function 'T& cTBList::Append() [with T = 
cTBString]':tools/list.h:307:   instantiated from 'void 
cTBList::Append(const T&) [with T = cTBString]'
tools/list.h:535:   instantiated from here
tools/list.h:288: error: dependent-name 'cTBList::cItem' is parsed as a 
non-type, but instantiation yields a type
tools/list.h:288: note: say 'typename cTBList::cItem' if a type is meant
tools/list.h: In member function 'T& cTBList::Append() [with T = cCard*]':
tools/list.h:307:   instantiated from 'void cTBList::Append(const T&) [with 
T = cCard*]'
cards.c:71:   instantiated from here
tools/list.h:288: error: dependent-name 'cTBList::cItem' is parsed as a 
non-type, but instantiation yields a type
tools/list.h:288: note: say 'typename cTBList::cItem' if a type is meant
tools/list.h: In member function 'typename cTBList::cItem* 
cTBList::Locate(uint) [with T = cCard*]':
tools/list.h:408:   instantiated from 'T cTBList::Take(uint) [with T = 
cCard*]'
cards.c:84:   instantiated from here
tools/list.h:238: error: dependent-name 'cTBList::cItem' is parsed as a 
non-type, but instantiation yields a type
tools/list.h:238: note: say 'typename cTBList::cItem' if a type is meant
tools/list.h: In member function 'typename cTBList::cItem* 
cTBList::NewItem(cTBList::cItem*, cTBList::cItem*) const [with T = 
cTBString]':
tools/list.h:288:   instantiated from 'T& cTBList::Append() [with T = 
cTBString]'
tools/list.h:307:   instantiated from 'void cTBList::Append(const T&) [with 
T = cTBString]'
tools/list.h:535:   instantiated from here
tools/list.h:206: error: dependent-name 'cTBList::cItem' is parsed as a 
non-type, but instantiation yields a type
tools/list.h:206: note: say 'typename cTBList::cItem' if a type is meant
tools/list.h: In member function 'typename cTBList::cItem* 
cTBList::Unlink() [with T = cCard*]':
tools/list.h:398:   instantiated from 'T cTBL

[vdr] error mldkgui compiled!

[h . h . braun]

When I compile mldkgui I get the following error:
MLdkGUIStart.cpp: In member function 'virtual eOSState
MLdkGUIStart::ProcessKey(eKeys)':
MLdkGUIStart.cpp:106: error: invalid lvalue in assignment
make[1]: *** [MLdkGUIStart.o] Fehler 1


Cheers 
H.Braun

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] error mldkgui compiled!

[jlacvdr]

Hi,

I known, I doesn't update this plugins to the last versions of vdr
Sorry,

Bye,


Le samedi 03 février 2007 à 16:36 +0100, [EMAIL PROTECTED] a écrit :
> When I compile mldkgui I get the following error:
> MLdkGUIStart.cpp: In member function 'virtual eOSState
> MLdkGUIStart::ProcessKey(eKeys)':
> MLdkGUIStart.cpp:106: error: invalid lvalue in assignment
> make[1]: *** [MLdkGUIStart.o] Fehler 1
> 
> 
> Cheers 
> H.Braun
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[VDR User]

On 2/2/07, martin <[EMAIL PROTECTED]> wrote:


 To be honest, i use BigPatch for just one reason. During playback, I can
jump 10 sec + / - with the "1" and "3" keys. I can't live without this
feature, because jumping 1 Minute is nice, but most of the times way too
long. So, actually, adding this 10 seconds jump to the main part, would also
help me a lot!


Maybe Klaus will let the skip-time be user-definable in a future version, or
maybe someone has already made a patch for it but for now why not just make
your own small patch for it rather than apply BigPatch?  I believe these are
the lines in menu.c to modify:

   case kGreen:   SkipSeconds(-60); break;
   case kYellow:  SkipSeconds( 60); break;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Same Channel from DVB-C, DVB-T and channels.conf

[Gavin Hamill]

On Saturday 03 February 2007 13:16, Tommi Lundell wrote:
> Hello
>
> I'm cannot find information how i can tell to vdr that example following
> channels are one and same. (Is that even possible?)

I've often wondered this and have posted about 'logical channels' here a 
couple of times... however, this might be useful for you:

http://www.linuxtv.org/pipermail/vdr/2006-August/010324.html

gdh

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

AW: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[martin]

Oh, thanks for the code reading. Hmm.. I can live with BigPatch, so I always
apply it.

 

martin

 

Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von
VDR User
Gesendet: Samstag, 3. Februar 2007 19:03
An: VDR Mailing List
Betreff: Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch
timer"

 

On 2/2/07, martin <[EMAIL PROTECTED]> wrote:

To be honest, i use BigPatch for just one reason. During playback, I can
jump 10 sec + / - with the "1" and "3" keys. I can't live without this
feature, because jumping 1 Minute is nice, but most of the times way too
long. So, actually, adding this 10 seconds jump to the main part, would also
help me a lot!

Maybe Klaus will let the skip-time be user-definable in a future version, or
maybe someone has already made a patch for it but for now why not just make
your own small patch for it rather than apply BigPatch?  I believe these are
the lines in menu.c to modify:

case kGreen:   SkipSeconds(-60); break;
case kYellow:  SkipSeconds( 60); break;



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] to record or not

[Reinhard Walter Buchner]

Hi,



Am Donnerstag 01 Februar 2007 23:42 schrieb abbe normal:
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 to the program...


Actually my Nessy Patch already did this years ag :o)). Selecting 
the "View Only" mode created a special timer. As soon as the

timer time was reached it let VDR switch to that channel. No
recording was started and the timer was deleted as soon as the
"switch to" channel was properly tuned to.

regards,
Reinhard

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [RFC] Shutdown rewrite for 1.5.x

[Reinhard Walter Buchner]

Hi,


But you surely would power the display off, to avoid burning the still
image on the CRT or plasma screen or to save the precious hours on the
lamp of your video beamer?  Or maybe you have a TFT screen and do not
care about wasting electricity?


Surely this shouldn't be too difficult to implement via a Plugin.

One could either simply blank out the screen after a configurable
time once the Pause button is pressed (and no other key). Another
idea would be to show a small OSD containing a configurable 
picture of one's on choice that is randomly placed and shown on

the main (large) OSD while blanking out the background. Maybe
as an extension of the Picture in Picture plugin or the Showpicture
plugin.

regards,
Reinhard

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] FF card AV sync problems, possible fix to VDR (fwd)

[Morfsta]

I lose sync on live tv as well as recordings and get the following in
/var/log/messages.

Feb  3 19:04:18 morfsta vdr: [6714] 1 cRepacker messages suppressed
Feb  3 19:04:18 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 584 bytes
while syncing on next audio frame
Feb  3 19:04:18 morfsta vdr: [3470] 1 cRepacker messages suppressed
Feb  3 19:04:18 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 584 bytes
while syncing on next audio frame
Feb  3 19:04:32 morfsta vdr: [6714] 1 cRepacker messages suppressed
Feb  3 19:04:32 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 588 bytes
to sync on next audio frame
Feb  3 19:04:32 morfsta vdr: [3470] 1 cRepacker messages suppressed
Feb  3 19:04:32 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 588 bytes
to sync on next audio frame

I made the mods to VDR as you suggested but haven't seen either entry in the
log file yet.

I want to try and isolate a recording sample shortly to give to Oliver, but
obviously there is nothing I can do about the live sync problem (you're
welcome to visit my house if you like!!!)

Regards

Morfsta

On 2/1/07, Reinhard Nissl <[EMAIL PROTECTED]> wrote:


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
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Vdr or driver performance dropout

[Kartsa]

Clemens Kirchgatterer kirjoitti:

Laz <[EMAIL PROTECTED]> wrote:

  

On Saturday 03 February 2007 10:13, Clemens Kirchgatterer wrote:


Marko Myllymaa <[EMAIL PROTECTED]> wrote:
  

Also this newer version does some weird busylooping or whatever
from time to time. Vdr gets all remote codes and buffers them,
but just starts executing them after ~45s. One time it took so
long, that I got ssh opened from other computer to restart vdr,
but vdr had recovered.


i can confirm this. i get the same delays in key processing very
frequently. i use also a low end machine - PII 233 MHz.
  

What type of remote receiver are you using? I've had delays with some
remotes but not others:



home brewed ir receiver on serial port using lirc. the same as you say
worked best for you. i'm sure the problem is not on the IR side but on
vdr, as that setup was not changed between vdr upgrades. 
  
I have home brewed also and I either do not think IR side is the 
problem. The delays became the longer the more recordings are on 
simultaneously. I just tested just to be sure that after second 
recording the playback of another recording starts to snap crackle and 
pop both sound and picture. Very small but noticeable. After third 
recording responces to remote are either very sluggish or in some remote 
actions nothing happens. And as I said earlier this behaviour is similar 
in PIII 550 and AMD 3000+.


And actually I think what ever is causing this may also be the reason 
for the AV sync problem I reported in another thread. I mean after the 
third recording AV sync is about all the time out of sync or atleast its 
no fun to watch. I'll report about this in the related thread.


\\Kartsa

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)

[Kartsa]

I also applied both of those changes and have not yet seen either of the 
errors in the log.


I do have thosa same log entrys as morfsta especially if I have more 
than two recordings going on while I am watching a previous recording.


\\Kartsa

Morfsta kirjoitti:
I lose sync on live tv as well as recordings and get the following in 
/var/log/messages.
 
Feb  3 19:04:18 morfsta vdr: [6714] 1 cRepacker messages suppressed
Feb  3 19:04:18 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 584 
bytes while syncing on next audio frame

Feb  3 19:04:18 morfsta vdr: [3470] 1 cRepacker messages suppressed
Feb  3 19:04:18 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 584 
bytes while syncing on next audio frame

Feb  3 19:04:32 morfsta vdr: [6714] 1 cRepacker messages suppressed
Feb  3 19:04:32 morfsta vdr: [6714] cAudioRepacker(0xC0): skipped 588 
bytes to sync on next audio frame

Feb  3 19:04:32 morfsta vdr: [3470] 1 cRepacker messages suppressed
Feb  3 19:04:32 morfsta vdr: [3470] cAudioRepacker(0xC0): skipped 588 
bytes to sync on next audio frame
 
I made the mods to VDR as you suggested but haven't seen either entry 
in the log file yet.
 
I want to try and isolate a recording sample shortly to give to 
Oliver, but obviously there is nothing I can do about the live sync 
problem (you're welcome to visit my house if you like!!!)
 
Regards
 
Morfsta
 
On 2/1/07, *Reinhard Nissl* <[EMAIL PROTECTED] > wrote:


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.




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[VDR User]

I've found the actual patch that is used in BigPatch in case you want just
that.  The thread is located at:

http://www.vdr-portal.de/board/thread.php?postid=68566

and the patch:

http://www.vdr-portal.de/board/attachment.php?attachmentid=1349
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] to record or not

[VDR User]

On 2/3/07, Reinhard Walter Buchner <[EMAIL PROTECTED]> wrote:


Actually my Nessy Patch already did this years ag :o)). Selecting
the "View Only" mode created a special timer. As soon as the
timer time was reached it let VDR switch to that channel. No
recording was started and the timer was deleted as soon as the
"switch to" channel was properly tuned to.

regards,
Reinhard



Is your patch compatible with the latest stable (1.4.5*) and developer (
1.5.0) versions?  Could you please post it up, I'd love to have a look.

Thanks.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] Fix EPG for UPC direct

[Thomas Günther]

Thiemo Gehrke wrote:
> UPC is a provider for middle european countries (Czechia, Hungary and
> Poland).  They use iso6937-2 for encoding their EPG data so this looks
> quite strange in  the vdr.
> The applied patch does a "remapping" to iso8859-2 so that characters
> are  displayed correct. (Currently only tested with Czech and
> Hungarian, but  should also work for Polish)

Here is an iconv version of the patch:
http://toms-cafe.de/vdr/download/vdr-epg-conv-iso6937-1.4.5.diff

Tom

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

AW: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch timer"

[martin]

Hi Klaus,

thanks for your input. I did some tests: actually I have a rather slow
Pentium M 1,7GHz with xine as frontend. I jumps at least 20 seconds, when
I'm lucky, sometimes even 30 seconds. This is too far for me. Stepping in 10
Seconds steps with a single click is more convenient for me.


Reagrds,
Martin


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von
Klaus Schmidinger
Gesendet: Samstag, 3. Februar 2007 10:43
An: vdr@linuxtv.org
Betreff: Re: [vdr] Feature Request: 10 Second Jump from BigPatch, "switch
timer"

martin wrote:
> To be honest, i use BigPatch for just one reason. During playback, I can
> jump 10 sec + / - with the “1” and “3” keys. I can’t live without this
> feature, because jumping 1 Minute is nice, but most of the times way too
> long. So, actually, adding this 10 seconds jump to the main part, would
> also help me a lot!

Why don't you just press FFWD/FREW shortly?

> PS: I changed the subject to the eMail, beause we have opened a new
> topic here.

Actually you should have started a new thread!

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr