[vdr] Re: Curious behaviour with radio record

["kafifi" <kafifi@easyconnect.fr>]

> Is it a bug of vdr under radio record, or did I missed something ?

Fix reported back in November but it has yet to make it in to vdr:
http://www.linuxtv.org/mailinglists/vdr/2004/11-2004/msg00081.html

The changes to remux.c which occurred about vdr-1.3.15 split the 'process'
function into separate 'get' and 'put' threads and this broke radio
recordings. The synced variable is never set in cRemux::Get becuase the
function returns before setting it if there is no video stream, i.e. a radio
channel. Obviously, A/V/ sync makes no sense for an audio only channel but
the cRemux::Put function bails out if no sync is found and vdr restarts with
a "ERROR: no useful data seen within 10 MB" error. This is why you get many
files from one recording, a new one each time it restarts.

The solution I worked out was to force synced = true for radio recordings: I
can see no bad effects from this, apart from the aesthetics of it being
impossible for it to be synced in practice!

--- remux.c.orig        2004-10-24 10:25:33.000000000 +0100
+++ remux.c     2004-11-03 10:43:41.000000000 +0000
@@ -541,6 +541,8 @@
      // XXX actually '0' should be enough, but '1' must be used with
encrypted c
hannels (driver bug?)
      // XXX also allowing 0x1FFF to not break Michael Paar's original
patch,
      // XXX but it would probably be best to only use '0'
+     // Force syncing of radio channels to avoid "no useful data" error
+     synced = true;
      if (PictureType)
         *PictureType = I_FRAME;
      return resultBuffer->Get(Count);

Some of the line numbers may have changed (that was for vanilla vdr-1.3.15)
but it shouldn't be hard to patch by hand.

Since patching this, I have had no problems with radio recordings.

Cheers,

Laz
=====================================================

Hi,

Thanks a lot for this very detailed response ! I am going to try this patch.
I hope that Klaus will add the fix in next vdr's release.

Regards.
Karim