stuart wrote: > This raises the age old question of how to develop code for Mythtv. Are > you willing to run the SVN version of mythtv so as to be able to > contribute?
True, but if we're talking about Mythweb specifically, and you're not too concerned with contributing code upstream (which ideally you should be), then you've already got the PHP source and can hack away on the installed version. I suppose the same could be said for the compiled MythTV code, where you can always check out the source for whatever release you happen to be running. So I guess it comes down to how much effort you're willing to go through to be able to contribute code upstream. > My guess, people who develop mythtv code maintain two boxes. Yes, that seems like the most practical approach. Even if you wrote some scripts to automate switching between production and development versions, you'd constantly be risking interrupting scheduled recordings. Unless you can figure out how to make two MythTV installations run in parallel on one box. Perhaps a dev mode where it binds to an alternate IP address, uses an alternate database name, and treats the recording directory as read-only. Still, given the way MythTV clients have tight-coupling to the database, that'll break some clients, and at minimum require inconveniently reconfiguring clients (as someone asked about on this list recently). > The web route would be faster, but it will always leave you wanting > or adapting to different clients. (Example, look at all the web page > styles SqueezeCenter can support. I know, it looks great, but we > don't have the room.) An mvpmc command line option specifying the location of the web page that should be served up for the UI would address that. (Or more simply, the "doc root" of the mvpmc web server.) That way the end-user could have it point to a network mounted file system, which could provide a rich UI with graphics, CSS, etc. without concerns about storage space limits. It would also facilitate easier end-user hacking without necessitating rebuilding a dongle. Perhaps even lowering the effort barrier enough that the web admin UI will get that long awaited face lift. That's not to say that a CLI or other interface shouldn't be implemented as well. Just that a web UI is likely to be more immediately useful. Another option to look at would be hacking the IR receiver driver so that it can accept keystrokes from an alternate source, like a named pipe, or TCP socket. Still not a deterministic interface, but should be far easier to implement that a proper CLI. -Tom ------------------------------------------------------------------------------ _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
