Artur Skawina | 1 Apr 01:05 2008
Picon

Re: Problems playing ongoing recordings?

Alexw wrote:
>>> Sometimes the player stops in the middle of a recording due to a zero size request. Here is the log:
>>>
>>> vdr: [3836] dvbplayer thread started (pid=3643, tid=3836)
>>> vdr: [3836] resuming replay at index 1950 (0:01:18.01)
>>> vdr: [3837] non blocking file reader thread started (pid=3643, tid=3837)
>>> vdr: [3836] SetBrokenLink: no GOP header found in video packet
>>> vdr: [3836] setting audio track to 1 (0)
>>> vdr: [3836] playing '/var/vdr/video/SERVER/recording/2008-03-28.18.58.50.50.rec/001.vdr'
>>>
>>> <<<unexpect stop of replay>>>
>>>
>>> vdr: [3837] non blocking file reader thread ended (pid=3643, tid=3837)
>>> vdr: [3836] dvbplayer thread ended (pid=3643, tid=3836)

>>> vdr: [5618] WANT: fd: 25 1068536495 .. 1068722913 SIZE: 186418
>>> vdr: [5618] READ: fd: 25 1068536495 .. 1068666704 SIZE: 130209 jump:         0 ra: 12582912
>>> vdr: [5618] WANT: fd: 25 1068666704 .. 1068983331 SIZE: 316627
>>> vdr: [5618] READ: fd: 25 1068666704 .. 1068680058 SIZE:  13354 jump:         0 ra: 12582912
>>> vdr: [5618] READ: fd: 25 1068680058 .. 1068690344 SIZE:  10286 jump:         0 ra: 12582912
>>> vdr: [5618] READ: fd: 25 1068690344 .. 1068721839 SIZE:  31495 jump:         0 ra: 12582912
>>> vdr: [5618] READ: fd: 25 1068721839 .. 1069246127 SIZE: 524288 jump:         0 ra: 12582912
>>> vdr: [5618] WANT: fd: 25 1069246127 .. 1070294703 SIZE: 1048576
>>> vdr: [5618] READ: fd: 25 1069246127 .. 1069246127 SIZE:      0 jump:         0 ra: 12582912
>>> vdr: [5618] non blocking file reader thread ended (pid=5563, tid=5618)
>>> vdr: [5617] dvbplayer thread ended (pid=5563, tid=5617)
>>>     
>> Weird, cUnbufferedFile::Read(Size=0). I'll try to reproduce this.
>>   
> Sometimes it take a long time to occur, sometimes not.
(Continue reading)

Dominique Simon | 1 Apr 10:02 2008
Picon
Picon

Re: vdr-1.6.0 and syncearly


Am 27.03.2008 um 21:01 schrieb Reinhard Nissl:
> I'd say it's suggested. At least it is part of my H.264 patches.

What does the sync early patch do?

Ciao, Dominique

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

Reinhard Nissl | 1 Apr 18:46 2008
Picon
Picon

Re: vdr-1.6.0 and syncearly

Hi,

Dominique Simon schrieb:

>> I'd say it's suggested. At least it is part of my H.264 patches.
> 
> What does the sync early patch do?

Vanilla VDR waits for an I frame before it passes video (and 
audio) data on to output devices. Further more, audio data is 
still not passed on from that time, because VDR takes some time 
to decide which audio track shall get selected.

The sync early patch addresses these issues. Audio and video 
packets are passed on a soon as they make up a valid frame. The 
result is that you can already hear the audio track before the 
video appears on screen. This is because video decoding can only 
start with an I frame. Any frames before the I frame won't appear 
on screen.

But passing these frames to the output device has the benefit 
that PTS' (presentation time stamp) for these frames are passed 
on to the output device which needs this information to 
synchronize audio and video. As a result, audio and video will be 
in sync already when the first image appears on screen.

That's why the patch got called "sync early".

Bye.
--

-- 
(Continue reading)

Reinhard Nissl | 1 Apr 21:07 2008
Picon
Picon

Re: [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.18

Hi,

Reinhard Nissl schrieb:

> attached you'll find updated patches for VDR-1.5.18.
> 
> The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR
> (based on VDR-1.5.14) and requires to use the DVB drivers
> from the multi-proto tree (see URL below for further details).
> 
> The other patch is without DVB-S2 support and therefore most
> suitable for DVB-C users.
> 
> VDR-1.5.14 reported changes to transponder data incorrectly. The
> attached dvbs2 patch contains a fix for this issue by introducing
> TransponderDataToString().
> 
> The patch includes now the formerly addon patch which fixed building 
> after recent multiproto changes.

The attached addon patch fixes a logic error in 
cIteratorImplSourceNidTid. The error caused VDR to skip updating 
transponder information for almost all channels.

The error is not related to DVB-S2 nor H.264 but slipped into 
these patches at the time when I extended the patches to contain 
formerly released speedup patches.

> Have a look at this page for more instructions on this concern:
> 
(Continue reading)

JJussi | 1 Apr 16:44 2008

Re: Problems playing ongoing recordings?

This kind of "problems" I had too.. 
When I report that playback is going faster than recording. I.e. you start 
recording and after awhile (maybe only 10 second) you start playback of that 
recording.  Because playback is faster that "real life" you reach (in some 
poin of time) place where you are 0 (zero) seconds behind on going recording.  
AND in that point your playback start freeze and jump loop.

--

-- 
JJussi

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

VDR User | 2 Apr 04:11 2008
Picon

Re: Problems playing ongoing recordings?

On Tue, Apr 1, 2008 at 7:44 AM, JJussi <linux-dvb <at> jjussi.com> wrote:
>  recording.  Because playback is faster that "real life" you reach (in some
>  poin of time) place where you are 0 (zero) seconds behind on going recording.
>  AND in that point your playback start freeze and jump loop.

Playback is faster then watching live tv?!  Maybe if you skip past the
commercials or something!  I've started playing back a recording many
times before it was finished and never had a problem with lockup or
that the playback was going faster then live tv!

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

Theunis Potgieter | 2 Apr 08:59 2008
Picon

Re: Problems playing ongoing recordings?

I guess what Jjusi is explaining is that some Broadcasters (wrong
frame/sec) or in the event of bad reception etc, it can occur that
some frames are lost, and/or because vdr plays back from a more
reliable source e.g. from disk it will catch up to live tv eventualy.
I've experienced this on my dvb-s system.

On 4/2/08, VDR User <user.vdr <at> gmail.com> wrote:
> On Tue, Apr 1, 2008 at 7:44 AM, JJussi <linux-dvb <at> jjussi.com> wrote:
> >  recording.  Because playback is faster that "real life" you reach (in
> some
> >  poin of time) place where you are 0 (zero) seconds behind on going
> recording.
> >  AND in that point your playback start freeze and jump loop.
>
> Playback is faster then watching live tv?!  Maybe if you skip past the
> commercials or something!  I've started playing back a recording many
> times before it was finished and never had a problem with lockup or
> that the playback was going faster then live tv!
>
> _______________________________________________
> vdr mailing list
> vdr <at> linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

--

-- 
Sent from Gmail for mobile | mobile.google.com

_______________________________________________
vdr mailing list
(Continue reading)

JJussi | 2 Apr 09:18 2008

Re: Problems playing ongoing recordings?

On Wednesday, 2. Aprilta 2008 05:11:37 VDR User wrote:

> Playback is faster then watching live tv?!  Maybe if you skip past the
> commercials or something!  I've started playing back a recording many
> times before it was finished and never had a problem with lockup or
> that the playback was going faster then live tv!

Yes.. Check that attached message OR search subtitle "Playback to fast.." from 
archives.
Clements Kirchgatterer said that, that's normal...

--

-- 
JJussi
From: JJussi <linux-dvb <at> jjussi.com>
Subject: [vdr] Playback too fast..
Date: 2007-12-05 15:57:21 GMT
Hi!
Have anybody notice that playback is little bit too fast..  Here easy way to 
determit that..

1. Select channel X and press REC to start recording
2. Change channel to Y
3. Start playback of recording of point 1.
4. Press Enter to get progress bar.  Make note how many seconds behind you are 
(Continue reading)

Halim Sahin | 2 Apr 13:30 2008
Picon

ac3 handling in cutted vdr recordings

Hello,
I have experienced a strange problem with vdr recordings after cutting
them in vdr.

My recording has e. G. two mpeg audio, 1 mpeg video and one ac3
audiotrack.
Then I have tried to burn a dvd-video using replex |dvdauthor &&
growisofs

Problem:
The ac3 audiotrack was not recognized by replex at the first time.
Adjusting the first cuttingmark changed this behaviour.
The problem does not exist any more if the first cuttingmark in vdr was
placed at another position (using 4/6 on my remote).

My question:
Whats wrong here?
I don't want to use another utility to cut vdr recordings to get a
valid file for replex!!!

Thanks
have a nice day.
Halim

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

(Continue reading)

Artur Skawina | 2 Apr 13:37 2008
Picon

Re: Problems playing ongoing recordings?

JJussi wrote:
> On Wednesday, 2. Aprilta 2008 05:11:37 VDR User wrote:
> 
>> Playback is faster then watching live tv?!  Maybe if you skip past the
>> commercials or something!  I've started playing back a recording many
>> times before it was finished and never had a problem with lockup or
>> that the playback was going faster then live tv!
> 
> Yes.. Check that attached message OR search subtitle "Playback to fast.." from 
> archives.
> Clements Kirchgatterer said that, that's normal...

Small drift is expected -- the clock used as reference for playback (on
dvb/dxr card etc) is not synced to the one used by the broadcaster. 
It's a similar problem to trying to record audio using one sound card
and playing it back using another card in real time -- at some point you
will get either over- or underruns because the sample rates are not 100%
identical.

I suspect some of the issues when playing ongoing recordings just after
they are extended are caused by the recorder telling the system to drop
the recently written data and this is interfering with the readahead
done by the player, which then has to wait for the data to be refetched
from disk. O_DIRECT helps here (by not using the cache at all), OTOH
it could cause playback problems at the very end (due to the small delay
and larger chunks used when extending the file)

artur

_______________________________________________
(Continue reading)


Gmane