alexw | 1 Dec 2009 10:20
Picon

Re: VDR frontend device: Xtreamer

On 11/29/2009 04:13 PM, Theunis Potgieter wrote:
> 2009/11/27 alexw<alexw <at> undercover.mine.nu>:
>    
>> Hi,
>>
>> I do.
>>
>>      
> Do you use an Xtreamer device as a frontend, what are you using to achive this?
>
>    

I am using a PCH-A110 device with vdr-ui running on a separate server 
(for better integration). Channels are served using the standard 
streamdev plugin.
The only drawback is the necessity to quit (close) the running stream 
and go back to the vdr-ui selection page each time you want to change to 
another channel.

I have managed to build a jsp playlist with all VDR channels, but 
channel change is not quick enough to bring a good `surfing` experience 
with this method.

Using xineliboutput you can watch the `live` stream and change channel 
without quitting the player but the mono pmt parser fails sometime to 
get the new pids (tested with soft and hard demuxerm. m2ts and pes 
container). I am convinced that this is the best way to have an 
acceptable switching time between 2 channels reusing existing player 
with low key/remote dev (directfb keyb app to redirect remote key to VDR 
app).
(Continue reading)

Darren Salt | 1 Dec 2009 17:30
Picon
Picon

Re: deinterlacing VDR-HD on xine?

I demand that Torgeir Veimo may or may not have written...

> 2009/12/1 Darren Salt <linux <at> youmustbejoking.demon.co.uk>:
>> http://hg.debian.org/hg/xine-lib/xine-lib-1.2-vdpau

> Does this version still inhibit the problem of freezing both audio and
> video for a brief moment after channel change, as a patched xine-lib 1.1
> does?

No idea. I don't have any nVidia graphics hardware.

--

-- 
| Darren Salt            | linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds    ,demon,co,uk    | Northumberland | Army
| + http://www.youmustbejoking.demon.co.uk/ & http://tlasd.wordpress.com/

Cogito cogito ergo cogito sum.

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Stephan Loescher | 3 Dec 2009 17:13
X-Face
Picon
Picon

Re: mdadm software raid5 arrays?

"Simon Baxter" <linuxtv <at> nzbaxters.com> writes:

> Anyway, I've bought 3x 1.5 TB SATA disks which I'd like to put into a
> software (mdadm) raid 5 array.

[...]

> But does anyone have any production VDR experience with mdadm - good or bad?

If you like good performance and simple recovery, then do not use
RAID5. Use RAID1 instead.

I use RAID5 only because I am too lazy to buy some new and larger disks
for my VDR at the moment :-)

I have had serious performance-problems with parallel recordings and
some Linux-background-jobs (like system-backup).
I solved it by raising the I/O-priority of vdr with ionice:

ionice -c2 -n0 vdr -w 120 -v $VIDEODIR -d -t /dev/tty5 -g /tmp ...

Stephan.

--

-- 
loescher <at> gmx.de
http://www.loescher-online.de/
Try LEO: http://www.leo.org/

_______________________________________________
vdr mailing list
(Continue reading)

Simon Baxter | 3 Dec 2009 19:40

Re: mdadm software raid5 arrays?

>> But does anyone have any production VDR experience with mdadm - good or 
>> bad?

I've now tested and implemented RAID5 on my system.  The biggest CPU hit is 
still with the OSD or noad processes - below is a bunch of tests I ran and 
the top processes during the test:

1 recording to raid, watching another live
top - 07:52:18 up 1 day, 20:29,  3 users,  load average: 0.66, 0.54, 0.42
Tasks: 168 total,   2 running, 156 sleeping,  10 stopped,   0 zombie
Cpu(s): 20.2%us,  6.7%sy,  0.5%ni, 68.3%id,  1.5%wa,  0.5%hi,  2.4%si, 
0.0%st
Mem:   2059352k total,  2038636k used,    20716k free,    19724k buffers
Swap:  1903692k total,      292k used,  1903400k free,  1412672k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2372 vdruser   20   0  542m  37m  18m S 37.1  1.9   1:09.50 xine
 2330 vdruser   20   0  486m  26m 4616 S 10.6  1.3   0:21.68 vdr
 3020 root      20   0  369m  24m  18m R  9.6  1.2 157:51.36 Xorg
 3521 vdruser   20   0  923m 306m  25m S  1.0 15.3  50:59.10 mms
 3723 root      15  -5     0    0    0 S  0.7  0.0  10:12.08 md0_raid5
 2455 root      20   0 14880 1188  872 R  0.3  0.1   0:00.32 top
 2593 root      15  -5     0    0    0 S  0.3  0.0   1:04.10 kdvb-ca-1:0
 3168 vdruser   20   0  139m 5468 3984 S  0.3  0.3   6:03.34 fluxbox

2 recording to raid, watching another live
top - 07:55:09 up 1 day, 20:32,  3 users,  load average: 1.67, 1.00, 0.61
Tasks: 168 total,   1 running, 157 sleeping,  10 stopped,   0 zombie
Cpu(s): 21.8%us,  7.8%sy,  0.3%ni, 66.6%id,  0.7%wa,  0.7%hi,  2.1%si, 
0.0%st
(Continue reading)

Simon Baxter | 3 Dec 2009 19:44

Re: vdpau setup steps for vdr client

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

VDR User | 3 Dec 2009 21:01
Picon

Re: vdpau setup steps for vdr client

On Thu, Dec 3, 2009 at 10:44 AM, Simon Baxter <linuxtv <at> nzbaxters.com> wrote:
> 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.

Maybe your problem is an outdated alsa or something like that?  I use
vdpau with vdr-1.7.10 and xine-0.9.3 with no sync problems.  I also
didn't have to edit ~/.xine/config as the default settings worked
fine.  I agree your issues are elsewhere then vdr or vdpau.

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

mike n | 4 Dec 2009 09:22
Picon
Favicon

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

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.
_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Theunis Potgieter | 4 Dec 2009 10:52
Picon

Re: vdpau setup steps for vdr client

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

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Pertti Kosunen | 4 Dec 2009 12:31
Picon
Picon

Re: vdpau setup steps for vdr client

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

Simon Baxter | 4 Dec 2009 20:35

Re: vdpau setup steps for vdr client

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

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Gmane