VDR-1.3.27: updated cVideoRepacker

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Simon Baxter wrote:

>>>Tried the new repacker, but it was not successful :
>>
>>Thanks for the report. Please specify some additional information:
>>
>>There are several threads involved (4972, 4969, 4970, 4968). Please send
>>the lines too, where these threads were created, respectively include
>>them in the next report.
> 
> attached

Hhm, there is nothing mentioned about these threads. I was looking for 
messages like the following:

Jul 16 23:13:02 video vdr[3153]: switching to channel 2055
Jul 16 23:13:02 video vdr[3516]: non blocking file reader thread ended 
(pid=3516, tid=507914)
Jul 16 23:13:02 video vdr[3515]: dvbplayer thread ended (pid=3515, 
tid=491529)
Jul 16 23:13:02 video vdr[3573]: transfer thread started (pid=3573, 
tid=524297)
Jul 16 23:13:02 video vdr[3574]: receiver on device 1 thread started 
(pid=3574, tid=540682)
Jul 16 23:13:02 video vdr[3575]: TS buffer on device 1 thread started 
(pid=3575, tid=557067)
Jul 16 23:13:04 video vdr[3573]: setting audio track to 1
Jul 16 23:13:14 video vdr[3153]: switching device 1 to channel 2055
Jul 16 23:13:14 video vdr[3153]: timer 1 (2055 2313-2318 '@TITLE 
EPISODE') start
Jul 16 23:13:14 video vdr[3153]: waiting for EPG info...
Jul 16 23:13:18 video vdr[3153]: no EPG info available
Jul 16 23:13:18 video vdr[3153]: record 
/video/@ASTRA_HD/2005-07-16.23:13.50.50.rec
Jul 16 23:13:18 video vdr[3153]: creating directory /video/@ASTRA_HD
Jul 16 23:13:18 video vdr[3153]: creating directory 
/video/@ASTRA_HD/2005-07-16.23:13.50.50.rec
Jul 16 23:13:18 video vdr[3153]: recording to 
'/video/@ASTRA_HD/2005-07-16.23:13.50.50.rec/001.vdr'
Jul 16 23:13:18 video vdr[3582]: file writer thread started (pid=3582, 
tid=573452)
Jul 16 23:13:18 video vdr[3583]: recording thread started (pid=3583, 
tid=589837)
Jul 16 23:13:18 video vdr[3153]: max. latency time 5 seconds
Jul 16 23:18:00 video vdr[3583]: recording thread ended (pid=3583, 
tid=589837)
Jul 16 23:18:00 video vdr[3582]: file writer thread ended (pid=3582, 
tid=573452)

Do you find any file that contains this data? On my system it is in 
/var/log/messages. Maybe you have to run vdr with debugging enabled (-l 3).

>>It might be possible, that at 08:42:04 the cVideoRepacker was resyncing,
>>e. g. due to some garbage that is comming in after switching the channel.

You wrote it happend just once so far (plus once with 1.3.26). Did you 
get some image distortions from time to time (or just rarely)?
Maybe cVideoRepacker just discovered some stream corruption that 
otherwise (= before 1.3.26) would only have been noticeable on screen.
Something like that might also be a driver issue.

>>Strange is that there are two threads (4972 and 4969) that are feeding
>>cVideoRepacker. Should there be a racecondition that spawns two threads
>>for this job somewhere else in VDR?
> 
> sorry couldn't tell you   ):

Maybe some of the missing logfile entries would put light on this issue.

>>Are you using other plugins that might attach a further receiver
>>(osd-teletext triggered some threading issues some time ago)?
> 
> -P'xine -q -r -s' -P'skincurses' -P'remote -i 
> /dev/input/event2' -P'sysinfo' -P'mplayer' -P'dvd' -P'femon' -P'clock'

I think, none of them should have any receiver active. Maybe it's just 
the transfer thread for live-TV and the recorder thread that both have a 
receiver running. What happend to live-TV at that time?

>>Thread 4968 seems to be a recorder. It considers the data stream to be
>>broken as it hasn't seen any data for MAXBROKENTIMEOUT (= 30 seconds),
>>i. e. since cVideoRepacker got synced. Please add two log messages to
>>cRepacker::Put() so that we can see how cVideoRepacker delivers data
>>after 08:42:04. Maybe a further log message at the beginning and end of
>>cVideoRepacker::Repack() would be useful too, to see whether
>>cVideoRepacker gets stuck.
> 
> happy to help, but you'll need to help me out here.  What should I be adding 
> to where?

Sorry, it seems that the below marked lines where not obvious enough. 
They have to go into remux.c, cRepacker::Put() respectively 
cVideoRepacker::Repack(). Be aware that these changes will produce big 
logfiles :-(

>>  static int Put(.....)
>>  {
>>    esyslog(">>>>> cRepacker::Put"); // <============
>>
>>    int n = ResultBuffer->Put(Data, Count);
>>    if (n != Count)
>>       esyslog(.....);
>>
>>    esyslog("<<<<< cRepacker::Put"); // <============
>>
>>    return n;
>>  }
>>
>>void cVideoRepacker::Repack(.....)
>>{
>>  esyslog(">>>>> cVideoRepacker::Repack()"); // <============
>>
>>  // synchronisation is detected some bytes after frame start.
>>  const int SkippedBytesLimit = 4;
>>
>>  // reset local scanner
>>  localStart = -1;
>>
>>.
>>.
>>.
>>
>>  // report that syncing dropped some bytes
>>  if (skippedBytes > SkippedBytesLimit) {
>>     esyslog(.....);
>>     skippedBytes = SkippedBytesLimit;
>>     }
>>
>>  esyslog("<<<<< cVideoRepacker::Repack()"); // <============
>>}

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux