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/soc...
On 04.12.2009 09:22, mike n wrote:
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.
VDR does start scanning for EPG data after a while if inactivity. To rule out this one, please set "EPG scan timeout" to 0 in the "Setup/EPG" menu.
Klaus
-
Klaus Schmidinger -
mike n