[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mythtv-dev
Subject:    Re: [mythtv] Empty and missing recording files when making multiple simultaneous dvb recordings
From:       Roger James <roger () beardandsandals ! co ! uk>
Date:       2012-06-30 20:06:22
Message-ID: 4FEF5C3E.40309 () beardandsandals ! co ! uk
[Download RAW message or body]

On 30/06/12 15:39, Steven Adeff wrote:
> On Fri, Jun 29, 2012 at 7:17 AM, Roger James
> <roger@beardandsandals.co.uk> wrote:
>> On 28/06/12 21:27, John Pilkington wrote:
>>>
>>> I posted yesterday about failure to populate the 'watch recordings'
>>> screen, but I believe this could be another instance of the problem above.
>>>   It looked as if my backend failed when asked to record four dvb-t
>>> recordings simultaneously.  I hadn't seen this before.  There had been lots
>>> of system changes, and I wondered if the tuner identification had failed, so
>>> I tried running mythtvsetup.  None of the tuners were recognised there,
>>> although dmesg showed that they had been registered. I have gone back from
>>> kernel 3.4.2-1 to 3.3.7-1 in fedora 16.x86_64 and mythtvsetup sees them
>>> again.  I didn't make any changes there.  I'm using mythtv 0.24.3 build 283
>>> from ATrpms dated 30 April.  I had made the kernel update earlier this week
>>> when a suitable nvidia module became available at ATrpms.
>> John,
>>
>> I am only seeing this particular problem since I moved to 0.25. Because it
>> is a race condition  is not to say that it did not exist but with a lower
>> probability in earlier versions. Because the backend ends up with two
>> threads deadlocked it can produce some strange symptoms in any attached
>> frontends. I have submitted a bug for it at
>> http://code.mythtv.org/trac/ticket/10870. The work round is to set any DVB
>> cards to only allow one simultaneous recording.
> is it possible this occurs in similar conditions but not for DVB? I'm
> having issues with 0.25.1 (after the hdpvr change) that sounds
> similar, and am wondering perhaps if that change in the hdpvr code is
> causing a similar condition to occur all the time when two HDPVR are
> present?
>
>
Yes,

The code is in streamhandler.cpp which is common to all the stream 
handlers. You can see if the bug affects you by turning on "record" 
logging. I do not recommend you run with turned on for long as it can 
produce very large log files. You should then schedule two recordings to 
start at exactly the same time on the same frequency (multiplex in DVB 
terms, I don't know if HDPVR has multiplexes). The error message you are 
looking for are,

"Programmer Error: Start called before Stop finished" and

"Programmer Error: Stop called before Start finished"

If you are not seeing one or the other of these messages then you are 
not getting the error.

I am currently testing  a patch which you may want to try.

roger@gatekeeper:/mnt/mythtv/fixes-0.25/mythtv/libs/libmythtv$ git diff 
streamhandler.cpp
diff --git a/mythtv/libs/libmythtv/streamhandler.cpp 
b/mythtv/libs/libmythtv/str
index 2b0a7b6..28de368 100644
--- a/mythtv/libs/libmythtv/streamhandler.cpp
+++ b/mythtv/libs/libmythtv/streamhandler.cpp
@@ -133,7 +133,8 @@ void StreamHandler::RemoveListener(MPEGStreamData *data)

  void StreamHandler::Start(void)
  {
-    QMutexLocker locker(&_start_stop_lock);
+    QMutexLocker start_stop_procedure_locker(&_start_stop_procedure_lock);
+    QMutexLocker start_stop_locker(&_start_stop_lock);

      if (_running)
      {
@@ -173,7 +174,8 @@ void StreamHandler::Start(void)

  void StreamHandler::Stop(void)
  {
-    QMutexLocker locker(&_start_stop_lock);
+    QMutexLocker start_stop_procedure_locker(&_start_stop_procedure_lock);
+    QMutexLocker start_stop_locker(&_start_stop_lock);

      do
      {
roger@gatekeeper:/mnt/mythtv/fixes-0.25/mythtv/libs/libmythtv$
roger@gatekeeper:/mnt/mythtv/fixes-0.25/mythtv/libs/libmythtv$ git diff 
streamhandler.h
diff --git a/mythtv/libs/libmythtv/streamhandler.h 
b/mythtv/libs/libmythtv/strea
index 1db0584..ae0bc80 100644
--- a/mythtv/libs/libmythtv/streamhandler.h
+++ b/mythtv/libs/libmythtv/streamhandler.h
@@ -45,7 +45,7 @@ class PIDInfo
  typedef QMap<uint,PIDInfo*> PIDInfoMap;

  // locking order
-// _pid_lock -> _listener_lock -> _start_stop_lock
+// _pid_lock -> _listener_lock -> > _start_stop_procedure_lock 
_start_stop_lock

  class StreamHandler : protected MThread, public DeviceReaderCB
  {
@@ -93,7 +93,7 @@ class StreamHandler : protected MThread, public 
DeviceReaderCB
      virtual void RemoveNamedOutputFile(const QString &filename) {}
      /// At minimum this sets _running_desired, this may also send
      /// signals to anything that might be blocking the run() loop.
-    /// \note: The _start_stop_lock must be held when this is called.
+    /// \note: The _start_stop_procedure_lock and the _start_stop_lock 
must be
      virtual void SetRunningDesired(bool desired) { _running_desired = 
desired;

    protected:
@@ -101,6 +101,7 @@ class StreamHandler : protected MThread, public 
DeviceReader
      bool              _needs_buffering;
      bool              _allow_section_reader;

+    mutable QMutex    _start_stop_procedure_lock; /// Serialises calls 
to Start
      mutable QMutex    _start_stop_lock;
      volatile bool     _running_desired;
      volatile bool     _error;
roger@gatekeeper:/mnt/mythtv/fixes-0.25/mythtv/libs/libmythtv$

Use this at your own risk.

Roger



_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-dev
[prev in list] [next in list] [prev in thread] [next in thread]