[vdr] VDR 1.7.x and unstable DVBT locking on channe (breaks after 60secs)l?

2009-12-04 Thread mike n

Hello,

 

I have been testing the latest VDR 1.7.10 and 1.7.5 versions and both have 
following problem I haven't seen on VDR 1.6.x version. 

 

The problem is that after starting VDR (with or without OSD GUI frontend), it 
looses a lock on channel after 60 seconds or so. 

 

If I have local or remote xinelibout GUI watching the live-tv then at first 
picture goes to garbage (lots of blocky artifacts) and after few seconds it 
freezes completely. OSD and VDR itself is still functional, but livetv picture 
is static picture. Or sometimes VDR all in a sudden shows a picture from 
another channel even when I didn't change channel (static picture with lots of 
blocky artifacts). To me it looks like VDR changed tuner to another MUX (I have 
4 DVBT muxes here or whatever the proper term is for those "channel groups") 
when static picture changes. 

 

This happens every time when I start VDR. Restart of VDR fixes the problem 
immediatly, but after 60 seconds booom again. When this happens, Xineliboutput 
console shows following text:

  "no data in 8 seconds. queing no signal image" 

 

 

If I use ZAP dvb-apps tool to save a channel output to a tempfile.ts file 
output, it works beatifully all day long. It doesn't loose lock on a channel 
and picture quality is perfect (no artifacts).

 

I have tried two different computers and two USB DVBT tuners and the problem is 
the same in all of these, so I assume it is not hardware related. It shouldn't 
be signal related either because ZAP saves perfect TS stream output all night 
long.

 

Is there some worker process which kicks in VDR every 60 seconds? Maybe EPG 
related process? For some reason I suspect that VDR starts to scan through EPG 
data even when I'm watching live-tv. This would explain why it seems that 
sometimes it tuned to another mux. When I start VDR, there is no cached EPG 
data file because it goes to TMP folder and tmp is cleared everytime machine 
boots up. 

 

Environment is as follows

- Linux kernel 2.6.31.1

- DVBT Reddo usb stick and Twinhan DVBT stick tested

- VDR 1.7.10 and 1.7.5 versions tested

- Xineliboutput latest CVS version as frontend (doesnt matter even when I start 
VDR in background without GUI frontend. Problem is the same)

 

I'm able to code/debug/read source code quite fluently, so I'm happy to help 
debug this if someone could point me to right direction where to look for this 
"60 secs timeout/worker process" issue in VDR.

 

Anyone any ideas?

 

Thanks in advance,

 Mike N

 
  
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] vdpau setup steps for vdr client

2009-12-04 Thread Theunis Potgieter
I experience the audio sync problems when I fast forward or rewind
recordings, or when I press green/yellow (jump 1 minute back/forward) or
press 7 or 9 between markings, this is however the problem with
xineliboutput. Only way to fix playback audiosync is by pressing the red
button (jump to a specific time). All the xineliboutput versions seems to do
this and, xine-lib-1.2 also does this. problem must be with the plug-in it
self and similar to yours?

2009/12/3 Simon Baxter 

> I wouldn't bother upgrading, to be honest.
>>
>> I've had several attempts to upgrade to 1.7 and VDPAU - but consistently
>> get audio/video sync problems with live video and issues with indexing
>> during rewinding/forwarding during playback.  Have spent more hours than I
>> care to say trying to fix this, only to downgrade again.
>>
>> vdr-1.6.0 and xine-0.8.0 work just fine for me!!
>>
>
> To be fair to my comment above, I've had audio sync problems with live TV
> on all versions above vdr-xine-0.8.0 which is why I've never been able to
> run a newer version in production.  I've had several posts on this and tried
> everything anyone has suggested - but after an hour or my wife banging on
> about the poor quality, always downgrade back to VDR-1.6.0 and
> VDR-XINE-0.8.0
>
> So I don't think my problems are related to VDPAU or VDR-1.7.x.
>
>
> -Simon
>
> ___
> 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] vdpau setup steps for vdr client

2009-12-04 Thread Pertti Kosunen

Theunis Potgieter wrote:
button (jump to a specific time). All the xineliboutput versions seems 
to do this and, xine-lib-1.2 also does this. problem must be with the 
plug-in it self and similar to yours?


audio.synchronization.av_sync_method:resample
audio.synchronization.resample_mode:off

Try with these options in xine's config.

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


Re: [vdr] vdpau setup steps for vdr client

2009-12-04 Thread Simon Baxter
I have two problems with playback:  
First main problem is audio sync, which while playing a recording the audio 
slips further and further out of sync after 5 or more minutes.  Then the video 
skips to catch up and I get a gap in the program (very disconcerting when 
you're trying to follow the programme!!).  These skips seem to occur 
coincidentally when console messages say "buffered 6.3 frames (v:10.9, a:6.3)"

Second problem is more similar to several other people, and possibly yours, 
where if I FF/REW a playback, when I hit play again it jumps "minutes" making 
FF/REW very inaccurant.


  I experience the audio sync problems when I fast forward or rewind 
recordings, or when I press green/yellow (jump 1 minute back/forward) or press 
7 or 9 between markings, this is however the problem with xineliboutput. Only 
way to fix playback audiosync is by pressing the red button (jump to a specific 
time). All the xineliboutput versions seems to do this and, xine-lib-1.2 also 
does this. problem must be with the plug-in it self and similar to yours?


  2009/12/3 Simon Baxter 

  I wouldn't bother upgrading, to be honest.

  I've had several attempts to upgrade to 1.7 and VDPAU - but consistently 
get audio/video sync problems with live video and issues with indexing during 
rewinding/forwarding during playback.  Have spent more hours than I care to say 
trying to fix this, only to downgrade again.

  vdr-1.6.0 and xine-0.8.0 work just fine for me!!



To be fair to my comment above, I've had audio sync problems with live TV 
on all versions above vdr-xine-0.8.0 which is why I've never been able to run a 
newer version in production.  I've had several posts on this and tried 
everything anyone has suggested - but after an hour or my wife banging on about 
the poor quality, always downgrade back to VDR-1.6.0 and VDR-XINE-0.8.0

So I don't think my problems are related to VDPAU or VDR-1.7.x.


-Simon 


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