I had a long trailing thought yesterday about a couple of items that
have been discussed in this thread and others : using embedded
databases and having multiple storage areas. They sort of overlapped
a little and I thought I would throw it up here just for people to
think about.
First, embedded databases. I've got a nice Mac laptop that goes on
the road and runs MythFrontEnd pretty well. But I can't take a
backend with me. But embedded databases might make this possible.
Think about running a slave backend on your laptop that is instructed
to connect to the master backend for its database needs, but could
fail back to a local embedded database if the master is not found.
What good would that be? Let's talk about multiple storage areas a
little.
I've got a pretty wide range of quality of recorded programs, from
analog cable to 1080i. I can't playback the 1080i on a couple of my
FrontEnds, but I don't want to transcode it down to their level, as
it does look really nice on my HD FrontEnd. So I was thinking about
file versioning. What if a "recordedprogram" could have multiple
files (looked up in related table)? Various transcodes could coexist
and could be used on different frontends. And transcode profiles
could select their own storage area, perhaps on a different backend.
Ok, there's the convergence. The slave backend could store a
particular transcode's files locally and mirror the database
information for them. A portable frontend could be disconnected from
the network and play it's local content without the master around.
Of course, synchronization issues become a nightmare pretty quickly.
What does the master do if it can't write to a remote storage area?
How does the mobile frontend get back in sync when it reconnects?
Of course, this adds the option to have a 320x240 mpeg4 transcode
profile that writes to a "put these files on my video iPod" directory.
Its not all easy stuff, or maybe not even possible in the framework
we're starting from. But something to think about. Feel free to
ignore a lurker that hasn't made a contribution yet (Yet!).
Keith C
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
