[vdr] Re: Curious behaviour with radio record

[Laz <laz@club-burniston.co.uk>]

On Sunday 12 Dec 2004 20:59, kafifi wrote:
> Hello,
>
> Under vdr-1.3.17, I've recorded 60 minutes of radio emission;
> when I've tried to replay, edit and cut it, I found a curious behaviour :
> 1/ vdr is displaying only 27 minutes instead of  60 minutes.

This is a known problem with vdr: radio recordings always appear as too short 
(I think the length is simply calculated form the file size, and so the radio 
recordings always seem to be too short). I think also affects skipping back 
and forth and maybe cutting.

> 2/ in video0 directory : 001.vdr, 002.vdr, 003.vdr etc... are only 9.4 MB
> files.

See below...

> 3/ It's very difficult to edit the radio record : it's impossible to move
> thinly along the record,
> cursor is moving too fast and very irregularly.

See above!

> Do you notice this strange behaviour in radio records ?

I did and it had me confused for ages...I think the main emphasis of vdr is 
for video so a lot of the radio stuff gets neglected. All of my radio 
recordings had lots of big, regular gaps in them.

> 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