[vdr] Fix for recording problem in VDR 1.7.20

Andreas Regel andreas.regel at gmx.de
Fri Sep 2 19:57:24 CEST 2011


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




More information about the vdr mailing list