Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: Curious behaviour with radio record
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
Home |
Main Index |
Thread Index