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(), under // 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. Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
