RingBuffer remains paused while dummyrec is filing it.

[danielk]

In some ways the RingBuffer? continues to work, but this causes a number of subtle problems. But most important it appears to be the cause of the UI unresponsiveness for John Pullan and Mark Spieth.

[danielk]

(In [7257]) Refs #326.

The locking for the RingBuffer? was a little more messed up than I thought. So this does not fix the problem, but simply refactors the concerned code a bit. A later commit will fix the locking.

[danielk]

The locking problem is not as easy to fix as it first appeared because we can't release that QMutex in the event loop because it is not in the thread that locks it.

But it is causing both the unresponsiveness on channel change problem and the channel change from unlocked channel problem. Basically this lock is being held when it shouldn't preventing the ringbuffer from sending data to a remote frontend, and it is also not released in certain cases on channel changes when there is no signal.

I'm not sure if pthread mutexes have this restriction but QMutex objects can only be unlocked by the thread that locked it so RingBufferInfo::Unpause() must be called by the same thread that calls RingBufferInfo::Pause() or it simply doesn't unlock the mutex...

[danielk]

(In [7258]) Refs #326.

This changes the implementation of Pause() and Unpause() so that Unpause() can be called from a different thread than Pause(). This still doesn't fix the problem, but simply makes possible to fix the problem in TVRec.

[danielk]

(In [7259]) Refs #326.

This partially fixes the problem. This properly shuts down signal monitoring on channel changes or when you exit the recorder when you haven't gotten a lock.

This also increases the time between signal checks from 50 ms to 250 ms. I hope to lower this again, but this should make debugging this problem a little easier.

I think to fully fix this we first want to unify the tuning process on channel changes and the initial/non-LiveTV tune. This would also fix some longstanding problems with the LiveTV code, such as bttv picture settings being set in a different place after a channel changes than on initial tune in LiveTV mode. And remove code duplication in the DVB/ATSC handling.

[danielk]

This is fixed, but I'm not terribly happy with the fix.

The tuning process is just way to complicated, I'd like to break it up into states and handle it all in one thread. Right now it takes place in three different threads. The pause locking I implemented makes this possible, but really it would be better to do the tuning in different states from within the RunTV loop, with multiple states that allow each portion of the tuning to be quick, but also don't require the 'abort' support or shutdown of the tune last from within Pause() when there isn't a signal, etc.

If you changed the channel or exited the program you would just have to fallback to the untuned tuning state and then work your way back up to [re]starting the recorder. Now we have one tuning process before you start the recorder, another one after you start it (channel changes), and yet another process when you tune for the EITParser's passive EIT scan (where the recorder is not started).