[mythtv] OSX backend beta test

[Daniel Kristjansson]

On Mon, 2006-01-09 at 08:50 -0500, David Abrahams wrote:
> As I do my refactoring, it begins to look to me as though the original
> FirewireChannel code has a few problems.  Close() doesn't seem to do
> anything, for example.  Also, if the channel failed to open,
> SetChannelByString generates an error message about having the wrong
> kind of device and then returns true.

The FirewireRecorder code is not our finest example of a recorder,
it was written by one guy who then disappeared. It was actually
impressive how quickly he got it together, but it needed on-going
care to iron out the oddities...

Look at ChannelBase, and Channel to figure out what channel should do.
If neither applies the DVBChannel class is probably doing the right
thing too, but not always. As for close it is possible that
StartRecording() is closing the file handle, this is not so nice.

> There are no documented requirements for SetChannelByString, so I
> could be wrong about what it's supposed to do, of course.  Maybe
> returning true in that case is just fine. 
It should only be returning true when it changes the channel
successfully.

>  And maybe it doesn't matter
> if Close() doesn't release the firewire handle allocated in the
> channel's Open() call.
Close should probably release the handle if it is still being held.
It looks like this is being done in the destructor instead. Since
none of the active developers are using the FirewireRecorder we can't
really change this since the assumption is that whatever is in there
now at least works to some degree.

> Also, is the Channel always allocated first?
I'm pretty sure the answer is yes.

> Is the Recorder supposed
> to work if the Channel couldn't be allocated or opened?
It is not required to. We used to try to do this, but with some
types of recorders this would be very difficult to do.

> Looking more closely, it seems like TVRec could benefit greatly by
> factoring out all the functionality that depends on genopt.cardtype
> into a family of related classes for each card type but that's a
> project for another day.
Yup

-- Daniel