On 30.08.2010 02:05, Simon Baxter wrote:
>> Am 29.08.2010 15:06, schrieb Klaus Schmidinger:
>>>> DiscontinuityDetected: triggering soft start
>>> You may want to find out where this message comes from (it certainly
>>> doesn't come from the core VDR).
>> This is just an implementation detail of vdr-xine.
>>>> Why am I getting a "SetPlayMode: 0"  and  "receiver on device 2 thread
>>>> ended (pid=16557, tid=16633)"  for no reason??
>>> When a receiver is detached from a device, the play mode is set to
>>> pmNone
>>> (which is 0).
>>> My guess would be that the "DiscontinuityDetected: triggering soft
>>> start"
>>> is generated by the output device, and that causes the transfer mode
>>> to be stoped and restarted. Maybe the output device chokes on something
>>> in the TS stream?
>> I doubt that vdr-xine does anything which would cause transfer
>> mode to be stopped and restarted.
> I have the same problem (transfer mode stopping) with plain VDR (no
> plugins) and a FF card.
> i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12)
> Happy to do any captures etc - any suggestions??

The only place where a 3 second timeout plays a role that also
might cause a channel to become unavailable is in cDevice::Action(),

  // Check whether the TS packets are scrambled:

Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here.
This could be caused by recording the PCR packets since version 1.7.12.
To debug this, just disable this check, and/or put in some debug printouts.


vdr mailing list

Reply via email to