LinuxTV Patchwork Fix for recording problem in VDR 1.7.20

login
register
mail settings
Submitter Klaus Schmidinger
Date Aug. 19, 2011, 4:43 p.m.
Message ID <4E4E9297.5060509@tvdr.de>
Download mbox | patch
Permalink /patch/12900/
State New
Headers show

Comments

Klaus Schmidinger - Aug. 19, 2011, 4:43 p.m.
There have been some reports about recording problems with VDR 1.7.20
on some HD channels.
This patch should fix this.

Klaus
André Weidemann - Aug. 21, 2011, 8:20 p.m.
Hi Klaus,

On 19.08.2011 18:43, Klaus Schmidinger wrote:
> There have been some reports about recording problems with VDR 1.7.20
> on some HD channels.
> This patch should fix this.
>
> Klaus
>
>
> --- remux.c 2011/08/15 09:50:14 2.58
> +++ remux.c 2011/08/19 15:33:26
> @@ -974,8 +974,10 @@
> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
> if (payloadUnitOfFrame != 0 && independentFrame)
> payloadUnitOfFrame = 0;
> - if (payloadUnitOfFrame)
> + if (payloadUnitOfFrame) {
> + newPayload = false;
> newFrame = false;
> + }
> }
> if (framesPerPayloadUnit <= 1)
> scanning = false;

Would the log messages look like this without above patch?

Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of 
payload - buffering
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type 
buffer (23312 > 940) - dropped 23124 bytes
Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type 
buffer (3948 > 940) - dropped 3572 bytes
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type 
buffer (24816 > 940) - dropped 24440 bytes
Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type 
buffer (26696 > 940) - dropped 26508 bytes
Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type 
buffer (20492 > 940) - dropped 20116 bytes
Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type 
buffer (20492 > 940) - dropped 20304 bytes


Regards
  André
Klaus Schmidinger - Aug. 21, 2011, 8:28 p.m.
On 21.08.2011 22:20, André Weidemann wrote:
> Hi Klaus,
>
> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>> There have been some reports about recording problems with VDR 1.7.20
>> on some HD channels.
>> This patch should fix this.
>>
>> Klaus
>>
>>
>> --- remux.c 2011/08/15 09:50:14 2.58
>> +++ remux.c 2011/08/19 15:33:26
>> @@ -974,8 +974,10 @@
>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
>> if (payloadUnitOfFrame != 0 && independentFrame)
>> payloadUnitOfFrame = 0;
>> - if (payloadUnitOfFrame)
>> + if (payloadUnitOfFrame) {
>> + newPayload = false;
>> newFrame = false;
>> + }
>> }
>> if (framesPerPayloadUnit <= 1)
>> scanning = false;
>
> Would the log messages look like this without above patch?
>
> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of payload - buffering
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (23312 > 940) - dropped 23124 bytes
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data!
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (3948 > 940) - dropped 3572 bytes
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (24816 > 940) - dropped 24440 bytes
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data!
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (26696 > 940) - dropped 26508 bytes
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data!
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (20492 > 940) - dropped 20116 bytes
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data!
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (20492 > 940) - dropped 20304 bytes

Those were the reports I got from users.

Klaus
VDR User - Aug. 21, 2011, 11 p.m.
On Sun, Aug 21, 2011 at 1:20 PM, André Weidemann <Andre.Weidemann@web.de> wrote:
> Would the log messages look like this without above patch?
>
> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of payload -
> buffering
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer
> (23312 > 940) - dropped 23124 bytes
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
> buffering - dropping some data!
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer
> (3948 > 940) - dropped 3572 bytes
> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer
> (24816 > 940) - dropped 24440 bytes

I had massive amounts of those log messages and all of my recordings
were empty.  This was fixed by the patch Klaus posted.  I expect the
same will be true for you as well after applying the patch.  Only one
way to find out!
Dirk Vornheder - Aug. 29, 2011, 8:30 p.m.
>>
>> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>>> There have been some reports about recording problems with VDR 1.7.20
>>> on some HD channels.
>>> This patch should fix this.
>>>
>>> Klaus
>>>
>>>
>>> --- remux.c 2011/08/15 09:50:14 2.58
>>> +++ remux.c 2011/08/19 15:33:26
>>> @@ -974,8 +974,10 @@
>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
>>> if (payloadUnitOfFrame != 0 && independentFrame)
>>> payloadUnitOfFrame = 0;
>>> - if (payloadUnitOfFrame)
>>> + if (payloadUnitOfFrame) {
>>> + newPayload = false;
>>> newFrame = false;
>>> + }
>>> }
>>> if (framesPerPayloadUnit <= 1)
>>> scanning = false;
>>
>> Would the log messages look like this without above patch?
>>
>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
>> payload - buffering
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>> buffer (23312 > 940) - dropped 23124 bytes
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>> buffering - dropping some data!
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>> buffer (3948 > 940) - dropped 3572 bytes
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>> buffer (24816 > 940) - dropped 24440 bytes
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>> buffering - dropping some data!
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>> buffer (26696 > 940) - dropped 26508 bytes
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>> buffering - dropping some data!
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>> buffer (20492 > 940) - dropped 20116 bytes
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>> buffering - dropping some data!
>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>> buffer (20492 > 940) - dropped 20304 bytes
>
> Those were the reports I got from users.
>
> Klaus
>

Patch for remux.c doesn't fix the problem if i use my Hauppauge 
PVR-cards 500 !

With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.

Aug 29 22:07:44 pcneu vdr: [20700] record 
/video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory 
/video0/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [20700] recording to 
'/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
Aug 29 22:07:44 pcneu vdr: [20700] creating directory 
/video4/ZIB_2/2011-08-29.21.57.13-0.rec
Aug 29 22:07:44 pcneu vdr: [21580] recording thread started (pid=20700, 
tid=21580)
Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread started 
(pid=20700, tid=21581)
Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 - 
accepted
Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread 
started (pid=20700, tid=21582)
Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of 
payload - buffering
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type 
buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type 
buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type 
buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type 
buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type 
buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while 
buffering - dropping some data!
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type 
buffer (2444 > 940) - dropped 2444 bytes
Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while 
buffering - dropping some data!


Dirk
Klaus Schmidinger - Aug. 29, 2011, 8:49 p.m.
On 29.08.2011 22:30, Dirk Vornheder wrote:
>
>>>
>>> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>>>> There have been some reports about recording problems with VDR 1.7.20
>>>> on some HD channels.
>>>> This patch should fix this.
>>>>
>>>> Klaus
>>>>
>>>>
>>>> --- remux.c 2011/08/15 09:50:14 2.58
>>>> +++ remux.c 2011/08/19 15:33:26
>>>> @@ -974,8 +974,10 @@
>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
>>>> if (payloadUnitOfFrame != 0 && independentFrame)
>>>> payloadUnitOfFrame = 0;
>>>> - if (payloadUnitOfFrame)
>>>> + if (payloadUnitOfFrame) {
>>>> + newPayload = false;
>>>> newFrame = false;
>>>> + }
>>>> }
>>>> if (framesPerPayloadUnit <= 1)
>>>> scanning = false;
>>>
>>> Would the log messages look like this without above patch?
>>>
>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
>>> payload - buffering
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>> buffer (23312 > 940) - dropped 23124 bytes
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>> buffering - dropping some data!
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>> buffer (3948 > 940) - dropped 3572 bytes
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>> buffer (24816 > 940) - dropped 24440 bytes
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>> buffering - dropping some data!
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>> buffer (26696 > 940) - dropped 26508 bytes
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>> buffering - dropping some data!
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>> buffer (20492 > 940) - dropped 20116 bytes
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>> buffering - dropping some data!
>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>> buffer (20492 > 940) - dropped 20304 bytes
>>
>> Those were the reports I got from users.
>>
>> Klaus
>>
>
> Patch for remux.c doesn't fix the problem if i use my Hauppauge PVR-cards 500 !
>
> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>
> Aug 29 22:07:44 pcneu vdr: [20700] record /video0/ZIB_2/2011-08-29.21.57.13-0.rec
> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2/2011-08-29.21.57.13-0.rec
> Aug 29 22:07:44 pcneu vdr: [20700] recording to '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2/2011-08-29.21.57.13-0.rec
> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started (pid=20700, tid=21580)
> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread started (pid=20700, tid=21581)
> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 - accepted
> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread started (pid=20700, tid=21582)
> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of payload - buffering
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes
> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data!

Can you please provide a 1 minute VDR recording from that device (made with the most recent
developer version that works for you) and tell me where to download it?

Klaus
Dirk Vornheder - Aug. 29, 2011, 9:02 p.m.
>>
>> Patch for remux.c doesn't fix the problem if i use my Hauppauge
>> PVR-cards 500 !
>>
>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>>
>> Aug 29 22:07:44 pcneu vdr: [20700] record
>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>> Aug 29 22:07:44 pcneu vdr: [20700] recording to
>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec
>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
>> (pid=20700, tid=21580)
>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
>> started (pid=20700, tid=21581)
>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
>> - accepted
>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
>> started (pid=20700, tid=21582)
>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
>> payload - buffering
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>
> Can you please provide a 1 minute VDR recording from that device (made
> with the most recent
> developer version that works for you) and tell me where to download it?
>

I doesn't know a ftp server where i can upload the 111 mb file.


Dirk
Arthur Konovalov - Aug. 30, 2011, 4:53 a.m.
30.08.2011 0:02, Dirk Vornheder kirjutas:
>
>>>
>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge
>>> PVR-cards 500 !
>>>
>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>>>
>>> Aug 29 22:07:44 pcneu vdr: [20700] record
>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to
>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec
>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
>>> (pid=20700, tid=21580)
>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
>>> started (pid=20700, tid=21581)
>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
>>> - accepted
>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
>>> started (pid=20700, tid=21582)
>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
>>> payload - buffering
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>> type buffer (2444 > 940) - dropped 2444 bytes
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>>> while buffering - dropping some data!
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>> type buffer (2444 > 940) - dropped 2444 bytes
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>>> while buffering - dropping some data!
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>> type buffer (2444 > 940) - dropped 2444 bytes
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>>> while buffering - dropping some data!
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>> type buffer (2444 > 940) - dropped 2444 bytes
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>>> while buffering - dropping some data!
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>> type buffer (2444 > 940) - dropped 2444 bytes
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>>> while buffering - dropping some data!
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>> type buffer (2444 > 940) - dropped 2444 bytes
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>>> while buffering - dropping some data!
>>
>> Can you please provide a 1 minute VDR recording from that device (made
>> with the most recent
>> developer version that works for you) and tell me where to download it?
>>
>
> I doesn't know a ftp server where i can upload the 111 mb file.

You can use any of filesharing providers. Rapidshare, for example. It 
allows up to 200MB file.

A.
Dirk Vornheder - Aug. 30, 2011, 5:40 p.m.
Am 29.08.2011 22:49, schrieb Klaus Schmidinger:
> On 29.08.2011 22:30, Dirk Vornheder wrote:
>>
>>>>
>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>>>>> There have been some reports about recording problems with VDR 1.7.20
>>>>> on some HD channels.
>>>>> This patch should fix this.
>>>>>
>>>>> Klaus
>>>>>
>>>>>
>>>>> --- remux.c 2011/08/15 09:50:14 2.58
>>>>> +++ remux.c 2011/08/19 15:33:26
>>>>> @@ -974,8 +974,10 @@
>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
>>>>> if (payloadUnitOfFrame != 0 && independentFrame)
>>>>> payloadUnitOfFrame = 0;
>>>>> - if (payloadUnitOfFrame)
>>>>> + if (payloadUnitOfFrame) {
>>>>> + newPayload = false;
>>>>> newFrame = false;
>>>>> + }
>>>>> }
>>>>> if (framesPerPayloadUnit <= 1)
>>>>> scanning = false;
>>>>
>>>> Would the log messages look like this without above patch?
>>>>
>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
>>>> payload - buffering
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>> buffer (23312 > 940) - dropped 23124 bytes
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>>> buffering - dropping some data!
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>> buffer (3948 > 940) - dropped 3572 bytes
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>> buffer (24816 > 940) - dropped 24440 bytes
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>>> buffering - dropping some data!
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>> buffer (26696 > 940) - dropped 26508 bytes
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>>> buffering - dropping some data!
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>> buffer (20492 > 940) - dropped 20116 bytes
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while
>>>> buffering - dropping some data!
>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>> buffer (20492 > 940) - dropped 20304 bytes
>>>
>>> Those were the reports I got from users.
>>>
>>> Klaus
>>>
>>
>> Patch for remux.c doesn't fix the problem if i use my Hauppauge
>> PVR-cards 500 !
>>
>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>>
>> Aug 29 22:07:44 pcneu vdr: [20700] record
>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>> Aug 29 22:07:44 pcneu vdr: [20700] recording to
>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec
>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
>> (pid=20700, tid=21580)
>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
>> started (pid=20700, tid=21581)
>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
>> - accepted
>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
>> started (pid=20700, tid=21582)
>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
>> payload - buffering
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>> type buffer (2444 > 940) - dropped 2444 bytes
>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload
>> while buffering - dropping some data!
>
> Can you please provide a 1 minute VDR recording from that device (made
> with the most recent
> developer version that works for you) and tell me where to download it?
>
> Klaus
>

The upload to Sigi's FTP-Server has finished.

The filename is problemvdr1720pvr3sat00001.ts !


Dirk
L. Hanisch - Aug. 30, 2011, 6:05 p.m.
Hi,

Am 30.08.2011 19:40, schrieb Dirk Vornheder:
> The upload to Sigi's FTP-Server has finished.
>
> The filename is problemvdr1720pvr3sat00001.ts !

  Since it's not impossible that the TS generated by pvrinput may be incorrect, which version of ivtv and pvrinput do 
you use?

Lars.

>
>
> Dirk
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
Dirk Vornheder - Aug. 30, 2011, 6:22 p.m.
>
> Am 30.08.2011 19:40, schrieb Dirk Vornheder:
>> The upload to Sigi's FTP-Server has finished.
>>
>> The filename is problemvdr1720pvr3sat00001.ts !
>
> Since it's not impossible that the TS generated by pvrinput may be
> incorrect, which version of ivtv and pvrinput do you use?
>
> Lars.
>

I use ivtv from linux kernel 3.0.3 and git-version of pvrinput.

Dirk
Klaus Schmidinger - Sept. 2, 2011, 2:08 p.m.
On 30.08.2011 19:40, Dirk Vornheder wrote:
> Am 29.08.2011 22:49, schrieb Klaus Schmidinger:
>> On 29.08.2011 22:30, Dirk Vornheder wrote:
>>>
>>>>>
>>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>>>>>> There have been some reports about recording problems with VDR 1.7.20
>>>>>> on some HD channels.
>>>>>> This patch should fix this.
>>>>>>
>>>>>> Klaus
>>>>>>
>>>>>>
>>>>>> --- remux.c 2011/08/15 09:50:14 2.58
>>>>>> +++ remux.c 2011/08/19 15:33:26
>>>>>> @@ -974,8 +974,10 @@
>>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
>>>>>> if (payloadUnitOfFrame != 0 && independentFrame)
>>>>>> payloadUnitOfFrame = 0;
>>>>>> - if (payloadUnitOfFrame)
>>>>>> + if (payloadUnitOfFrame) {
>>>>>> + newPayload = false;
>>>>>> newFrame = false;
>>>>>> + }
>>>>>> }
>>>>>> if (framesPerPayloadUnit <= 1)
>>>>>> scanning = false;
>>>>>
>>>>> Would the log messages look like this without above patch?
>>>>>
>>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
>>>>> payload - buffering
>>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>>> buffer (23312 > 940) - dropped 23124 bytes
>>>>> ...
>>>>
>>>> Those were the reports I got from users.
>>>>
>>>> Klaus
>>>>
>>>
>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge
>>> PVR-cards 500 !
>>>
>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>>>
>>> Aug 29 22:07:44 pcneu vdr: [20700] record
>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to
>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec
>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
>>> (pid=20700, tid=21580)
>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
>>> started (pid=20700, tid=21581)
>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
>>> - accepted
>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
>>> started (pid=20700, tid=21582)
>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
>>> payload - buffering
>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>> type buffer (2444 > 940) - dropped 2444 bytes
>>> ...
>>
>> Can you please provide a 1 minute VDR recording from that device (made
>> with the most recent
>> developer version that works for you) and tell me where to download it?
>>
>> Klaus
>>
>
> The upload to Sigi's FTP-Server has finished.
>
> The filename is problemvdr1720pvr3sat00001.ts !

Apparently in this file every TS packet that starts a new PES packet
has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this
should only be set for TS packets that contain the beginning of an
actual payload unit (which may consist of several PES packets).

So I would assume that the TS data is in error.

Klaus
L. Hanisch - Sept. 2, 2011, 4:07 p.m.
Am 02.09.2011 16:08, schrieb Klaus Schmidinger:
> On 30.08.2011 19:40, Dirk Vornheder wrote:
>> Am 29.08.2011 22:49, schrieb Klaus Schmidinger:
>>> On 29.08.2011 22:30, Dirk Vornheder wrote:
>>>>
>>>>>>
>>>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>>>>>>> There have been some reports about recording problems with VDR 1.7.20
>>>>>>> on some HD channels.
>>>>>>> This patch should fix this.
>>>>>>>
>>>>>>> Klaus
>>>>>>>
>>>>>>>
>>>>>>> --- remux.c 2011/08/15 09:50:14 2.58
>>>>>>> +++ remux.c 2011/08/19 15:33:26
>>>>>>> @@ -974,8 +974,10 @@
>>>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
>>>>>>> if (payloadUnitOfFrame != 0 && independentFrame)
>>>>>>> payloadUnitOfFrame = 0;
>>>>>>> - if (payloadUnitOfFrame)
>>>>>>> + if (payloadUnitOfFrame) {
>>>>>>> + newPayload = false;
>>>>>>> newFrame = false;
>>>>>>> + }
>>>>>>> }
>>>>>>> if (framesPerPayloadUnit <= 1)
>>>>>>> scanning = false;
>>>>>>
>>>>>> Would the log messages look like this without above patch?
>>>>>>
>>>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
>>>>>> payload - buffering
>>>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>>>> buffer (23312 > 940) - dropped 23124 bytes
>>>>>> ...
>>>>>
>>>>> Those were the reports I got from users.
>>>>>
>>>>> Klaus
>>>>>
>>>>
>>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge
>>>> PVR-cards 500 !
>>>>
>>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>>>>
>>>> Aug 29 22:07:44 pcneu vdr: [20700] record
>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to
>>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec
>>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
>>>> (pid=20700, tid=21580)
>>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
>>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
>>>> started (pid=20700, tid=21581)
>>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
>>>> - accepted
>>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
>>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
>>>> started (pid=20700, tid=21582)
>>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
>>>> payload - buffering
>>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>>> type buffer (2444 > 940) - dropped 2444 bytes
>>>> ...
>>>
>>> Can you please provide a 1 minute VDR recording from that device (made
>>> with the most recent
>>> developer version that works for you) and tell me where to download it?
>>>
>>> Klaus
>>>
>>
>> The upload to Sigi's FTP-Server has finished.
>>
>> The filename is problemvdr1720pvr3sat00001.ts !
>
> Apparently in this file every TS packet that starts a new PES packet
> has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this
> should only be set for TS packets that contain the beginning of an
> actual payload unit (which may consist of several PES packets).
>
> So I would assume that the TS data is in error.

  I will take a look at the PS-to-TS-code of pvrinput. When I wrote/adjust it I didn't know anything of TS and I had to 
learn a lot in a short time. Esp. adding PCR etc.

  Thanks!
Lars.

>
> Klaus
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
Andreas Regel - Sept. 2, 2011, 5:57 p.m.
Am 02.09.2011 16:08, schrieb Klaus Schmidinger:
> On 30.08.2011 19:40, Dirk Vornheder wrote:
>> Am 29.08.2011 22:49, schrieb Klaus Schmidinger:
>>> On 29.08.2011 22:30, Dirk Vornheder wrote:
>>>>
>>>>>>
>>>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>>>>>>> There have been some reports about recording problems with VDR
>>>>>>> 1.7.20
>>>>>>> on some HD channels.
>>>>>>> This patch should fix this.
>>>>>>>
>>>>>>> Klaus
>>>>>>>
>>>>>>>
>>>>>>> --- remux.c 2011/08/15 09:50:14 2.58
>>>>>>> +++ remux.c 2011/08/19 15:33:26
>>>>>>> @@ -974,8 +974,10 @@
>>>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) %
>>>>>>> -framesPerPayloadUnit;
>>>>>>> if (payloadUnitOfFrame != 0 && independentFrame)
>>>>>>> payloadUnitOfFrame = 0;
>>>>>>> - if (payloadUnitOfFrame)
>>>>>>> + if (payloadUnitOfFrame) {
>>>>>>> + newPayload = false;
>>>>>>> newFrame = false;
>>>>>>> + }
>>>>>>> }
>>>>>>> if (framesPerPayloadUnit <= 1)
>>>>>>> scanning = false;
>>>>>>
>>>>>> Would the log messages look like this without above patch?
>>>>>>
>>>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
>>>>>> payload - buffering
>>>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>>>> buffer (23312 > 940) - dropped 23124 bytes
>>>>>> ...
>>>>>
>>>>> Those were the reports I got from users.
>>>>>
>>>>> Klaus
>>>>>
>>>>
>>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge
>>>> PVR-cards 500 !
>>>>
>>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>>>>
>>>> Aug 29 22:07:44 pcneu vdr: [20700] record
>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to
>>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec
>>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
>>>> (pid=20700, tid=21580)
>>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
>>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
>>>> started (pid=20700, tid=21581)
>>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
>>>> - accepted
>>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
>>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
>>>> started (pid=20700, tid=21582)
>>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
>>>> payload - buffering
>>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>>> type buffer (2444 > 940) - dropped 2444 bytes
>>>> ...
>>>
>>> Can you please provide a 1 minute VDR recording from that device (made
>>> with the most recent
>>> developer version that works for you) and tell me where to download it?
>>>
>>> Klaus
>>>
>>
>> The upload to Sigi's FTP-Server has finished.
>>
>> The filename is problemvdr1720pvr3sat00001.ts !
>
> Apparently in this file every TS packet that starts a new PES packet
> has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this
> should only be set for TS packets that contain the beginning of an
> actual payload unit (which may consist of several PES packets).
>
> So I would assume that the TS data is in error.

I would say this is the expected behaviour as one PES packet normally is 
one payload unit. The MPEG2 standard only defines that when the PUSI bit 
is set a PES packet shall start in the payload of the TS packet. There 
is no other limitation.

Andreas
L. Hanisch - Sept. 2, 2011, 6:32 p.m.
Am 02.09.2011 19:57, schrieb Andreas Regel:
> Am 02.09.2011 16:08, schrieb Klaus Schmidinger:
>> On 30.08.2011 19:40, Dirk Vornheder wrote:
>>> Am 29.08.2011 22:49, schrieb Klaus Schmidinger:
>>>> On 29.08.2011 22:30, Dirk Vornheder wrote:
>>>>>
>>>>>>>
>>>>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote:
>>>>>>>> There have been some reports about recording problems with VDR
>>>>>>>> 1.7.20
>>>>>>>> on some HD channels.
>>>>>>>> This patch should fix this.
>>>>>>>>
>>>>>>>> Klaus
>>>>>>>>
>>>>>>>>
>>>>>>>> --- remux.c 2011/08/15 09:50:14 2.58
>>>>>>>> +++ remux.c 2011/08/19 15:33:26
>>>>>>>> @@ -974,8 +974,10 @@
>>>>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) %
>>>>>>>> -framesPerPayloadUnit;
>>>>>>>> if (payloadUnitOfFrame != 0 && independentFrame)
>>>>>>>> payloadUnitOfFrame = 0;
>>>>>>>> - if (payloadUnitOfFrame)
>>>>>>>> + if (payloadUnitOfFrame) {
>>>>>>>> + newPayload = false;
>>>>>>>> newFrame = false;
>>>>>>>> + }
>>>>>>>> }
>>>>>>>> if (framesPerPayloadUnit <= 1)
>>>>>>>> scanning = false;
>>>>>>>
>>>>>>> Would the log messages look like this without above patch?
>>>>>>>
>>>>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of
>>>>>>> payload - buffering
>>>>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type
>>>>>>> buffer (23312 > 940) - dropped 23124 bytes
>>>>>>> ...
>>>>>>
>>>>>> Those were the reports I got from users.
>>>>>>
>>>>>> Klaus
>>>>>>
>>>>>
>>>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge
>>>>> PVR-cards 500 !
>>>>>
>>>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine.
>>>>>
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] record
>>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to
>>>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts'
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory
>>>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec
>>>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started
>>>>> (pid=20700, tid=21580)
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection
>>>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread
>>>>> started (pid=20700, tid=21581)
>>>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816
>>>>> - accepted
>>>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection
>>>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread
>>>>> started (pid=20700, tid=21582)
>>>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of
>>>>> payload - buffering
>>>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame
>>>>> type buffer (2444 > 940) - dropped 2444 bytes
>>>>> ...
>>>>
>>>> Can you please provide a 1 minute VDR recording from that device (made
>>>> with the most recent
>>>> developer version that works for you) and tell me where to download it?
>>>>
>>>> Klaus
>>>>
>>>
>>> The upload to Sigi's FTP-Server has finished.
>>>
>>> The filename is problemvdr1720pvr3sat00001.ts !
>>
>> Apparently in this file every TS packet that starts a new PES packet
>> has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this
>> should only be set for TS packets that contain the beginning of an
>> actual payload unit (which may consist of several PES packets).
>>
>> So I would assume that the TS data is in error.

  Would that mean that the PUSI bit should only be set in packets where a picture start code is contained?

> I would say this is the expected behaviour as one PES packet normally is one payload unit. The MPEG2 standard only
> defines that when the PUSI bit is set a PES packet shall start in the payload of the TS packet. There is no other
> limitation.

  I just know what Wikipedia tells me... :-)

Lars.

>
> Andreas
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
Reinhard Nissl - Sept. 2, 2011, 7:37 p.m.
Hi,

Am 02.09.2011 16:08, schrieb Klaus Schmidinger:

> Apparently in this file every TS packet that starts a new PES packet
> has the "Payload Unit Start Indicator" flag set. Normally (AFAIK)
> this
> should only be set for TS packets that contain the beginning of an
> actual payload unit (which may consist of several PES packets).
>
> So I would assume that the TS data is in error.

I don't think that this assumption is correct. The playload start 
is related to carried payload only, i. e. PES packets in case of 
the video stream. And it would be sufficient to put there just a 
single byte of the PES packet to set this bit, i. e. the first 
0x00 of the start code sequence 0x00, 0x00, 0x01. Furthermore it 
is specified that no second PES packet is allowed to start in the 
same TS packet.

The PES layer itself has no access unit (= e. g. image) start 
indicator. But when a PTS is part of the PES header, it has to be 
applied to the first access unit (= e. g. image) which starts in 
that PES packet (once again, it would be sufficient to put there 
just the first byte of the start code sequence at the tail of the 
PES packet). So you may use the PTS flag as Access Unit Start 
Indicator ("AUSI"), which tells you that this PES packet will 
start a new image but you cannot tell where, i. e. it is likely 
that the PES packet will carry the tail of the previous image in 
front of the new image. Using the "AUSI" is only of hint quality 
as not every access unit (= e. g. image) will have a PTS 
attached. Some stations label only I frames while others label 
every frame or field.

In video streams, it is common use to have PES packets with a 
zero length indicator which means the TS layer has to tell you 
where the next PES packet starts. So such streams are likely to 
have just a single PES packet per access unit (= e. g. image) and 
as a result you see the TS PUSI at the same time as the PES "AUSI".

Bye.
Klaus Schmidinger - Sept. 2, 2011, 9:05 p.m.
On 02.09.2011 21:37, Reinhard Nissl wrote:
> Hi,
>
> Am 02.09.2011 16:08, schrieb Klaus Schmidinger:
>
>> Apparently in this file every TS packet that starts a new PES packet
>> has the "Payload Unit Start Indicator" flag set. Normally (AFAIK)
>> this
>> should only be set for TS packets that contain the beginning of an
>> actual payload unit (which may consist of several PES packets).
>>
>> So I would assume that the TS data is in error.
>
> I don't think that this assumption is correct. The playload start is related to carried payload only, i. e. PES packets in case of the video stream. And it would be sufficient to put there just a single byte of the PES packet to set this bit, i. e. the first 0x00 of the start code sequence 0x00,
> 0x00, 0x01. Furthermore it is specified that no second PES packet is allowed to start in the same TS packet.
>
> The PES layer itself has no access unit (= e. g. image) start indicator. But when a PTS is part of the PES header, it has to be applied to the first access unit (= e. g. image) which starts in that PES packet (once again, it would be sufficient to put there just the first byte of the start code
> sequence at the tail of the PES packet). So you may use the PTS flag as Access Unit Start Indicator ("AUSI"), which tells you that this PES packet will start a new image but you cannot tell where, i. e. it is likely that the PES packet will carry the tail of the previous image in front of the new
> image. Using the "AUSI" is only of hint quality as not every access unit (= e. g. image) will have a PTS attached. Some stations label only I frames while others label every frame or field.
>
> In video streams, it is common use to have PES packets with a zero length indicator which means the TS layer has to tell you where the next PES packet starts. So such streams are likely to have just a single PES packet per access unit (= e. g. image) and as a result you see the TS PUSI at the same
> time as the PES "AUSI".

Hmm, I guess you're right.
Looks like it was sheer luck that this change fixed the problems with
TS streams where the picture start code extends over two packets.
I guess I'll go back to the earlier version then and make sure there
are always at least two TS packets at the start of a payload to look at.

Klaus

Patch

--- remux.c     2011/08/15 09:50:14     2.58
+++ remux.c     2011/08/19 15:33:26
@@ -974,8 +974,10 @@ 
                                       payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
                                       if (payloadUnitOfFrame != 0 && independentFrame)
                                          payloadUnitOfFrame = 0;
-                                     if (payloadUnitOfFrame)
+                                     if (payloadUnitOfFrame) {
+                                        newPayload = false;
                                          newFrame = false;
+                                        }
                                       }
                                    if (framesPerPayloadUnit <= 1)
                                       scanning = false;

Privacy Policy