Simon Hyde wrote: > ...we'd be better off accessing the data > directly over SQL than requiring some extra server-side > functionality/files. If we had to resort to SQL for normal recordings then > we might want to make it optional. > > It's nice that at the moment SQL access is only required for LiveTV.
...and commercial skip, and bookmarks, and...the list is growing. :-) But yes, I agree with both parts of your statement: use SQL and make it optional. More specifically that's mean storing a stripped down record in memory, but making an SQL query for the full details when the user requests to view the full show details page. If they didn't have SQL setup, they wouldn't see most (any?) of the details, but that's a non-critical function. > It's worth noting that a (re-encoded) version of the data in this > structure is passed back to MythTV to request playback of a recording, so > you also need to determin what data in this structure MythTV uses/needs > for file i/o. I haven't looked at the protocol, but just about everything in MythTV is keyed off of the show's channel ID and start time. > My guess would be that this is related to the different block sizes in use > for the MythTV protocol connection compared to the NFS connection... If so, then playing around with the MTU setting might help. -Tom ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
